> At 12:17 PM 10/24/02, Margaret Wasserman wrote: > > >I think that we should keep site-local addresses in the > >addressing architecture, but limit their use to non-globally- > >connected IPv6 networks. > > Some folks have pointed out that it might have been helpful if > I had explained my reasoning... > > The addressing architecture currently defines a set of addresses > that are allocated for use as "site-local unicast addresses", but > it does not discuss the details of when or how those addresses can > or should be used. > > The scoped addressing architecture document defines how site-local > unicast addresses (and other scoped addresses) will be used, and > defines node behaviour related to these addresses. I am suggesting > that we should consider placing some restrictions on the _use_ > of site-local addresses in the scoped addressing architecture > document.
that sounds reasonable. at least we should say that site-locals cause problems for some kinds of applications, we don't have good solutions to those problems yet, and we discourage use of site-locals until such problems are solved - and even then we don't know how well they will work with apps that aren't aware of SLs. IMHO we should also make similar statements about link-locals. > However, it is imperative that the site-local address allocation > remain in the addressing architecture, even if we do decide that > the use of these addresses should be restricted (or even forbidden). > The allocation has been there for several years, and there are some > implementations that recognize these addresses. I certainly don't want to make SL addresses available for other uses - having them be labelled 'reserved for site-local use if we ever figure out how to use them sanely' makes sense to me. > I also believe that it is apporpriate for the node requirements > document to indicate the minimal acceptable support that a node > should have for site-local unicast addressing. > > In my opinion, we should limit the use of unicast site-local > addresses to non-globally connected sites, I think we should limit them to sites that aren't connected to other IP networks using IP. If host H1 is on a network N1 that uses site-locals, and host H2 is on a network N2 that connects to both N1 and the public Internet, then an app that employs both H1 and H2 and perhaps other hosts on the Internet will have problems dealing with SL addresses from N1. > and have the following > requirements for IPv6 nodes: > > - Hosts do not have to be aware of site-local addresses > at all (treat them just like globals). > - Routers do not have to be aware of site-local > addresses at all (treat them just like globals). also: Applications should not have to be aware of SL addresses at all (just treat them like globals). > I do understand that, even if we do make this restriction, there may > be some people in the world who will later insist on using site-local > addresses (or other allocated private addresses) to build > a private address space within a globally connected IPv6 network. > I also understand that those people may build a kludge tower to > support this, similar to the IPv4 kludge tower needed to support > NAT, but with the added twist that a single node may have both > private and global addresses (yum!). However, I don't think that > the IPv6 WG should go down the rat-hole of documenting that kludge > tower... right. and we would do well to discourage that kludge tower, and also to identify better ways to solve the problems that the kludge tower was attempting to solve - easy renumbering (IPv6 is better but we're not there yet), efficient access via multiple providers (there are lots of limitations with advertising multiple prefixes), security, privacy, ease of configuration, etc. > Instead, I think that we should advocate a position where all > nodes on globally attached networks have global addresses, and > site-local addresses are only used on non-globally connected > networks. I don't think that's sufficient. We need for all nodes on all non-isolated networks to have global addresses. It's becoming increasingly common for private networks to interconnect to other networks which may or may not be attached to the public Internet. We need for applications to be able to cope with operating across both private and public networks. That doesn't mean that such applications should route data between private networks and the public internet or between private networks that don't explicitly connect to one another, (e.g. the app shouldn't try to circunvent access controls). on the contrary, the app should be able to trust the addresses to be globally unique and to trust the network to be able to route packets from any source to any destination if the network's policy permits. unless the app is explicitly configured to do otherwise (as in a proxy that permits limited access across a firewall), it shouldn't have to build its own addressing and routing system. > This would work with the currently documented IPv6 > routing protocols, would provide the easiest IPv4->IPv6 transition > for applications, and would not require changes to DNS. This also > has the advantage of limiting the problem that the IPv6 WG is trying > to solve, which should allow us to finish up the base IPv6 documents > and confidently deploy IPv6. > > In my opinion, IPv6 does not require support for private > site-local unicast address spaces to be successful. The major > benefits of IPv6 are a larger address space (which should eliminate > some motivations for using private address spaces) and host > autoconfiguration, and I think that the world is already preparing > to deploy IPv6 based on those current advantages. > > I _would_ support an effort to start a separate IRTF or IETF WG > to explore whether we can build an architecturally sound model for > private and global addresses to co-exist on the same network > and in the same nodes, but I would prefer not to invent that > model in the IPv6 WG and build it into the core of IPv6. sounds reasonable, provided such a WG or RT were populated with a healthy balance of layer 3 and layer 7 folks. 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] --------------------------------------------------------------------
