Re: Removing features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)

Attachment: pgp00335.pgp
Description: PGP signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]