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

[Brian E Carpenter <[e-mail]>]

Toerless,
On 2018-11-01 04:30, Toerless Eckert wrote:
> 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.

It's only an argument for SHOULD rather than MUST. And you know that in
the real world of product development, everything is SHOULD anyway, if that
suits the vendor better.

   Brian

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