Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

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

On 28-May-19 04:21, Bjoern A. Zeeb wrote:
> On 24 May 2019, at 14:47, Philip Homburg wrote:
> 
>>> I wonder if the ipv6only flag could be used to test IPv6 on networks.
>>> That is, turn off IPv4 and see if the IPv6 is working.  Turn off 
>>> IPv4,
>>> then make sure there is working IPv6 connectivity, throughput, etc.,
>>> then turn IPv4 back on.
>>>
>>> Perhaps a new use case.
>>
>> To make that work you have to turn off DHCPv4 as well. So you don't 
>> need
>> the flag.
> 
> That wasn’t the case with the earlier initial versions of the draft; 
> the ability for that “use-case” only went away with people asking 
> for it as they are worried about legacy accidentally turned off by a 
> rouge RA packet.
> 
> There’s still good ways to use the two options together for testing if 
> I think about tuning lifetimes of each of these protocols, etc.
> 
> It was all simpler when the draft was simple and I wonder if with the 
> (global) flag to turn off enabling of processing the flag, the “IPv4 
> address configured on the interface” requirement could be removed 
> again from the draft;  that would also avoid cross-protocol-family 
> pollutions in the implementations.

Agreed. I think this discussion has been drifting into layers of
operational and implementation implications of how dual stacks will
in general deal with a world in which IPv4 is becoming redundant.
We're going to have to face those issues with or without an IPv6-only
flag.

     Brian

> 
> 
> In addition to that, I challenge you to see what a network without 
> DHCPv4 looks like when you check the “legacy IP noise levels” (even 
> if there is no static IPv4 configurations and even more so if you’d 
> only send DHCPv4:116).
> 
> 
>> The bigger problem is that without IPv4, most of the internet is 
>> unreachable.
>> So it is bit hard to test if it is IPv6 that is failing or not.
> 
> You can still test (a) that your local services on the LAN work with 
> IPv6-only, that you can reach (b) important (external) IPv6 enabled 
> services, (c) if anything breaks if you go through a proxy or 
> translation service, .. (just to name the first three which came to my 
> mind).
> 
> 
> /bz
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>