Those of you who follow these things can’t have missed that the RIPE NCC had got down to it’s last /8 of unallocated IPv4 space last week.
They even made a cake to celebrate…
This means the RIPE NCC are down to their last 16 million IPv4 IP addresses, and they can’t get another big block allocated to them, because there aren’t any more to give out.
Networks have a thing called a Maximum Transmission Unit (MTU), and on many networks it’s long been somewhere around 1500 bytes, the default MTU of that pervasive protocol, Ethernet.
Why might you want a larger MTU? For a long time the main reason was if you’re transferring very large amounts of data, you reduced the framing and encapsulation overheads. More recent reasons for wanting a larger MTU include being able to accommodate additional encapsulations (such as MPLS/VPLS) in the network without reducing the end-to-end MTU of the service, to carry protocols which by default have a higher MTU (such as FCoE, which defaults to ~2.5k bytes), and make things like iSCSI more efficient.
There’s often been discussions about whether Ethernet-based Internet Exchange Points – the places where networks meet and interconnect over a shared fabric – have been one of the barriers (there are lots!) to adoption of a higher MTU in the network. Most are based on Ethernet, and most have a standard Ethernet MTU of ~1500 bytes.
Ethernet can carry larger frames, up to around the 9k byte mark in most cases. These are known as “Jumbo Frames“. Here is quite a nice article about the ups and downs of jumbo frame support from the perspective of doing it on your home network.
The inter-provider networks to date where you can usually depend on having a higher end-to-end MTU are the large Research and Educational Networks, such as JANET in the UK. With white-coated (and occasionally bearded) scientists wanting to move huge volumes of experimental data around the world, they’ve long needed and have been getting the benefits of a larger MTU. They deliberately interconnect their networks directly to ensure the MTU isn’t reduced by a third-party enroute.
This has recently resurfaced in the form of this Internet Draft submitted by my learned friend Martin Levy of Hurricane Electric – yes, he of “Just deploy IPv6” fame.
With this draft Martin is trying to break what is at best a chicken-and-egg, and at worst a deadlock:
He’s trying to support his argument by collecting the various pieces of rationale for supporting inter-provider jumbos in one place, to guide IXP communities in making the right decision, and hopefully documenting the pitfalls and things to watch out for – the worst being that your packets go into the bit-bucket because of a MTU mismatch and PMTUD being broken by accident at best or foolish design at worst.
My own personal, most-recent experience dancing around this particular handbag as with an IXP operators hat on, gave the following results:
It was actually easier for this minority to interconnect bi-laterally over private pieces of wire or fibre, where they could also set the MTU for that link on a bi-lateral basis, rather than across a shared fabric where everyone had to agree.
Martin’s rationale is that folk argue about this because there’s no well-known guidance on the subject, so his draft is being proposed to provide just that and break the previous deadlock.
In terms of IXPs which do support a larger MTU today, there are a few, the most well-known probably being Sweden’s Netnod, which has long had an MTU of 4470, largely due to it’s own ancestry of originating on FDDI, and subsequently using Cisco’s proprietary DPT/SRP technology after the exchange outgrew FDDI (largely because of a local preference for maintaining a higher MTU). When Netnod moved to a Gigabit/10 Gigabit Ethernet based exchange fabric, the 4470 MTU was retained despite the newer ethernet hardware having support for a ~9k MTU, and it’s explicitly required by Netnod that IXP participant interfaces are configured with a 4470 MTU to avoid mismatches. It seems to be working pretty well.
One of the issues which is likely to cause discussion is where 100Mb Ethernet is deployed at an exchange, as this, generally speaking, cannot support jumbo frames. Does this create a “second class” exchange in some way?
Anyway, I applaud Martin for trying to take this slippery subject head-on. Looking forward to seeing where it goes.
Comcast, long active in the IPv6 arena have announced that they will be doing a native residential IPv6 deployment in Pleasanton, CA, on the edge of the San Francisco Bay Area, which will be a dual-stacked, native v4/v6 deployment with no NAT.
This is a much needed move to try and break the deadlock that seems to have been holding back wide scale v6 deployment in mass market broadband providers. Apart from isolated islands of activity such as XS4ALL‘s pioneering work in the Netherlands, v6 deployment has largely been available only as an option from providers focused on the tech savvy user (such as A&A in the UK).
Sure, it’s a limited trial, and initially aimed at single devices only (i.e. one device connected directly to the cable modem), but it’s a start, and there’s plans to expand this as experience is gained.
Read these good blog articles from Comcast’s John Brzozowski and Jason Livingood about the deployment and it’s aims.
So, I’m currently at the RIPE 63 meeting in Vienna. Obviously, one of the ongoing hot topics here is IPv4 depletion, at times consisting of discussion on either a) the transition away from IPv4 to IPv6 via various transition mechanisms, and b) how to make the pitiful amount of IPv4 addressing that’s left last as long as possible.
One of the things that is often said about (b) is that it shouldn’t be done to death, IPv4 should just be allowed to run out, we get over it, and deploy IPv6. However (b) behaviour is to be expected when dealing with exhaustion of a finite resource.
There are similarities and parallels to be drawn between IPv4 runout and IPv6 adoption, fossil fuel depletion and movement to alternative energy techologies. The early adopters and the laggards. The hoarders and speculators. The evangelists and the naysayers.
So, for a minute don’t think about oil and gas resources being depleted, that’s way in the future. We’re facing one of the first examples of exhaustion of a finite resource on which businesses and economies depend.
If the IPv4 depletion and IPv6 (slow) adoption situation is a dry run of what might actually happen when something like oil runs out, then we should be worried, because we can’t just rely on carrier grade NAT to save us.
One of the first big deals in the IPv4 address secondary market appears to be happening – Microsoft paying $7.5m for pre-RIR (aka “early registration”) IPv4 address space currently held by Nortel.
There have been deals happening on the secondary market already. But this one is significant for two reasons:
Interesting times… Now, where’s my dodgy yellow van?
Or, with apologies to Rolf Harris, “Can you guess what it is yet?”…
The NRO are inviting us to a webcast of a “special announcement” tomorrow. I wonder what it could be?
Might it be the end of the IANA IPv4 free pool? Or could it be that a few more /8s have been found down the back of the sofa? The latter is very unlikely.
We’re probably looking at a ceremonial doling out of the remaining /8s to the various RIRs.
While it may look a bit profligate to fly a load of RIR folk to Miami, it’s probably a necessary media stunt, as implementers and vendors have been sodding around, sat on their hands, for long enough, to the point that many folks’ home broadband routers and systems won’t do IPv6 and therefore can’t support a dual-stacked (v4 and v6 enabled) environment.
(The Real) Geoff Huston has, as usual, produced an interesting graph:
So we should find APNIC moving to activate their “final /8 policy” first, the idea being it – assuming Cyclone Yasi doesn’t try and finish the job the Queensland floods started in Brisbane – will start to issue allocations from the final /8 in smaller blocks, and only one allocation can be made to each APNIC member LIR from the last /8 – to try and give some level of running out fairly.
Anyway, it will certainly be interesting to keep an eye on these graphs!
Fortunately (in some respects), the runout in the RIPE NCC region looks to still be about 12 months away. Still doesn’t give me the warm fuzzies.
Folk need to start using IPv6, and debugging what’s wrong with it to stand any chance of being ready.
ISOC have announced the date for World IPv6 Day – mark it in your calendars now – 8th June 2011.
This will be the day that you will need extra support resources available to deal with the potential for brokenness which will ensue from folks with poor v6 implementations or incomplete v6 connectivity.
It may look a bit drastic to submit the Internet at large to this “experiment”, but I think this is an important and sensible move.
Folks such as Marco Hogewoning and Martin Levy (among many, many others, these are the first two which spring to mind if you mention IPv6 to me) have been demonstrating the various gotchas or downright brokenness which exists out there for some time now. Sadly, while the enlightened have no problem listening, some have been sat with their heads in the sand. The bad thing is that these are often the people we need to listen most – software and system vendors.
So, get the popcorn ready, be ready for the unexpected, and watch what happens.
In the meantime, you might want to check how IPv6-ready your network is… not just how much it claims to be.
Best of all, N(ew/A)NOG 52 meeting will be happening in Denver the following week, so we get to have a discussion of the aftermath in near real time. I’d love to link to it, but there’s nowhere to go.
At least it’s a Wednesday – no-one’s Friday is being ruined. š
Mike's Twitter Overflow - Tech, Travel, other stuff 