IETF Logo Mail Archive

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

Michael Richardson <mcr@sandelman.ca> Fri, 24 May 2019 16:15 UTC

Return-Path: <mcr@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 9F3ED120301 for <ipv6@ietfa.amsl.com>; Fri, 24 May 2019 09:15:16 -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 ywo0u3A-Ufnl for <ipv6@ietfa.amsl.com>; Fri, 24 May 2019 09:15:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520BB1202F6 for <ipv6@ietf.org>; Fri, 24 May 2019 09:15:13 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 91A1E380BE; Fri, 24 May 2019 12:14:13 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 94CB5FFB; Fri, 24 May 2019 12:15:08 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9308AE47; Fri, 24 May 2019 12:15:08 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: David Farmer <farmer@umn.edu>
cc: Fernando Gont <fgont@si6networks.com>, 6man WG <ipv6@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
In-Reply-To: <CAN-Dau02MYCrKx2BgyuYJeHBdoz6SHCnp+-byM+LMM8af0S+rA@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> <663F6C0B-7B8A-4088-B9C0-B2867B0C3EB8@gmail.com> <CAN-Dau3VJN7qNHAW-yStMrDRCa4vsDs2ObkAxswnYbcHde2t_w@mail.gmail.com> <m1hPqHO-0000J8C@stereo.hq.phicoh.net> <CAN-Dau3R=4JbcbK7tWkJKYzVjq7DvAAEjVsbCLbZdYYO8OJ0YA@mail.gmail.com> <m1hQ7Dm-0000M3C@stereo.hq.phicoh.net> <CAN-Dau040j6U+1CCn0QJiVMy2nVShHqqSFdCkM-FbMAH-2wjRA@mail.gmail.com> <m1hQCYr-0000KBC@stereo.hq.phicoh.net> <561d9dc3-c769-c774-8f65-f975ac2a10a0@gont.com.ar> <m1hT1DZ-0000HEC@stereo.hq.phicoh.net> <ce07ade8-5105-055f-4798-f4ef20a2393c@si6networks.com> <CAN-Dau02MYCrKx2BgyuYJeHBdoz6SHCnp +-byM+LMM8af0S+rA@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: Fri, 24 May 2019 12:15:08 -0400
Message-ID: <19388.1558714508@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CfE3kQ0lY9ojN13sHX8m2EKZazQ>
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: Fri, 24 May 2019 16:15:17 -0000

David Farmer <farmer@umn.edu> wrote:
    > What he is saying is a dual-stack host that has functioning IPv6 should not
    > enable IPv4 LL. And functioning IPv6 means at a minimum it has learned an
    > IPv6 GUA and probably a default router as well, you could also test for
    > connectivity beyond the default router, but that

    > The risk this creates is that on a dual-stack network if a there is an issue
    > with the DHCPv4 server, such as it crashed or was misconfigured then the
    > dual-stack host cannot fall back to IPv4 LL and will not be able to perform
    > Link-Local communications with IPv4-Only devices on the common link between
    > them.

If one assumes a host with some history of connectivity,
(So Linux running NetworkManager, OSX, Windows, iOS and Android), then the
the failure of the DHCPv4 server, can simply be tolerated.

The turn off IPv4 LL heuristic can apply only to the first (few?)
connections.

    > Personally, I think this is an acceptable risk, but I'm not convinced that
    > there is a consensus that this is an acceptable risk. Therefore, I'm

I agree.

Where/how does this heuristic get document?
There was an RFC mentioned back in the thread... do you think it's enough for
ipv6only document to reference it?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email