IETF Logo Mail Archive

Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 November 2017 18:28 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 50F9B129B6D for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 10:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 wVX7oCzqxNaX for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 10:28:48 -0800 (PST)
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 6E91B1267BB for <ipv6@ietf.org>; Tue, 21 Nov 2017 10:28:48 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2C57620008; Tue, 21 Nov 2017 13:30:50 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2178E82C48; Tue, 21 Nov 2017 13:28:47 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: <alpine.DEB.2.20.1711211716140.32099@uplift.swm.pp.se>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com> <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <CAKD1Yr3WC+vwL_=0PeiJ_D85NqFVTCkb8c83x-ZtGhAbSELGMA@mail.gmail.com> <5A119443.2030108@foobar.org> <CAFU7BASwgLfkO-4kk9-vba_P+jmcFHD5+Hy_7b3cnNkOSv30wg@mail.gmail.com> <CAKD1Yr3pKk22Hkxy4_8YMZYiA4Wwp=6JzdRDKFGdTY1gf=ntfA@mail.gmail.com> <alpine.DEB.2.20.1711200848390.32099@uplift.swm.pp.se> <5A12FBE4.9030101@foobar.org> <alpine.DEB.2.20.1711210647151.32099@uplift.swm.pp.se> <5A144A78.6060108@foobar.org> <alpine.DEB.2.20.1711211716140.32099@uplift.swm.pp.se>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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: Tue, 21 Nov 2017 13:28:47 -0500
Message-ID: <6863.1511288927@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3qYEBuQL07PRO9UdaNReNWpSF9Y>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 21 Nov 2017 18:28:50 -0000

Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    nick> is why I question the wisdom of the RA approach.  Simple, even if it
    nick> doesn't solve everything, is usually better.

    > Then I guess we should not do anything on the protocol side, and just have a
    > sunset4 document that tells hosts that "if you get IPv6 and there seems to be
    > no IPv4 in any timely fashion, stop asking for IPv4 information".

    > I think this is what Ole is saying he wants.

And hosts should do this for both v4 and v6 by heuristic anyway, because no
matter what we do, it won't be deployed tomorrow.
So that BCP is worth writing.

I'd also like to see a recommendation not to configure IPv4 LL so quickly,
the way that many systems do today, preferring to use v6LL.  Why? because I
think that v4-ARPs wake up more hosts than v6 NDs, and we also have efficient-ND.

We had a WG a decade ago called Detecting Network Attachment (DNA)... I'm
sure that there are documents we could reference... and I think this (BCP) work
belongs in sunset4.

I wonder if we can get consensus on the above statement?



====

Having SAID all of that, I still believe that an RA option (not flag bit)
that declared on behalf of the router, "I do not speak IPv4" might be worth
standardizing.  Perhaps, we should rather name the option, "I speak only IPv6"
since many of the devices also do not not speak XNS or AppleTalk.

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

v2.23.0 | Report a Bug | By Email