Daniel Senie wrote:
... The IPv6 mechanism to give hosts a-priori
knowledge that the "site local" block is flawed in that it
cannot truly
provide the scoping information, since it does not address
the wider issues
associated with administrative address scoping.
You assume an outcome ('flawed') without first discussing the full set
of requirements.
...
There will remain a need and desire for private address
space, be that the
assigned "site local" block (without the "special treatment" in the
stacks), RFC 1918 space, or a combination. I think it would
be useful to
decouple the issue of the special treatment of the Site Local
address block
from the religious war over whether private address space and other
mechanisms sometimes associated are beneficial or not. In
reviewing the
recent discussion, it is clear the two are being intertwined, and it
appears to be adding to the heat, and producing no light.
I have no argument with discussing them separately, as long as we don't
end up with the usual discussion where it is the private address space
causing the problems. There is a general lack of recognition that
private addresses only exposes the underlying mis-match in the
perceptions of scope.
Separately, if there is genuine interest in addressing the
scoping problem,
I suggest that be addressed separately.
Reset your clocks to 1995 ...
A proper effort might encompass
mechanisms to deliver indications to applications as to the scoping
limitations causing communications to be blocked, as well as
wire protocol
issues to carry such signalling.
You assume such signaling would somehow solve the problem of A using a
literal referral to C that Bl is the address it is using, when C can
only see Bg. How is A supposed to know that Bl has a scope limitation
when it can get there without receiving any signaling? How is the
infrastructure supposed to know that A intends to tell C a literal
address rather than a name? If Bl & Bg had indicators of scope
differentiation in the prefix, A could recognize the difference if it
bothered to look. It wouldn't have to, but if it didn't it would either
have to refer the name, or provide C with the entire list so it could
figure out which one works. Brian's C000 thread was exploring this
space.
In a broader sense, there is a need to
deal with signalling issues as well. There are network
operators, firewall
vendors and network administrators who've been taught ICMP
packets are
inherently dangerous and must be filtered. The work output of
such efforts
should span the Internet Area producing standards track documents to
specify how to properly implement mechanisms in hosts, routers and
firewalls, and the Operations Area to provide BCPs giving guidance to
network administrators and service providers on the
operational needs of
such issues.
I agree education is appropriate. Part of that is educating the
application development community that the real network has addressing
with limited scopes of relevance, so blindly assuming a flat routing
space and passing around topology specific information will result in
broken apps.
Tony