IPv10 – a Joke or a Serious RFC Draft?

IPv10 – a Joke or a Serious RFC Draft?

    Recently, a new Internet draft – Internet Protocol Version 10 (IPv10) attracted attention of network enthusiasts. People on the Internet forums often ask if the draft represents a new milestone in the deployment of the IPv6 protocol, allowing peaceful coexistence of both IPv4 and IPv6 protocols. Other people suggest that the draft is another work falling into a category of  April Fool’s pranks. We still remember a joke with a title A Historical Perspective On The Usage Of IP Version 9 that was released on the 1st of April 1994. Interestingly, ten years later, the IPv9 was mentioned again. According to the news, the IPv9 compatible with IPv4 and IPv6 protocols should have been adopted and popularized in the civil and commercial sector in China.

    IPv9 China

    Picture 1: China Deploys IPv9 Network.

    Before we say our final judgment about IPv10 let us mention several facts discussed in the draft. As we know, the draft is currently in version 9 and it is published by a single author.  According to the words of its creator, the draft is designated to allow IP version 6 to communicate to IP version 4 and vice versa. It is worth adding that the new protocol is in version 10 because the header of IPv10 packet can contain both IPv6 and IPv4 addresses (IPv6 + Ipv4).

    The source and destination address fields in IPv10 packet are the same length as IPv6 addresses – 128-bits. For IPv6 to IPv6 communication, the source and destination address fields inside the IPv10 packet contain IPv6 addresses. For packets sent from IPv6 to IPv4 hosts, the source address field contains an IPv6 address inside the IPv10 packet. The destination address field is constructed of 48-bits of zeros followed by the 48-bits MAC address of the sending host and ended with 32-bits IPv4 address. The leading 48-bits of zeros indicate that there is 32 bit IPv4 at the end of the destination address. According to the author, the sender MAC address inside IPv10 packet can be used for host identification. However, the draft does not discuss the benefit of inserting layer 2 information into the layer 3 header of the IPv10 packet. For communication between the IPv4 hosts, both source and destination 128-bit addresses contain 48-bits leading zeros, the sender MAC address and the 32-bits IPv4 address. The sender MAC address information is then doubled as it is inserted into both source and destination address fields.

    For routing IPv10 packets, both IPv4 and IPv10 stacks must be enabled on all routers. When a router receives an IPv10 packet, it should use either the IPv4 or IPv6 routing table based on the destination address within the packet. When the destination IP address is IPv6 type, the router uses the IPv6 routing table to make a routing decision. Similarly, when the router receives IPv10 packet containing an IPv4 address in the destination address field, a router uses the IPv4 routing table.

    From what we see above, every host on the Internet must have both IPv4 and IPv6 installed in order to forward IPv10 packets. As the author of the draft says, all Internet connected hosts must be IPv10 hosts to be able to communicate regardless the used IP version. Also the IPv10 deployment process can be accomplished by ALL technology companies developing OSs for hosts networking and security devices. Several questions arise immediately. Why vendors should bother to implement a new and unknown IPv10 protocol if still both IPv4 and IPv6 stacks must be installed on every device? Dual-stack is a well known transition mechanism and with the addition of a new IPv10 stack, we would have triple-stack instead. How can millions of existing legacy IPv4-only devices easily be upgraded in order to teach them to insert IPv4 address into the 128-bits address fields? The strategy obviously introduces a new problem instead of solving the existing one.

    The question is: how could IETF approve and post a draft like this? Well, first we need to understand that anyone can submit an Internet draft to the repository. Internet drafts are valid for 6 months unless they are replaced by the updated versions. After six months, drafts are removed from the repository or are being reviewed by the Internet Engineering Steering Group (IESG) and later published as RFCs. As we can see, there is a huge gap between a posted draft and a final RFC document.

    Second, the good ideas can come from anywhere.  Although the IPv10 draft is not useful at all, it might reflect the author’s frustration with slow IPv6 adoption. The protocol has been with us since 1995 (IP Version 6 Addressing Architecture RFC1884). According to Google’s statistics, maximum availability of IPv6 connectivity among Google users between January 2009 and September 2017 has risen to 21%. Hence, the IPv10 draft represents the author’s attempt to solve this serious problem.

    IPv6 users

    Picture 2: Percentage of Users that Access Google Over IPv6.

    Conclusion: Different Internet drafts were written for different purposes. For instance, Warren Kumari’s draft describes a collapse of an ancient Egyptian industry caused by arrival of the bearded Atlanteans who brought mass quantities of lightly tanned eel leather into Egypt. The draft suggests that all ASCII based IETF protocols should use the phrase “Don’t allow eel bearing Atlanteans into your country; economic ruin follows close behind” as the payload of Hello messages and monitoring protocols. The author chose a funny and creative way to educate readers not to assume that the existence of the draft means that “IETF thinks” or “IETF is planning” or the draft is supported by IETF. The certain drafts represent real solutions of various problems and are being standardized as RFC documents. Regardless of the category the IPv10 draft falls into, IPv6 has been growing much faster over the last years using transition mechanisms such as dual-stack, NAT64 and tunneling. However, we can only hope that one day we will live in a world where isolated IPv4 islands are tunneled across IPv6 Internet.

    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP


    Leave a Reply