Re: [Softwires] IPmix I-D version 01.

Khaled Omar <eng.khaled.omar@outlook.com> Wed, 14 November 2018 11:04 UTC

Return-Path: <eng.khaled.omar@outlook.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6B512D4EB; Wed, 14 Nov 2018 03:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 3rCemTMkR86N; Wed, 14 Nov 2018 03:04:17 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03olkn082c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A71C12D4E7; Wed, 14 Nov 2018 03:04:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xuYORMgA7zEEYgRdGFlN9T3FIGL3E1BILXuMtCO6mus=; b=LoEoJMxnwlAuNYWpyEB7OvV5YbuOKXET/AHNA2XptVKybOrisSX3V4FZEzqP8Ls92mKOr9YRCVqJ/MKfT3qs2zcTLJLlDgi4qOgPBpRvIL2S58WrhvB66HKfP4T6J1jrtenRXqz/+Uwe5fHXzuModOQCFutzxYawClPpk4q4Ae8KI3y6LxsUPAf6wvqusgty2D7bnU8WOIkuT3FQSeV/qiUFB86kuDCMG6FC+MwyQ2nqUEhhz37d7FmFuPQpwq8ZZwdL5M832fjZqGTEerTIKnMf4ltd4i0puHaKrbcYSN3l2nufGrQddWN+OGM6FiJnJ7ZKp2GU9ekpio4PjsWdGQ==
Received: from VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com (10.152.18.59) by VE1EUR03HT175.eop-EUR03.prod.protection.outlook.com (10.152.18.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10; Wed, 14 Nov 2018 11:04:14 +0000
Received: from HE1PR0402MB2937.eurprd04.prod.outlook.com (10.152.18.59) by VE1EUR03FT044.mail.protection.outlook.com (10.152.19.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10 via Frontend Transport; Wed, 14 Nov 2018 11:04:14 +0000
Received: from HE1PR0402MB2937.eurprd04.prod.outlook.com ([fe80::952e:86d2:1940:cb70]) by HE1PR0402MB2937.eurprd04.prod.outlook.com ([fe80::952e:86d2:1940:cb70%10]) with mapi id 15.20.1294.045; Wed, 14 Nov 2018 11:04:14 +0000
From: Khaled Omar <eng.khaled.omar@outlook.com>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>, "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: IPmix I-D version 01.
Thread-Index: AdR7XlR6bx8kmBBsROK5EeYebaelZgAlvT6AAAIDCoA=
Date: Wed, 14 Nov 2018 11:04:14 +0000
Message-ID: <HE1PR0402MB293774D01A1C350A21ADC884AEC30@HE1PR0402MB2937.eurprd04.prod.outlook.com>
References: <HE1PR0402MB29377F0DD1854F1786FC67ACAEC20@HE1PR0402MB2937.eurprd04.prod.outlook.com> <78c52356-7d3e-21cc-ca3e-5e237fb4d55d@kit.edu>
In-Reply-To: <78c52356-7d3e-21cc-ca3e-5e237fb4d55d@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:596BEF745231BC3121AE2207BC5681102464C59F13B769366501B18124000EF6; UpperCasedChecksum:1047A14134FA6EBFFC7E1FD7E745776BF39846AC5D82AE739E676A666E1DE84B; SizeAsReceived:7152; Count:45
x-tmn: [g1NZKNLcUk56UyGjn7saOvFPLy4nj9G1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VE1EUR03HT175; 6:m2kefuMidsQZk36v9uulgkhTCS7c2Xsr3hofdOwmPVAZcc+v5vYce4uZAnIdwSGhaXr12AuEeGNNAZFvRd7Q5Dpp5ZeyCWxSXjuFVFmx2X7wyf1/daOwo7yEgNLFg+aP8L6xvozRbFJLZMXfu1w5PnFHv9i2mfvYjQVVCr1Vof1Bg3P/4TSC5d1YzNarWZVjB7HLqghIVxc3MesLaok78divdhUxVkefF4Z+InPrY4INAKbYBCYaA5LLl43x1idFrctnNlONNLrct9EL2OZrsqJZqparpm02TA8Ipxbrke7mbEh5xysOnDgItFhB6d1NictMZlw5JyYxdxznaiHM+9WuWTFNL59wM1hIIigUzxCEv2Xj2fbPyHm/BCCE3TPKxwcoiED1aKymaAohE9oyUFYk/hzcau5I3diNCsQq2Hzt1N+ZYO+JN93uAB5ncmcvZrZBIwyVd9MVy3sTX1NcQg==; 5:2B0AqHKfvIrOE3aB1mGtKr719F6cgFB7e+xO8ytFwzUWfT2GQalKEvRWmh7VrMYIJlHtAE1oNbhAA+y0Ql6Peay0s5SOssCcC2yV6gMzyIAjlWHF78pA6/CgTHxfTFr7aXwUNWSETttAdhccKKEFAhIBnY0u13z6Qv65Rx+jSG8=; 7:LQps5D0B2NhwwT/KNpj8D45I9YAfp8c6MndyAcd2XfcIG3OmYgV4cS7mgjnFFYOncwRcjEOGmH0Mqvqo9fBMU6uhrOFhdkc4RH5+qWz/Nw5Uw2HnybG9OFPXlADeNuyemUA9f6BAHp+62UuOkEkswQ==
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:VE1EUR03HT175;
x-ms-traffictypediagnostic: VE1EUR03HT175:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:VE1EUR03HT175; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR03HT175;
x-microsoft-antispam-message-info: apXGaOffjUjk9KJQXBbGDzv/fSPXF2Hd+3bkdWxUnWoZktJAkwGdVLrViHD4nvPm
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8
X-MS-Exchange-CrossTenant-Network-Message-Id: a81c54b6-b5fe-4e6d-a6c0-08d64a20ea0c
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2018 11:04:14.5150 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR03HT175
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/v6e0nkHy5EkKQXq5nkokQK1eAnU>
Subject: Re: [Softwires] IPmix I-D version 01.
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2018 11:04:21 -0000

Hi Roland,

Let's take it step by step, first I'm not asking the IETF to publish the document as an RFC as version 01, there are more to add.

> This is simply wrong: "IPv4 only" and "IPv6 only" hosts would not be able to speak IPmix by definition of "only". This is a fundamental contradiction in your proposal. 

"Only" means the assigned IP address for the host is either IPv4 only or IPv6 only.

> If an IPv4 host would be upgraded with IPmix, there is no reason to not let it upgrade to IPv6 and be it a dual stack host. Problem solved.

IPmix is not an address as IPv6 to be assigned, the host will not be upgraded but it will be updated.
IPv6 requires efforts from the client side that's why IPv6 took more than 23 years and until now no full action are taken, IPmix does not, clients are not required to do anything, if you are using IPv4 only, keep using it, but the "system" should be updated to support IPmix, which is easier than deploying IPv6.

> Introducing something like IPmix would be more difficult than simply deploying IPv6.

For now, these are the requirements to call a host an IPmix host:
For IPv4-only hosts --> The only requirement is that the IPv4 packet be replaced by the IPv6 packet and the IPv4 address be replaced by the IPv4-embedded IPv6 address and the host can understand an IPv6 address and insert it in the destination IP address (system update).
For IPv6-only hosts --> The only requirement is that the host can understand an IPv4 address and replace it by an IPv4-embedded IPv6 address and the host can handle the packet normally (system update).

All these two requirements requires no efforts from the client side, they don't have to do anything more than accepting the updates.

> IPv4 only hosts would never be able to reach the whole IPv6 address space.

Who said never, it is achieved in this I-D, it is true without modification to the IPv4 host.
 
> For IPv6 only hosts we have NAT64/DNS64 to let them talk to the IPv4 world.

Does this support communication using IP address rather than hostnames?
Does this requires a "public IPv4 address" on the external interface of the NAT64 device?

> BTW: There are still remnants of IPv.. in the document (sections 4.2 and 7). Please remove them in any future versions as it will confuse people outside the IETF.

Modified.

Regards,

Khaled Omar


-----Original Message-----
From: Bless, Roland (TM) [mailto:roland.bless@kit.edu] 
Sent: Wednesday, November 14, 2018 10:38 AM
To: Khaled Omar <eng.khaled.omar@outlook.com>; v6ops@ietf.org; ipv6@ietf.org; softwires@ietf.org
Subject: Re: IPmix I-D version 01.

Hi Omar,

> Your feedback will be appreciated for the submitted version of the 
> IPmix I-D.

I couldn't see any substantial changes, so there are still the same issues with this proposal:
- The draft states: "It solves the issue of allowing IPv6 only hosts to
  communicate to IPv4 only hosts and vice versa in a simple and very
  efficient way."
  => This is simply wrong: "IPv4 only" and "IPv6 only" hosts would not
  be able to speak IPmix by definition of "only". This is a fundamental
  contradiction in your proposal.
  If an IPv4 host would be upgraded with IPmix, there is no reason to
  not let it upgrade to IPv6 and be it a dual stack host. Problem
  solved.
- Introducing something like IPmix would be more difficult than simply
  deploying IPv6.
- IPv4 only hosts would never be able to reach the whole IPv6 address
  space
- For IPv6 only hosts we have NAT64/DNS64 to let them talk to the IPv4
  world

All these issues have been mentioned before. If you don't consider them, don't expect any more comments.

BTW: There are still remnants of IPv.. in the document (sections 4.2 and 7). Please remove them in any future versions as it will confuse people outside the IETF.

Regards
 Roland