Techniques for Prolonging the Lifespan of IPv4

May the road rise up to meet you, may the wind be ever at your back and may you outlive IPv4

1 2 Page 2
Page 2 of 2

DS-Lite can be considered a late-stage IPv6 transition mechanism to help service providers continue to conserve IPv4 address space. One of the dependencies for a service provider to implement DS-Lite is that it requires the ISP core network to be IPv6-enabled. While some service providers have implemented IPv6 in their core networks today, there are still many service providers that are still working on that deployment.

Address Plus Port (A+P)

Another technique to prolong the lifespan of IPv4 involves changing how we use 32-bit IPv4 addresses in combination with 16-bit port numbers. The technique called Address plus Port (A+P) borrows bits from the port number and uses them to augment the IPv4 address yielding more public IPv4 addresses.

This is an address-sharing technique that reduces the port number range and allows multiple hosts to statefully share a single public IPv4 address. Each node is assigned the shared IPv4 address and a port-range that its applications may use. A+P is standardized in IETF RFC 6346 titled "The Address plus Port (A+P) Approach to the IPv4 Address Shortage".

One of the advantages of this technique is that it avoids the problems of a centralized CGN/LSN solution in the service provider's environment. A+P also helps to maintain the end-to-end nature of TCP/IP and allows for forensics and tracebacks. The downside is that applications may need to be re-written so that they use the restricted range of source TCP/UDP port numbers properly.

There are several implementations of A+P available today (RFC 6346 Section 3.4). There needs to be a signaling mechanism to communicate to the end node which IPv4 address it should use and the port range it should use. One proposed port-range signaling technique is "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation". The other problem is that A+P only works for applications that use TCP/UDP port numbers. For example, ICMP will not function properly because it does not use a port number to borrow bits from to use to uniquely distinguish the source address.

IPv4 Address Sharing

One idea that I have thought of before is the idea of performing even greater address sharing techniques. What if your device only had an IPv4 address when it had something to send to/from the Internet? This would be like having a very short-term IPv4 address lease. Other times when your device was "dormant" then it would release its IP address for use by another end-user device. Think of this as DHCP with a lease-time of 60ms.

This reminds me of the video that Cisco created titled "IPv6 - Are you Ready?" You can think of this as an IPv4 address equivalent of a vacation time share. You only have an IPv4 address when you have something to send (like interesting traffic). This is the ultimate combination of time domain multiple-access, packet-based networking, and statistical multiplexing.

This might work for mobile devices that do not need an IP address while its owner sleeps. This might be a workable solution so long as this temporary IPv4 address leasing is done quickly enough to not impact end-user performance. It could be too much for a system like this to work with Dynamic DNS (DynDNS). Furthermore, this is not an ideal solution for a service that needs a FQDN that resolves to a fixed IP address that doesn't change over time.

Locator ID Separation Protocol (LISP)

As the Internet strives to drive greater efficiency of the use of IPv4 addresses the size of blocks of IPv4 addresses advertised to the Internet will get smaller. The problem with IPv4 that causes this issue is that IPv4 uses a single 32-bit namespace where the address represents the location of the node on the network and its point of attachment.

This leads to deaggregation of the addressing space as the Internet becomes more densely populated. This fragmentation of the IPv4 address space will cause the Default Free Zone (DFZ) Internet routing tables to dramatically grow in size.

Today the Internet is closing in on 400,000 IPv4 prefixes, but over the next 10 years this could grow dramatically. In order to prolong the lifespan of IPv4 we need a technique that can help us with the scalability of the Internet routing tables.

One technique that can ease this growth is Locator/ID Separation Protocol (LISP). LISP is a network architecture that splits the namespace into two sections: one used for the routing (Routing Locator (RLOC)) and one used for the end-node (Endpoint Identifier (EID)). This technique separates the topology location on the Internet from the identifier of the single node on the Internet, hence the name.

The other aspect of LISP is that it is a technique for mapping and encapsulating (map and encap) packets on the Internet. The RLOC is the IP address of the LISP router and the EID packets are encapsulated in the RLOC's packets as they are sent to the Internet. Therefore, you can think of LISP as an "over-the-top" tunneling method adding a 32-byte UDP port 4341 LISP header.

There is also a mapping service that uses UDP 4342 packets, and similar to DNS, that will resolve the EIDs to locators defined in the mapping database. One of the advantages to LISP is that it does not require any modifications to the end-systems.

Only the routers are aware of these tunnels and the name mapping/lookups. As such, LISP is considered an "over the top" technology that can operate on an IPv4 or IPv6 network. The LISP IETF working group has been working on this architecture for many years. There are many drafts of the standard and the various components of the protocol but there are no RFCs yet.

Another advantage for LISP is that it has broad vendor support. Cisco has been supporting LISP extensively. Facebook has been using LISP and has used it for IPv6. LISP is implemented in FreeBSD with OpenLISP.

Other companies like Qualcomm, VeriSign, Microsoft, Verizon and Wells Fargo are experimenting with LISP. Furthermore, LISP is already running on the Internet and there is a functional LISP beta network. Imagine if the effort that is being put into LISP were being put into helping the world migrate to IPv6. Would that work have resulted in a bigger long-term impact over simply development of a tunneling technique?

Host Identity Protocol (HIP)

Another "two-space" technique is the Host Identity Protocol (HIP). This technique inserts a shim between the IP header and the transport header that contains the "Host Identifier" and "Location" of the end-system. HIP is an IETF experimental standard defined in RFC 4423 "Host Identity Protocol (HIP) Architecture" and RFC 5201 "Host Identity Protocol".

The down-side to this approach is that it requires changing the IP stack within the operating system and applications and changes to DNS to add new resource records. Applications need to be modified to use the HIP names space rather than IPv4 or IPv6 addresses. The other limitation is that these Host IDs are cryptographic public keys so we need a global PKI to make this functional on the Internet. The industry already had to endure a decade of adding IPv6 to operating systems so another stack modification seems daunting at best.


Regardless of whether these techniques are a good idea or not, it will take a lot of time before these solutions are viable. The CGN/LSN techniques required stable vendor products and service provider deployments. The IP stack shim techniques require software to be integrated into all the popular operating systems and network devices across many manufacturers in an interoperable way.

Just look at how much time it has taken to get IPv6 capabilities into the broad range of systems available today. Even if someone came up with a great idea today it would take several years before it was available for ubiquitous deployment on the global Internet. If you think the Internet is in bad shape now, we just can't wait 5-10 years from now for the hot-new-idea to be ready for deployment.

Time is wasting while the industry works on techniques to prolong IPv4. While we argue and try to look at alternatives, time is passing by and IPv4 addresses are growing increasingly scarce. Any of the other techniques that we can come up with here at the last minute are just "too little, too late".

Many people would like to "do the right thing" and help preserve the Internet for everyone to use. Some people want to create an economic advantage for themselves. Others are lazy and have not learned about IPv6 and these alternatives enough to help their organizations make an informed decision on the topic. Many people seem to be delaying the decision as they try to see how IPv4 address exhaustion applies to them or how they can make money in these market conditions.

This seems to be distracting us from the only alternative that will result in a unified and interoperable Internet. Fall is coming and the weather is changing. In Colorado, where I live, summer basically gives way directly to winter. A few weeks ago the temperature was 80(f)/27(c) and last week it snowed. With winter fast approaching it is important to "Be Prepared" (Boy Scout motto) and not wait until the last minute.

It is far better to be knowledgeable about these alternatives rather than be clueless. The same is true for planning your organization's Internet Protocol version 6 (IPv6) transition. Today is a great day to get started on your transition strategy. Whether we like the idea of transition to IPv6 or not, we may be in a situation to "love the one you're with" and IPv6 is the only possibility at this point in time. However, now our backs are against the wall and we have no choice but to jump directly to dual-stack. Scott

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2011 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2