> -----Original Message-----
> From: Paul Vixie [mailto:[EMAIL PROTECTED] 

> site-local was deprecated because nobody could agree what a 
> "site" was, which
> in other words means it's down under the same swamp we are 
> now waist deep in.

Okay, I'll gladly agree on both points.

> so my previous question stands.  what's a "site"?

My not-well-articulated point was: if everyone seems to have made RFC
1918 work quite well, why do we need to get overly precise in this time
around?

As far as my own preferences go, I liked site-local and I equally like
mind ULA-Cs with some flexibility. Even though I have no fool-proof
definition for what a "site" is, that covers all possible examples. I've
no trouble at all establishing boundaries for private IPv4 addresses or
for ULA-Cs, when it makes sense for whatever I'm doing.

Is this a little like the RH0 thread? When it was a choice of disabling
by default or removing entirely? My vote is, don't forward ULA-Cs by
default, but let us use them as we used RFC 1918. It was also my vote
when we were discussing site-local.

If we get more restrictive about ULA-Cs, my bet is that something else
will morph to take their place (and the place of site-local addresses).
I guess people just like to have this tool.

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to