Re: Removing features

On Fri, 10 Oct 2003 23:43:20 +0200, Iljitsch van Beijnum said:

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.


The problem is that usually, the offending site isn't the one feeling the pain.

We've been doing bogon filtering of 1918 addresses for a LONG time.

The *real* fun is collateral damage - we filter inbound 1918 source
addresses.  A certain clueless Tier-1 numbers their point-to-points
out of 1918 space.  If one of those links tosses an ICMP error,
it gets dropped at our border router.

Does wonders for PMTU discovery when the frag-needed packet gets tossed.

How many sites have to Get It Wrong before 30% of all the packets seen
at the root nameservers are from 1918 space?

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.


Agreed.  On the other hand, if we don't, we're stuck looking at
having inbound FEC0::/10 packets for eternity.

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.


Well.. OK... *disconnected* networks, I can see the point.  Unfortunately,
unless you make a rule that an IPv6 host will categorically refuse to
accept traffic to/from a FEC0::/10 host if it knows *ANY* other non-link-local
prefixes, it will end up leaking.  Yes, that means if you connect and learn
other prefixes, you need to renumber the site-locals.  It also means that
if you have a router talking to the outside world, you aren't allowed to do
NAT-style games - the router has to pretend your FEC0:/10 hosts don't exist.

<mime-attachment>


Huh?


RFC2440 - OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R.
     Thayer. November 1998. (Format: TXT=141371 bytes) (Status: PROPOSED
     STANDARD)

pgpG4cbxK8TvN.pgp
Description: PGP signature