> In a nutshell, the point you are trying to make is that RFC1918 > addresses are bad because NAT exists.
no, that's missing the point. use of RFC 1918 addresses in a network that can also use global Internet addresses is harmful regardless of whether that connection to the global Internet uses NAT or whether it is merely via a router that filters traffic to/from the 1918 addresses. NAT is irrelevant to this particular problem. The problem is that in the presence of either 1918 or SLs applications have to deal with a mixture of scoped and global addresses without any good way of knowing whether such an address is valid (and whether it means the same thing) in the context of a particular node. > Now, let's *not* generalize and say > 1. site-local = RFC1918 > 2. site-local is bad because RFC1918 is bad. sorry - the two are quite similar, and they cause similar problems for apps. > >> I think this is a terrible idea. I can envision many > >> situations where a host would need both a site-local > >> and a global address. > > > please, elaborate. I haven't seen a good one yet. > > A somehow isolated subnet, where most hosts would have site-local only > addresses, except for a gateway or proxy that would have both. that's what 1918 was intended for. again, I don't have a huge problem with it as long as the apps don't have to deal with multiple scopes - but experience with 1918 predicts that that's exactly what will happen. > > you're missing the burden that having a mixture of SLs > > and globals puts on apps. > > You are missing the point, IMHO. This is not your call nor mine. > Site-local addresses do exist, been there for long, some people will > purposedly choose to use them in combination with global addresses. As > of today, the address selection draft addresses use of site-local and > global addresses simultaneously and I do not see a reason to change it. IETF's job is to try to explain what will make the network work well. Imposing constraints on the use of SLs will help the network work better. If SLs are encouraged as in the current draft it will degrade the ability of the network to support applications. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
