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

Khaled Omar <eng.khaled.omar@hotmail.com> Sun, 02 April 2017 00:19 UTC

Return-Path: <eng.khaled.omar@hotmail.com>
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 8155C12785F for <int-area@ietfa.amsl.com>; Sat, 1 Apr 2017 17:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.146
X-Spam-Level:
X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 P5i-Kkw256Lq for <int-area@ietfa.amsl.com>; Sat, 1 Apr 2017 17:19:37 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068109.outbound.protection.outlook.com [40.92.68.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1106A1274D0 for <int-area@ietf.org>; Sat, 1 Apr 2017 17:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VOkpmK2MKM5LPTNOsdMJZjznoB7Q0MLZlqpZdnLdg2A=; b=fkkjGOJRc3bZAj60gcaqM6HMYcmMGw+6D1Kfx80s45zq0q/O3RPhXhpXI7gxozQ6WP/eWicAe1HTyb8jVGH9MbBlSj/CMAvQ0cV8ud1w616ewOxO3UyjS3vyc3sIq5HFqj0lwKLGOXJz2ENXF1T2KY5+T9RXbpUenZXvwbHBpV6+S+ln8deV5lTgxPl33YUeyinCjtLWZF4rPwxEH6mLOy+f2h+IG8J8m13Z7w9lg05o+dfVVYRv+X02zVLhSxWq4+kpWbEpjTu8ntvtYbL7UoDoe7BfH1aPkPkOJHMVHh40A6qCdY5ujhWA5z+J3NvVgudhWjQ/QOVQk6i9vr5dHQ==
Received: from HE1EUR02FT021.eop-EUR02.prod.protection.outlook.com (10.152.10.60) by HE1EUR02HT064.eop-EUR02.prod.protection.outlook.com (10.152.11.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5; Sun, 2 Apr 2017 00:19:31 +0000
Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.10.56) by HE1EUR02FT021.mail.protection.outlook.com (10.152.10.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.5 via Frontend Transport; Sun, 2 Apr 2017 00:19:30 +0000
Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::bd5b:1ace:ba8d:6166]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::bd5b:1ace:ba8d:6166%19]) with mapi id 15.01.1005.016; Sun, 2 Apr 2017 00:19:30 +0000
From: Khaled Omar <eng.khaled.omar@hotmail.com>
To: Christian Huitema <huitema@huitema.net>
CC: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] Review of draft-omar-ipv10-01
Thread-Index: AQHSqz58sctllBpSK0+MvF+P5B9/NKGxL+Yg
Date: Sun, 2 Apr 2017 00:19:30 +0000
Message-ID: <AM4PR0401MB2241CF29FE45A94284D466A2BD090@AM4PR0401MB2241.eurprd04.prod.outlook.com>
References: <68d4f945-8ece-45b0-ed4b-51847720740f@huitema.net>
In-Reply-To: <68d4f945-8ece-45b0-ed4b-51847720740f@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:3B2F2AE716CD502C98907131EC57BD13142C01BEDDD9C35A1C471FC5FBD1014E; UpperCasedChecksum:C4DDA1B4034D33451B8979E13AF989CF0DC9218B7C342246560DF63D211C7C6B; SizeAsReceived:8114; Count:42
x-tmn: [2bTGEqGTF9ooK9ckUV/SLbcRoMNz72tV]
x-microsoft-exchange-diagnostics: 1; HE1EUR02HT064; 5:LEuWQINxj8q3WV7T1WfFg3u1KnxAxizPgyvtvqlniGIpMBxJaSw4vxQYebZrbFlXOSMlNMSGzvXGMDrzeqv2WENA4OjzgHIwUn1dzlFaD2ZM3vC46owtrSzk7e1Tn8jcZfmkly9PFSAkzNuH1/W4DQ==; 24:aQcuPtXWvSVsObErBU56zMjVeRVb0wKvf2blWb8TBZwa8zfGLRJTsil5WQNBin5Z3ZCm2aaU421ws1zI2vQ2C7UBujNFF2LIAssgHP1Xp/M=; 7:c5MqgPsS6+RUhViIWsW3byGPBU5TX+HKIqC6oLUWuoqLRZxgkVEoi72WVOH1GN1h1F78v7JoNzwP7spXL6fsUGJs8DontdlADqhBso1wraZY46P9ouVlHDR7zLwke0g5QPQ8AMCmvLzdLHeaA3e/yaT+EOYIoKBhu76r8TlG/J5vCmys//emIh5EKVaBpJCc6uguOIpi9ecfYugOpToE6IhkCWRPF8m/i7Siz2lGLLuwVJalycH7GNgrgRn83+T/R84bU4rtAclahcXOVmpU2aJi/cRjP3tq3eILrKU1mccxblKRT7qj4lfCLHuPOVBt
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR02HT064; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: d0b599a4-fd37-4fe0-7c91-08d4795dee6e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR02HT064;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR02HT064; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR02HT064;
x-forefront-prvs: 02652BD10A
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 00:19:30.4679 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR02HT064
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/SmQhG3ygQM7L3umf3U65GIAwJas>
Subject: Re: [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: Sun, 02 Apr 2017 00:19:39 -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:int-area-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Sunday, April 2, 2017 1:20 AM
To: int-area@ietf.org
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
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area