Re: [v6ops] Please review the No IPv4 draft

[Owen DeLong <[e-mail]>]

On Apr 22, 2014, at 6:23 AM, Simon Perreault <[e-mail]> wrote:

> Le 2014-04-22 09:00, George, Wes a écrit :
>> WG] I think that there’s a need for clarification here. A lot of this
>> discussion has focused almost exclusively on the full-on disabling of
>> IPv4. Part of what the draft discusses is that there are differing
>> things that can be signaled to the local devices from the network based
>> on the bit set in the proposed option. There is an option that simply
>> signals “there is no IPv4 support on this network” and makes attendant
>> recommendations that the device decide on its own what to do for any
>> local IPv4 traffic on the LAN, including doing nothing, configuring 169
>> addresses, etc. but that it should disable IPv4 on the upstream
>> interface facing the network that provided the signal (I.e. Stop
>> forwarding IPv4 traffic and stop sending DHCPv4). 
>> I’m willing to go with consensus (if exist) that the more aggressive
>> option of something like a full-on IPv4 killswitch that affects more
>> than one interface and affects the local network is a bridge too far,
>> both for security reasons (It’ll be hard to secure to a level that
>> exploits aren’t likely) and because it gets into a question about
>> autonomy and span of control. But I think it’s worth highlighting that
>> there are also less aggressive options discussed in the draft, and I’d
>> like to have some sense that those are mostly on the right track, and
>> your statement is so broad that I wanted to get clarification on what
>> you think of this.
> 
> Right.
> 
> To be very explicit, one of the "less aggressive" options on the table
> is to specify a "there is no IPv4 on this network" signal while saying
> nothing about how a host should react to this signal. Each
> implementation could use that hint however it sees fit.

Because IPv6 deployment has been helped so much in the past by ambiguous standards which allow wildly different implementations from vendor to vendor.

If we’re going to specify a signal, we should specify what the host should do with that signal.

Owen