Tony Hain wrote: > Keith Moore wrote: > > your understanding is incorrect. the question posed at the > > meeting was > > quite clear. and yes, the plurality of opinions in the room was so > > overwhelmingly in favor of deprecating site local (even if it's > > something people are already using) that it is inconceivable > > that this > > is not indicative of WG consensus. > > This has not been discussed on the WG mail list, so despite your > apparent limited ability to conceive of valid objections, > they do exist. As you probably know, check http://playground.sun.com/ipng/ There are a couple of objections against deprecation/removal. But most of these IMHO simply boil down to having a place where it is possible to register globally unique address space which is not to be connected to the internet. Because it is globally unique it can be used to interconnect multiple sites though. Note also that if this space is available and those networks suddendly do want to connect to the internet one will see NAT for IPv6 and thus RFC1918 is born for IPv6 but with registration. If that happens I see little sense in actually giving those people IPv6 as they are not out for e2e connectivity at all. Most applications that work with IPv6 also work in IPv4... > > site local is broken. it creates far more problems than it > > solves, and > > it cannot be fixed. it's just taken people awhile to realize it. > > Trying to use SL for routing between sites is what is broken. > The space > identified in RFC 1918 was set aside because people were > taking whatever > addresses they could find in documentation. SL was set aside because > there are people that either want unrouted space, or don't want to > continuously pay a registry to use a disconnected network. It is far > cheaper to train an app developer (though there may be an exception or > two) to deal with it than it is to fix all the ad-hoc solutions that > people will come up with to replace SL. And thus *every* application should suddenly be aware of the fact that some address space is not to be used in some certain currently non specified cases? Could this even be more fague? Either there is an address on the link or there isn't. Either it routes or it doesn't. There are numberous reasons why an address can't connect to another host. If an address on a link exists an application should be able to use it as an outgoing address. Currently we already have an exception here for fe80::/10 but that case has already been handled for quite some time and is quite logical as a link is a link and it's quite easy for the stack to detect that a host is not on the same link. Greets, Jeroen