[Int-area] Review of draft-omar-ipv10-01
Christian Huitema <huitema@huitema.net> Sat, 01 April 2017 23:19 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B666127337 for <int-area@ietfa.amsl.com>; Sat, 1 Apr 2017 16:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcfycWgPuBGa for <int-area@ietfa.amsl.com>; Sat, 1 Apr 2017 16:19:49 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAD31201F2 for <int-area@ietf.org>; Sat, 1 Apr 2017 16:19:49 -0700 (PDT)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cuSJ9-0004lw-Vq for int-area@ietf.org; Sun, 02 Apr 2017 01:19:49 +0200
Received: from internal.xmail02.myhosting.com ([10.5.2.12] helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1cuSJ0-0007mm-Nm for int-area@ietf.org; Sat, 01 Apr 2017 19:19:39 -0400
Received: (qmail 26428 invoked from network); 1 Apr 2017 23:19:37 -0000
Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.160]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <int-area@ietf.org>; 1 Apr 2017 23:19:37 -0000
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
X-Originating-IP: 168.144.250.177
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.35)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrqQH3GdejsBzdIhzsyD8+3RcOb18WfxGyg6Om6u4YYmySxOhwEqHBVZiN+ 25LatPQ5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0R/z5ctp0 Xk6w2p7umgr8+bbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/gkjqdXk6qmyDQ4w/U/UBMWgxFIzsjPI5quM 23m6o9WaGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+UENvSgP50fgFRnQVhHNu8xf/tvEsq8ECzFNZ6L8s8pn
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/b4njm-bB7QxuYCza_5zvxJ34ahg>
Subject: [Int-area] Review of draft-omar-ipv10-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Apr 2017 23:19:52 -0000
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