Stack-Hacker Itojun Talks About IPv6

Alert reader Sin Yuhara writes: "I've encountered [an interview in which] Jun-ichiro "itojun" Ogino(KAME Project Core/NetBSD Core/FreeBSD Comitter) talks about IPv6. The KAME IPv6 ^[?] stack is very well known in the BSD world and beyond. I'm sure IPv6 and related stuff must deploy, and this article may help all people." It's a really good read -- itojun talks about the IPv6 tools that are already integrated into the various BSD systems, about the need for ever more testing, and about why Japan rocks.

Security without NAT

Many people seem to use NAT for security purposes, because it makes it harder for outsiders to connect to internal machines. Of course, NAT is not meant for this, and has potential holes (e.g. if the NAT software fails it may just forward packets straight through, as has happened on at least some NAT boxes), but that's what a lot of people think.

Until people manage their host and firewall security a lot better, many sites may just stick with NAT because it's what they know, removing a key benefit of using IPv6. So perhaps improved security processes and technology are a prerequisite for IPv6 deployments.

MPLS makes IPv6 work on core routers

First of all, the IPv6 header is actually more regular than the IPv4 header - fewer fields, and only twice the size of IPv6 despite addresses that are four times larger. Also, the routing tables for IPv6 are supposed to be more regular, so the performance impact on software-based routers may not be that much.

The vast majority of IPv6 packets will not have options - yes, they need to be looked at if present, but in that case you just dump the packet into a slow path. Also, MPLS will help here (see below) - the packet should only hit the slow path on lower end routers.

As for core routers that use forwarding ASICs - the answer is to implement MPLS, starting on edge routers that forward IPv6 in software, and attach MPLS labels. The core routers ONLY see the 32 bit MPLS label, so there is no problem about forwarding IPv6 just as efficiently as IPv4, once it is MPLS labelled. The core routers need to run IPv6 routing processes, but that's just on the main CPU.

MPLS is already deployed in ISP and telco IP networks - it is currently used for traffic engineering (balancing traffic loads over the network) and MPLS VPNs, and the same technique will be used to carry ATM, Frame Relay, Ethernet and SONET.

In the longer term, new routers will come on the market with smart enough ASICs and network processors to handle IPv6 with no reduction in forwarding rates, but MPLS will be useful for those ISPs that want its extra features.

Not using NAT, are ISPs going to become nicer.

He asks why anyone still uses NAT seeming to say that with ipv6 noone will need to use NAT. I personally use NAT so I don't have to pay my isp 40$ extra every month to have all my machines hooked up. Are ISPs going to just start handing out ipv6 address for free, I don't think so. I can't wait until my isp just hands out subnets, not individual addresses.

Japan is ahead of us in IPv6

Not only do they have large deployed IPv6 networks; not only their ISPs provide IPv6 service to their subscribers, and it's actually supported; not only does the government give tax breaks to ISPs that support IPv6; not only are their companies doing IPv6; not only do they develop games for freaking consoles that use IPv6; not only are their cell phone providers implementing IPv6; but they actually have a fairly large IPv6 user community.

Go, Japan!

IPv6 routing doesn't fit well in hardware

I don't see IPv6 taking off any time. IPv6 problem is not just a deadlock between ISPs and router manufacturers. The big roadblock on the way towards TWGD (i.e. total worldwide global domination, let's see if this one sticks ;-) is that IPv6 doesn't fit well in hardware acceleration. IPv6 has huge and variable headers, which are a pain in the bottom end to process in hardware.

IPv4 is much nicer. Only the first few hundreds bits in the packets really matter. Sure, an IPv4 header can be much bigger with options. It's just that nobody expects those options to be implemented. With IPv6, ignoring options is not ... an option. Even core routers must completely walk the header chain of each packet.

The reason is that the IPv6 effort was started in the early 90s at a time when IP routers where basically a bunch of interfaces and DMA engines around a shared packet buffer with a CPU in the middle chopping and tweaking the headers to route the packets. All the decisions were made by software, and, sometime in low cost routers, the CPU even performed the data transfers with the interfaces, no DMA. The IPv6 was built with this architecture in mind and requires the routers to do a lot of smart gee whiz things on the headers. That clean architectural model is alas obsolete.

Nowadays, routers' CPUs nearly never see a packet. All the routing is completely done in hardware. The CPUs just do housekeeping, maintaining the routing tables, collecting and processing statistics, that kind of stuff. The only packets they ever see are those for network maintenance, SNMP, etc, and routing protocols, OSPF, IGRP, BGP, you name it.

In serious routers, the real stuff happens between the switch fabric and the routing processors. The switch fabric, centralized or distributed, handles the bulk of the data transfers, receiving and sending packets between the interfaces and the packet buffers. Here, the unit is the gigabit per seconds (a few tens or hundreds of Gb/s or even Tb/s). When the switch fabric receives a packet, it stores it in a buffer and at the same time extract a few hundred bits of the header and forwards that to routing processors, a huge pipeline of table lookups and processing, 100% hard-coded in silicon.

After a while, the routing processors spit an answer to the switch fabric to flush or forward the packet with updated data for the variable fields (the TTL for instance, or even the whole header on NAT or multicast), or to create new packets. For instance, ISMP packets on TTL timeout can be completely generated in hardware! The unit there is the 100s of millions of packets per second. Go do that with CPUs... Worst of all, the IPv6 headers are highly variable and that completely screws up pipeline design where it's much better to handle bounded amount of data.

So, on current routers, IPv6 is supported ... as an exception, using the CPUs. The performances are merely catastrophic. IPv6 is not really practical with current router architecture. May be an IPv7 will come, one day when IPv4 is really breaking at the seams.

Oh well ... that just my $0.02 on IPv6 ...

Heh.

Great; now we can all steal the *BSD IP stack again. :)

Thanks, *BSD, for continuing to be the research arm of the software community...

Re:need NT, NOT.

Unfortunately, you are wrong. Microsoft® WindowsNT® and Windows2000® products can give you a reliability guarantee that no other products, certainly not this supposedly 'free' software, can provide. That's right, the nine fives promise. You heard it correctly. Microsoft will guarantee an uptime of %55.5555555. Yes: More than half of the time, your servers will be up and running, allowing you to take advantage of the new, electronic economy. With that kind of power, you can transform your business. That's the kind of leverage Microsoft provides.

War3 doo u w4nt 2 g0 70d@y!!!1©

ICANN Pricing obstacle to IPv6

I'm not having much luck searching www.icann.org tonight, so these details may be incorrect and may have changed by now - YMMV. One of the big obstacles to IPv6 deployment is ICANN's totally artificial pricing for address space. One of the motivations for IPv6's design is to provide nearly-infinite quantities of address space, which means it ought to be basically free - but ICANN set pricing on it that makes the smallest available chunk of routable address space cost an annoyingly large amount of money. IIRC, it was something like $2500 for a /48, but even if I've got the size wrong the principle is reflected accurately - they're trying to delay and control the deployment by setting an unreasonable price.

It's not totally stupid - one of the problems that does need to be solved by any widespread replacement of the current IPv4 stack is routing table size for the Big Internet, as BGP usage continues to multiply. IPv6 has some support for efficiency and consolidation, but there's still a lot of work to be done.

No mention of 6to4?

It's too bad this article didn't mention that you do not need to wait for your ISP; you can start using IPv6 today with 6to4. Slashdot ran a story [slashdot.org] about how to configure 6to4 under BSD, and here are the instructions for Linux [debian.org].

I know someone is going to mention that freenet6 or the 6bone is also easy to use, but they're much less efficient than 6to4.