The 69/8 Networking Problem

jaredmauch writes "A number of networking providers who receive address space from ARIN have been having problems with their recent IP space allocations. This is a result of outdated filters that applied a few years ago during the boom time of the net, but have not been updated to reflect the current state of the network. Here is a paper that documents some of the problems this filtering is causing providers."

just in case...

[Anonymous Coward]

mirror [no-ip.com]

Re:Could someone explain this

[jaredmauch]

We have a few things that happened here I believe. Denial of service attacks lead the reason people would filter out 'unallocated' space. A bunch of people just used rand() to generate fake source IPs to DoS from. Dropping from unallocated or unrouted space has become commonplace as it can prevent that extra little bit of packets from reaching your firewall/router/end host. It can make the difference for some people being able to survive an attack and not. The "dot com" bubble that burst created a lot of devices that used to be cared about deeply and now are ignored by the suits as the network is too stable and runs itself. This is both good and bad. As the network becomes more reliable more people start using VoIP and other technologies that reduce costs. Problem is this ends up causing jobs to be lost. (VoIP aside, if you take 250mil phone calls all going on at the same time, using 64k per call, you've got ~16Gb/s of traffic. Most of the international backbones can easily handle this traffic. What does this mean for the existing PSTN networks once the IP networks are more reliable.) People are just busy. I know that I sometimes lag in updating software on my systems unless it's necessary. Imagine the people who think "hey, i need to update these filters" but never get around to it.

Re:Roll on IPv6

[silas_moeckel]

Your not going to see IPV6 untill they figure out how to bill for multicast traffic as it's REQUIRED to work inside IPv6 not optional like under v4. This is a HUGE problem in implementing it as you cant bill for it rationaly. How much sould it cost are home users going to be billed per megabit leaving there ISP? If multicast works lots of the current issues with the net can go away think bit torrent is fast think about file send loops via multicast just join as many as you have bandwith to receive. All of the routers etc etc out there have supported IPv6 for a long time I cant say that people are realy familiar with it but it could be made to work but you NEED to be able to fit a billing plan around it before any of the big guys are going ot make it work world wide.

Yeah, I had this a while ago with 65/8

[felicity]

Last year I had to rush over to a client to look at why they couldn't send email with their lawyers and, ironically, the firm I worked for (which was an on-going issue).

Turns out that a previous admin blocked all the "reserved" nets, including the 65/8 net which the lawyers and my firm were in.

Blocking these seems like a good idea, but it tends to get neglected and only causes problems in practice.

Re:Could someone explain this

[afidel]

They were filtered because prior to being allocated the only uses for them were nefarious in nature (basically spoofing). If everyone did proper egrees filtering this wouldn't be necessary.

Re:Not surprising

[lucifuge31337]

0.0.0.0/1 means any address between 0.0.0.1 and 255.255.255.254. 0.0.0.0/8 is much different, meaning any address between 0.0.0.1 and 0.255.255.254. So, basically what I'm saying is that it can mean "all IP addresses (in IPv4 space)" or it can denote a smaller subset of addresses beginning at 0.0.0.1, depending on what subnet mask is applied to it.

The "problem" with using blocks like that are not technical....just like using addresses ending in .0 as valid IP space is also not a problem in the right network blocks.....it's broken sysadmin's understaning of IP that causes issues.

Oh...and there that nasty problem of certian addresses lying on bondaries that cause routers that don't properly understand classless routing to choke, but honestly...how many edge device could possibly be out there that are that dated to still have that problem? At least how many that are in a backbone situation where their being broken would actually effect more than 10 people?

Re:Not surprising

[Wild Wizard]

handy link on 0.0.0.0 [zvon.org]

Re:Could someone explain this

[lucifuge31337]

No, that's not insightful. -1, Stupid Moderators.

There are several reasons why blocks are reserved by ARIN. Some of them are reserved because they fall on classful routing boundaries, some were reserved based on wanting to keep contiguous space free for various purposes including but not limited to RIPE and APNIC allocations, allowing flexibinity for large network to renumber out of non-contiguius space, etc.

Don't think I'm sticking up for ARIN. Their policies are poor, mostly undocumentated in their actual application, and their customer service sucks.

Testing 69/8

[Leme]

Jon Lewis setup a nice utility to test if your network is affected by outdated filters.

http://69box.atlantic.net/ [atlantic.net]

It includes a nifty traceroute utility that you can use to test with.

As a holder of space in the 69/8 range, I'll admit the problem is annoying, but thanks to people like Jon, and this posting on Slashdot, hopefully it will go away.

Re:Not surprising

[Michael Hunt]

It ain't just broken routers.

I was recently assigned a /29 from my DSL ISP at home. Since the whole thing runs on NAT, this gives me 8 IPs not 6, since NAT ranges have no concept of 'broadcast' or 'network' addresses (which only have link-local significance, and there's no link.)

Unfortunately, the /29 fell at the top of the /24 in question (202.59.108.248/29.) This means that 202.59.108.255 is one of the IPs which are being routed to my network. Cool, right?

Wrong. Having configured static NAT between that IP address and a machine on the inside of the network (172.18.16.24, case in point,) the machine was reachable from Unix and Linux machines, but not from Windows boxes.

Further testing reveals that Windows still uses classful logic to determine whether an IP is 'valid' or not. On attempting to ping 202.59.108.255 from a slew of windows 2000 boxes, tcpdump showed nothing on the other end. An identical test from a unix box showed that it worked just fine.

Re:exactly

[marvinglenn]

Theres a ton of companies sitting on class A blocks and doing nothing with them. Anything from 4.0.0.0 and up is hardly used. Redistribute these as a temporary solution until IPv6 is mainstream.

Exactly. Here are a few of the class A's that I don't see valid reason for the holder of them to have a block of such size:

019/8 Ford Motor Company (a car company)

040/8 Eli Lily and Company (a drug company)

048/8 Prudential Securities Inc. (an insurance company)

051/8 Deparment of Social Security of UK (a government department in a relatively small country that has a ridiculously unproportional share)

056/8 U.S. Postal Service (the opposite of email)

There are a handful more which you can see here: http://www.iana.org/assignments/ipv4-address-space [iana.org]

The fact that these companies are cyber-squatting on more than they could resonably need torques me off to the point that, if I run out of unroutables (10/8, 192.168/16, etc) for my intranetworking, I'm going to lay claim to a block or two of those class A's for my intranet and firewall them [existing squatters] off to the outside.

Re:Not surprising

[Alien Being]

"0.0.0.0/1 means any address between 0.0.0.1 and 255.255.255.254"

Shouldn't that be "any address between 0.0.0.1 and 127.255.255.254?"

Re:Devalued IP Space?

[adri]

You _can_ get lucky if you're _near_ the provider in question with the superblock you're in.

Example: Say you've got x.x.x.0/24 out of x.x.0.0/16.
Now, if people ignore you're announcement they're going to send traffic towards the provider announcing x.x.0.0/16. Somewhere along the way a network in the path might actually be paying attention to your routes, and your traffic gets shuffled towards you.

(But then, somewhere between THERE and you might be a network which doesn't pay attention and it heads back towards the /16 announcement.)

In short - remember, routing is hop-by-hop. Just because n-1 nodes in the path are listening to the announcement, things don't have to work. Similarly things might be working even if a node in the path isn't listening.

Now, some more facts - do some googling to determine meanings behind some terms/acronyms:

* the whole internet isn't populated with /20s and larger. In fact, there's still a lot of historical "swamp space" - see 203.0.0.0/10 (Australia). Its full of /24s. They're still globally visible because when the "nazi" filters were making the rounds at NANOG a while back.) If you're resourceful you might find the filters Randy Bush made up whilst working at Verio (i think!) which limited netmask lengths based on prefixes. So, fe, large chunks of space had a /19 limitation but the swamp space didn't. It was copied, verbatim, into many Cisco routers.

* Mass BGP filtering isn't to protect memory usage, its also to protect update times. Those CPUs can only _talk_ to neighbouring routers at speeds much below the linerates of cards (even today! :) and so taking 20 minutes to pull in a full BGP table would be 20 minutes where most routers performed in a degraded state. (yes, routers today are increasingly using seperate lookup, forwarding and data paths, but..)

* For a fun bit of historical information do some google searching for the AS7007 incident (or the mass deaggregation/redistribution incident.) Basically someone confed up a router, deaggregated large chunks of IP space into /24s and started locking up parts of the internet. Unfortunately due to bugs in software and non-instant propagation times these announcements just kept going round and round. Eventually netadmins had to coordinate with each other to shut down large parts of the internet "backbone" (there was a definable one, mostly, back then) to purge the announcements and then bring stuff back up again.

Phew. I drifted a bit there. I find it interesting to listen and learn about things like this so one doesn't make the mistake in other fields.

Re:Allocation

[nakaduct]

IPv4 routing tables would get unmanageable if you tried finer grained allocation

A routing table with entries for every /24 requires a stunning:

117 440 512! bytes!

... or, roughly $12 worth of RAM, at today's prices.

I'm not sure what you mean by "unmanageable": it's been a long time since backbone routing tables were managed by hand. There may be good reasons for small routing tables, but inherent cost and/or complexity of management are not.

Re:Allocation

[obidex]

care to explain that one?

each entry requires (at the very minimum) prefix, netmask and nexthop. this is before you remember it's bgp, and has to hold a whole host of other shit (communities, as-path, metric, localpref, weight, origin etc).

i make that:

2^24
= 16777216 /24s
16777216*96
= 1610612736 bits for prefix,mask,nexthop
1610612736/8
= 201326592 bytes for the very basics

You can safely double that (at the very least) to factor extra bgp overhead gubbins. Take a third off for route compression, and double that figure if you wanna run soft reconfiguration inbound. That comes out on the sunny side of half a gig for just your bgp table.

also, remember that your $12 stick of RAM will cost $1500 if you're buying ram direct from a router vendor (many refuse to support devices unless you use their propriatory labelled RAM). add on 50 meg for the OS itself and a random amount for your IGP and you're talking about needing a router with a gig of ram.

then think how long it'll take for you to learn this 200 meg routing table. bgp convergence is bad at the best of times, but adding 200 mbyte overhead when you start a bgp session is just ridiculous.

there's a reason why route aggregation is a good thing. and it's precisely because of the 'inherent cost and/or complexity of management'

HTH & HAND