[6bone] non-global address space for IXs (was: 2001:478:: as /48)

[John Fraizer]

On Mon, 8 Sep 2003, Gert Doering wrote:

> Hi,
> 
> On Sun, Sep 07, 2003 at 06:14:08PM -0400, Haesu wrote:
> > general. My consensus is that 'why should I recv a packet if it does not
> > exist in routing table?' 
> 
> Because it will break PMTUD in those cases (and, more frequent, in the
> case of stupid ISPs that use RFC1918 transit networks and send ICMPs from
> those source addresses).

I tend to lean towards preventing spoofed packets from entering my network
over keeping PMTU-D alive.  RFC1918 address space is dropped - period the
end, as are all other known BOGONs.  Address space to which we have to
return address is also dropped.  To not do so presents two problems:

(1) It allows "spoofed" attacks to make it into our network.
(2) It perpetuates the existance clueless operators.  IE; if they can't
communicate with RESPONSIBLE networks, they might just find some clue and
fix their networks!

> 
> In a world where everybody knows what he's doing, upstream "loose uRPF"
> should be fine (but in that world you wouldn't need it either).  *sigh*.

Gert, I'm not trying to be elitist here but, in THIS world, I'm not going
to bend over backwards to allow broken networks to communicate to or
through my network.  If they're broken, the operative word is
"THEY'RE" and it is THEIR problem, not mine.  Why should I drop shields
because some bonehead decided to use RFC1918 space on WAN links where MTU
changes or because some other bonehead "made up" an address range to use
"internally" and then misconfigured NAT on his border devices, and is thus
spewing packets from invalid (read: hijacked) address space?

If they're broken, they're broken and to change common convention to
accomodate them will only serve to KEEP them broken.


--
John Fraizer
EnterZone, Inc 
(13944+$|13944+_14813+$|13944+_17266+$)
PGP Key = 6C5903C4
Fingerprint = 2AA6 6614 1B5E EDD2 38AD C417 3E61 F975 6C59 03C4