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

[Mark Andrews <[e-mail]>]

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

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.

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

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

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

You can do a thousand "what if someone does something stupid”.   

>>> (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
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]