Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[David Farmer <[e-mail]>]

On Fri, Oct 19, 2018 at 8:42 PM Brian E Carpenter <
[e-mail]> wrote:

> On 2018-10-20 09:37, [e-mail] wrote:
> >> Job,
> >> On 2018-10-20 01:35, Job Snijders wrote:
> >>> I think it would be good to have some running code before advancing
> this to
> >>> IESG review and RFC publication.
> >>
> >> Why is this proposal special in that respect? This is not an IETF
> requirement
> >> and despite the BCP advocating an Implementation Status section, very
> few drafts
> >> do this.
> >>
> >> Note, I am all for some trial implementations, but why does *this* draft
> >> need one when so many others don't?
> >
> > Whatever happened to "We believe in rough consensus and running code"?
>
> It hasn't gone away, although formally it only applies for promotion
> above "Proposed Standard" status. And I believe in it, and that's why
> there's running code for GRASP (draft-ietf-anima-grasp-15). But for
> something that has to go into the basic IP stack, it's not so easy to
> prototype, and I am still not seeing why people would raise the barrier
> for this particular minor extension rather than, say, for the extension
> mechanism for RA flags that appears to be completely unimplemented.
>
> In other words: if this is what you want for ipv6only-flag, then
> I'd like the same rule for all the other draft-ietf-6man documents
> from now on, please.
>
>    Brian
>

I don't think "running code" needs to be a requirement for this draft or
generally in 6man. However, in this case, where there doesn't seem to be a
clear and obvious consensus, running code or some sign that there will be
running code could help promote consensus.

Personally, I'm in the probably not camp at this point, I don't see
fundamental flaws in the spec, but I have serious doubts about client
implementations of the spec occurring. And, I'm not excited to use one of
the two remaining native router advertisement flags (not using the RFC 5175
extension option) if there are doubts about there being any host
implementations of the spec.

However, the existence running code or even a few host developers coming
out and saying they intend to implement this spec if published as standards
track would go a long way to dispelling many of my doubts about this draft.

I did ask for at least some commentary about "about taking care to prevent
unsuspecting WiFi users from accidentally connecting IPv4-only WiFi hosts
to IPv6-only WiFi links", such as by using "IPv6" or "IPv6-only" in open
SSIDs, using PSK or other authentication, or using 802.11u Access Network
Query Protocol (ANQP) with "Address type available" for IPv6 and "Address
type not available" for IPv4.  I think my other comments were covered, but
I don't see where this was covered in the new version.

Further, last week at the Internet2 TechEX in Orlando, we ran some
experiments with the RFC2563 option, and the initial unvalidated results
are not good, all clients seemed to not request the option and still
generated IPv4 link-local addresses.  We still have some work to do to
completely understand the results and to ensure it wasn't some kind of
screw up on our part configuring the DHCP server.

Also, as I've been thinking about this situation, and I'd also like to see
a new DHCPv4 option for Dual Stack clients that are capable of utilizing
IPv4AAS on their own, signaling that the provided IPv4 address should be
configured only if they cannot make IPv4AAS work over the IPv6 service
provided. This allows a network to service newer Dual Stack Client in
IPv6-only mode, while still servicing older Dual Stack clients and
IPv4-only clients with a provided IPv4 address. This allows networks to
gracefully transition to IPv6-only and have data to determine when IPv4 can
be safely be turned off on a link and then maybe eventually turning on the
IPv6-only flag for the link, assuming we can find consensus to do the
IPv6-only flag.

Thanks

-- 
===============================================
David Farmer               Email:[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
===============================================