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

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

On 11-May-19 06:53, 神明達哉 wrote:
> At Thu, 9 May 2019 11:08:03 +0200 (CEST),
> Mikael Abrahamsson <[e-mail] <mailto:[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).

It seems to me that the host's internal 'IPv6-only-received' flag
theoretically has three states: Unknown, False, True.

Unknown means it's too soon after interface-up to know the status.
The only safe treatment of Unknown is to treat it as False.
 
> 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.

Yes, it should be made clear to the reader.

Thanks
    Brian

> 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>