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.