IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 08 May 2019 19:17 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5A4EB1201BB for <ipv6@ietfa.amsl.com>; Wed, 8 May 2019 12:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 LBN4J3rKpP86 for <ipv6@ietfa.amsl.com>; Wed, 8 May 2019 12:17:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42BB81200FC for <ipv6@ietf.org>; Wed, 8 May 2019 12:17:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B987E380BE for <ipv6@ietf.org>; Wed, 8 May 2019 15:16:53 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 67184F47; Wed, 8 May 2019 15:17:29 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 64A53CBE for <ipv6@ietf.org>; Wed, 8 May 2019 15:17:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IPv6 List <ipv6@ietf.org>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
In-Reply-To: <CAKD1Yr1OcQqxv1Z5XA7OBMfyC7kayXUOLJEGvY8QVu0XB-H=Xw@mail.gmail.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> <478d5dc5-af00-4ab0-d8ef-75e41cd501d4@foobar.org> <CAKD1Yr1OcQqxv1Z5XA7OBMfyC7kayXUOLJEGvY8QVu0XB-H=Xw@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 08 May 2019 15:17:29 -0400
Message-ID: <17174.1557343049@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CokMhuyQ2BrEFwnQt1o-wmOlv8o>
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 19:17:34 -0000

Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
    > frames, use L2 ACLs, whatever they want to do. But even if the
    > administrator does all that, the host has no way of knowing that this
    > network has no IPv4 *by design*, as opposed to a network that is
    > experiencing an IPv4-only outage, or because the host's DHCPv4 packets
    > all got unlucky and got taken out by cosmic rays, or...

In particular, imagine you arrive at a conference or hotel and you try to use
link-local IPv4 addresses to speak between your laptop and phone.
It's one of us... It doesn't work due to all the undebuggable L2
magic.... what's going on?  What's broken?

So if all a device did was pop up a note, "This network may not support
legacy IPv4" on the screen, the flag would, for me, have benefit.

    > On such a network, the flag provides a good way to tell the host: we
    > don't support IPv4 on this network. The host can trust that or not. If
    > it does, it can save battery power for its users and reduce airtime
    > impact by disabling DHCPv4 or retransmitting DHCPv4 less frequently,
    > disabling features like IPv4 MDNS, etc. etc.

Does this mean you'll be implementing?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email