draft-ietf-v6ops-addcon-02.txt

IPv6 Unicast Address Assignment

Considerations

Olaf Bonness, Tim Chown, Christian Hahn, Ciprian Popoviciu,

Gunter Van de Velde

IETF 67, November 6th 2006San Diego, CA

draft-ietf-v6ops-addcon-02.txt

Agenda Document Overview Changes made based on WG feedback since

version 01 General addressing design considerations Enterprise Case study Service Provider Case Study

Next steps

draft-ietf-v6ops-addcon-02.txt

Document Overview

This draft aims to provide considerations on planning addressing aspects of IPv6 deployments

This draft also provides Case studies of address plans for different kinds of networks: Enterprise and Service Provider

draft-ietf-v6ops-addcon-02.txt

Document Overview (cont.)

Planning considerations discussed within various scopes Network level (Section 2) Subnet level (Section 3) Host level (Section 4)

Case Studies (Section 5) Enterprise Considerations – University of

Southampton Service Provider Considerations

draft-ietf-v6ops-addcon-02.txt

Changes from v01 based on WG Feedback and Discussions

Sections 2, 3 and 4 ("Network, Subnet and host level addressing design considerations"): Since v01 only editorial changes Clarified deprecation of 6bone addresses Added remarks about (piloting of) IPv6 PI addresses by ARIN

and clarified, that ideas of addcon I-D are independent of nature of used address block (PI or PA)

Some remarks/clarifications regarding use of ULAs for internal network addressing

draft-ietf-v6ops-addcon-02.txt

Changes from v01 (continued)Enterprise considerations

Section 5 had most enhancements based on WG feedback

Chapter 5.1 ("Enterprise considerations"): Wording Added note that public IPv6 address space could solve some

problems of networks with only private IPv4 address Underlined that IPv6 unicast-prefix-based Multicast addresses

have some advantages for sites without own ASN (and hence not being able to use GLOP) to generate globally unique Multicast addresses to use

Added more text regarding the usage of DHCPv6 for address delegation within an Enterprise network scenario (also with the background that RFC 3041 addresses are not always desired)

draft-ietf-v6ops-addcon-02.txt

Changes from v01 (continued)Service provider considerations

Chapter 5.2 ("Service provider considerations") received most/major changes

Some general remarks: Tried to clarify, that we can only describe some basic

addressing design considerations and not a "One size fits all" solution for every kind of SP (small / large, MPLS / routed, …)

Restructured chapter 5.2: Separated more strongly between general considerations

regarding ISP addressing schemas and the exemplary sketched addressing schema of an MPLS-based ISP Requirements (LIR, NAP and ISP perspective) Thumb rules Exemplary SP addressing schema

draft-ietf-v6ops-addcon-02.txt

Changes from v01 (continued)Service provider considerations

Newly inserted - Basic "Rules of Thumb": Tried to derive a handful of general "thumb rules" from the

requirements section of service provider considerations1. No "One size fits all"2. # of aggregation levels within the SP addressing schema

- should correspond to implemented network infrastructure - influences strongly the number of customer routes inside the SP network.- decreases the efficiency of the addressing schema

3. The SP addressing schema should provide maximal flexibility regarding changes in network topology and customer needs.

4. SPs own infrastructure should be addressed in a fairly flat way.

draft-ietf-v6ops-addcon-02.txt

Next Steps

Please provide your feedback on the changes / the whole document to the list and the editor team

After that: Document ready for WG Last Call?

draft-ietf-v6ops-addcon-02.txt

THANK YOU!