Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: Tim Hartrick <[email-masked]>
Date: Wed, 19 Jun 2002 15:56:56 -0700 (PDT)

Jim,

> 
> Site identification requires a site-zone-id to differenentiate fec0::1 from fec0::1 on a node with two sites.   Under the site-identifier for the two sites are local links that also require zone ids for the link-locals.  
> 
> So the structure for an interface requires site-zone-id and then within each site link-local-zone ids.  
> 
> What I am saying is the site-id abstraction now requires another level of indirection when determining which interface the packet should be sent for interface data structures, routing data structures, and tansport data structures.  It also requires more intelligence for SCTP as example that uses addresses as failover in this case.  For site-local just the addresses is not enough but also the site-id now.
> 
> Rather than debate site-local existence maybe it would be good to just get consensus on their complexity and what they mean regarding added work for implementations?  
> 

I think that this is the right direction to go and I agree with Jim that the
vast majority of the implementation complexity associated with limited
scope addresses is associated with nodes that are connected to two or more
zones.  Given this, I don't see any reason that individual implementors can't
decide for themselves, based on customer demand, whether or not their
implementation needs to be able to support being connected to two or more zones.
This, in my opinion, goes for link-local, site-local or any future limited scope
unicast address that can be imagined.

The existence of site-local addresses in the address architecture doesn't
imply a requirement that every implementation be able to act as a site-border
router or implement "two-faced" DNS or implement various unspecified routing
protocol extentions to implement site-border router functionality.  All of
these features are admittedly complex to specify and implement, but not
impossible given appropriate motivation.  The good news is that not every
implementation needs to have all these features from day one. Most
implementations will never need any of them.

There are a minimum set of requirements that any node will have to implement
in order to communicate using site-local addresses.  As far as I can tell that
minimum set is pretty well specified in the Draves destination/source address
selection draft.  Any specification and implementation beyond that minimum
set should be driven by customer demand.

What I would like to see come out of this long discussion is simply some text
in the in progress "Node Requirements" document that specifies how much of the
scoped address architecture MUST be implemented and that that text would say
that the rules specified in Draves' draft are the only MUST implement portion
of the architecture.  There should be no requirement that a node be able to be
part of more than one zone.

The above should solve. in the near term, the fears of implementation
complexity.  The "architectural" arguments against site-local/private addresses
can't be countered except to say, as many others have, that customers will use
"private" address space.  It is going to happen.  Something like RFC 1918 will
come into existence.  We can specify the bit pattern now or specify it later,
but it will be specified.  It is indeed scary that this might lead to IPv6 NAT
but IPv4 NAT happened without any RFCs or architectural blessing.  Removing
site-local addresses from the address architecture will do exactly nothing to
stop IPv6 NAT if the reasons that IPv4 NAT exists persist; address scarcity
and cost, and questionable security capabilities.  The first reason is solved
by IPv6 as long as the providers do the right thing.  The second part is mostly
FUD which can be countered with some BCP or informational RFCs, and secure
products.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Wed, 19 Jun 2002 16:41:35 -0700

> part of more than one zone.

So this is a different suggestion than the one Margaret made this morning.
We now have 5 alternatives on the table:

1 - Site local scope is enforced in the kernel by Addres selection rule when
       available and applications are build to work in a multi-sited environment.

2 - Site local scope is enforced in the kernel by Addres selection rule when
       available but applications can be limited to only support one site.

3- Site local scope can be requested by specific applications when available.

4- Site local are reserved for sites that are not connected to the Internet.

5- Site local are taken out of the address architecture.

    - Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Jun 2002 22:03:29 -0400

Hi Tim,

Excellent points.

>part of more than one zone.

I think that this would be an excellent way to limit the impact
of scoped addressing on implementations that are not interested
in existing at site borders.

Margaret