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

[Toerless Eckert <[e-mail]>]

Ok, so more generalized, the argument is 

"Trust the sum of all IPv6 router on a subnet more than a possible
IPv4 router" may not apply in cases where the host wants to try all
it can do to communicate. Example: emergency communications.

Qualitatively this is not wrong, i am just not sure if this should
really be considered for standards track behavior now.

One argument is that it does not make sense to introduce this level
of complexity before an even more important level of resiliency is
not done either. For example IMHO it would be even more important
to rethink resilience in the presence of multiple routers of the
same address family first and for example make such a device/app
try in parallel to reach the remote server in parallel across all of
the found IPv6 routers. Unless there is a different IPv6
prefix assigned to the host for each such router, there is no
way for a host stack to do this because the standard transport APIs do not
offer knowledge about the different routers (You would have to hack
this). 

So, in my book this means that we should not bother about third priority
considerations unless we've resolved all second tier priorities,
and then we can still write an update of this document.

Aka: KISS to make the approach more attractive.

Cheers
    Toerless


On Wed, Oct 31, 2018 at 01:36:44PM +1300, Brian E Carpenter wrote:
> On 2018-10-31 10:03, Toerless Eckert wrote:
> > Brian,
> > 
> > I think i would be happier with a stronger goal of the flag
> > relying less or not at all on heuristics of hosts.
> > 
> > Give me a reason why dual-stack hosts should want to do IPv4
> > on a subnet if there is no IPv4-only host and no router routing IPv4. 
> 
> The example I've used is a an IP-based smoke detector trying to connect
> to an IP-based central fire alarm system. Because human safety is
> involved it needs to try every possible type of connectivity in any case,
> so giving up on IPv4 because the IPv6 routers say so is not the right
> answer. IMHO, a perfect case for an RFC2119 SHOULD:
>   "... there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course."
> 
>       Brian
> 
> 
> 
> > 
> > This seems like the most simple case to discuss about and agree
> > what to do for it. TO me it seems that it would be great to
> > recognize this case and automatically disable IPv4 stack/interface
> > because of a flag from routers on all dual-stack hosts.
> > 
> > Cheers
> >     Toerless
> > 
> > On Wed, Oct 31, 2018 at 08:43:40AM +1300, Brian E Carpenter wrote:
> >> On 2018-10-31 02:47, Philip Homburg wrote:
> >>>> So, here's the challenge which you seem to be holding back from,
> >>>> write down the actual rules. No hand waving that "that's a good
> >>>> clue", but actual rules that "if you see <some observable state>
> >>>> then <do some specific action>".
> >>
> >> If by "rules" you mean "a typical heuristic", sure. But there will
> >> be hosts that follow a different logic for their own good reasons.
> >> That simply isn't the IETF's business.
> >>
> >> The draft is quite clear on this:
> >>
> >>    Dual stack hosts that have a good reason to use IPv4, for example for
> >>    a specific IPv4 link-local service, can attempt to do so.  Therefore
> >>    respect of the IPv6-Only flag is recommended, not mandatory, for
> >>    hosts.
> >>
> >> On 2018-10-31 04:18, Toerless Eckert wrote:
> >> ....
> >>> IMHO:
> >>>
> >>> If the host sees the ipv6only flag from all IPv6 routers, it MUST NOT
> >>> perform IPv4 DHCP.
> >>
> >> Who cares? Legacy hosts will try DHCP anyway. We don't want an updated
> >> host to waste spectrum on this, but that's a SHOULD NOT, because such
> >> traffic won't actually break anything.
> >>
> >>     Brian
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > 

-- 
---
[e-mail]