Re: Adoption call for <draft-hinden-ipv4flag-03>

Hi Ole,
On 23/03/2018 23:14, Ole Troan wrote:
> [Now with participant hat on]
> 
> Before adopting this document I would really like to be convinced that it adds "value".
> 
> - Do we understand the size of the problem?
>   How much unnecessary traffic is there and for how long after the node has connected to a link?

Well, we had observational data from the v6 only experiment in Singapore,
which is available somewhere. But I'm not sure the IETF population is typical.
However, the argument is that on a wireless network with mainly battery powered
devices, getting rid of even a few percent of the traffic, especially L2 broadcast
traffic, is very desirable.

>   Is this the same problem on IPv4 only versus IPv6 only links?

Probably not; I think the issue is asymmetric between v4 and v6.

>   Given that this will not solve the problem with legacy hosts, what are the expected gain?

As above: any reduction in traffic helps battery life.

> - Has solutions optimising only the host behaviour without relying on the network been investigated?
>   (The document asserts that a network notification is more precise, but I would like to see that documented).

It gives the hosts more of a hint than the simple absence of v4 responses. I have no
idea how to quantify that.

> - This doesn't specify host behaviour, doesn't that lead to what would effectively be interoperability problems?
>   E.g. some implementations support IPv4 link-locals, some implementations not.
>   I presume the advice here is to the operator is. Thought shalt not enable this flag if there are IPv4 only devices on the link.

Why? Those devices will behave exactly the same either way. All you are signalling,
to those who listen, is "I don't route IPv4 or answer DHCPv4."

> 
> As a general comment on the draft itself, I still think it is wrong to make the flag say something about the "IPv4 service" for the advertising router. A host does typically not correlate an IPv6 router and an IPv4 router on a link. The two protocols are running as ships in the night.

In fact that's exactly why the flag is defined as it is, and why the host
behaviour is defined the way it is. It is a slightly strange inversion of the
normal thinking.

> The correct approach here would be that the flag states that IPv4 is not enabled on the link. Similarly to other link properties like MTU.

That only works on a 100% managed network. The way we have it, where
routers only announce their own capability, is fail-safe on a network
with more casual management.

Regards
    Brian

> 
> Ole
> 
> 
>> On 22 Mar 2018, at 16:47, Ole Troan <otroan@employees.org> wrote:
>>
>> This message starts a two week 6MAN call on adopting:
>>
>>     Title     : IPv6 Router Advertisement IPv4 Unavailable Flag
>>     Authors   : R. Hinden, B. Carpenter
>>     Filename  : draft-hinden-ipv4flag-03
>>     Pages     : 9
>>     Date      : 2018-03-02
>>
>>     https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
>>
>> as a working group item. Substantive comments and statements of support
>> for adopting this document should be directed to the mailing
>> list. Editorial suggestions can be sent to the authors.  This adoption
>> call will end on April 5th, 2018.
>>
>> See also the gap analysis from sunset4 on disabling IPv4:
>> https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-3
>>
>> Regards,
>>
>> Ole Trøan
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 