2. Several folks stumbled over the wording (in section 1.0) that "applications may treat these address[sic] like global scoped addresses". How about:
"Applications may treat these addresses like global scoped addresses; such applications will function correctly within the reach of the local addresses. Sites using a mixture of Globally Routable and Local addresses may experience sub-optimal application behaviour, see sections 8.0-10.0 for further discussion".
I think this will only confuse people who aren't aware of all the details. But the problem is more fundamental than wording issues anyway. The problem is that there are two types of uses for local addresses:
1. To number systems/interfaces that are only accessible from withing the local network.
2. To have stable addresses for systems/interfaces regardless of intermittant external connectivity and renumbering.
In the case of 1. the scope is site local, although the difinition of "site" may be subject to change. Being able to route these addresses throughout the internet would be more of a drawback than a usable feature, as packets using these addresses may not enter or leave the network. In the case of 2. having the addresses be globally routable throughout the internet would be extremely desirable: having addresses that are stable within the site is good, having addresses that are stable throughout the net is even better.
If we recognize that unique local addresses will be used in both capacities and there is a significant chance that a locator/identifier separation mechanism could make these addresses globally usable (if not immediately routable), then it's obvious there are going to be problems. For instance, coming up with relatively simple filters that accommodate both uses of the addresses at the same time would be a big challenge. Having to change the default filtering policies that come with the OS for huge numbers of boxes would be another issue.
I think that either it must be explicitly stated which type of addresses we're talking about here. It would probably be best to only specify type 1 and see what can be done for type 2 with locator/identifier separation mechanisms.
4. Regarding DNS; there were some comments regarding RFC1918-style lookups. I assume the concern was regarding reverse lookups (the 1918 root server load issue). However, the Local addresses in this draft are unique (FC00::/8) or nearly unique (FD00::/8). As such there is really no reason not to allow reverse lookups for FC00::/8 in the global DNS.
It would make sense to delegate authority for the "nearly unique" type to a set of anycast addresses so that people can provide reverse mapping information for their own local address ranges through DNS servers listening to those anycast addresses.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
