Re: [v6ops] Please review the No IPv4 draft

[Ray Hunter <[e-mail]>]

Simon Perreault wrote:
> Le 2014-04-15 07:35, Nick Hilliard a écrit :
>> This is not an especially relevant argument because if there were a dhcpv4
>> option to handle this, all you would need to provide the service would be a
>> local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service
>> option. There would be no requirement to back-haul the initial DHCPREQUEST
>> to a centralised provisioning system.  IOW, from an operational point of
>> view, this can be provided simply and easily using dhcpv4 at the local
>> level, and this mechanism would spectacularly avoid the deployment problems
>> that Ray outlined.  Handling this over DHCPv6 involves a level of string,
>> gum and duck tape that makes me want to cringe.
>
> This doesn't work when the L2 link is shared with clients to which you
> do want to provide IPv4 service.
Wait a minute. If there's routers there that need to provide IPv4 
selectively to some client nodes on the same L2 link then you almost 
certainly have an on link DHCPv4 server already. Or at least an IPv4 
speaking router that can support one. And that is most likely already 
hooked in to a centralised provisioning system via DHCPv4 relays.

And you anyway have to track L2 addresses to know which nodes on the 
link DO need a proper IPv4 service and which DON'T.

In that case, just assigning all clients that do not enjoy an IPv4 
service an address from a network 10.X.X.X/8 (the range can can be 
re-used on every end router) and filtering at L3 with an access list has 
exactly the same effect.
Better still: assign those hosts that should not be using IPv4 an 
address with a very long lease via DHCPv4 from one of your RTBH black 
hole ranges. http://tools.ietf.org/html/rfc5635.

They'll never send packets off link and they'll not retransmit DHCPv4 
requests for a very long time.

It's re-using an existing mechanism that is operationally proven, is 
unlikely to cause surprises, and has the advantage of not requiring any 
new code on either the end nodes nor the last-hop routers.

>
>> As a separate issue, if the operator really wants to disable all ipv4, why
>> not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer?
>
> This doesn't work when the L2 link is shared with clients to which you
> do want to provide IPv4 service.
>
> Simon
We should fix this in IPv4. Polluting IPv6 with IPv4 switches is a bad move.

Why does anyone think that badly behaved DHCPv4 clients will be any 
better behaved because there's a (new) DHCPv6 or RA option being advertised?
If they're broken for IPv4 and haven't been patched for a long time, 
they're even more likely to be broken for IPv6, and just as likely not 
to be patched IMHO.

-- 
Regards,
RayH