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

[Ole Troan <[e-mail]>]

[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?
  Is this the same problem on IPv4 only versus IPv6 only links?
  Given that this will not solve the problem with legacy hosts, what are the expected gain?
- 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).

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

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

Ole


> On 22 Mar 2018, at 16:47, Ole Troan <[e-mail]> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------