North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Who does source address validation? (was Re: what's that smell?)

  • From: Iljitsch van Beijnum
  • Date: Sat Oct 12 06:50:48 2002

On Thu, 10 Oct 2002, Jared Mauch wrote:

[People using RFC 1918 addresses for routers that terminate tunnels which
breaks path MTU discovery when RFC 1918 source addresses are filtered
elsewere.]

> 	People number out of 1918 space primarily for a few
> reasons, be them good or not:

> 	1) Internal use
> 	2) Cost involved.. nobody else needs to telnet to my p2p
> links but me, and i don't want to pay {regional_rir} for my
> internal use to reduce costs

So use IP unnumbered.

> 	3) "security" of not being a "publicly" accessible
> network.

Well then they get more security than they bargained for if their network
becomes inaccessible...

> 	With the past scare of "we'll be out of ip addresses by 199x"
> still fresh in some peoples memories, they in their good consience decided
> to also conserve ips via this method.

>From where I'm sitting, getting IP addresses is largely a matter of
spending some time and energy, but after a while you get them. It seems
this is different for other people. For instance, an ISP here in NL gave
their premium ADSL a few addresses when they first started offering the
service, but later offered those customers a free ADSL router if they
returned the addresses. So obviously there must have been a pretty big
incentive for getting the address space back.

Another problem with numbering router links is that you need to break up
your address blocks. This is extremely annoying and wasteful.

> 	The problem is not everyone today that considers themselves
> a network operator understands all the ramifications of their current
> practices, be they good or bad.

Very true.

> 	Going into fantasy-land mode, if IPv6 addresses were instantly
> used by everyone, people could once again obtain ips that could be
> used for internal private use yet remain globally unique, therefore
> allowing tracking back of who is leaking their own internal sources.

Ok, quick question: how do I number my point to point links in IPv6:

1. /64
2. /126
3. /127
4. IP unnumbered
5. just link-local addresses

I hate to say it, but I don't think IPv6 is ready for prime time yet.

> > Making a good list of best practices (and then have people widely
> > implement them) might also go a long way towards showing concerned parties
> > such as the US administration that the network community consists of
> > responsible people that can work together for the common good.

> 	I agree here, I personally think that numbering your internal
> links out of 1918 space is not an acceptable solution unless it's
> behind your "natted" network/firewall and does not leak out.

Agree.

> 	Perhaps some of those that are the better/brighter out there want
> to start to write up a list of "networking best practices".

I've started with a list of BGP best practices recently. When I think it's
ready I'll post a link. If anyone has anything to contribute before then
(even just (contructive) criticism), mail me off-list.

> > > But if the best reason we can
> > > come up with is ISIS, the IEEE will just keep laughing.

> > Why is the IEEE laughing?

> 	The implication is that IEEE will not change the 802.x specs
> to allow larger [default] link-local mtu due to legacy interop
> issues.

So? We don't stick to IEEE 802.3 anyway...

> imagine your circa 1989 ne2000 card attempting to process
> a 4400 byte frame on your local lan.  a lot of the "cheap" ethernet
> cards don't include enough buffering to handle such a large frame
> let alone the legacy issues involved..

4400 bytes on a 1989 card, you are being _very_ optimistic to even take
the trouble of saying that doesn't work. Many of today's cards 100
Mbit cards (and that's not just the $10 ones) can't even handle 1504 bytes
as needed for 802.1q VLAN tags.

I have to side with the IEEE here: simply changing the spec isn't an
option, since none of the 10 Mbps stuff will handle it, very little of the
100 Mbps stuff and not even all of the 1000 Mbps stuff. (I once complained
to a vendor about this. They sent us new GE interfaces. Those did 64k
frames...)

Having a larger than 1500 byte MTU in backbones would be very good,
because then you have some room to work with when adding extra headers. A
good solution for this would be an neighbor MTU discovery protocol. Maybe
ARPv2? Then boxes with different MTUs can live together on the same wire
and doing more than 1500 bytes over an Ethernet-based public exchange
point wouldn't be a problem.