Re: [v6ops] Please review the No IPv4 draft

[Ted Lemon <[e-mail]>]

On Apr 14, 2014, at 11:49 AM, Owen DeLong <[e-mail]> wrote:
> What is being proposed here would be more like responding to an IPv4 packet with an ICMP6 unreachable, which I’m pretty sure would be considered problematic.

Okay, let's consider your example as it relates to the discussion.   Here we are talking about responding to an IPv6 packet with another IPv6 packet, which contains information about the availability of IPv4 service on the local wire.   In your example you are talking about responding to an IPv4 packet with an IPv6 packet.   So the two situations are not analogous.   I agree that if we were doing what you suggest in your example, that would be a bad idea, because the association between an IPv4 and an IPv6 address is something that would have to be inferred by the network, and that _would_ involve a layering violation.

But the actual use case we are talking about involves no such layering violation.

> Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 makes sense to me.

So you are proposing a massive change to the DHCPv4 protocol in order to arrange for it to be able to be turned off, rather than a minor change to the DHCPv6 protocol to signal that there is no IPv4 available.   How does this make sense?

> Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST message by any router which is configured to authoritatively deny DHCPv4 on the link? A host receiving such a message should be expected to behave in an identical manner to the behavior proposed in this draft.

ICMP != DHCP.   You just objected to the No IPv4 proposal (or Nick did) on the basis that it's hard for a DHCPv6 client to pass information to a DHCPv4 client (which, TBH, sounds like a bug to me).   Why is it easier for the ICMP implementation in the kernel to pass information to the DHCPv4 client?   I have personal experience with this: there's code in the ISC DHCP server/client that has to catch bogus error messages pushed up the stack by the kernel and ignore them in order to avoid having its state machine broken, because the kernel has no way to associate ICMP messages with particular datagram sources.  My belief was that the kernel should discard such messages, because it can't do anything useful with them, but the linux guys decided to deliver them; neither solution is really satisfactory.  You are proposing to use this as a solution in favor of something that would actually work reliably.   That doesn't make sense.

The reality is that one of the biggest problems with the configuration system on linux is that the various components don't communicate with each other in a useful way.   Other operating systems manage to do a better job, and there's work ongoing in the linux community to fix this problem (e.g., systemd is now pulling a lot of network stack functionality into it specifically so that it can be part of the system configuration state machine as a whole, and dnsmasq does something similar).

So in reality it makes a tremendous amount of sense to put this information in DHCPv6, and the concern that it may be difficult to communicate the information to the IPv4 stack is a temporary situation that's easily addressed.   Putting it in IPv4 means more useless network traffic, more attack surfaces on IPv6-only routers, etc.