Re: Removing features

On vrijdag, okt 10, 2003, at 21:55 Europe/Amsterdam, 
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
> the biggest basis for removing the feature is the fact that
> RFC1918 contains essentially the same provision for IPv4, and 1918 
> addresses
> are continually leaking like sieves, and nobody (to my knowledge) was 
> able to
> point at magic router filter dust that would prevent it from happening 
> on IPv6.
> So the basic concept is (in my opinion) broken and needs to be 
> euthanized.
This is based on the assumption that leaking RFC 1918 routing 
information or packets with RFC 1918 source or destination addresses is 
actually harmful in and of itself. This is a broken assumption. If 
people are going to send bogus routes or packets, then having RFC 1918 
addresses in them is the least harmful way to do it. Now obviously 
people shouldn't send out bogus routes or packets, but this is a 
problem that is completely unrelated to private addressing issues. It's 
just that private addresses make this problem much more visible. 
Removing that which is clearly wrong only helps to make sure the 
wrongness that remains is less visible.
And if you're unable to figure out how to filter private addresses in 
routing updates or IP traffic, there are numerous non-magical books out 
there that will tell you how to do this.
> > outright. Deprecation doesn't prevent people from using them, but 
> > outright
> > removal can be dangerous. And in this case, the assertion that one can
> > still use the address prefix in a local manner is simply incorrect; 
> > it can
> > be assigned at the whim of IANA, and network administrations need to 
> > plan
> > accordingly.
> And in fact, we've seen this effect in operation recently, when the 
> 69/8 address
> space was allocated but often unreachable due to bogon filters....
> All in all, however, I think outright removal, although short-term 
> more painful,
> will be less troublesome than many years of debugging problems caused 
> by
> 1918-style leakage of addresses for a "deprecated" feature.
Your argument is self-defeating. If we were to recycle FEC0::/10 this 
would be the 69.0.0.0/8 but ten times worse. Everybody knew that 
69.0.0.0/8 would be assigned at some point, so the people filtering 
this range knew what they were doing (or at least, they should have). 
FEC0::/10 on the other hand has been in the specification as a fixed 
special purpose range for a lot of years, and presumably people have 
implemented their networks accordingly. Pulling the rug from under them 
by removing this address range from the spefication and (at least 
theoretically) allowing it to be reassigned for a different purpose is 
insane.
And that's not even considering the lack of alternatives at this point 
in time. We may not be able to come up with a reasonable way for 
networks that implement site local addressing and interconnect with 
other networks that do the same, but there is still a very real need 
for addresses that can be used in disconnected IPv6 networks. I believe 
that forcing people who just want to interconnect a few boxes to do 
some testing to obtain globally routable IPv6 unicast space is a very 
bad idea. As long as there aren't any alternatives, FEC0::/10 should be 
used for this. And even after we have alternatives, FEC0::/10 should 
forever be set aside to avoid problems.
> <mime-attachment>
Huh?

Iljitsch van Beijnum