[Int-area] Review of draft-omar-ipv10-01

Christian Huitema <huitema@huitema.net> Sat, 01 April 2017 23:19 UTC

To: "int-area@ietf.org" <int-area@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <68d4f945-8ece-45b0-ed4b-51847720740f@huitema.net>
Date: Sat, 01 Apr 2017 16:19:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/b4njm-bB7QxuYCza_5zvxJ34ahg>
Subject: [Int-area] Review of draft-omar-ipv10-01
Precedence: list

Since there has been lots of exchanges on the list, I decided to
actually write a review of draft-omar-ipv10-01.

This "IPv10" proposal  can be summarized as a version of IPv6 in which
the source and destination addresses will be either native IPv6
addresses, or IPv6 addresses with embedded IPv4 addresses. The author
makes many claims of interoperability and deployment properties, but
does not present any interoperabilty mechanism between "IPv10" and
legacy IPv4 nodes.. As such, I find the draft both unnecessary, since it
mainly restates an existing option of the IPv6 protocol, and
unconvincing, since it basically relies on a magical update of all
existing nodes. I don't see value in pursuing discussion of this draft
in the IETF.

The short draft starts with a description of Internet evolution as
perceived by the author, Omar Khaled, which he uses to motivate the
introduction of a new Internet Protocol, which he calls "IPv10". Section
2 makes a number of assertions about the supposed qualities of IPv10.
Section 3 presents the supposed advantages of the proposal, and section
10 presents the proposed "IPv10" format. This short section, exactly one
page long, constitutes the technical part of the document, and this is
where I will start my review.

The IPv10 headers can carry source and  destination addresses that will
be either IPv6 or IPv4 addresses. Specifically, the addresses can be
either 128 bit IPv6 addresses, or IPv4 addresses encoded as 96 zero
bits. The header format is identical to the IPv6 header format, with the
exception of the version field with encode whether the addresses are
IPv4 (v = 4), IPv6 ( v = 6), or a mix of IPv4 and IPv6 (v = 10).

The obvious observation is that the encoding of IPv4 addresses proposed
in the draft is exactly the "IPv6 Addresses with Embedded IPv4
Addresses" format specified in section 2.4.4 of RFC 1884, the original
"IP Version 6 Addressing Architecture" authored by Bob Hinden and Steve
Deering in December 1995. The IPv10 format expressed in the draft is
thus equivalent to the IPv6 format proposed in December 1995 in RFC
1883, with an emphasis on the "embedded IPv4 Addresses" defined in RFC
1884.

The change in protocol type proposed by the author is actually not
necessary, since the presence of IPv4 addresses is indicated by the 96
bit zero prefix of the address format. In fact, the use of the protocol
type 4 for indicating the presence of 2 IPv4 addresses is probably
dangerous, since this version is reserved for IPv4, which uses a
different header format.

After analyzing the proposed header format, I went back to review the
section 1, in which the author presents his motivations. This section is
riddled with some errors. For example, it states that IPv6 was defined
in 1998, while the drafts were produced as early as 1993, leading to RFC
1883 in 1995. More importantly, it dismisses NAT64, stating that "NAT64
requires so much protocol translations and statically configured
bindings, and also getting a DNS64 involved in the communication
process." The author is entitled to his opinions, but NAT64 is in fact
widely deployed. Also, there is no proposal in the short draft of any
mechanism letting IPv10 hosts communicate with unmodified IPv4 hosts.
Dismissing a deployed mechanism without proposing an alternative is poor
engineering practice.

This glaring omission of any interoperability mechanism with existing
hosts makes the properties and advantages claims in section 2 and 3
unsubstantiated. For example, the author claims that "IPv10 allows hosts
from two IP versions (IPv4 and IPv6)  to be able to communicate," but in
practice that would only happen if the hosts all changed their software.
The difficulty comes precisely from the existing deployed IPv4 systems,
many of which will not be able to change their software, and in some
cases their hardware. If they could be updated to a new protocol, they
could just as well switch to IPv6.

My advice to the author is that he studies the deployment constraints
that drove the  evolution towards the current NAT64 mechanisms. The
IPv10 draft is best abandoned, but there may very well be a better way
to perform the NAT64 functions. Work on that would be welcome!

-- Christian Huitema

[Int-area] Review of draft-omar-ipv10-01 Christian Huitema
Re: [Int-area] Review of draft-omar-ipv10-01 Khaled Omar
Re: [Int-area] Review of draft-omar-ipv10-01 Mikael Abrahamsson
Re: [Int-area] Review of draft-omar-ipv10-01 Khaled Omar