Re: New Version Notification for draft-hinden-ipv4flag-00.txt

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 19 November 2017 14:53 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 E8FFC126D46 for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 06:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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] 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 VpEPjAet9VtW for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 06:53:49 -0800 (PST)
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 BD310126D3F for <ipv6@ietf.org>; Sun, 19 Nov 2017 06:53:49 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 57B38AF; Sun, 19 Nov 2017 15:53:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511103228; bh=s4iVqCQZeGpag3CWkBXMZLYmpu8DNfE1FkNmwsypmJ4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=SZ1gpthEG6wOsVoY0HMFqVMQ+6KDneNcmsEfUM4s58TNcCQDf99mZ6R9tGUcAKkVU vv0uNmh1O8KTUkmOJmZC3lXrO3/+HjgQzzjN3AqMsq17JTzfWG4ClAmL8cOSDuEdMY 72FHyckUZIDhkHA0WhLCjz+82CED3EkWx24Qraac=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 554959F; Sun, 19 Nov 2017 15:53:48 +0100 (CET)
Date: Sun, 19 Nov 2017 15:53:48 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Lorenzo Colitti <lorenzo@google.com>
cc: james woodyatt <jhw@google.com>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
In-Reply-To: <CAKD1Yr3vqJB9_virMp7+uH2zOYLDM+XNf=L1OihN0DdXzCNobA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1711191550020.32099@uplift.swm.pp.se>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com> <CAKD1Yr3vqJB9_virMp7+uH2zOYLDM+XNf=L1OihN0DdXzCNobA@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: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FKZTe5C0Z0zJornz0b-qtdlKjIk>
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: Sun, 19 Nov 2017 14:53:51 -0000

On Sat, 18 Nov 2017, Lorenzo Colitti wrote:

> Not sure how that would support IPv4 becoming available once the option 
> has been set. Also, not clear how to deal with the DOS scenario where a 
> rogue RA disables all IPv4 on the network until the end of time.

I think any "No IPv4"-flag would need to be just a hint to the hosts, and 
it would only be relevant to the router actually sending that RA.

So if your normal DHCPv4 "give up" time is X, then if this flag it set, 
shorten X to something much less?

The IPv6 specs say M=1 is a hint that tells the host that it might use 
DHCPv6 to acquire addresses if it so wants, right? Nothing says it can't 
do IA_NA request if M=0, and nothing says a host does the wrong thing if 
it doesn't do IA_NA request? I think this flag should be the same level of 
hint, and then the rest is up to the host implementation to do what it 
think is best.

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