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

[Fernando Gont <[e-mail]>]

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.

(things like e.g. what we have with SLAAC/DHCPv6 interaction ar, IMO,
quite undesirable)

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