Re: [v6ops] Please review the No IPv4 draft

[Owen DeLong <[e-mail]>]

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

> On Apr 14, 2014, at 11:51 PM, Owen DeLong <[e-mail]> wrote:
>> Calling it the wrong thing while advocating an even more wrong thing is equally absurd.
> 
> When I call it the wrong thing, I mean that it doesn't work well (and I explained that).  In practice, not in theory.   You are claiming that adding the capability to shut off DHCPv4 is even more wrong, but you haven't explained why.   So when we weigh the two considerations next to each other, one of which is substantiated by everybody's daily experience of Linux networking, and the other of which is purely speculative and not substantiated by any reasoning that would lead us to think it is true, then despite the fact that, if it were true, it would be worse, we should, logically, weigh the other consideration more heavily.

No, I am not. I am claiming that putting DHCPv4 instructions into DHCPv6 (and/or RA) is even more wrong.

I’m all for adding an ICMP4 or DHCPv4 message to execute that task.

I have, in fact explained why and so has Gert and so have several other people. You are choosing to ignore us while simultaneously disagreeing with us, but that doesn’t change the fact that we have, in fact, done so.

However, to summarize:

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.

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.

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

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.

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

	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);
		}
		…

	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.

> For comparison, suppose you were to assert that there's a significant risk of giant bunnies leaping out into the road when driving on any interstate highway in the U.S.  We could definitely say that if such a statement were true, it would require us to change our driving habits.   And yet we likely would not change our driving habits, because you have given us no reason to think it's true.

If you simply want to bloviate while misrepresenting what has been said, then I see little point in the discussion.

Owen