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

[Tim Chown <[e-mail]>]

> On 18 Nov 2017, at 13:12, Erik Kline <[e-mail]> 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?

Tim