Re: Interop

On Wed, Oct 24, 2018 at 02:24:34PM -0400, Lee Howard wrote:
> > > 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.

Hmm. Maybe i am overexpecting what dual stack hosts should do, maybe
what i am thinking of is not called happy eyeballs but categorized
differently. ICE for example tries to figure out which combination of
local/remote addresses works best across all address families and i
thought there where various more lightweight similar methods not tied to just
ICE/STUN capable apps.

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

Sure, but thats just a statement of fact (can't change behavior of nodes
you can't influence), not a goal of the proposal.
See your discuss about rfc3927 below for more.

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

Right.

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

The SHOULD could cover the case where the LAN hosts some IPv4 only hosts
whose mutual communication will not be impacted by this feature, in
which case it is still OK to set the flag.

I think a better statement would be to say that the flag indicates the
operators desire to enable and support only IPv6 communications  on the
subnet and optimize it for those nodes supporting the feature.
Additional IPv4-only host communication may continue to run as ships in
the night.

Which leaves the question about the impacts of communications between
dual-stack nodes and partial feature support where i'll stick to my
notion that the most lightweight guidance is what the behavior of a node
should be one of already used modes, just triggered in a new way. Which
may not be complete, but would need to be reminded better of current
expected or possible happy-eyeball style requirements/options.

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

Is it my english ? I agree with your statements, but i don't think my
statements contradict them. I was just saying that specs should be
worked out as good as possible, and not lazily hope for implementations to find
bugs that could have been found in design/review of the spec.

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

Use the extended space then ?

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

Talking about guidelines, i can't remember where i heard
"Never stand in the way of a bad idea", but it solves that issue:
Spend time only on ideas you think could be(come) useful or be made better by
your input.

Of course, it's not ideal, but i think everyone who has tried to reject
a bad idea in IETF in the past knows how that can be a lot more time
consuming than just ignoring it, and the outcome is at most that you
have to spend more time pitching a better solution to the problem to
customers confused by bad ideas. And if ultimately what you continue to
think is a bad idea wins big in the market place, you may have been
technically right but practically wrong anyhow.

Oh, and while we are at it, another unsolicited service reminder:

The "We reject: kings" part of the IETF dogma is suspended for Thailand.
;-)

Cheers
    Toerless

> Lee
> 
> 
> > 
> > Cheers
> >     Toerless
> > > Lee

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------