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

Tim Chown <> Sat, 18 November 2017 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46FD2126D74 for <>; Sat, 18 Nov 2017 05:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id whXC1dKIDp-J for <>; Sat, 18 Nov 2017 05:24:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB998126B6E for <>; Sat, 18 Nov 2017 05:24:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20170213; t=1511011460; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=6GW2g7qEsjPS2WBCq8nJ+QiKoDpLEAm8HI/xiYMuVw8=; b=Wa64pnzF1fCh4LN5YnwxFMXhb+iTVri51j76A38JHVaMHSshNeW2uedosLge5cQxMXzux1Qr/mZdl4GH3fLPPjRbRePMyD2qpVov0Ej5sDCprkhpHow8jm2D9sh0LSwxOHts9+3RMAulxfOdA3MBInW2ytdWtEN72DMTT4rYEkE=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-21-ICc_SyUmPBGwfMWgA4d-fA-1; Sat, 18 Nov 2017 13:24:15 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Sat, 18 Nov 2017 13:24:14 +0000
Received: from ([fe80::d9b7:5aa5:5084:74c2]) by ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0260.001; Sat, 18 Nov 2017 13:24:13 +0000
From: Tim Chown <>
To: Erik Kline <>
CC: Bob Hinden <>, IPv6 List <>
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Thread-Topic: New Version Notification for draft-hinden-ipv4flag-00.txt
Thread-Index: AQHTYG7i5kNf/E4LqE21AqWzsMjgsaMaIC6A
Date: Sat, 18 Nov 2017 13:24:13 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:7117:5632:cec4:6680]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:lQPQwsJ3DKnufyr47NbrTOqL9P4rIDGy0DdLBcwAt9XQeD7HrfKhp95Lrv3TCo7YJtHIp3QUl9OoAYISpHvonREEMUJ1nhuA2O4pzItyidmCz+Dck3znyae2EwS4xbE2I08iMCsSGvr2wl7yu4PT0M/7QWDy0Rl+LvIDYjp11/Y=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3e1274a3-ab74-4369-2aa0-08d52e87a961
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1140;
x-ms-traffictypediagnostic: AM3PR07MB1140:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132)(275809806118684);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(3231022)(920507027)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1140;
x-forefront-prvs: 04953B1F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(82746002)(2900100001)(83716003)(53546010)(74482002)(786003)(316002)(6506006)(6116002)(102836003)(99286004)(72206003)(39060400002)(97736004)(8936002)(36756003)(50226002)(229853002)(478600001)(6436002)(6486002)(54906003)(5890100001)(189998001)(4326008)(106356001)(5660300001)(230783001)(101416001)(105586002)(42882006)(6916009)(2950100002)(2906002)(5250100002)(34040400001)(86362001)(25786009)(3660700001)(50986999)(305945005)(68736007)(8676002)(7736002)(76176999)(53936002)(6512007)(6246003)(57306001)(14454004)(81166006)(33656002)(3280700002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e1274a3-ab74-4369-2aa0-08d52e87a961
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2017 13:24:13.9660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140
X-MC-Unique: ICc_SyUmPBGwfMWgA4d-fA-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Nov 2017 13:24:27 -0000

> On 18 Nov 2017, at 13:12, Erik Kline <> wrote:
> I like this, and it seems similar to something that came out of some
> sidebar conversations I was having in Singapore.
> Here are a few changes I might suggest, followed by how I could see
> implementing such a thing in an OS like Android.
>    [1] I would propose making it an EFO bit and leave the reserved
> bits for potentially more IPv6-critical information signaling.
>    [2] I would not say that 0 means "IPv4 is Available on this
> Router" but rather "this router makes no attestation about the
> availability or lack thereof of IPv4".
> The actual implementation that I could see being reasonable is as follows.
> Because every OS starts IPv4 and IPv6 configuration paths in parallel
> on link-up/link-attach, I think the most reasonable thing to do is to
> interpret this flag as the "save your electrons flag".
> In Android I think I would propose that we consider the bit only after
> we have satisfactory global IPv6 provisioning, which I would define
> as:
>    [a] at least one valid (i.e. non-deprecated), non-ULA, GUA
>    [b] at least one valid (i.e. non-deprecated) default route
>    [c] at least one valid (i.e. non-deprecated) DNS server
> Additionally, we could include a successful internet connectivity
> check as a requirement, just to make sure we keep trying IPv4 until
> any captive portal has been passed.
> Finally: once IPv6 can be categorized as "working", and we saw no
> other RAs with 0 in the extended flags options nor any RAs without
> extended flags options, and we hadn't yet found any DHCPv4 server,
> then we could use the "save your electrons" flag as a signal to stop
> our DHCPv4 client.  Operating Systems that implement IPv4 link-local
> communications (Android does not) might use this signal to disable
> that as well.

So the flag might be the IPv4 equivalent hint to the IPv6 M/O flag, or it might be a stronger hint to also not auto configure a v4 LL.  I think when sunset4 last discussed this idea the focus was on the former case.

Perhaps this is this something to introduce with the PvD work?  The presence or not of v4 service is a property of a PvD, and in scenarios with multiple PvDs the host can choose to use v4 (or not) for each PvD?