On Fri, 25 Oct 2002, Bound, Jim wrote: > I think this is a reasonable proposal. With these guidelines stated > somewhere it will prevent most problems.
Agree. > 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. This would be relatively easy to do, I suppose. But note that there is (currently) more than that: site-border routers must also check source addresses of packets and drop them. This may get difficult as you have to have a way of configuring the fact that this is indeed a site border. This can't really be solved by adding a route.. (Note I meant site/global border with site border above, not two different sites) > > -----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] > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
