Category: IPv6

It seems that most people not having a vested interest in status quo agree the socket API is broken. After all, why should every single application ever written have to deal with the idiosyncrasies of two address families?

Not surprisingly, the browser vendors got sick and tired of waiting for a fixed API or a standardized session layer (nothing happened in the last two decades) and decided to implement happy eyeballs – a simple mechanism that creates two TCP sessions (one over IPv4, another one over IPv6) and uses whichever one works better.

You might not have to deploy IPv6 in your network tomorrow (if you’re an ISP I sincerely hope you do), but that’s no excuse for not getting prepared for the eventual inevitable deployment (Tom Hollingsworth has way more to say on this topic).

Don’t believe in the “inevitable” part? Maybe you should spend some time with people who were running SNA and IPX networks two decades ago and living in blissful IP denial.

A heated debate on one of the IPv6 mailing lists (more about that later) contained a gem I simply have to share with you: The importance of IPv6 application testing from Apricot 2013. Enjoy!

One of my readers sent me an interesting question:

Are you aware of any studies looking at the effectiveness of IPv6 address allocation policies? I'm specifically interested in the affects of allocation policy on RIB/FIB sizes.

Well, we haven’t solved a single BGP-inflating problem with IPv6, so expect the IPv6 BGP table to be similar to IPv4 BGP table once IPv6 is widely deployed.

Sander Steffann, Iljitsch van Beijnum and Rick van Rein recently published an amazing IETF draft comparing IPv6-over-IPv4 tunneling mechanisms. If you’re even remotely interested in this topic, the draft is an absolute must-read (and if you want to know about other transitional mechanisms, check out this webinar).

Martin Bernier has decided to open another can of IPv6 worms: how do you address multiple subnets in a very typical setup where you use a firewall (example: ASA) to connect a SMB network to the outside world?

During the IPv6 Security webinar, Eric Vyncke explained the intricate details of IPv6 Security Neighbor Discovery (SEND) and the reasons it will probably never take off.

Numerous residential access technologies face path MTU discovery issues. PPPoE connections (with MTU = 1492 bytes instead of 1500 bytes) is the best-known example, and we’ll see more of them as various tunneling-based IPv4-to-IPv6 transition mechanisms (6rd, DS-Lite, MAP-E) become more popular.

Obviously you could use the same old MSS clamping tricks in the brave new IPv6 world or decide (like DS-Lite) to deal with IP fragmentation in underlay access networks ... but there’s another option in the IPv6 world: reduce client-side MTU with router advertisement messages.

Cassidy Larson from InfoWest sent me an interesting challenge: using the sample configurations I provided in the Building Large IPv6 Service Provider Networks webinar he was getting weird DHCPv6 errors when a residential CPE device requested a delegated prefix from the BRAS router (before moving forward, have to mention how nice it is to see an US ISP deploying IPv6 ;).

Justin asked an interesting question in a comment to my IPv6 On-Link Determination post: do we need HSRP for IPv6 as the routers already send out RA messages? Pavel quickly pointed out that my friend @packetlife already wrote about it, concluding that you could use RAs unless you need deterministic sub-second failover.

However, there are (as always) a few more gotchas: