Re: [v6ops] Please review the No IPv4 draft

[Owen DeLong <[e-mail]>]

On Apr 15, 2014, at 10:39 AM, Ted Lemon <[e-mail]> wrote:

> 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.

Not adequately refuted to change my opinion.

> 
>> 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.

The current proposal states that the problem is clients sending DHCPv4REQUESTS.

>> 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.

No, a technical solution to the proposed problem.

>> 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.

OK, but this is a technical problem with the current draft as written.

>> 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.

And I’m saying you don’t need to add another state to the state machine, you simply provide a way to tell a DHCPv4 client to turn itself off. This does not have to be stateful or added to the state machine as shown below.

> 
>> 
>> 	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.

Neither am I. In my experience on most hosts (and I admit I am not an expert on all operating systems, but this seems easy enough to change where a change would be required), the DHCP client gets relaunched on a link state transition from no-link to link, including sleep/wake events. Unless you believe such a transition would occur without a link-state or sleep/wake transition occurring, I don’t see this as a serious problem.

>> 	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… But we’ve also never required interaction between DHCPv6 and the behavior of the DHCPv4 client before, either, whether directly or through “glue code”.

> 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.

No, the state of the art is all over the map. There is absolutely no homogenous configuration architecture. One may be getting developed here and there on some platform(s) and some platforms may actually already have one, but it is by no means the ubiquitous state of the art.

I’m not proposing punting on making it work. In fact, I proposed what I believe to be a superior solution which keeps things properly modular, but you want to decry my concerns as invalid simply because I’m not paying attention to sunset4, but as an operator I am here in v6ops, which in my mind is one of the main reasons for bringing this draft to v6ops.

I care about making it work, but as you have just admitted, it can be made to work in a way which doesn’t break modularity.

> 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.

Unfortunately, while I might personally find that entertaining, I actually have other more pressing things that I must do for $DAYJOB.

I think you will find that this is one of the primary reasons that operator participation in the IETF and other such working groups and development efforts.

The biggest other one would be the tendency to tell us that we’re not complaining in the correct way or that our concerns are invalid when we do speak up.

Owen