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

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

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.

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

    Brian