Re: Interop

[Lee Howard <[e-mail]>]

On 10/24/18 1:33 PM, Toerless Eckert wrote:
> 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.

Case A could decide to use/prefer/do everything over IPv4.

There is no requirement to implement Happy Eyeballs. Indeed, it is 
intended for eyeball applications, where users get tired of waiting, not 
for deciding which IP version to use underlying a service discovery 
protocol, for instance.



> 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 document specifically says, "IPv4-only hosts, and dual-stack hosts 
that do not recognize the new
    flag, may continue to attempt IPv4 operations, in particular IPv4
    discovery protocols typically sent as link-layer broadcasts."


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


  Dynamic Configuration of IPv4 Link-Local Addresses"

i.e., 169.254.0.0/16

Now, the draft does say:
    Administrators SHOULD only use this mechanism if they are certain
    that the link is IPv6-Only.  For example, in cases where there is a
    need to continue to use IPv4, when there are intended to be IPv4-only
    hosts or IPv4 routers on the link, setting this flag to 1 is a
    configuration error.
~

But that's a SHOULD not a MUST (as I noted in previous comments). Now 
that we're discussing further, I think it's wrong to say "the link is 
IPv6-Only," but needs to say, "there are no hosts using (or dependent 
on) IPv4 on the link." Saying a "link" is IPv6-Only might mean no more 
than a router interface has an IPv6 address and IPv4 unnumbered, or even 
less than that, since links don't get addresses.


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

Huh? Not even slightly.

Many implementations never see production deployment, and are simply 
proofs-of-concept.

Many implementations are well-executed and are good ideas.

I can't wrap my head around this assertion.


>> 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 agree that would reduce the risk.
>
> 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.

Interesting point. The draft does point out that there are only two bits 
left, but extended space is available (Section 4 of rfc5175 "IPv6 RA 
Flags Options").


Of course, if no one will implement and/or no one will deploy, then the 
hurt is to the time of the people participating in this discussion.

Lee


>
> Cheers
>     Toerless
>> Lee