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

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

While waiting for meetecho to fix the feed I was using...


On 2018-11-05 19:06, Lee Howard wrote:
> 
> On 11/4/18 2:45 AM, Brian E Carpenter wrote:
>> On 2018-11-04 00:35, Lee Howard wrote:
>>>
>>>>> 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.
> 
> If there are no IPv4 services, there is nothing to turn off using this flag.

The host doesn't know that; the flag tells the host not to waste its time.

> 
> 
>>
>>> 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.)
> 
> Okay, "understands that IPv4 will continue to work locally if enabled on 
> hosts."

Locally = on a traditional broadcast LAN segment with no L2 filters.
But I don't see why this changes anything; we know we can't physically
prevent a host trying to use IPv4 if it insists.

> 
>>> 4. understands that applications may have already negotiated IPv4
>>> connectivity,
>> Again - doesn't care.
> 
> The document says:
> 
> Administrators MUST only use this mechanism if they are certain that
>     the link is IPv6-Only.  For example, in cases where there is a need
>     to continue to use IPv4, when there are intended to be IPv4-only
>     hosts or IPv4 routers on the link, setting this flag to 1 is a
>     configuration error.
> 
> "certain that the link is IPv6-Only" is not the same as "doesn't care if 
> there are residual IPv4 connections."

Again, I don't see your worry. It's all about the admin's intention, and it's
fair warning to any hosts. This is not a switch, it's literally a flag with
"No IPv4 services" written on it.

>>> 5. desires to break communications for 3b and 4,
>> Again - doesn't care.
> 
> The flag is specifically to disable connectivity through IPv4. If you 
> don't care about IPv4, you don't set the flag.

No, the flag is to announce that there is no IPv4 service. That is not
the same thing as "to disable connectivity."

>>> 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.
> 
> If she didn't care, she wouldn't set the flag. This administrator is 
> intentionally setting the flag for one or more of the reasons given in 
> the Introduction.

Yes, but the real action is *not* enabling IPv4 routing, DHCPv4, or
DNS over IPv4. (And installing L2 filters, maybe.) The flag is only
a flag.

> 
>>> 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.
> 
> The number of cases where IPv4 might exist and an administrator wants to 
> shut it down and has no other tools seems narrow to me. While I agree 
> that all dual-stack hosts understand RAs, that doesn't mean they all 
> understand this flag. I have counted zero host operating system 
> implementers who have said they will take action on this flag, but check 
> my math.

As for most IETF proposals, it takes time.
 
> In a desire to be constructive, I think we had talked earlier about 
> defining the flag to mean, "I have no IPv4 routes." That might be useful 
> information for a host, letting it decide whether it needs IPv4 locally 
> (or has another IPv4 route), and disable appropriately.

That is one of the things it means, along with "I don't grok DHCP" (which
also means "I don't announce a DNS/IPv4 server").

And yes, a host MAY ignore it (that's the complement to the SHOULD
in the draft). We've never said anything else.

   Brian