Re: [v6ops] Please review the No IPv4 draft

[Owen DeLong <[e-mail]>]

>  The authors of the draft thought about it, wrote drafts documenting various solutions, and came up with "no, it's better to do it over IPv6."

Which is strictly THEIR OPINION. An opinion which is apparently NOT shared by many people on this list.

> What I am characterizing as opinion is "this is hard to do on Linux, therefore we should do it this other way."   It's true that it's hard to do on Linux, for certain values of Linux, but the connection between that and "we should do it this other way" is opinion.   This is compounded by the fact that there are already other configuration interdependencies that are handled poorly by the same Linux configuration framework we are talking about, and consequently work is being done to come up with a more robust framework.   I've mentioned this, but the response was to ignore that point and continue to assert "this is hard on Linux."   Which is why I tend to see this as "opinion" rather than "technical objection."

I don't believe that is a valid characterization of what was said.

What was said was "This is a bad way to do it for a number of reasons..."

Beyond that, there was an "oh, by the way, it's also hard and brittle on Linux".

IMHO, this should be done in DHCPv4 or ICMPv4 (and the more I think about it, the more I think ICMPv4) and NOT IPv6 because:

	1.	Principle of least surprise. IPv4 developers do not expect to have to anticipate that things happening
		over IPv6 will affect the behavior of core IPv4 services, nor should they. Most systems and network
		administrator have the same expectation.

		Configuring an IPv4 address over an IPv6 tunnel might be an exception, but at least in that case, the
		operator is aware of the fact that they are trying to tunnel IPv4 through IPv6 and that is likely to modify
		their general expectation. Shutting down IPv4 on command issued over IPv6, OTOH, violates all kinds
		of expectations and is likely to result in significant surprise in the operator community.


	2.	This feature could be implemented in IPv4 with little or no IPv4 stack running on the implementing device
		in question (AP, Router, etc.), so the argument that it requires an IPv4 stack to be preserved is somewhat
		specious. All that is needed is enough to detect an IPv4 DHCPREQUEST (and/or BOOTPREQUEST) and
		respond with a preformed ICMP DHCP4UNAVAILABLE message.

	3.	A host could receive conflicting IPv6 and IPv4 messages about what it is supposed to do about IPv4
		configuration. You can argue that such behavior is a broken network configuration, but the reality is that
		failing to consider this in real world scenarios has undesirable operational effects and security implications.
		At the very least, behavior in the face of such an event on the client side should be specified and
		deterministic.

	4.	The number of clients likely to be affected by this change is much greater than the target space. Moving this
		to IPv4 would reduce the impact space to match the target space.

And Oh, by the way:

		While Linux is an example of a well modularized operating system where IPv4 configuration is handled
		by completely separate mechanisms than IPv6 configuration, it is likely not the only one. Implementation
		of this on any such modularized system is likely to result in brittleness and unexpected consequences.

> 
>>> I'd be just as happy if the conclusion of the process was "just
>>> filter IPv4 at the access points if you want it to go away," and I'd
>>> like to see more discussion on that topic.
>> 
>> this is also a valid concern.  I can see no reason why anyone would heed an
>> unauthenticated signal to entirely shut down all ipv4 services o/s wide on
>> their ipv4-enabled client (or even no-ipv4 options 1-2 for that matter),
>> when we already have the existing option for operators to fully satisfy all
>> aims of this draft by declining to forward ethertypes 0x0800 and 0x0806.
>> Simple and enforceable are both good engineering principals to aspire to.
>> Complex+advisory+piles of failure modes+controversial need a much greater
>> level of justification, which is notably absent from this draft.
> 
> Noted.   I think it would be good to have text in the document that explains why this isn't the proposed solution, so that it can be evaluated on the merits and we don't have to speculate.

I'd agree with that at the very least, though modifying the draft to propose an ICMP4 DHCPUNAVAILABLE message and client behavior in the face of receiving both that and a DHCPOFFER would be preferable IMHO.

Owen