Methods of servicing legacy IPv4-only nodes with an IPv6-only core<\/p>\n
In the\u00a0first part of this 3-part blog series<\/a>, we discussed how IPv4 will soon become a legacy protocol.\u00a0 In a few years,\u00a0IPv6 Internet traffic volumes will surpass IPv4 Internet traffic volumes<\/a>.\u00a0 We also explored the motivation for service providers to build an IPv6-only core network yet still fulfill their obligations to connect customer IPv4-only devices to the Internet.\u00a0 We must remember that, even though we may be striving for a near-term dual-protocol transition strategy, the\u00a0long-term strategy is to run an IPv6-only environment<\/a>.\u00a0 This article is going to continue by exploring how this will be accomplished while also peering into what is going on behind the scenes (from the subscriber\u2019s perspective) in the service provider network.<\/p>\n These\u00a0transition mechanisms<\/a>\u00a0for providing IPv4 as a Service (IPv4aaS) require some changes to the service provider\u2019s network architecture.\u00a0 This can include some form of\u00a0Carrier Grade NAT<\/a>\u00a0(CGN) or\u00a0Large Scale NAT<\/a>\u00a0(LSN)\u00a0NAT44<\/a>\u00a0function at their Internet edge due to the\u00a0shortage of public IPv4 addresses<\/a>.\u00a0 The service provider is allowed to use the shared IPv4 prefix 100.64.0.0\/10 (RFC 6598<\/a>) for these transition purposes.\u00a0 Most of these IPv4aaS techniques require some form of encapsulation and tunneling of the subscriber\u2019s legacy IPv4 packets across the service provider\u2019s IPv6-only core network.\u00a0 These techniques must also consider how to perform\u00a0Lawful Interception<\/a>\u00a0(LI) and session logging for local and national Law Enforcement Agencies (LEAs).<\/p>\n Some of these techniques require some changes to the software running on the device at the customer\/subscriber edge.\u00a0 This could involve changes to the\u00a0DSL Modem<\/a>\u00a0or the\u00a0DOCSIS<\/a>\u00a03.1 cable modems and\u00a0eRouters<\/a>.\u00a0 However, today, most consumer home routers support IPv6 (RFC 7084<\/a>), particularly if they are the higher-end routers that\u00a0have 802.11ac wireless<\/a>.\u00a0 Getting your\u00a0home network connected with IPv6<\/a>\u00a0isn\u2019t as difficult as you might expect, but you would want to make sure that your legacy IPv4-only systems remain operational in the near-term.<\/p>\n There are also ISPs who are actively planning on establishing an IPv4aaS offering.\u00a0 Brian Field Ph.D., with Comcast gave a great presentation at last year\u2019s\u00a0NANOG64<\/a>\u00a0on the \u201cMotivation, Analysis, and Architecture for IPv4aaS<\/a>\u201d describing this concept from their perspective.\u00a0 He has also written a paper on the topic of \u201cApproaches for IPv4 as a Service (2015)<\/a>\u201d.\u00a0 John Jason Brzozowski, Fellow and Chief Architect, IPv6 for Comcast Cable has\u00a0published a presentation about their IPv6-only plans<\/a>\u00a0and given a\u00a0presentation at RIPE72<\/a>.\u00a0 Comcast\u2019s plans include taking\u00a0Software-Defined Networking<\/a>\u00a0(SDN) techniques like Fast Data Input Output (fd.io<\/a>) and their\u00a0Vector Packet Processor<\/a>\u00a0(VPP) combined with\u00a0Segment Routing<\/a>\u00a0over an IPv6 core.<\/p>\n The protocol architects at the IETF have been considering this IPv4aaS concept for many years now and have been working on establishing several different techniques for tunneling IPv4 across an IPv6-only ISP infrastructure.\u00a0 The IETF has established the \u201cSoftwires<\/a>\u201d (softwire) working group that is chartered with developing ways to seamlessly carry IPv4 over IPv6 core networks.\u00a0 What follows are descriptions of the various methods of accomplishing an IPv4 as a Service network.<\/p>\n Encapsulating one type of packet within another creates a tunnel-type experience for the inner packet.\u00a0 It is as if it went into an intergalactic wormhole and miraculously emerged in the next dimension over what seemed like a single hop, but in reality, the packet traversed many parsecs.<\/p>\n In the early days of IPv6, it was envisioned that IPv6 packets would be encapsulated in IPv4 (RFC 4213<\/a>) on their way to their ultimate IPv6 destination.\u00a0 Early tunneling transition mechanisms like 6over4 (RFC 2529<\/a>), 6to4\u00a0(RFC 3056<\/a>), Teredo (RFC 4380<\/a>), ISATAP (RFC 5214<\/a>), and 6rd (RFC 5969<\/a>) were developed.\u00a0 It has also been possible to use Generic Packet Tunneling in the IPv6 Specification (RFC 2473<\/a>) to carry IPv6 packets within IPv4.\u00a0 This was a method that was created before\u00a0Generic Routing Encapsulation<\/a>\u00a0(GRE) and was officially standardized in\u00a0RFC 2784<\/a>.\u00a0 The original\u00a06bone<\/a>\u00a0IPv6 testbed used this technique to tie together early IPv6 researchers.\u00a0 Ironically, the\u00a0IANA assigned IP protocol number<\/a>\u00a0for encapsulating IPv6 packets in IPv4 packets is 41, which precedes the protocol number for encapsulating IPv4 packets in IPv4 with GRE, IP protocol 47.<\/p>\n Now we have full \u201cIPv6 Support for Generic Routing Encapsulation\u201d (GRE) (RFC 7676<\/a>) and an ISP would be able to use this technique to create an IPv4aaS offering.\u00a0 This is a simple technique that just reverses the original IPv6 transition mechanism: i.e., instead of joining islands of IPv6 across an ocean of IPv4 by putting the IPv6 packets in an IPv4 boat, we inverse the method.\u00a0 Now we are talking about joining solar systems of IPv4 across a galaxy of IPv6 by thrusting the IPv4 packets into the IPv6 \u00a0wormhole for their voyage across the intergalactic Internet.\u00a0 GRE could be used within the subscriber\u00a0CPE<\/a>\u00a0device and encapsulate all IPv4 packets within IPv6 packets, traverse those GRE packets across the service provider\u2019s core, and then use a GRE tunnel termination system to decapsulate the IPv4 packets and send them to the Internet.\u00a0 This function could optionally be combined with a CGN\/LSN NAT function.<\/p>\n One of the first techniques conceived to transport IPv4 across an IPv6-only core is\u00a0Dual-Stack Lite<\/a>\u00a0(DS-Lite).\u00a0 DS-Lite was defined by\u00a0RFC 6333<\/a>\u00a0as a method of leveraging IPv6 for the service provider core as IPv4 address exhaustion occurred.\u00a0 The way that DS-Lite works is the subscriber CPE will have a Basic Bridging BroadBand (B4) element that encapsulates IPv4 packets within IPv6 packets.\u00a0 IPv6 packets from the subscriber are handled natively across the ISP\u2019s IPv6-only core.\u00a0 These encapsulated connections are handled with the per-session state maintained per subscriber to a central CGN gateway called the Address Family Transition Router (AFTR).\u00a0 Get it?\u00a0 B4 (before) and AFTR (after).<\/p>\n The AFTR terminates the 4in6 tunnels from the B4 elements and performs the CGN\/LSN translation.\u00a0 To be able to scale to many subscribers, the AFTR requires significant compute and throughput resources.\u00a0 The B4 elements use a\u00a0DHCPv6<\/a>\u00a0Option for Dual-Stack Lite (RFC 6334<\/a>) to help the B4 element learn its global IPv6 address.\u00a0 The IETF has documented \u201cDeployment Considerations for Dual-Stack Lite\u201d (RFC 6908<\/a>) and there are \u201cRADIUS Extensions for Dual-Stack Lite\u201d (RFC 6519<\/a>).<\/p>\n One advantage with DS-Lite is that subscribers can have overlapping IPv4 address space.\u00a0\u00a0IANA<\/a>\u00a0has set aside the IPv4 address block 192.0.0.0\/29 and documented it as the \u201cIPv4 Service Continuity Prefix\u201d (RFC 7335<\/a>) for this exact purpose.\u00a0 The overlapping IPv4 subnets are separated statefully by the fact that they are wrapped in globally-unique IPv6 addresses.\u00a0 However, the down side to DS-Lite is that it requires changes to the subscriber CPE.\u00a0 If an ISP is going to go through all the trouble and cost to replace CPE, they could just as easily replace it with dual-protocol CPE to help speed up IPv6 adoption.<\/p>\n The IETF is continuing to develop new IPv4 as a Service standards.\u00a0 The IETF has finalized an RFC for \u201cLightweight 4over6: An Extension to the Dual-Stack Lite Architecture\u201d (RFC 7596<\/a>).\u00a0 As the name implies, it is a modification of DS-Lite whereby the NAT function occurs on the B4 element instead of on the AFTR element.\u00a0 This adjustment to the DS-Lite architecture alleviates the NAT44\/NAPT per-client state maintenance from the AFTR element. \u00a0Additionally, there is no centralized stateful CGN\/LSN function performed.\u00a0 Moving the NAT function to the B4 CPE element decouples the binding between the IPv4 and IPv6 addresses.\u00a0 This Lw4o6 method still maintains per-subscriber state for the provisioning of the IPv6 tunnels carrying the subscriber\u2019s legacy IPv4 packets inside.\u00a0 With the Lw4o6 method, the central system is referred to the lwAFTR and the CPE element is referred to as the lwB4.<\/p>\n The Lw4o6 method can leverage \u201cDHCPv4-over-DHCPv6 (DHCP 4o6) Transport\u201d (RFC 7341<\/a>) or the alternative \u201cDynamic Allocation of Shared IPv4 Addresses\u201d (RFC 7618<\/a>) to facilitate providing the shared IPv4 address to the lwB4 element using an IPv6 core infrastructure.\u00a0 Early Lw4o6 research results were published at\u00a0IETF 85 in 2012<\/a>\u00a0and the IETF is continuing its work on this method by documenting \u201cDeployment Considerations for Lightweight 4over6<\/a>\u201d.<\/p>\n The IETF has also published an RFC titled \u201cPublic IPv4-over-IPv6 Access Network\u201d (RFC 7040<\/a>).\u00a0 This is an informational RFC related to work done at the China Next Generation Internet (CNGI) and China Education and Research Network 2 (CERNET2).\u00a0 This RFC emphasizes that this is a specific implementation of IPv4 over IPv6, but any new deployment of an IPv4aaS should use Lightweight 4over6 instead.<\/p>\n In this Public 4over6 method, the CPE is referred to as a 4over6 CE and the central tunnel concentrator is referred to as a 4over6 BR.\u00a0 This method uses public IPv4 addresses for the subscriber and completely avoids any NAT function.\u00a0 Therefore, there is no IPv4 address sharing but the tunnel concentrator still maintains per-subscriber binding state of the subscriber\u2019s public IPv4 and global IPv6 addresses.<\/p>\nProviding IPv4 as a Service<\/h2>\n
GRE over IPv6<\/h2>\n
Dual-Stack Lite (DS-Lite)<\/h2>\n
Lightweight 4over6<\/h2>\n
Public 4over6<\/h2>\n
Part 3<\/h2>\n