I think this is a reasonable proposal. With these guidelines stated somewhere it will prevent most problems. But in routing code I would as implementor check if a site came in at me and if globally connected drop the packet and not let thru default route. /jim
> -----Original Message----- > From: Margaret Wasserman [mailto:mrw@;windriver.com] > Sent: Friday, October 25, 2002 3:41 PM > To: [EMAIL PROTECTED] > Subject: Re: Node Requirements Issue 3 > > > 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. > > 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 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, 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). > > 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... > > 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. 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. > > This is my personal opinion, not a directive from the chairs > or anything like that. > > Margaret > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
