RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).

"Tony Hain" <> Wed, 28 December 2016 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FC36129499 for <>; Wed, 28 Dec 2016 11:23:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.891
X-Spam-Status: No, score=-4.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1056-bit key) reason="fail (OpenSSL error: data too large for modulus)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3AfiFPIpgnkQ for <>; Wed, 28 Dec 2016 11:23:22 -0800 (PST)
Received: from ( [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50EA712945D for <>; Wed, 28 Dec 2016 11:23:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:Cc:To:From; bh=K96C5WEpx85qhCL50BX/Fqqy+THNAIGdCGpBELwhzu4=; b=Aw6TQ0EZXPSmYBzhsqTnhi7K33oyEqLU+kUeGXmC1WOz/LKHPxM4SxFyGw7nFXLc2kVCKatCzhU+ZdqjpqnH7LZtVOeF2vFa2Eoe7LqzjE/ZjwHYC2t3ymZ8YJuEDGfSDClSH2IY6msQGqpjvvPPVZdsEbjKSh/hIcVJeQA6b0OhhIYI;
Received: from ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1cMJoE-000C1r-7b; Wed, 28 Dec 2016 11:23:18 -0800
From: "Tony Hain" <>
To: "'Leonir Hoxha'" <>, "'Ladislav Lhotka'" <>, "'Khaled Omar'" <>
References: <> <> <>
In-Reply-To: <>
Date: Wed, 28 Dec 2016 11:22:46 -0800
Message-ID: <049f01d2613f$c5431ef0$4fc95cd0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFaOFGhXEa08ucczGwOPi0ChXdXLwF2CENOAaDHoImh9UjJsA==
Content-Language: en-us
X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a
Subject: RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Dec 2016 19:23:23 -0000

Leonir Hoxha wrote:

> Hi Khalid,
> Are you aware what you are proposing!!?
> Those RFCs are incorporated into all the Vendors for many years now. 
> Hundreds of Experts have been working on these Protocols, and you just
> want them to obsolete? 
> What is your value proposition, I have read your letter, but honestly it 
> doesn't give me any feeling that it is a real solution.
> We do have IPv6/IPv4 already talking to each other, why do you think an 
> additional Address Family would make our life easier?
> Please consider this, and try to answer these questions to yourself.
> And last, please STOP sending mails to, this is not the right way to do it.

On the contrary, the calls for someone to stop sending work that is outside the scope of any existing working group to this list are "not the right way to do it". If you believe this belongs in an existing group, redirect as appropriate. If this is truly a new protocol and doesn't fit alongside existing work, it belongs here to help determine consensus about forming a new working group. 

That said, at best this belongs in v6ops as a transition approach. In reality, it is inconsistent with itself to the point where it can't be implemented, even if you wanted to. The section 3 descriptions use variable length headers, while the section 4 description of the proposed "new protocol" header is fixed length. Independent of that, the author has not recognized existing technology (RFC 4921 Sections & that does more than what this draft is proposing despite being pointed at that a month ago. 

Finally, this proposal does nothing to solve the problem it identifies, legacy IPv4 hosts in the enterprise environment that will not migrate. There appears to be an unstated assumption that administrators of legacy hosts will make the changes necessary for this inconsistent and underspecified proposal, despite the demonstrated fact that they are unwilling to make the well documented changes to deploy IPv6 because they simply refuse to make a change, or to  learn something new. 

In the beta version of Windows XP I made sure IPv6 was ON-BY-DEFAULT, with no knob to turn it off, because I knew that given the option enterprise administrators would turn it off. I lost the battle in the shipping version though, and sure enough the first things that showed up on search engines were instructions for how to turn IPv6 off. The lack of deployed end systems limited the willingness of app developers to bother making their changes, which in turn fed the resistance to change by the intermediate network administrators. Fast forward to the point where IPv6 is required, and forcing the changes outward from the middle is proving to be as difficult as predicted. The IPv10 proposal does nothing to solve this fundamental problem, and actually amplifies it by removing what clarity there is in dual-stack network administration and diagnostics.