On Wednesday, March 26, 2003, at 01:38 PM, Tony Hain wrote:
Ted Hardie wrote:
There is a long and "interesting" history here, but it isn't
directly
relevant
to this discussion. I think it would be valuable to focus the
discussion on Site Local,
rather than on RFC 1918 space.
The reason for bring 1918 into the discussion is that prior to NAT,
there was a market demand for private address space. That demand hasn't
gone away, and the non-NAT users of that space are completely
disenfranchised in this discussion because they have seen no need to
worry about it given there is a comparable space defined for IPv6.
I'm not sure I agree that there was ever a non-scarcity induced market
demand for private address space in the pre-RFC 1918 days, but I'll
concede it for the sake of argument. I think we then to consider
whether
the current need is for:
"non-routed globally unique space"
or for something else. If the answer is "non-routed globally unique
space",
then the follow-on question is "Why not get globally unique space and
simply
decide not to route it?". If the market demand is for something else,
then I'd
appreciate a concise statement of what it is.
I am not arguing that every app need to know about topology. If this is
such a big deal, we should simply fix the API so that by default it
only
returns global scope addresses, then add a new function for those apps
that are interested in the limited scope. This doesn't sound like
rocket
science, and the arguments against it are coming across like 'we don't
want to change because it is too much work'. Rather than argue that
nobody can ever use a new feature, the basic approach should be that
you
don't have to unless you want to.
I'm sorry that the arguments against it are coming across like "we don't
want to change because it is too much work". That is certainly a part
of
the reaction, but the underlying reason is actually that the model
doesn't
fit the Internet architecture as the apps understand it.
As I tried to note in my first response, I agree that it is possible to
*change* the
assumptions about the app's layer knowledge of topology, but the reasons
given for the need seem remarkably weak in the light of such a basic
change.
To put it bluntly, this is not a new feature that requires a tweak to
some
ur-API. This change requires apps to understand address scope,
and to understand it in a totally new way.
Again, I urge folks following the discussion to read Margaret's draft.
regards,
Ted Hardie
Margaret's presentation, for those not at the APPs open area, was
derived from her
draft, found at
http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-
02.txt.
See especially section 3.7.