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