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

[Brian E Carpenter <[e-mail]>]

On 2018-10-20 03:12, Mikael Abrahamsson wrote:
> 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. 

Agreed, and the current text is supposed to allow that. One example is the
dual stack fire alarm - if I had one of those, I'd want it keep looking for
both v4 and v6 connectivity whatever happens, although possibly reducing
the probe frequency.

   Brian

> 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.
>