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

Re: Removing features



On zaterdag, okt 11, 2003, at 01:12 Europe/Amsterdam, 
Valdis.Kletnieks@vt.edu wrote:

> 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.

Wouldn't the people behind this setup feel the pain too?

I must say giving a router that handles links with different MTU sizes 
RFC 1918 addresses is an interesting choice.

But then path MTU discovery has been broken (by assuming packet too big 
messages would *always* be returned) for 10 years and only recently the 
IETF and implementers have been starting to do something about that.

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

Dunno. What kind of pathalogical setup makes this happen anyway? 
Running a resolving nameserver behind a broken NAT? But only a few of 
those will generate lots of queries as they never see any answers.

>> 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.

I doubt that FEC0::/10 will be as prevalent as RFC 1918. But if you 
absolutely don't want to see them, you probably need to filter them for 
eternity, yes.

> 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.

Yes, all of this is very problematic. What we really need is provider 
independent address space that is globally usable. If we can't make 
this happen I'm sure IPv6 will end up with much of the IPv4 
unpleasantness, such as two-faced DNS if not full-out NAT.

>>> <mime-attachment>

>> Huh?

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

But why bother signing your messages? We're discussing based on 
arguments here, it doesn't matter who makes them...


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------