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

[Lee Howard <[e-mail]>]

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,

2. expects that there are some applications using IPv4,

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

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

5. desires to break communications for 3b and 4, and prevent IPv4 
Internet access.

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."


This seems to me a very narrow application.

Lee

>
>     Brian
>