Margaret Wasserman wrote: > Hi Tony, > > At 09:44 AM 4/30/2003 -0700, Tony Hain wrote: > >What many are missing here is that this is not about 1918 style > >addressing. This is about the fact that addresses do not > have the same > >visibility and accessibility throughout the network. This > operational > >reality causes the affect we have labeled scoping. > > There are three ways in which a particular address can be non-global: > > - Unreachable: The address can be unreachable from some > portions of the network (due to filtering, network > failures, etc.). > > - Not Globally Routed: There can be no route to the address > from some portions of the network. > > - Not Globally Unique (AKA Ambiguous): A single address can > indicate one node when it is used in one part of > the network, and a different node when it is used > in other parts of the > > It is an inevitable fact of physics that some addresses will > be unreachable from some parts of the network. The > widespread use of filtering/firewalls makes this both > intentional and common. Applications must deal with this > (either well or badly), because there is no other choice. The point is they don't when they claim to be passing around 'opaque identifiers', at the same time they are explicitly assuming the content of that opaque object is a valid topology object at the receiver. > > If the only way to get a globally routable address is to get > it from your provider, people may choose to use addresses > that are not globally routed for some purposes, such as > convenience or provider-independence. > > I have not heard any compelling operational requirement for > ambiguous addresses in IPv6. According to the definition above, anycast is one such case. Given that anycast is in daily operational use, there must be a requirement for addresses to refer to different physical devices in different parts of the network. > > The IPv6 scoped addressing architecture defines addresses > that have all three of these properties, and this is what I > hear when you say "scoped addressing". There could be types > of local addressing, though, that don't have all of these properties. > > If you are using the term "scoped" addressing to refer to > something other than the type of addressing defined in the > IPv6 scoped addressing architecture, could you define your term? I have been attempting to be very explicit about separating the third point from the other two. As my note to Ofer showed, the issues raised by a mismatch in expectations, about the validity of different members in list of addresses, apply independent of any discussion about multiple networks using the same prefix. > > Thanks, > Margaret > > P.S. There were some proposals to remove (or lessen the > likelihood of) ambiguous site-local addresses, but none of > those proposals removed the restrictions from the IPv6 scoped > addressing architecture that are only required because > addresses are ambiguous (sites can't be nested or overlap, > zone IDs are needed to disambiguate, etc.). They didn't propose an end to world hunger either. Personal drafts don't necessarily reflect community thought and input on a topic, and may fail to cover all possible edits needed in other documents. We have technical examples of ways to remove ambiguity from the discussion, but there is still a group that wants to eliminate SL. By taking item 3 off the table, that desire must be related to the other two. There is a strong desire to kill anything that is related to the first two since they collectively expose the bogus assertion that the 'opaque identifiers' have an unknown value by the application, but (wink, wink) we really know they contain a topology locator that the receiver will use because resolution services are too slow. I have no problem with applications passing these around as long as they make sure the 'opaque contents' matches the network topology. If they don't want to go the the effort required to do that right, they need to be passing around labels so the receiver can construct a topologically correct list. Tony