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

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

Thanks David. In my opinion the main issue now is for the WG to decide whether to proceed or to drop the whole idea, but I comment below assuming that we decide to proceed.

On 04-May-19 19:25, David Farmer wrote:
> Basically, I support this document, in the near-term, I think it will be useful in some specialized situations, longer-term it may have more general applicability. 
> 
> Below are some issues from my detailed review of the current version, it has been two or three versions since my last detailed review;
> 
> 1. In my opinion, the following sentence contradicts part of the applicability statement. I never really liked the document talking about unmanaged networks, but I couldn't articulate a reason why, until now. My recommendation is to remove it
> 
>    It may also be valuable on unmanaged networks
>    using routers pre-configured for IPv6-Only operations and where Layer
>    2 filtering is unavailable.

I agree that we should drop "unmanaged" for now. I could argue with some of your points below, but I think it's a distraction and it can be left for future work.

> The following is the portion of the Applicability Statement in question; 
> 
>    Administrators MUST only use this mechanism if they are certain that
>    the link is IPv6-Only.
> 
> Unmanaged networks do not usually have an administrator, by definition they are not managed. I think maybe this was intended to suggest an ISP or CPE manufacture could ship IPv6-Only CPE with this flag set by default. However, that would also violate the Applicability Statement, neither the ISP or CPE manufacture could have the certainty required by the Applicability Statement that IPv4 is not in use on the local network. 
> 
> I think the use of this flag on unmanaged networks is ill-advised and should not be discussed in the document. The trade-offs involved in using this flag as it is currently designed requires someone, the administrator, with intimate knowledge of the local network to decide if this flag should be set or not on the router's link. Discussing the use of the flag on unmanaged networks implies this level of knowledge may not be necessary. The remainder of the paragraph already covers "networks without the ability to filter L2 traffic."
> 
> If you intend this flag to be used on unmanaged networks it will need to be much more automatic, as designed it requires an administrator to decide its appropriate setting. 
> 
> It might even be appropriate to add that this flag is only intended for use on managed networks, that have an administrator, but as long as you don't mention unmanaged networks, that is good enough for me.
> 
> 2. I think Section 6 should additionally recommend the use of Router Guard [RFC6105], it is discussed in the Security Considerations Section, but I think it should be in Section 6 as well. Without Router Guard an IPv6-Only network is open to the attack discussed in paragraph 4 (not including the bullets) of the Security Considerations Section. Therefore, I think the use of Router Guard should be recommended with normative language in Section 6.

Seems reasonable to me.

> 3. In Section 7, paragraph 5 seems to repeat the idea in the last half of paragraph 3, my recommendation is to delete paragraph 5.

Yes, good catch.

> 4. Previously I asked for the following (slightly edited) and I don't see where it has been addressed, nor do I find an email explaining why it was not addressed. The only email I found was Brian saying "your suggestions below make sense to me," in my mind that included the following;
> 
> Finally how about some additional non-normative discussion about taking precautions to prevent unsuspecting WiFi users from accidentally connecting IPv4-Only WiFi hosts to IPv6-Only WiFi links. Possibly by including "IPv6" or "IPv6-Only" in the name of open SSIDs to help inform unsuspecting WiFi users, using secured SSIDs to prevent unsuspecting WiFi users from connecting all, or using 802.11u Access Network Query Protocol (ANQP) with "Address type available" for IPv6 and "Address type not available" for IPv4 to inform the connecting WiFi host instead of the user. Putting this in an appendix would be fine with me. 

Yes, this got lost on the editing room floor. I still think it's useful.

Thanks
   Brian
 
> Remember the IETF's own discussions regarding this issue. If the IETF isn't willing to have its default WiFi be IPv6-only, maybe some caution is warranted for the general population of the earth. :) 
> 
> Thanks
> 
> 
> 
> On Mon, Apr 29, 2019 at 5:02 AM Ole Troan <[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.
> 
>     Best regards,
>     Ole, 6man co-chair
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer@umn..edu <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota  
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>