ietf
[Top] [All Lists]

Re: A simple question

2003-04-19 16:59:16
Folks,

RE> First, they're clearly of local use (defined in the
RE> architecture), hence if they do leak, at least it is obvious what is
RE> happening.

And, yes, that sounds like 1918, for which there are no new
requirements.

oh. but wait. we *have* been given new requirements, including the
suggestion that applications now need to know about different kinds of
addresses.

Forgive me, but I do not recall that requirement being imposed in the
days of 1918, and could have sworn that it was something new. Such a
requirement only comes from a significant change to the architecture,
and that was my original contention.

(I really do wish folks would check their various *-bashing arguments at
the door.  I have no desire to re-live diatribes against NATs or even
1918, though it's worth noting that those caveats in 1918 only got there
because a few of us put up a fuss at the time.  At any rate, the
question at hand is about new-vs-old architecture, so could we please
focus on it?)


RE> Is not true for site locals, as no-one anticpiates that a SL address is
RE> all an enterprise will be using

And since that was also true in IPv4, we have nothing new, right?

Oh.

You mean SLs are only interesting because they derive from a very new
architectural feature, and we are only now trying to think through the
implications, and those implications are turning out to be widespread?

So, folks, could we please return to the content issue I tried to raise:

DC> site local is, in fact, an addition to the IP architecture and that is
DC> what is causing the controversy.  For example, it has prompted the
DC> suggestion that applications be made to know the difference between site
DC> local vs. global IP addresses.
DC>
DC> When we go around making basic additions to an architecture, we should
DC> try to be very clear on how it will be used, how it will impact the rest
DC> of the architecture, and what the benefits and problems are likely to
DC> be.



RE> is not true of SL addresses, as one doesn't "renumber" them, one just
RE> augments with a global address.

I like the "just". As in, one "just" re-design the Internet's applications.


RE> You may notice that it isn't *just* site locals that provide the cleanup
RE> here, it is the whole IPv6 architecture, considered as a whole.

Dandy.  Glad to move my query to the "as a whole".  Any relevant list of
benefits and detriments will be a constructive start.

However not just idealized, conceptual benefits, but thinking that shows
some dirt under the fingernails, from foraging through the messy details
of making this stuff work in a real-world system.

My own guess is that the implications have *not* been drawn. Hence
roughly 9 years years after the first draft of IPv6, we get broad
suggestions to make applications know about different kinds of
addresses.

The other requirement for differential address handling -- local-net vs.
routed -- is handled at the IP layer and is invisible to applications.
It is computationally cheap and offers a very, very big benefit, by
avoiding the choke-point hop through the local router.

Someone needs to provide a similar analysis for SLs, or any other sort
of major change to the architecture.

For example, note that dropping header checksums from IPv6 was, shall we
say, a rather astonishing suggestion, but Deering readily produced very
solid arguments for the benefits and very solid arguments showing a lack
of detriments.

Why is it unreasonable to expect the same for other such changes?


d/
--
 Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>