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

[Mikael Abrahamsson <[e-mail]>]

On Mon, 29 Apr 2019, Ole Troan 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 can be changed so that IPv4 and IPv6 operations MAY be started 
simultaneously and then the presence of this flag means IPv4 DHCP timers 
etc can be agressively backed off and IPv4 LL operations SHOULD NOT be 
performed.


Secondly, In the security section:

"   o  An attack would not succeed if the dual stack hosts had active
       IPv4 configuration.  As specified in Section 7, a dual stack host
       will ignore the flag if it has active IPv4 configuration."

There needs to be text that handles the (today not mentioned) case of a 
device that attaches to a link, wait to see if the flag is set (doesn't 
perform IPv4 operations), and then trusts it. A mitigation section can be 
added that to mitigate this problem, presence of IPv4 can be verified by 
trying IPv4 operations and if no DHCP answer is seen in a timely fashion 
and RA with bit=1 then IPv4 operations SHOULD be ceased. This still 
doesn't handle the case where a host actually should have configured 
itself an IPv4 LL and talked to other IPv4 LL hosts to do something 
useful, but I think this is a quite rare event that the IPv6 only flag=1 
is seen on a network without DHCPv4 and it's desired that IPv4 LL 
operations should exist? Anyhow, text on this case can be part of a 
section as well.

Thoughts?

-- 
Mikael Abrahamsson    email: [e-mail]