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

Erik Kline <ek@google.com> Sat, 18 November 2017 13:42 UTC

Return-Path: <ek@google.com>
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 582AB126B6E for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 05:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 NmNjbrAlHylr for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 05:41:59 -0800 (PST)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F83D120726 for <ipv6@ietf.org>; Sat, 18 Nov 2017 05:41:59 -0800 (PST)
Received: by mail-yb0-x22d.google.com with SMTP id p19so1451310ybd.2 for <ipv6@ietf.org>; Sat, 18 Nov 2017 05:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LvXLR75GgrrWfIOi/127Ky5pIm7cN0xVbQrr1Ik7eGw=; b=bV6THEW4VTfamO35QEAnJWij+cnECVg5iUPY+2kl6IdrqqoHEjX/CKAWodmQSuU9R/ GK4z+4jlWxSjD5QSa2OQlXaWUJcyNwJVl3eASBaDjXafXGPjIT1fD1oK7Ety3BiHN8yI esLIDMxzWtiwVpvfF42FnY9e44ahfBxVLQpbz1q+TdOPemMWWlV8lTmKNiOnNHSZA6BZ SBZK7Y9Md/X1MwwWkGElwPkhvbq5UNKaYNUj15rjprYRNg6oGAO3Ylj5mgImjaHcSJrq Ki5rSh8snTXWoQFlYcrhl7H24ZSRw3g+cLB1PZ3JlxcKZ2yAxMPdxD7U01SLaGG5DiwP 8Y1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LvXLR75GgrrWfIOi/127Ky5pIm7cN0xVbQrr1Ik7eGw=; b=rN4+vPE1eL+UlVabz3gDT2qp9XcY2v2V9SUJTiMJFSx9n9hDES8KHBXpDnGX+855I4 475W2eGC+xdqtvhL5eSPMpyBDu1RBrzq9lfYu/5iuxcTpxmxVzi5inBX0BZhsULj8j3h tRanYCb7O2KQy7qOyre8OpJpWjSEPxnFdf6CmtwjXwO1aD4wWi5ltfO8si4aMvvnWoBH vue5ZYHYGxJc8HqpPh+5QVj2kpmnfbLeTbMYEvFtsy6qaf35ofr/YnPUFNjnVul3jJ3z vXb+wT40AdK5NF0pK7fZaUXI/3KivcmP8UJBj/cQHQ53YI676+YWxdR6T8tjTq/5w2F3 B7VQ==
X-Gm-Message-State: AJaThX7shnfVl3fPwddmhGQ9EAPwy2McfdKPnELb8nq2AIT1jf3HrOR4 SHO75sfZVrC6syLS2gKcli9kLS7+8kH50IKjb2iOSA==
X-Google-Smtp-Source: AGs4zMZlyRM5Ae7L/+Bp7669y3LSKeEU0uWOra/AbW1ivq1B3f4nsTBzDAZlqjZ19+vwHmD0aDbxYFjzKj4ckRX1+i8=
X-Received: by 10.37.189.74 with SMTP id p10mr5184926ybm.185.1511012518404; Sat, 18 Nov 2017 05:41:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.187.17 with HTTP; Sat, 18 Nov 2017 05:41:37 -0800 (PST)
In-Reply-To: <7A8296F8-197A-47E7-B793-30CEE4AA3EB1@jisc.ac.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAAedzxr7PDp51Ok+AVfExG7gHGgn5N=8qg1+nC75i-qN_wrFUQ@mail.gmail.com> <7A8296F8-197A-47E7-B793-30CEE4AA3EB1@jisc.ac.uk>
From: Erik Kline <ek@google.com>
Date: Sat, 18 Nov 2017 22:41:37 +0900
Message-ID: <CAAedzxrwE3OOOM2M4ceDE6RHvE70f8JiemOxpRqtga0=3d4v5A@mail.gmail.com>
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="089e0828949c72e161055e420424"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Idgc7wlQBQ2QmYpzPXoUxTasZOw>
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: Sat, 18 Nov 2017 13:42:01 -0000

On 18 November 2017 at 22:24, Tim Chown <Tim.Chown@jisc.ac.uk>; wrote:
>> On 18 Nov 2017, at 13:12, Erik Kline <ek@google.com>; 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?

PvD information is for configuration information above and beyond
bootstrapping configuration.  Whether or not IPv4 service is available
on-link is part of the bootstrapping configuration.  Besides, the PvD
may provide IPv4 service via NAT64, but that's separate from what's
available on the link.

I think it should be a hint, yes.  But you raise a good point: IPv4
Internet access not being available on-link is different from, say,
0x0800 ethertype being filtered out by the infrastructure (perhaps 2
bits?).  Still, a hint would be useful for us to save transmitting
useless packets and we could even install a hardware filter to drop
all 0x800 in the wifi chip, further saving us from wake-ups (on
networks where 0x800 wasn't dropped).