How important is IPv6 connectivity expected to be soon?

[lif_andi]

The idea is that you use the link-local address for internal communications. That way, it doesn't matter what the IP address of the device is in terms of external communications, as your internal address is always the same. The drawback, of course, is potentially massive broadcast domains.

There are no broadcasts in IPv6.

 

[mikeymikec]

It is a typical failure of markets or what is called the "tragedy of the commons".
Because of that, things will continue to increasingly break and get worse. But because no one benefits from taking the first step, nothing happens even though everyone agrees that it is the correct thing to do.

+1

Also, industries would prefer to wait until the system breaks and then sell upgrades!

 

[lif_andi]

Seeing as there seem to be some misconceptions about IPv6 and why it is important I wanted to write a little about this.

Aside from the addressing problem of IPv4 and the gazillion addresses IPv6 gives us, there are several benefits to IPv6, some of which are:

• IPSec is included in the standard.
• Roaming capabilities are greatly enhanced.
• Smaller headers which are aligned with 64-bit allowing much greater processing and lookup speeds.
• Allows multiple addresses per each host.
• Enhanced routing efficiency.
• Expanded use of multicast communication.
• No broadcasts at all.

as well as several other improvements. Think about it this way: IPv4 was created a long time ago with completely different kinds of networks in mind, and much of what is included in IPv4 is becoming obsolete. IPv6 is created, pretty much from scratch with modern networks in mind, and once we all learn it and start to use it, network administration will be more efficient and in some ways actually easier. IPv6 should have been integrated more quickly, but we are resistant to change I suppose and so many will cling on to IPv4 because they know it and it works, not necessarily because it is in any way better than IPv6.

 

[theevilsharpie]

I believe one of the reasons for the slow roll-out is related to the equipment. Because the addresses are so much larger it takes more ram, more ROM/EPROM/EEPROM, and more execution space. Devices that are slow now would be brought to it's knees but using IPv6. Firewalls / firewall processes are much more difficult, and would likely take more time to accomplish.

LOL no.

The biggest performance bottleneck in most CPE routers relates to the use of NAT. The CPU has to constantly translate IP headers, and it has to maintain a NAT table in memory to keep track of NAT'ed connections. They also have perform "fix-ups" on certain protocols (e.g., FTP, SIP, most VPN protocols, etc.) to allow them to work with NAT. IPv6 doesn't need to do this, and can simply route packets to where they need to go.

IPv6 has slightly lower throughput than IPv4 because the packet header is bigger, but from a computational standpoint, a low-end router will perform better with IPv6 than with IPv4 (all other things being equal).

The reason you haven't seen CPE manufacturers adopt IPv6 is because they operate in a low-margin price-conscious market, and there hasn't been enough demand for IPv6 functionality until recently to make developing and maintaining IPv6 functionality worth the expense.

 

[theevilsharpie]

IPSec is included in the standard.

No, it isn't. It's an optional extension, just like in IPv4.

Smaller headers which are aligned with 64-bit allowing much greater processing and lookup speeds.

IPv6 headers are more efficient to process (in theory) than IPv4 headers, but they are not smaller.

Allows multiple addresses per each host.

IPv4 allows multiple addresses per host.

No broadcasts at all.

IPv6 doesn't have a dedicated broadcast function, but it has default multicast groups whose memberships are wide enough that transmitting a packet to those groups is effectively the same as broadcasting. In addition, unless the underlying Layer 2 switch supports MLD snooping, IPv6 multicasts will be sent out as Layer 2 broadcasts. While I don't dispute that IPv6 lacks broadcasts, using it as an advantage over IPv4 is questionable, as the efficiency gains from forcing the use of multicasts instead of broadcasts are entirely dependent on how much effort networked application vendors put into limiting the size of their multicast groups.

 

[ScottMac]

LOL no.

The biggest performance bottleneck in most CPE routers relates to the use of NAT. The CPU has to constantly translate IP headers, and it has to maintain a NAT table in memory to keep track of NAT'ed connections. They also have perform "fix-ups" on certain protocols (e.g., FTP, SIP, most VPN protocols, etc.) to allow them to work with NAT. IPv6 doesn't need to do this, and can simply route packets to where they need to go.

IPv6 has slightly lower throughput than IPv4 because the packet header is bigger, but from a computational standpoint, a low-end router will perform better with IPv6 than with IPv4 (all other things being equal).

The reason you haven't seen CPE manufacturers adopt IPv6 is because they operate in a low-margin price-conscious market, and there hasn't been enough demand for IPv6 functionality until recently to make developing and maintaining IPv6 functionality worth the expense.

I disagree. It take more processor cycles to run an address (16 bytes versus 4, per address), the address bus for the processors used in most SOHO equipment is (at best) 32 bit. For system-on-a-chip (SOC) based systems, there is no fast way to expand them ... expandable, yes ... but you require external (to the SOC) resources, which often means a slower and/or narrower bus. Most SOHO equipment has a fairly small amount of available RAM; every address-based table would expand by at least eight more bytes per entry (likely sixteen because of source-destination pairs per entry). The systems were designed to handle things in an IPv4 world, they were "sized" to the IPv4 world. Many / most will operate with IPv6, but they won't be as fast, regardless of the efficiencies gained (if any, depending on the application) by IPv6.

Newer stuff will probably be designed and sized to handle both flavors, but the older IPv4 stuff will not run as well on IPv6 and may not have the resources to move from IPv4 to the newer standard.

 

[theevilsharpie]

I disagree. It take more processor cycles to run an address (16 bytes versus 4, per address), the address bus for the processors used in most SOHO equipment is (at best) 32 bit. For system-on-a-chip (SOC) based systems, there is no fast way to expand them ... expandable, yes ... but you require external (to the SOC) resources, which often means a slower and/or narrower bus. Most SOHO equipment has a fairly small amount of available RAM; every address-based table would expand by at least eight more bytes per entry (likely sixteen because of source-destination pairs per entry). The systems were designed to handle things in an IPv4 world, they were "sized" to the IPv4 world. Many / most will operate with IPv6, but they won't be as fast, regardless of the efficiencies gained (if any, depending on the application) by IPv6.

With IPv6, you would have to store the IPv6 header in memory, look up the destination address in the routing table, and then send the packet on its way. If the route is running a stateful firewall, it will store state information about the connection in memory. Other than state tracking information, once the packet has been handled, the memory it used can be freed for the next packet.

With IPv4, you would have to store the IPv4 header in memory. For an outgoing connection, the router needs to check if the packet needs "special" handling to work with NAT. Outgoing connections will need to stored in a NAT tracking table, and the source address re-written with whatever address is being used for NAT. As part of this process, the router also needs to keep all available source ports in memory, and needs to keep track of which connection is using which source port. When an IPv4 router receives a packet destined for an internal host, it needs to look up whether that connection has an existing state, and if so, it then it needs to re-write the destination address with the address of the internal host.

IPv4 with NAT requires more processing power due to all of the lookups and address manipulation that it has do do, and it requires more memory because of all the shit it has to track to ensure that traffic flows are directed to the right internal host.

If we were just talking straight IPv4 and IPv6 routing, then I could see IPv4 being less computationally intensive under certain circumstances, all other things being equal. IPv4 with NAT vs. IPv6? The only way IPv6 will use more resources is if the IPv6 stack is broken.

 

[lif_andi]

No, it isn't. It's an optional extension, just like in IPv4.

IPv6 headers are more efficient to process (in theory) than IPv4 headers, but they are not smaller.

IPv4 allows multiple addresses per host.

IPv6 doesn't have a dedicated broadcast function, but it has default multicast groups whose memberships are wide enough that transmitting a packet to those groups is effectively the same as broadcasting. In addition, unless the underlying Layer 2 switch supports MLD snooping, IPv6 multicasts will be sent out as Layer 2 broadcasts. While I don't dispute that IPv6 lacks broadcasts, using it as an advantage over IPv4 is questionable, as the efficiency gains from forcing the use of multicasts instead of broadcasts are entirely dependent on how much effort networked application vendors put into limiting the size of their multicast groups.

You may be right about all those things, I'm no expert, not even by a longshot. However, the CCNA study guide written by Todd Lammle suggests to me all those things and more (which I couldn't be bothered to search for and write up) are the advantages of IPv6 over IPv4. What I wrote up is what the book says are true, and were part of my learning for the CCNA so until I advance further in my studies, this is fact for me 🙂

Edit: Looked up the part about IPsec, and it seems that originally it was written into the IPv6 standard, but as of 2005 was only a recommendation.

A quick web search had this to say about the advantages of IPv6 over IPv4:

"
No more NAT (Network Address Translation)

• Auto-configuration
• No more private address collisions
• Better multicast routing
• Simpler header format
• Simplified, more efficient routing
• True quality of service (QoS), also called "flow labeling"
• Built-in authentication and privacy support
• Flexible options and extensions
• Easier administration (say good-bye to DHCP)"

Just a random website: http://www.webopedia.com/DidYouKnow/Internet/ipv6_ipv4_difference.html

In any case I think its fair to say that IPv6 is a better protocol than IPv4, and once it has become the "norm" it will function better than IPv4 ever did. This is not to say that IPv4 is not good, it's just old. A protocol that was initially created in the 70s and is still THE standard for internet routing 30-40 years later is good, in fact very good, but it can sure use an update and that is what IPv6 is.

 

[jersiq]

Carrier NAT doesn't happen in the US outside of shitty WISPs, and it won't happen on a large scale.

There are still unassigned /24s available from ARIN. There are also unused blocks that can be reclaimed. I worked for a university for a while that had a /16 and assigned a static public IP to every single node within the network. Forcing people who were over-allocated to clean up their networks and be responsible will add years to IPv4.

Also, when people talk about IPv4 exhaustion and that all IP blocks have been used, they're being intentionally misleading. IANA has allocated all blocks to RIRs, yes. However, the RIRs still mostly have available blocks to assign to end users who need them...yes, even RIPE and AFRINIC. If you can justify it, you can still get a /24 or potentially larger block in the US. ARIN has made justification more rigorous, but anyone can still do it.

Carrier NAT doesn't happen in the US outside of shitty WISPs, and it won't happen on a large scale.

There are still unassigned /24s available from ARIN. There are also unused blocks that can be reclaimed. I worked for a university for a while that had a /16 and assigned a static public IP to every single node within the network. Forcing people who were over-allocated to clean up their networks and be responsible will add years to IPv4.

Also, when people talk about IPv4 exhaustion and that all IP blocks have been used, they're being intentionally misleading. IANA has allocated all blocks to RIRs, yes. However, the RIRs still mostly have available blocks to assign to end users who need them...yes, even RIPE and AFRINIC. If you can justify it, you can still get a /24 or potentially larger block in the US. ARIN has made justification more rigorous, but anyone can still do it.

Baloney. I have worked for a mobile ISP, which I can guarantee isn't a tiny WISP. Nat was running at 250:1 roughly. Mobility is a pain, and IPV6 provides much needed relief.

Expect much more IPV6. LTE operators are running dual stack on the internet connectivity, and the IMS connections are all IPV6. This will likely include peer points between providers as it just makes more sense considering the quantity of mobile devices in use and operators plans for VOIP.

 

[theevilsharpie]

Auto-configuration

IPv4 has stateful and stateless autoconfiguration. The advantage of IPv6's stateless configuration is that, because it's based on the MAC address, the stateless address is predictable and permanent, and the likelihood of colliding with another address is small.

No more private address collisions

IPv6 has private address space, and there is nothing preventing addresses in this space from colliding.

True quality of service (QoS), also called "flow labeling"

Flow labeling is a component in a QoS system, not "true QoS."

Built-in authentication and privacy support

This is part of IPSec, and as mentioned above, it's not built-in.

Easier administration (say good-bye to DHCP)

DHCPv6 is available, and is required for all autoconfiguration needs beyond IP and DNS settings.

Just a random website: http://www.webopedia.com/DidYouKnow/...ifference.html

Maybe instead of relying on the words of others, you should try it out for yourself 🙂

 

[drebo]

Flow labeling is a component in a QoS system, not "true QoS."

To add to this, nothing says anyone needs to honor these values. Similarly to DSCP, I can send whatever values I want upstream, but the carrier isn't likely to do shit about it and will probably rewrite them to 0 anyway.

 

[VirtualLarry]

Carrier NAT doesn't happen in the US outside of shitty WISPs, and it won't happen on a large scale.

So Verizon DSL is a "shitty WISP" now?

Edit: Reference:
http://forums.verizon.com/t5/High-Speed-Internet-DSL-and-Dial/Carrier-Grade-NAT-CGN/td-p/560237

 

[lamedude]

Remove the W and its correct. Verizon not wanting to spend an extra $ for their copper customers isn't a surprise.

 

[cmetz]

VirtualLarry,

>IPv6 failed, you say? Ok then, what about the fact that there are twice as many IPv6-connected nodes as last year.

Twice a trivial minority is still a trivial minority.

>And if IPv6 is a failed experiment, I shudder to think of the alternatives... carrier-grade NAT for everybody? No true peer-to-peer internet anymore?

That ship sailed years ago. Most residential customers are behind a SOHO PAT router/firewall today. Many commercial customers are behind a PAT firewall today. Many wireless customers are behind a PAT today.

Carrier-Grade NAT is about the unfortunate but currently inevitable next step, which is where your ISP doesn't even give you one public IPv4 address by default. As much as it might churn the stomach of anyone who cares about networking (it does me!), it will work just fine for your average residential or mobile customer, and it will buy us a LOT of pressure reduction on address space.

Add to this SNI for TLS, and maybe crack down on the silly SEO nonsense, and work on reclaiming dark parts of /8s, and we've got even more pressure reduction.

>To me, the failure of IPv6 would be the death of the internet as we know it. I really don't want that to happen.

Death of Internet predicted. Film at 11.

Seriously - gloom and doom predictions predate the IPngWG. We find a way to keep the bits flowing. It's gonna be ugly - usually is 🙁 - but we'll find a way.

IPv6 is too much change, too painful+expensive to deploy, completely fails to solve serious problems actually affecting ISPs, solves problems that don't need solving, there's no actual transition strategy since the IPv6 folks have an insane anti-PAT religion, and meanwhile we can just keep kluging on the edge to buy us time for years to come.

So I'd bet heavily on kluge we will.

I've heard your arguments in support of IPv6 and why we have to do it. The problem is that I've heard them for 20 years now. At some point, the market has spoken, and it's time to cut the loss and figure out what we're REALLY going to do.

 

[cmetz]

Mobility is a pain, and IPV6 provides much needed relief.

Expect much more IPV6. LTE operators are running dual stack on the internet connectivity, and the IMS connections are all IPV6. This will likely include peer points between providers as it just makes more sense considering the quantity of mobile devices in use and operators plans for VOIP.

This is the most realistic way that I see IPv6 getting deployment. As a real Internet WAN technology, I don't see it. But between the handset and the mobile gateway (which is basically just a CGN)... this I totally can see. In a LTE world, the fact that it's not routable directly between the carrier's internal network and the rest of the Internet might be considered a feature, not a bug.

I heard that several Asian ISPs are doing something similar - using IPv6 for the inside of the carrier-grade PAT. It probably causes the IPv6 folk who have anti-NAT religion all sorts of heartburn, but it's a somewhat realistic and deployable.

 

[theevilsharpie]

Add to this SNI for TLS, and maybe crack down on the silly SEO nonsense, and work on reclaiming dark parts of /8s, and we've got even more pressure reduction.

SNI is a non-starter as long as a non-trivial amount of users still use browsers that don't support it, SEO isn't going anywhere, and the IANA has no legal authority to reclaim any "dark" /8's.

IPv6 is too much change, too painful+expensive to deploy, completely fails to solve serious problems actually affecting ISPs, solves problems that don't need solving, there's no actual transition strategy since the IPv6 folks have an insane anti-PAT religion, and meanwhile we can just keep kluging on the edge to buy us time for years to come.

So I'd bet heavily on kluge we will.

I've heard your arguments in support of IPv6 and why we have to do it. The problem is that I've heard them for 20 years now. At some point, the market has spoken, and it's time to cut the loss and figure out what we're REALLY going to do.

The IPv6 Internet is already here and functioning. The only thing holding back adoption are support on the endpoint nodes (both client and server), and support within applications, and all are slowly adding support for IPv6 as hardware and software are upgraded.

CGN is part of the transition to IPv6, and CGNs are being deployed alongside IPv6 as carriers upgrade their networks. CGN breaks a non-trivial amount of applications, so the maintainers of those applications will have a very strong incentive to enable IPv6 support in their applications if they haven't already. In addition, CGN hides even more information about end-users, and companies that rely on recording that information (like ad networks and any applications they support) will have a strong incentive to get their products and services running over IPv6.

In short, while you claim that CGN is the "alternative" to IPv6, I'd wager that's it more of a catalyst for IPv6 adoption. Few people have any incentive to use IPv6 because IPv4 works for everything, but CGN will change that, and the limitations of IPv4 (and the costs they impose) will become readily apparent. Hell, even ISPs don't like CGNs, as their use exposes ISPs to additional liability for the content that flows through their networks.

 

[Gryz]

• IPSec is included in the standard.
• Roaming capabilities are greatly enhanced.
• Smaller headers which are aligned with 64-bit allowing much greater processing and lookup speeds.
• Allows multiple addresses per each host.
• Enhanced routing efficiency.
• Expanded use of multicast communication.
• No broadcasts at all.

Can't say much about roaming. But at the routing level, I don't think there's anything in the RFCs that really does something that is not possible with IPv4 too. I'd be glad to be proven wrong, but please include a link to a spec.

64-bit Alignment has nothing to do with speed. That's not where the performance is.

Enhanced routing efficiency ?
What ? Please explain.
Are you talking about the forwarding paradigm ? Because IPv6 has exactly the same forwarding paradigm as IPv4. Hop-by-hop, longest match prefix routing. Exactly the same.
Or are you talking about routing protocols ? Because IPv6 uses BGP4 and IS-IS, exactly the same as IPv4. And OSPFv3, which is exactly the same as OSPFv2, but with longer prefix fields.
This is my personal biggest gripe with IPv6. The fact that a new protocol introduced exactly *zero* improvements over the old technology. Zero. Nada. Nothing.

Expanded use of multicast communication ? Only when sending "broadcasts" on the local link. There is a small benefit, because not everyone needs to spend cycles on their NICs to check the packet. But on most bridged networks, the multicast frames still need to be flooded everywhere. (Causing burden on bridges, and taking away bandwidth on every segment).

The biggest problem with IPv6 is exactly that it is *NOT* better anywhere than IPv4. Therefor the only benefit is the larger addressspace. Which benefits others, in the future, maybe. If IPv6 had any significant benefits over IPv4, it had been getting larger penetration a decade ago.

IPv6 is a missed opportunity.
I still think there's only a 50/50 chance it'll really make it. Just like I thought 10 years ago.

 

[Gryz]

About memory usage.
I don't think the memery usage of IPv4 and IPv6 will be so different. If IPv6 doesn't use NAT, it'll use a firewall with ACLs. And use more memory there. The size of addresses isn't that much of a deal, compared to all other overhead.

If there is a memory constraint, it is because the low-end routers will have to have enough memory to run IPv4 and IPv6 at the same time. You can't blame one or the other.

Where memory constraints are maybe a concern, is on high-end and mid-end routers. Those routers use a special type of memory for their forwarding tables. Called TCAM. That is very expensive memory, about 10 times more expensive than regular memory. Because IPv6 addresses are 4x bigger, with overhead, it turns out that you can fit only half the number of IPv6 prefixes in your forwarding tables than IPv4 prefixes. How much this impacts real life depends on the situation.

 

[theevilsharpie]

Enhanced routing efficiency ?
What ? Please explain.

IPv6 headers are guaranteed to be 40 bytes, and extension headers are guaranteed to align to a 64-bit boundary, which makes it easier to build IPv6 ASICs.

IPv6 packets don't require the computation of checksums.

Numerous functions that were traditional performed by intermediate routers in IPv4 (e.g., MTU lookup and packet fragmentation) are required by spec to be handled by the end nodes in IPv6.

Although this isn't an inherent feature of IPv6, the large IPv6 address space allows network operators to more easily segment their networks in a hierarchical manner, which requires fewer global routing entries.

 

[Gryz]

I use the words "routing" and "forwarding" for two different things. I use "forwarding" when I talk about taking a packets from an input interface, do a table looking, and queue it for the output interface. I use "routing" when I talk about stuff to do with routing protocol, and deciding where to send packets to.

IPv6 headers are guaranteed to be 40 bytes, and extension headers are guaranteed to align to a 64-bit boundary, which makes it easier to build IPv6 ASICs.

IPv4 headers are almost guaranteed to be 40 bytes too.
Only when there are options, the header is longer. And surprise, surprise, nobody uses options. The few packets that do, you bump them to the slow path. No big deal. This works fine today. Also, I really don't think it's easier to build IPv6 forwarding ASICs.

Edit: Intermezzo.
The first hit in google, when searching for "ipv6 ipv4 forwarding performance asics".
http://www.cisco.com/en/US/prod/col...ps708/product_data_sheet09186a0080159856.html
Same piece of hardware: does 400 Mpps of IPv4 packets, or 200 Mpps of IPv6 packets. In other words: IPv6 has half the performance.

IPv6 packets don't require the computation of checksums.

Big deal. Most people who mention this, have no clue how computational hard it is to do the header checksum when forwarding an IP packet. Wanna take a guess how many instructions this is ?

Numerous functions that were traditional performed by intermediate routers in IPv4 (e.g., MTU lookup and packet fragmentation) are required by spec to be handled by the end nodes in IPv6.

Modern client IP stacks all do IP PATH MTU discovery. So not a big difference. I'm not sure what all those "numerous" other functions are. I think it's exaggerated.

Although this isn't an inherent feature of IPv6, the large IPv6 address space allows network operators to more easily segment their networks in a hierarchical manner, which requires fewer global routing entries.

This is myth.
http://blog.ioshints.info/2010/02/ipv6-myths.html
Short explanation by Ivan Peplnjak:

IPv6 will reduce IP routing tables. Not true. IETF had 15 years to solve multihoming issues, but failed to do so. SHIM, SCTP ... are still in a very experimental stage. If anything, the situation will only get worse, as everyone will try to get PI address space.

And I agree. Because IPv6 routing is exactly the same as IPv4 routing, the global IPv6 table will be just as big as the current IPv4 table. If not bigger.

 

[theevilsharpie]

IPv4 headers are almost guaranteed to be 40 bytes too.
Only when there are options, the header is longer. And surprise, surprise, nobody uses options. The few packets that do, you bump them to the slow path. No big deal. This works fine today. Also, I really don't think it's easier to build IPv6 forwarding ASICs.

An IPv4 header without options is 20 bytes. However, it can be longer if options are present, and since options are valid part of the IPv4 spec (regardless of how rarely they're used), an IPv4 with an ASIC designed for 20-byte headers needs to check to verify that the header is indeed 20 bytes before processing it. IPv6 requires no such check.

The fact that ASIC-powered IPv4 routers even have a "slow path" should be a huge clue that designing accelerated IPv4 routers involves some degree of complexity beyond the ASIC. Accelerated IPv6 routers have no need for a "slow path" because all IPv6 headers are guaranteed to be the same size, and headers are also guaranteed to align on an octet bounder (IPv4 has no such guarantee).

Big deal. Most people who mention this, have no clue how computational hard it is to do the header checksum when forwarding an IP packet. Wanna take a guess how many instructions this is ?

IPv4 requires the computation of checksums, which requires at least one instruction, and may require up to n instructions. IPv6 doesn't require a checksum, so it requires zero checksum computation instructions. Even if an IPv4 router only requires a single instruction to compute a checksum, that's still infinitely more than zero. In addition, this checksum needs to be recomputed by every node in the path.

Modern client IP stacks all do IP PATH MTU discovery. So not a big difference.

Modern client IP stacks attempt to do PMTUD, but it's not a requirement of the spec, and so many network operator block or otherwise mangle IPv4 ICMP that IPv4 PMTUD can't be relied upon to reliable set the MTU for the traffic flow. As such, intermediate routers still need to check if the packet needs to be fragmented, and they also need to process existing fragmented packets to ensure that they send them down the wire in the right order.

This is myth.
http://blog.ioshints.info/2010/02/ipv6-myths.html
Short explanation by Ivan Peplnjak:
And I agree. Because IPv6 routing is exactly the same as IPv4 routing, the global IPv6 table will be just as big as the current IPv4 table. If not bigger.

A big part of the reason why the IPv4 routing table is so bloated is because organizations have had to continually request new IP address allotments as their network needs grow, and these allotments are very unlikely to be contiguous. A network operator cannot possibly structure their network addressing in a fully hierarchical manner if they have discontiguous IP addresses. IPv6 largely avoids this problem by having such a large address space for a typical assignment that additional allotments are unnecessary for reasonable growth.

You can see the impact of this efficiency on the current size of the global IPv6 routing table. The IPv6 routing table is only about 3% of the size of the current IPv4 routing table, even though about 16% of the registered AS's on the Internet are advertising at least one IPv6 prefix.

Edit: Intermezzo.
The first hit in google, when searching for "ipv6 ipv4 forwarding performance asics".
http://www.cisco.com/en/US/prod/col...ps708/product_data_sheet09186a0080159856.html
Same piece of hardware: does 400 Mpps of IPv4 packets, or 200 Mpps of IPv6 packets. In other words: IPv6 has half the performance.

So an ASIC designed to route 20-bytes headers at 400Mpps routes 40-byte headers at 200Mpps?

No shit.

You can't use an ASIC designed for IPv4 routing as a benchmark for IPv6 performance. It's obviously going to favor the IPv4 use case.

LTFS went to other other extreme, and tested IPv6 performance on an old Linksys WRT54GL running DD-WRT. Now, before you scoff, consider the following:

1. The Linksys WRT54GL is a pure software router--no ASICs involved that could sway performance to any one protocol.
2. DD-WRT is running Linux, which has reasonably mature IPv4 and IPv6 stacks, so performance is not going to be swayed by an unoptimized IPv6 stack.
3. The Linksys WRT54GL is bottlenecked by its CPU and is unable to route at line-speeds, so any differences in efficiency between the protocols will become immediately apparent.

The result? Greater throughput and lower packet loss was achieved with IPv6 in all cases. The only advantage IPv4 achieves was lower latency.

 

[freegeeks]

I work for an European ISP, we are in the processing of doing a full blown IPv6 rollout. The USA does not equal the world. RIPE has run out of ipv4 basically, all you can get is a measly /22, good luck with that. CGN is giving a very bad user experience so that's a no-go. We will run dual stack for as long as we can and eventually go ipv6 only

 

[Gryz]

The fact that ASIC-powered IPv4 routers even have a "slow path" should be a huge clue that designing accelerated IPv4 routers involves some degree of complexity beyond the ASIC.

IPv6 has a slow path too.
In any case, sometimes you need to be able to "punt" packets to the control plane. E.g. when you receive packets destined for yourself. (Ssh, SNMP, BGP, IS-IS, OSPF, etc). Or packets that generate an error (ICMP).

Accelerated IPv6 routers have no need for a "slow path" because all IPv6 headers are guaranteed to be the same size, and headers are also guaranteed to align on an octet bounder (IPv4 has no such guarantee).

That nonsense about "octet-boundery" and "64-bit aligned" keeps coming back. I heard the same nonsense about "OSPF has all IP-fields on a 4-byte boundary" and IS-IS has them all over the place (because of TLV-encoding). Guess what ? It doesn't matter one bit. In fact, the fact that OSPF had all its fields are fixed locations made the protocol a pain to deal with.

When you design a forwarding ASIC, you should design an ASIC that.
1) take N bits from location L in an incoming packet.
2) does a lookup for longest match prefix in a table (radix-trie or TCAM)
3) queue the packet on an output queue.

It shouldn't matter where those bits live. I won't believe that alignment would matter much.

IPv4 requires the computation of checksums, which requires at least one instruction, and may require up to n instructions. IPv6 doesn't require a checksum, so it requires zero checksum computation instructions. Even if an IPv4 router only requires a single instruction to compute a checksum, that's still infinitely more than zero. In addition, this checksum needs to be recomputed by every node in the path.

The IP header checksum is literally a sum. It adds the value of all (20) bytes in the header (modulo 256 of course). The only change in the header when forwarding a packet, is that the TTL gets decremented by 1. That results in the fact that the IPv4 header checksum also gets decremented by 1. Ergo: all you need to adjust the IPv4 header checksum is 1 single instruction: decrement the TTL octet by one.

One instruction. And if you don't want to check the headerchecksum, then don't do it. If you think it's not needed in IPv6, then it won't do much good in IPv4 either. One instruction, in the big bulk of route-lookup, firewall checks, NAT (maybe), QoS, queueing, etc. It's nothing. Mentioning the fact that IPv6 has no header checksum shows that you took your list from a list on the Internet, and didn't do you own thinking.

Modern client IP stacks attempt to do PMTUD, but it's not a requirement of the spec, and so many network operator block or otherwise mangle IPv4 ICMP that IPv4 PMTUD can't be relied upon to reliable set the MTU for the traffic flow. As such, intermediate routers still need to check if the packet needs to be fragmented, and they also need to process existing fragmented packets to ensure that they send them down the wire in the right order.

And still I don't think fragmentation is a big deal.

A big part of the reason why the IPv4 routing table is so bloated is because organizations have had to continually request new IP address allotments as their network needs grow, and these allotments are very unlikely to be contiguous.

That was the case 25-20 years ago.
In the early nineties, there was the CIDR-initiative. The goal was to summarize prefixes better, and reduce the amount of entries in the global routing table.

Then it turned out you need to advertise extra entries in the globabl routing table if you want to multi-home your site. And this has been done on a large scale. In the early nineties the global routing table kept stable in size for a short while (because of CIDR). And then it started to grow again, because of multi-homing.

You are right that in theory IPv6 would allow for much better summarization. But in reality, it's just a big a mess as IPv4. And because it's easier to get PI addresses in IPv6, chances are we will see many more PI-prefixes advertised in the global IPv6 routing table. Of course you need to wait and see the full effect when (if) IPv6 gets really popular.

You can see the impact of this efficiency on the current size of the global IPv6 routing table. The IPv6 routing table is only about 3% of the size of the current IPv4 routing table, even though about 16% of the registered AS's on the Internet are advertising at least one IPv6 prefix.

Just wait till more non-ISPs get their own prefixes.

So an ASIC designed to route 20-bytes headers at 400Mpps routes 40-byte headers at 200Mpps?
No shit.
You can't use an ASIC designed for IPv4 routing as a benchmark for IPv6 performance. It's obviously going to favor the IPv4 use case.

That's a linecard designed for both IPv4 and IPv6. And the result is that it can forward less pps with IPv6. What more do you want ?

A similar discussion sometimes happened with MPLS. MPLS forwarding does a simple table-lookup O(1) in a small array. People were boasting that this was much faster than an IPv4 lookup. And thus that MPLS forwarding was much faster than IPv4 forwarding. Guess what, it's hype. It doesn't matter. If you use the right datastructure (tree with nodes with 256 pointers down) the cost of doing a route-lookup is O(4). In real life, it doesn't matter at all.

3. The Linksys WRT54GL is bottlenecked by its CPU and is unable to route at line-speeds, so any differences in efficiency between the protocols will become immediately apparent.

If that is the case, and the box can't do simple forwarding at line-speed, it has more issues to worry about. (Like performance when you enable a few features, like QoS).

Anyway, it is still my opinion that IPv6 brings nothing valuable to the table. Besides a larger address space. No real problems (like multi-homing, on the fly-readdressing, locator-identifier separation, et) are tackled by IPv6. It was a missed opportunity to improve the network layer.