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