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

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 10 May 2019 20:08 UTC

Return-Path: <swmike@swm.pp.se>
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 22D5B1200F1 for <ipv6@ietfa.amsl.com>; Fri, 10 May 2019 13:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 l0zFDJlTshZj for <ipv6@ietfa.amsl.com>; Fri, 10 May 2019 13:08:28 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 A18F51200C5 for <ipv6@ietf.org>; Fri, 10 May 2019 13:08:28 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1C7A7B2; Fri, 10 May 2019 22:08:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557518906; bh=IW3xi/pzaPEq4C11V8fRdRcPqiEPJWptSgjXMOaG3AY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yc7ltJZMEBqx09EwoddIqymDMYCgAS6NlQxlXkggvoGC3V+xPeNqzmMtnkrl7TihG HV51FeSnfLfS004YuwcLwtRh9/SO4pPVpLcdEWqaS6Yki0c/tJcT7qmLHqC4EM7c1J iz9AyN9M4o9Wrp6KZSMswW41PdPuCNjBBwXKmXtY=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 17AA0B1; Fri, 10 May 2019 22:08:26 +0200 (CEST)
Date: Fri, 10 May 2019 22:08:26 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: 神明達哉 <jinmei@wide.ad.jp>
cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
In-Reply-To: <CAJE_bqeDE9bwkMm63p_Dz+ha7_tLa38wA27YRK2n59D1g-qLrA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1905102204270.1824@uplift.swm.pp.se>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <alpine.DEB.2.20.1905091054560.1824@uplift.swm.pp.se> <CAJE_bqeDE9bwkMm63p_Dz+ha7_tLa38wA27YRK2n59D1g-qLrA@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-1545694639-1557518906=:1824"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ALQ0DcXHvvDsY2yI2O5QNf0kjpc>
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, 10 May 2019 20:08:31 -0000

On Fri, 10 May 2019, 神明達哉 wrote:

>> "   A host that receives only RAs with the flag set to 1 SHOULD NOT
>>     attempt any IPv4 operations, unless it subsequently receives at least
>>     one RA with the flag set to zero.  As soon as such an RA is received,
>>     IPv4 operations MAY be started.
>> "
>
> This text doesn't read to me that "a host SHOULD NOT start IPv4
> operations until it has received an RA with the ipv6only-flag
> cleared".  At least literally, it just talks about the host's behavior
> *after* it receives an RA with ipv6only-flag on.

Some people seems to have read "attempt" in the above text as "should not 
start", meaning it should delay starting IPv4 operations until it knows 
about the status of this flag (the host has no idea about the flag status 
until it has received RAs at attach time).

If we don't want this to happen then the current text in -05 is not clear 
enough on this case. I believe several people have voiced their opinion 
that they would accept the flag being part of the heuristic of deciding 
whether to continue doing DHCPv4 and/or IPv4 LL (or not). The -05 text 
doesn't seem to actually say this, so it should be changed?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se