Subject: RE: Node Requirements Issue 3

From: "Bound, Jim" <[email-masked]>
Date: Fri, 25 Oct 2002 19:49:30 -0400

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:[email-masked]] 
> Sent: Friday, October 25, 2002 3:41 PM
> To: [email-masked]
> 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-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Oct 2002 08:13:52 +0300 (EEST)

On Fri, 25 Oct 2002, Bound, Jim wrote:
> somewhere it will prevent most problems.  

Agree.

> But in routing code I would as

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)

-- 
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