IETF Logo Mail Archive

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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Wed, 08 May 2019 10:39 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 D9ED112003E for <ipv6@ietfa.amsl.com>; Wed, 8 May 2019 03:39:48 -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 J11gNXu8GpO2 for <ipv6@ietfa.amsl.com>; Wed, 8 May 2019 03:39:46 -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 22FA112001E for <ipv6@ietf.org>; Wed, 8 May 2019 03:39:46 -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 m1hOJzC-0000FlC; Wed, 8 May 2019 12:39:42 +0200
Message-Id: <m1hOJzC-0000FlC@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> <a2465e81-a17f-ab48-efda-20fe12a70077@foobar.org> <30239E0C-C444-4A7E-8342-AEE47BF8A2BB@employees.org> <20190505200449.GB7546@vurt.meerval.net> <80073906-c3c0-1f22-9e7f-c2b349063936@gmail.com> <CAO42Z2xzVW3m0mN7jEn8SYyYCYhrufVnkfp3rBjJcijBkvucNQ@mail.gmail.com> <CACWOCC-35yVYXSRR0sRL-MBMHyOFZtJx9E9h14G8qqVh5T7qGA@mail.gmail.com> <232c1a43-0fd9-4eae-737b-260a3906f72a@gmail.com> <51F2BD2A-A590-4AF1-B8C1-FE62C9416340@steffann.nl> <8C63324F-FEF6-40BD-B918-B413CDEF9186@gmail.com> <BC988F7C-B262-4FF3-929A-02E6BCCE2266@steffann.nl> <BC23F51B-4135-47C6-B22F-8AE5CD8CB6F6@lists.zabbadoz.net> <m1hO4j3-0000IYC@stereo.hq.phicoh.net> <2980d6ed-c718-1f99-e203-cfdfe0c372c0@gmail.com>
In-reply-to: Your message of "Wed, 8 May 2019 11:50:30 +1200 ." <2980d6ed-c718-1f99-e203-cfdfe0c372c0@gmail.com>
Date: Wed, 08 May 2019 12:39:42 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BlJ00ffqAncf0EyeBhWCtGfkEm4>
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: Wed, 08 May 2019 10:39:49 -0000

>> But nobody is doing any work on what IPv4 should look like in the future.
>
>I don't understand that sentence. IPv4 is a legacy protocol,
>so it will simply fade away.

If we are ready to let it fade then we would not be discussing a draft that
modifies IPv4 behavior claiming that it is good for (among others)
battery life.

Yes, just let IPv4 fade away and kill this draft. We don't need new protocol
that deals with IPv4.

>The nail has never been unknown, but some people claim it's too
>small to be worth hammering.

The nail has changed. Early on in sunset4 it would just disable IPv4
unconditionally. Over time the nail has become smaller and smaller and now
we have text basically doesn't mandate anything anymore.

>>   Because there is no analysis from an IPv4 perspective, we don't actually
>>   know if this draft is needed and how much effect it will have. 
>
>We know that we're talking about a few percent of the traffic on an
>IPv6-only network. Quantifying the effect on battery life is not
>a reasonable task.

The draft has two bullet points on battery. Battery life of hosts has been
used often to argue for this draft. And now the effect cannot be quantified?

Maybe it is time to actually start with a problem statement that can be
measured?

Of course the same applies to how big of an issue the extra network 
traffic is.

>It's unclear to me what that accident might be, apart from what is
>already in the security considerations.

The security section does not mention accidents. There is a risk that somebody
will accidentally turn this flag on on a official router. In the field it is
very unlikely that people will relate weird IPv4 failures to something that
is sent in an RA.

I don't know if the security considerations are intentionally incomplete,
but they clearly reflect the hammer looking for a nail. Maybe the authors
can take the time to actually experiment with the draft and have 
somebody look at it who knows about security.

v2.23.0 | Report a Bug | By Email