Re: [v6ops] Please review the No IPv4 draft

[Nick Hilliard <[e-mail]>]

On 14/04/2014 16:11, Simon Perreault wrote:
> This is a comment that has already been made. It is addressed in section
> 4.1. Did you find the analysis unconvincing?

unfortunately, yes.  Taking the points in order:

4.1.1.1: "Devices that haven't been updated to speak IPv6 likely won't
recognize a new DHCPv4 code telling them that IPv4 isn't supported."  This
is a circular argument which is a bit pointless.

4.1.2 "Devices that don't speak IPv6...": this is not relevant.

4.1.3: maintaining ipv4 infrastructure:  this is reasonable, but there are
relatively simple workarounds with not much overhead (dhcp relays).

4.1.4: no way back: a DHCPv4 option can be enabled with a timeout.
Similarly, you could argue that there's no way back with any DHCP option
because you can set an option timeout to be unfeasibly large for anything.
 But we regard this as an operational or configuration error, not a
protocol problem.  Anyway, most PE access device operators will have some
back-door means of forcing a DHCP retry, e.g. forced line / carrier /
tunnel drops, etc.

Here are some reasons why No Service would be better served over DHCPv4:

0.  this is a protocol layering violation, plain and simple.  From an
architectural point of view, a v6 service should not provide signalling for
a v4 service or vice versa.

1. You need a protocol to allow the the DHCPv6 client to attempt to
communicate with the DHCPv4 client on the end host.  E.g. how do you get
the dibbler v6 client to tell ISC ipv4 dhclient to stop issuing DHCP
requests?  Unless there's a standardised mechanism for doing this, the
draft will not solve the problem you're trying to solve because the DHCPv4
and DHCPv6 clients may be different code trains from different vendors.

2. It would be necessary to implement this for both DHCPv4 and RA.  If it's
in the RA spec, then this will mean that some implementations will need to
have more kernel code to handle a user-space problem.  This is not sensible.

3. it would be trivially easy to implement a No Service option for dhcpv4.

As a separate issue, you may want to put in a time-out field into the
protocol with all-zeros or all-ones meaning infinite timeout.

Nick