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

[Fernando Gont <[e-mail]>]

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?

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

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.

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



>> (things like e.g. what we have with SLAAC/DHCPv6 interaction ar, IMO,
>> quite undesirable)
> 
> Agreed. But if that was easy to fix, we'd have fixed it years ago.

I'd say it's worse than that: we don't even seem to have much of a model
for automatic configuration, and keep contributing to that mess. I
believe we should have a clear model about what goes where, etc....
rather than continuing adding features (normally to SLAAC) with the
implicit idea of "well, if the feature is needed, and since nobody is
gonna use DHCPv6, we should add it to slaac". (which I don't necessarily
object.. but if we're really going to do that, we better stop working on
dhcpv6).


For some of us that at times have to explain IPv6 to newcomers, the part
where we get to autoconfiguration is... quite uncomfortable, so to
speak. (particularly when it gets to how to convey info about RDNSS, no
routes in DHCPv6, etc.)

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