Subject: RE: Proposal for site-local clean-up

From: "Christian Huitema" <[email-masked]>
Date: Tue, 19 Nov 2002 10:29:18 -0800

>> Ok, but it isn't clear that these two factors are of even remotely similar
>> weight.  Leakage is a problem that can be addressed, but there are a lot of
>> things that simply will not work without stable addresses (at least not
>> without a complete overhaul of many higher-level protocols).
>
> Agreed that stable addresses are necessary, but experience suggests that
> it is very difficult to 'address' leakage of addresses.  Every application
> is another path by which addresses can be leaked.  For that matter, so
> is every mobile host.
During the transition phase, a number of hosts will be using IPv6 addresses 
that are derived from IPv4 addresses, and will thus be just as stable as 
IPv4 addresses. Even if we close our eyes very hard and wish for stable 
addresses very strongly, global IPv6 addresses will not be all that 
stable, at least not during the transition phase. We need some form 
of provider independent addresses for the local applications, and site 
local are what we have.
 
Clearly, site local are not perfect. As Keith points out, we can minimize 
address leakage, but we can certainly not guarantee a leakproof use of 
site local addresses. We can all observe that RFC 1918 do leak. 
 
I would argue that we are in a better position with IPv6 site local than 
with RFC 1918 IPv4 addresses. There is a standard API to determine the scope 
of an address, which makes the application's writer job somewhat simpler; 
indeed, these application writers has already to be concerned with not leaking 
link local addresses, so site local don't make their task much more complex. 
Also, IPv6 site local address include a mostly unique 64 bit node ID, which
means that the consequences of leakage are not quite as bad as for IPv4: you 
will mostly get a failed conection, not a connection to some other random host 
on the remote site.
 
The right solution could be to have provider independent non routable addresses. 
They would effectively be global, which would make programming simpler and would 
make leaks mostly  harmless. However, we don't have such addresses today, so this
is mostly a rhetorical argument. Also, such global addresses would require much
more management. I guess we are stuck with site local for now.
 
-- Christian Huitema

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 19 Nov 2002 16:12:57 -0500

>  I guess we are stuck with site local for now.

As long as we don't have a willingness to either solve the problems with
site-locals (by imposing limits on their use ) or to solve those problems
in other ways (e.g. by providing provider-independent addresses) I think
we are stuck in general.   But I don't find the argument that we must
have site-locals (even though we know they are broken) because we aren't
willing to solve the problems in a better way, very persuasive.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------