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

[Lee Howard <[e-mail]>]

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?

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.




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

Lee