Monthly Archives: October 2014

IPv6 in a Global Company – a response: NPTv6?

This is a response this post by Ivan. In summary he is talking about the issues companies will face if they wish to use IPv6 and multi-home. Leaving aside the fact the most Small/Medium Enterprises (SMEs) aren’t going to want to run BGP, the questions of NAT in IPv6 (a terrible idea) and Internet Routing table explosion remain.

I was at the IPv6 Council meeting last week and Eric Vyncke drew our attention to the experimental RFC, RFC6296, IPv6-to-IPv6 Network Prefix Translation (NPTv6). The clue is in the name; rather than translating the entire address and breaking the end-to-end communication model, translate the Prefix section of the IPv6 address and leave the Host part unchanged. Unlike NAT, NPTv6 is stateless which considerably reduces the burden on network equipment. Also ports at L4 can be left alone and asymmetric flows won’t cause an issue.

By way of a simple example, a business is assigned 2001:10::/48 Provider Independent Address (PIR) space. They are a small business with no BGP skills but would like resilience. They take out an Internet connection with two different providers and set up outbound routing however they like. Provider A gives them 2001:A::/48 and provider B allocates 2001:B::/48.

Now, any flows which egress Provider A get prefix translated to 2001:A::/48 and any going out via provider B get 2001:B::/48. For client access to the Internet this is great, hosts can use SLAAC or manually assigned addresses, troubleshooting is easy as any issues can quickly be narrowed down to a host and ISP.

For example, let’s assume the SME uses /64s for its clients. A client with the address 2001:10::baad:food:cafe:d00d is part of the first subnet of the PIR 2001:10::/48 (2001:10:0:0/64) and has a host address of baad:food:cafe:d00d. If that user accesses the Internet via provider A their source address will appear as 2001:A::baad:food:cafe:d00d, within the 2001:A::/64 subnet of provider A’s 2001:A::/48. If they egress via provider B they’ll appear as 2001:B:baad:food:cafe:d00d in B’s 2001:B::/64 subnet of 2001:B/48.

If the company wishes to run Internet facing services, then further design work would be needed with a careful consideration of the impact of different failures, but for the small business with blah blah cloud hosting, or the remote sites Ivan mentions, this RFC looks promising. Head office may choose to use NTP for client subnets and PIR for any onsite data centres, thus reducing global routing table explosion and keeping the design simple.

Admittedly I’ve cheated a bit on requirement 1 (No NAT) by replacing it with NPTv6, but requirements 2 (Ubiquitous redundancy) and 3 (Local Internet Exit) are met by this in my opinion.