Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

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

On 2018-11-04 00:35, Lee Howard wrote:
> Sorry, I didn't trim because I think it's all context...
> 
> On 11/3/18 12:50 AM, Brian E Carpenter wrote:
>> On 2018-11-02 19:09, Lee Howard wrote:
>>> On 11/1/18 1:13 AM, Brian E Carpenter wrote:
>>>> On 2018-10-31 22:24, Nick Hilliard wrote:
>>>>> Job Snijders wrote on 30/10/2018 22:27:
>>>>>> Can you (or others running FreeBSD EXPERIMENTAL) share reports on how
>>>>>> this pans out in practise?
>>>>> Looking at the code, it acts by blocking outbound ipv4 frames from being
>>>>> transmitted on ethernet interfaces.  This would mean - for example -
>>>>> that if there were a default route already configured on the receiving
>>>>> device, any userland code attempting to use ipv4 services would block
>>>>> until ARP times out for the default route (default 20 minutes on freebsd).
>>>>>
>>>>> The only part of the ipv6only discussion that was uncontroversial was
>>>>> implementation of the kernel processing side of this flag - there's very
>>>>> little to go wrong when toggling a single flag.
>>>>>
>>>>> The problem area is how to handle the interpretation of this flag in
>>>>> userland and in the kernel, which is a much more difficult problem.
>>>> It's a question, but I don't know why it's a problem. It isn't an interop
>>>> problem, because each host is an independent actor in this. And we now have
>>>> running code proof that legacy hosts aren't affected. So I'd say that from
>>>> a protocol spec point of view, it's actually a non-issue.
>>> Doesn't it mean that user space applications on a host that had/expected
>>> IPv4 would fail?
>> Well yes, but that is presumably the network administrator's intention,
>> so I'm not sure I'd characterise it as am interop issue exactly, and it's
>> not an interop issues *involving the RA message itself*.
>>   
>>> I think I described my interop concern:
>>> https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm
>>>
>>> IPv4-only hosts, and dual-stack hosts
>>> that do not recognize the new
>>>       flag, may continue to attempt IPv4 operations
>>>
>>> If some devices require IPv4 and others disable IPv4, you have lost
>>> connectivity between systems on a local network. As written, this is not
>>> considered a misconfiguration by the administrator who sets the flag.
>> Indeed not. The admin will presumably be happy at this result.
>> I don't think we disagree about the effect, just about whether
>> it's desirable.
>>
>>>>> This also disregards the issue of whether the flag was either necessary
>>>>> or a good idea to start with, and nearly 700 emails into this
>>>>> discussion, the WG seems to be hopelessly divided on these issues.
>>>> I'll leave that one to the WG chair who isn't a co-author. But I will
>>>> say that in my mind the issue is whether the feature is one that will
>>>> be valuable in 5, 10 or 20 years time rather than whether it's valuable
>>>> today.
>>> I've come into the camp that believes that in 10 or 20 years IPv4 will
>>> be disabled by default. When people post to stackoverflow complaining
>>> that their 10-20 year old devices are unreachable from their brand new
>>> devices, the response will be, "The old stuff might be using the old
>>> protocol, IPv4. Go into Control Panel, Networking, Protocols, select
>>> IPv4, click enable."
>>>
>>> If that's likely, then this flag is only useful in the interim 5 years.
>>> During that time, I would like to maximize connectivity.
>>>
>>> If a network administrator wants central control over IPv4/IPv6
>>> enablement in hosts, there are better, more centralized tools for that.
>>> As a principle, host behavior should be managed by host management
>>> tools, and not by hints from a router.
>> I'm not sure how that can work on a BYOD network. On a fully managed network,
>> sure, we could "easily" invent a solution.
> 
> Taken all-in-all, then, the use case for this flag is a network where 
> the administrator:
> 
> 1. does not know what's on the network,

May not know what's on the link, or does not have management access
to some devices on the link, or does not have policy control over
some devices on the link. There are many such networks.

> 2. expects that there are some applications using IPv4,

I don't see that. The admin has decided that there are no IPv4
services on the link - presumably no DHCPv4, no DNS over IPv4,
no IPv4 routing. Whether or not some hosts contain IPv4 applications
isn't necessarily known to the admin.

> 3. understands that IPv4 will continue to work locally, 3b. except for 
> dual-stack hosts that honor the flag,

It might be fairer to say that the admin doesn't care whether
IPv4 works locally, but has decided to announce to everybody that
there are no IPv4 services on the link, knowing that only 3b hosts
will understand the announcement.

(The fact that RAs are universal, whereas other possible mechanisms
such as DHCPv6 or NETCONF are not, is relevant here.)

> 4. understands that applications may have already negotiated IPv4 
> connectivity,

Again - doesn't care.

> 5. desires to break communications for 3b and 4, 

Again - doesn't care.

> and prevent IPv4 
> Internet access.

Yes, that's the primary decision. Of course, the assumption is that
IPv6-only access to the Internet is necessary and sufficient.

> It's not just that administrator accepts that 3b and 4 won't work, but 
> as you said above, "The admin will presumably be happy with this result."

Or doesn't care.

> This seems to me a very narrow application.

It's certainly directed at a specific (and future) phase of history, when
IPv6-only is viable and IPv4 has not yet faded into oblivion. How many
links for how many years would be in that phase is an open question.

As the draft recognizes, there are other mechanisms available too.
What strikes me as unique about this mechanism is simply that *every*
dual stack host receives and understands RAs; this is our only way
of getting a bit to every single dual stack device. That's not
narrow, IMHO.

     Brian