> > > 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. > > Which just means that we need to provide a way for the application / > library to return appropriate addresses.
no, it doesn't solve the real problem. putting SLs in a separate space will keep existing apps from being confused by them, but it won't supply global addresses when they are needed, it won't provide a way for appst to recognize and deal with scope boundaries, and it won't stop sites from requiring apps to recogize the new addresses and use them even though they're a tremendous pain in the wazoo. and as I keep saying, DNS is just one example of an application that provides address referrals - are we going to impose the same amount of additional complexity on every app that does this? > Make SL work rather than > saying "kill them" or "don't put them in the DNS". the best way to make them "work" is to make them global. > Site locals provide a solution for a certian problem space. pray tell, what is that problem space? especially if you eliminate the bogus argument that they somehow provide security or relieve devices of the need to provide security. long-lived connections, perhaps. that's all I've seen so far. > They > do create additional problems but they are not insolvable problems > and are no different to the problems causes by LLs. LLs do cause similar problems. but at least LLs have a use case - bootstrapping, autoconfiguration, router and neighbor discovery, ad hoc networks. those are compelling enough that it makes sense to say "keep LLs but don't use LLs except for those specific cases". I'm still looking for a compelling case for SLs. > You need a function that looks up names and returns addresses along > with the scope_id. We have that in getaddrinfo(). You need a > function that takes a address and a scope_id and returns the name. and you need for apps to know which addresses work in which scopes, and to know which scopes each node can access, and to keep track of each node's scopes so that they'll know how to do referrals, and how to route messages across that maze of scopes. and to do that you need a global scope space. suddenly 128 bits isn't enough for an address any longer, because we also need a scope id to disambiguate scoped addresses. why don't we just make IPv7 with 256 bits of address, and assign 128 bits for a global scope id? are we having fun yet? 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] --------------------------------------------------------------------
