ietf
[Top] [All Lists]

RE: Fw: Welcome to the InterNAT...

2003-03-26 14:14:07
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