Re: If past ipv6 articles are anything to go by...
Actually IPv6 will reduce router memory load. The IPv4 space is heavily fragmented. IPv6 will be much less fragmented, so routing tables will have much fewer entries.
That's a theory. It's really only an issue for routers that need a full table, but you can track growth here:-
http://bgp.potaroo.net/v6/v6rpt.html
v6 has some of the same challenges as v4, ie support for PI addresses, but like for like, a v6 route is longer simply due to header length. And during transition, routers that need full tables may need to hold 2 tables (or VRFs) to support dual stacking. If v6 ends up with similar fragmentation levels as v4, then that also means RIB space, and also FIB. The RIB bloat is less challenging given that changes with routing updates (ie slow) but TCAM memory for the FIB is expensive.. Especially if you need a large FIB on an edge/peering/transit router running Nx100Gbps links. It's also more computationally expensive given you may need to read deeper to get a prefix match than you do for v4. Then there's fixed header length vs v6's 'option' fields.
(I also think v6 missed a trick by keeping v4's source-destination in the header rather than flipping that to desitination-source. After all, if you're routing/forwarding traffic, you're more interested in the where it's going than where it cam from.)
The issue with bandwidth efficiency is not significant. While it is true that there are some tiny packets flying around (ssh sessions spring to mind, with each keypress generating two packets),
Hello, cloud! That's down to looking at link utilisation and packet length distribution. But if a v4 link is currently congested, it'll be more congested if it's converted to v6 simply due to the increased header size.
Biting the hand that feeds IT
