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

From: Christian Huitema <[email-masked]>
Date: Sat, 1 Apr 2017 16:19:35 -0700

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

---

From: Khaled Omar <[email-masked]>
Date: Sun, 2 Apr 2017 00:19:30 +0000

This review is unofficial but thanks for the initiative.

Let me clarify many things:

> 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.

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 "native IPv4 addresses" but the 96 zero bits are to make the packet size fixed, and the requested updates should makes devices extract the native IPv4 address when the 1st 96-bits are zeros, because for IPv6 there is no IPv6 address starts with zeros and ends with IID, but full zeros is ok and this is not our case, devices will be intelligent to differentiate and extract the pure IPv4 address. 

> The author makes many claims of interoperability and deployment properties, but does not present any interoperabilty mechanism between "IPv10" and legacy IPv4 nodes.

True, but you have to understand that there is no communication between IPv10 and IPv4 or IPv10 and IPv6, the communication is between IPv6 and IPv4, all should be IPv10 hosts.

> 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.

What about the IPv6 migration? ... it requested the whole world to change their existing network to another version, with a new address structure, what this hard work will bring for those poor people after this migration? ... any solution will request modification, and the more applicable modification makes a better solution, updating all existing nodes is not a hard request, at least, the poor people will not get involved in solving a problem that they never did.

I will not give more replies to your review because they have been repeated many times earlier, but thanks for your time.

Before I forget, in 1995 I was 9-years old, so I didn't realize what the IETF was doing, but from reading their produced standards, the IPv6 RFC 2460 states the date when IPv6 became a standard, I can't guess when actually that proposal was issued.

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Sunday, April 2, 2017 1:20 AM
To: [email-masked]
Subject: [Int-area] Review of draft-omar-ipv10-01

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 2 Apr 2017 08:10:20 +0200 (CEST)

On Sun, 2 Apr 2017, Khaled Omar wrote:

> What about the IPv6 migration? ... it requested the whole world to 
> change their existing network to another version, with a new address 
> structure, what this hard work will bring for those poor people after 
> this migration? ... any solution will request modification, and the more 
> applicable modification makes a better solution, updating all existing 
> nodes is not a hard request, at least, the poor people will not get 
> involved in solving a problem that they never did.

Khaled, I admire your energy. I just wish you would direct it in a more 
productive direction. Implementing a new on-wire format is a 10-20 year 
process in todays Internet with many many billions of hosts and network 
devices.

Christian made some interesting observations, and I think you should read 
his email again. The interesting point he made was that your proposal 
basically uses the IPv6 on-wire format. This means that if re-think your 
solution to instead work within the IPv6 packet format (because it's by 
now a lot easier to IPv6 enable the rest of the hosts on the Internet, 
than it is to IPv10-enable all the hosts).

The biggest problem is that we have IPv4-only hosts on IPv4-only Internet 
access. This is the real problem. If they can be upgraded to IPv10, they 
can be upgraded to IPv6, solving the problem with a solution that is 20 
years old, instead of one that is currently on the drawing board (IPv10). 
But now, if they can't and they need to interoperate, then we need to use 
IPv4<->IPv6 translation mechanism. There are numerous of these in the 
IETF. If you have an idea how to do that which is better than what has 
already been proposed, then I (and most likely others) are very interested 
in hearing about it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Khaled Omar <[email-masked]>
Date: Sun, 2 Apr 2017 13:24:29 +0000

> I understand that is what you are saying, but you are failing to listen to what others are telling you. If we could magically upgrade software and hardware on all legacy IPv4 nodes, we would have converted all of them to IPv6 long ago.

If there is a better solution introduced, I would follow it with pleasure.

> I am concerned by the way this discussion is going. Specifically, I am concerned that you will end up embittered by the rejection of your proposal. I have seen that happen before. A young researcher presents what he believes is a brilliant idea, reviewers point out major flaws, and after the rejection the young researchers either marginalizes himself, or abandons the field of networking. I would much rather help you work on your next proposal!

Rejecting my proposal is not my decision, I'm waiting for the official decision and will accept it regardless what it is, then I will make my decision regarding sharing my ideas with the IETF or not.

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: Sunday, April 2, 2017 3:05 AM
To: Khaled Omar
Subject: Re: [Int-area] Review of draft-omar-ipv10-01

> True, but you have to understand that there is no communication between IPv10 and IPv4 or IPv10 and IPv6, the communication is between IPv6 and IPv4, all should be IPv10 hosts.

I understand that is what you are saying, but you are failing to listen to what others are telling you. If we could magically upgrade software and hardware on all legacy IPv4 nodes, we would have converted all of them to IPv6 long ago.

I am concerned by the way this discussion is going. Specifically, I am concerned that you will end up embittered by the rejection of your proposal. I have seen that happen before. A young researcher presents what he believes is a brilliant idea, reviewers point out major flaws, and after the rejection the young researchers either marginalizes himself, or abandons the field of networking. I would much rather help you work on your next proposal!

-- Christian Huitema