Re: [v6ops] Please review the No IPv4 draft

[Ted Lemon <[e-mail]>]

On Apr 15, 2014, at 11:33 AM, Owen DeLong <[e-mail]> wrote:
> 1.	It makes little sense to me to try and turn off DHCPv4 using an IPv6 message when it can much more cleanly be
> 	done with a very simple IPv4 message.

An opinion, which is addressed and refuted in the draft.

> 2.	A client which is a “problem” as you describe the problem statement is a client which is sending DHCPv4REQUEST
> 	messages. Therefore, an appropriate way to identify and rectify such a problem is to send an IPv4 packet in
> 	response to the DHCPv4REQUEST message which says “STOP THAT”. Such a message could either be a
> 	new DHCP response type or an ICMP message indicating that the DHCPv4 service is unavailable.

An opinion, not a technical objection to the current proposal.

> 3.	Others have raised a concern that forged ICMP based “STOP THAT” messages in IPv4 could:
> 	1.	Bypass DHCP Snooping safeguards
> 	2.	Serve as a DoS vector

True, but since this draft doesn't propose such a mechanism, not a technical objection to the current proposal.

> 4.	The concerns expressed in 3 received the following response:
> 	1.	The IPv6 based message would also bypass IPv4 DHCP snooping
> 	2.	Require clients which receive both a “STOP THAT” message and a DHCPOFFER to act on the Offer
> 		and ignore the “STOP THAT” message for some time.

There's been some discussion of this specifically on the homenet mailing list which I think didn't get Cc'd here, unfortunately, and it looks like there will be a new draft out that addresses this issue.

> 5.	You argued that it is more difficult to implement changes to the DHCPv4 state machine than to implement something
> 	where the IPv6 DHCP or RA client would somehow pass a message to the upstream “glue code” whatever that may be
> 	on any given platform which would then cause it to kill off the DHCPv4 process on the client (and possibly shut down
> 	other aspects of the IPv4 stack on the client as well).

No, I said we'd have to update the DHCP protocol specification to add another state to the state machine, and we'd have to think through all the implications of that.   Whereas simply shutting off the DHCP client while the network says "suppress IPv4" is quite easy, and we already know how to do it.

> 
> 	I don’t buy that argument as I believe it would be pretty simple to add code to DHCPv4 clients that essentially does the following:
> 
> 		...
> 		if (DHCP_SHUTDOWN_RECEIVED)
> 		{
> 			/* code here to listen for other DHCP responses over the next n seconds (probably n<30) */
> 			if (DHCP_OFFER_RECEIVED) break;
> 			/* If needed, any clean-up code before terminating the DHCPv4 process and/or to shutdown the IPv4 stack */
> 			exit(0);
> 		}
> 		…

Great, so what happens when I switch networks to an IPv4-only network?   My DHCP client is down, and you haven't implemented a mechanism for bringing it back up.   No offense, but I've had my hands deep and dirty in this code—I'm not just talking through my hat.

> 
> 	On the other hand, what you propose requires:
> 
> 		1.	Add options to RA
> 		2.	Add options to DHCPv6
> 		3.	Update every RA implementation to somehow pass receipt of this option up to “glue code”
> 		4.	Update every DHCPv6 implementation to somehow pass receipt of this option up to “glue code”
> 		5.	Update glue code to deal with all possible variants of how the RA/DHCPv6 information may be passed up to that glue code.
> 		6.	Update glue code to properly terminate all possible variants of DHCPv4 client which may be running on the host.
> 		7.	Update glue code to do any other tasks required to shutdown IPv4 on the applicable interface on the host.
> 
> 	I’ll note that in many cases, the DHCPv4, DHCPv6, RA, and “glue code” come in multiple variants and even in one set of variants,
> 	each of those 4 items may have different maintainers and/or different organizations/persons responsible for said maintenance.
> 
> 	As near as I can tell the draft does not standardize any of the APIs necessary for the communications in the above 7 steps.

We've never written a standard API for DHCP because nobody's been interested.   Microsoft has their way, Apple has their way, Linux hasn't really figured out a way yet.   When I wrote the ISC client, I made the action part of the client a shell script so that it would be easy to script, but that turned out to be a mistake because the DHCP client state machine interacts with so many other state machines.

Right now the state of the art on this is a homogenous configuration architecture.   I share your desire for the architecture to be general enough that parts can be plugged in and out, but that doesn't mean we can just punt on making it actually _work_.   And if we make it actually work, the points you raise above, while valid, are not a show stopper.   If we don't care about making it work, then we might as well punt on the turn-off-DHCPv4 thing entirely on that platform, because I don't think it can be made to work satisfactorily anyway.

If you are interested in what's going on in terms of advancing the state of the art on Linux, I encourage you to look at what the systemd team is doing, and also at what Simon Kelley has been doing in dnsmasq.   NetworkManager is not something I'd suggest wasting any time on, and the other configuration infrastructures on Linux are too half-baked to even seriously consider when we're talking about touchless configuration.