On Tue, 12 Jun 2007 15:36:42 -0400 "Manfredi, Albert E" <[EMAIL PROTECTED]> wrote:
> > -----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? > RFC1918 doesn't work well at all because it creates overlapping / duplicated addressing, and NAT, with all it's worts, is the only way, other than renumbering, to overcome that if you need to interconnect. It's as ugly as sin to see multiple NAT boxes facing each other when you have 2 (or more ! - and this happens at corporate DMZs when building "extranets" to other corporates) duplicate RFC1918 addressing domains that have to be interconnected. RFC3879, "Deprecating Site Local Addresses" describes the reasons why site-locals were deprecated, but all those reasons are fundamentally problems that have and do occur with RFC1918 addressing in IPv4. At least with IPv6 we have a chance to avoid them. Having had to deal directly with some of those reasons myself when working with IPv4, I certainly don't want to go there again in IPv6 if possible. > 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. > I agree. I don't think it is that hard to decide on the boundry. I think fundamentally the thing that is trying to be avoided is that ULAs become considered "cheap" or "free" PI addressing, and then having their reachabilty scope slowly increase overtime e.g. initially your own network, then the networks you directly peer with, then the local city or other continent etc. Regards, Mark. > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
