Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Fernando Gont <[e-mail]>]

On 10/25/18 2:15 AM, Mark Andrews wrote:
> 
>> On 25 Oct 2018, at 8:38 am, Fernando Gont <[e-mail]> wrote:
>>
>> On 10/24/18 9:54 PM, Brian E Carpenter wrote:
>>> On 2018-10-24 16:20, Fernando Gont wrote:
>>>> On 10/24/18 4:54 AM, Brian E Carpenter wrote:
>>>>> On 2018-10-24 11:13, Fernando Gont wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>
>>>>>> In this particular case (ipv6-only flag), what goes on the wire is
>>>>>> simple enough that..I don't think having an implementation will buy much
>>>>>> wrt how different implementations interoperate with each other. And the
>>>>>> insights you'll gain from an implementation are most likely "out of the
>>>>>> scope of the I-D", since how you disable the IPv4 stack is certainly
>>>>>> going to be very implementation-dependent. (me thinking out loud)
>>>>>>
>>>>>
>>>>> Exactly right. There isn't actually an interop requirement of any kind.
>>>>> This is a one-way signal from the routers to each host, and each host
>>>>> may choose what to do with that information. Legacy hosts will ignore
>>>>> it, for example. A host with a sophisticated connection manager might
>>>>> use a complicated heuristic, and there are many possibilities in
>>>>> between, which is the reason that the draft uses SHOULD language.
>>>>
>>>> Without endorsing or opposing to the proposal what I would expect is
>>>> that it's quite clear what is expected from hosts in response to the bit.
>>>>
>>>> If, when sending the bit set you get each node doing it's own thing (one
>>>> reduces timers, another disables the stack forever, another disables it
>>>> but might re-enable it when the bit is no longer set, etc.), that would
>>>> be an undesirable outcome. Me, I think it should be clear what to do
>>>> with the bit, and the exceptions (the corner cases when you might go
>>>> against the advice) should be spelled out.
>>>
>>> That's exactly the reason for using an RFC2119 SHOULD - but spelling out
>>> all the corner cases seems like an impossible task.
>>
>> I'd expect that, say, you spell out the cases that made you use "SHOULD"
>> rather than "MUST". Put another way: what are the scenarios that you
>> have already envisioned where hosts shouldn't disable the IPv4 stack?
> 
> When you as the administrator of the host know that the administrator of
> router erred.

Administrator of the host? You must be operating in a different
environment? I'd bet the closest thing to "admnistrator" in a growing
and growing number of nodes is the app doing automated updates.



> When you as the administrator of the host configure the host to only talk
> to a subset of otherwise reachable machines over IPv4.
> 
> When you as a administrator of the host want to test something.

Same as above.



>> If I had to code the host part, for example, I'd wonder: Should I
>> disable IPv4 for mDNS? If the network is marked as IPv6-only does it
>> meant that I shouldn't even try to find, say, a network printer using
>> IPv4 link-local addresses (169…)?
> 
> Yes.  The assumption when the flag is set is that all the boxes are IPv6
> capable.

...and apps.

In which case, make the "SHOULD" a "MUST", and put an applicability
statement noting that.


> 
>> Putting this mechanism (ipv6-only flag), I am not sure the extent to
>> which you might want to disable IPv4 completely. For instance, there are
>> networks that, whether we like it or not, end up learning the RDNS
>> address via DHCPv4, because e.g. they employ a version of MS Windows
>> that predates W10.
> 
> If I was implementing it the interface would become un-numbered for IPv4,
> the DHCP client would be disabled, mDNS would not be attempted over IPv4.
> 
> I might gate that decision on whether there is a working IPv4 lease or not
> (see SHOULD).

I would like that there is less of "I would", "I might" with "MUSTs" in
the spec.



>> Or the network might not use IPv6 itself, but nodes might need IPv4 for
>> "peer to peer" stuff withing the network (whether transferring files,
>> printing documents, etc.). And those services are not provide by "the
>> network", so the networrk admin doesn't have much of a say about them
>> (i.e., he/she might not even know about apps that might require IPv4).
> 
> Then the network is not IPv6-only and you shouldn’t be setting the flag.

It depends what you mean by "the network". Only stuff that yu the net
admin runs? Does it also include nodes you don't control? If the later,
than "you never know".


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492