Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 09 May 2019 09:53 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5596120092 for <ipv6@ietfa.amsl.com>; Thu, 9 May 2019 02:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0thD7MxvXpFc for <ipv6@ietfa.amsl.com>; Thu, 9 May 2019 02:53:19 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 581EA120041 for <ipv6@ietf.org>; Thu, 9 May 2019 02:53:19 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1hOfjp-0000IdC; Thu, 9 May 2019 11:53:17 +0200
Message-Id: <m1hOfjp-0000IdC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <alpine.DEB.2.20.1905091054560.1824@uplift.swm.pp.se>
In-reply-to: Your message of "Thu, 9 May 2019 11:08:03 +0200 (CEST) ." <alpine.DEB.2.20.1905091054560.1824@uplift.swm.pp.se>
Date: Thu, 09 May 2019 11:53:16 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jbiDnHvsmugU75Sj3j4a5aOZot0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2019 09:53:21 -0000

In your letter dated Thu, 9 May 2019 11:08:03 +0200 (CEST) you wrote:
>An attaching host will not start IPv4 operations until it has received 
>(and decided it's received all of them) RA answers to its initial RS 
>message, because before this it doesn't know what the flag will be. This 
>will increase attachment times before a working setup can be had on IPv4 
>only links. I think this is a valid concern.

I think the proponents of this draft should create an experimental 
implementation in a mobile device (for example Andriod, but I guess a 
laptop running Linux would work as well).

And then actually try to attack that implementation and write both about
implementation guidelines and security issues.

Much better would be to just drop this draft and move on.