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