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@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>