Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[神明達哉 <[e-mail]>]

At Thu, 9 May 2019 11:08:03 +0200 (CEST),
Mikael Abrahamsson <[e-mail]> wrote:

> > At the 6man meeting at IETF 104 in Prague there was support to close
the working group last call and advance
> > draft-ietf-6man-ipv6only-flag-05 to the IESG.
> >
> > This call is to confirm that decision on the mailing list.
> >
> > Please give objections and comments to this decision to the mailing
list, by 2019-05-13.
>
> Having discussed the objections to this draft with multiple people, I
> propose to enhance the document with some text regarding mitigation of
the
> rouge RA with bit=1.
>
> The main objections I have seen are:
>
> An attaching host will not start IPv4 operations until it has received
> (and decided it's received all of them) RA answers to its initial RS
> message, because before this it doesn't know what the flag will be. This
> will increase attachment times before a working setup can be had on IPv4
> only links. I think this is a valid concern.
>
> Problematic text:
>
> "   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 MAY be started.
> "

This text doesn't read to me that "a host SHOULD NOT start IPv4
operations until it has received an RA with the ipv6only-flag
cleared".  At least literally, it just talks about the host's behavior
*after* it receives an RA with ipv6only-flag on.

Note also that this same section clarifies the case where there's no
IPv6 default router:

   [...]  In other words, at any given
   time, the state of the flag as seen by the host is the logical AND of
   the flags sent by all unexpired default IPv6 routers on the link.

   This also means that if all default routers on the link have set the
   flag, the resulting host state for the link is IPv6-Only.  If the
   lifetimes of all the routers on the link subsequently expire, then
   the host state for the link is not IPv6-Only.

Although the specific situation it discusses is when the lifetimes of
IPv6 default routers expire, I believe it's natural to apply the same
logic to when a host hasn't received any RAs at all (on startup).

If the author's intent is actually different from that on the startup
case, I think it should be more explicitly clarified; if my
understanding of the intent is correct, those objections would be
based on misunderstanding of the text, so it's probably better to
clarify it explicitly.

Note: this comment is independent from whether the proposal is good or
bad (I'm personally mostly neutral about it).  It's basically about
its editorial clarity.

--
JINMEI, Tatuya