Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[rbrabson]

On Friday, 06/14/2002 at 02:13 ZE7, Robert Elz <[EMAIL PROTECTED]> wrote:
>   | Exactly.  The entire IPv6 code base would be reduced in size and more
>   | importantly the decision constructs and data struct lookups which is a
>   | big win.
> 
> Can you actually justify that, or is this just more nonsense?
> 
> Remember that as long as link locals stay, and as long as their are
> apps that use them (doesn't BGP peering use LL's these days?) then all
> of the system support for scoped addresses has to remain, including the
> data structs, API's, ...
>
> What you would gain by removing them is the change from testing
> fe80::/9 into testing fe80::/10 when deciding if the address you
> have is one that also needs a scope.   Beyond that it is essentially
> all the same if scopes are involved - are the scopes for source &
> destination the same, etc - regardless of whether it is fe80::/10 or
> fec0::/10 that the address happens to be.
> 
> So, just where is this saving?

I can think of plenty of savings in my protduct if I restrict it so that 
it only supports a single site.  Support for simultaneous connectivity to 
multiple sites requires updates to my routing table, so that I now support 
multiple "logical" routing tables, one for each site I'm connected to and 
one for global addresses.  Support for this takes new configuration (to 
define the multiple sites) and new code within the stack.

But the TCP/IP stack changes are just the tip of the iceberg.  Support for 
simultaneous connections to multiple sites requires changes to the DNS name 
server and resolver, routing daemons, and potentially applications.  While 
I have no doubt all of this can be architected and made to work, but it 
isn't here today and it isn't going to be free and, I suspect, neither is 
it going to be easy.

If I only support connecting to a single site, then I no longer need the 
configuration, nor do I need a site zone index to differentiate between 
two site-local addresses.  I no longer need to support multiple "logical" 
routing tables, and my DNS resolver doesn't need to understand which 
interfaces are connected to which sites.  I don't have to update RIP and 
OSPF to add support for multiple sites.  I still need to run a two faced 
DNS, but that is business as usual for customers who want to use a mixture 
of private and public addressing.

Link-local, on the other hand, is different.  I don't need to use the 
routing table in selecting where to send the packet, as the destination 
must (by default) be on a directly attached link.  I simply need to 
identify the link onto which to place the packet, and can use the scope 
zone to index into the link on which the outgoing packet needs to be sent.  
No route table lookups are used or required, and no changes to the routing 
table are needed.

So, from my perspective, the complexity of site-local and link-local are 
quite different.  And, while it wouldn't pain me to see SL simply 
disappear, restricting hosts to connecting to a single site would 
alleviate much of the complexity surrounding the use of private addresses.

Roy