I agree this version is fine and needs to be out the door already. There area a number of conflicting trade-offs in address management and as such there will never be a one-size-fits-all solution that the IESG seems to so desperately want. This document spells out a need, discusses alternatives then shows how to fill it, and explains why this approach should not be used to solve unrelated problems. There is nothing more it can do so it is time to ship it.
Tony > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Brian E Carpenter > Sent: Monday, January 17, 2005 1:50 AM > To: Brian Haberman > Cc: Bob Hinden; IPv6 WG > Subject: Re: Proposed update to ULA Draft (-09) > > I support this version. Although I don't fully agree with > the concerns expressed by some IESG members, I think this > new version is quite OK, and the quickest way make ULAs > available to networks that need them. > > Brian > > Brian Haberman wrote: > > IPv6 WG, > > > > In order to resolve the last IESG discuss comment on the ULA draft two > > sets of changes are proposed. Sam Hartman, who holds the Discuss, has > > reviewed these changes and said these proposed changes resolve the > > Discuss. The changes are: > > > > o Removed all mention of centrally assigned IPv6 local address > > addresses based on IESG comments. L=0 is left to be defined in > > the future. > > > > o Added new section titled "Global Routing Considerations" that > > discusses the issues relating to why using these addresses for > > general purpose unicast address on the global internet is not a > > good idea. > > > > An updated draft with the proposed changes can be found at: > > > > http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr > > -09.txt > > > > along with an diffed version (-09 vs. -08) at: > > > > http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr > > -09.html > > > > (Note the htmldiff that was used to produce the html diff file got a > > little confused in places, but it is still useful to see the changes). > > > > The new section 5.0 is also attached inline below. > > > > We wanted the working group to review the proposed changes before a new > > version was submitted. > > > > Thanks, > > Bob Hinden / Brian Haberman > > IPv6 working group chairs > > > > ---------------------------- > > > > > > 5.0 Global Routing Considerations > > > > Section 4.1 provides operational guidelines that forbid default > > routing of local addresses between sites. Concerns were raised to > > the IPv6 working group and to the IETF as a whole that sites may > > attempt to use local addresses as globally routed provider- > > independent addresses. This section describes why using local > > addresses as globally-routed provider-independent addresses is > > unadvisable. > > > > 5.1 From the Standpoint of the Internet > > > > There is a mismatch between the structure of IPv6 local addresses and > > the normal IPv6 wide area routing model. The /48 prefix of an IPv6 > > local addresses fits nowhere in the normal hierarchy of IPv6 unicast > > addresses. Normal IPv6 unicast addresses can be routed > > hierarchically down to physical subnet (link) level and only have to > > be flat-routed on the physical subnet. IPv6 local addresses would > > have to be flat-routed even over the wide area Internet. > > > > Thus, packets whose destination address is an IPv6 local address > > could be routed over the wide area only if the corresponding /48 > > prefix were carried by the wide area routing protocol in use, such as > > BGP. This contravenes the operational assumption that long prefixes > > will be aggregated into many fewer short prefixes, to limit the table > > size and convergence time of the routing protocol. If a network uses > > both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these > > types of address will certainly not aggregate with each other, since > > they differ from the most significant bit onwards. Neither will IPv6 > > local addresses aggregate with each other, due to their random bit > > patterns. This means that there would be a very significant > > operational penalty for attempting to use IPv6 local address prefixes > > generically with currently known wide area routing technology. > > > > 5.2 From the Standpoint of a Site > > > > There are a number of design factors in IPv6 local addresses that > > reduce the likelihood that IPv6 local addresses will be used as > > arbitrary global unicast addresses. These include: > > > > - The default rules to filter packets and routes make it very > > difficult to use IPv6 local addresses for arbitrary use across > > the Internet. For a site to use them as general purpose unicast > > addresses, they would have to make sure that the default rules > > were not being used by all other sites and intermediate ISPs > > used for their current and future communication. > > > > - They are not mathematically guaranteed to be unique and are not > > registered in public databases. Collisions, while highly > > unlikely, are possible and a collision can compromise the > > integrity of the communications. The lack of public > > registration creates operational problems. > > > > - The addresses are allocated randomly. If a site had multiple > > prefixes that they wanted to be used globally the cost of > > advertising them would be very high as they could not be > > aggregated. > > > > - They have a long prefix (i.e, /48) so a single local address > > prefix doesn't provide enough address space to be used > > exclusively by the largest organizations. > > > > --------------------- > > > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
