Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[Mikael Abrahamsson <[e-mail]>]

On Fri, 19 Oct 2018, Mikael Abrahamsson wrote:

> On Fri, 19 Oct 2018, Ole Troan wrote:
>
>> There should be a SHOULD disable IPv4 processing on the interface in there 
>> somewhere.
>> If it is not then I think the SHOULD MUST be added.
>
> "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 SHOULD be started."
>
> The word "MUST" is never used in the document as a requirement to turn off 
> IPv4.

Btw, I have no problem to make this language even less prescriptive. I do 
not want the host to turn off IPv4 all of a sudden if it has passed its 
captive portal check and deems it has fully working IPv4 connectivity to 
the Internet.

I want this RA flag to be the input of a decision the host makes to turn 
off IPv4, but one of potentially several. If you all of a sudden see this, 
don't turn off IPv4 immediately but perhaps wait 5-10 minutes since you 
last had working ARP or saw DHCPv4 reply. If you see it on network attach, 
do try DHCPv4 a few times and see if something answers. Perhaps do higher 
exponential backoff on your re-tries for DHCPv4 messaging.

Since I don't know much about how hosts treat IPv4 internally and we don't 
have an v4ops group to discuss it in, I don't think this is 6mans job to 
come up with exact descriptions what host operating systems do with this 
information.

The only thing I as an network operator want is to lessen the load of 
multicasts/broadcasts in the air for devices never-endingly trying to do 
IPv4. From what I can tell, IETF has no working group with critical mass 
to work on this problem. Sunset4 is gone.

-- 
Mikael Abrahamsson    email: [e-mail]