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

[Toerless Eckert <[e-mail]>]

On Wed, Oct 24, 2018 at 12:21:50PM -0400, Lee Howard wrote:
> If two implementers can't tell from a draft what to do to make sure their
> implementations can interoperate, the draft should not advance, regardless
> of how good the idea is.

Agreed

> A) In this case, one OS could say, "That's advisory,
> I'll ignore it and do everything over IPv4,"

> B) another could say, "The router
> has no IPv4 but I'm using IPv4 for service discovery, so I'll keep doing
> it,"

> C) and a third could say, "RA says no IPv4, I'm disabling the stack."

> All
> comply with the document as written, but those three systems would have a
> very hard time communicating.

Why would any of those nodes have problems communicating via IPv6 with
each other ?  Its a basic happy eyeball problem of selecting the IP version
that works best in dual stack, right ? If they fail to communicate via IPv6 it
sounds to me A) or B) are violating those pre-existing requirements.

The way i see it, the resulting behavior on a host MUST NOT be anything
that is not already defined behavior, just triggered differently, or
else the new behavior has to be spelled out by the draft and the
interop with existing hosts/happy-eyeball recommendations has to be
described.

C) is existing behavior, it's called non-dual-stack-IPv6-only-host,
just thats its triggered here differently so thats safe i think.

A) is also existing behavior, that's safe too.

I am not sure what exactly you mean with B), but it sounds broken
already in the absence of the new RA option because if it doesn't
interop with C) it wouldn't interop with an IPv6 only host on he LAN
either.

The draft does mention IMHO new behaviors like 

D) Bring up IPv4 on-demand. Thats new and i mentioned that previously in
email, IMHO thats something that should be defined separately and vetted
separately. Sounds like a cool IPv4 sunset option, but quite difficult.

E) Do not do RFC3927. Sounds fine to me, because i think this is
pre-existing functionality in many IPv4 nodes (i hope there is no
host requirement to support RFC3927). 

> What guidance would you give those implementers? Can we put that guidance
> into the draft?

Agree on as specific guidance as is agreeable to the WG to be put into
the draft.  Just don't think that consistency (one single recommendation) across
all hosts on a LAN is necessary. See above.

> > A couple of examples I can remember, IPv6 site local (it was an RFC) and draft-ietf-ipv6-dns-discovery, different process stages, both got implemented by many OS vendors and also Linux. No longer used.
> 
> Implementation is not a guarantee of deployment.

Implementation is a guarantee to make bad ideas big pains for years to
come. Especially when its conception process is as nasty as site local was. 
There is a lot to be said about well vetted drafts before implementing.

> Yes. We are trying to discriminate between clear documents and vague
> documents. From what I can see, developers can write completely compliant
> implementations that break communications between systems on a network.
> 
> We also discriminate between ideas that help and those that hurt, or even
> those that do no harm but are useless. If we never discriminated, we would
> publish every draft.

And there are different hurts.

I think hurt to operations can be eliminated through above discussed
better guidance, e.g.: "don't make hosts do new things to IPv4, just
use this as a new trigger for existing modes to operate or non-operate
v4".

I'd be even happy if no host use the trigger and its just for
diagnostics showing up in a GUI (IPv4 not supported on this network).

The hurt to the RA codepoint space is IMHO a more difficult problem to
vet because i have no idea about the likelyhood of running out and
workarounds if one does, so the value of this options seems to need to
be quite high to justify the desired encoding. IMHO it would help a lot
to use an encoding that wouldn're quire justifing a high-value of the
feature.

Cheers
   Toerless
> 
> Lee