Re: [v6ops] Please review the No IPv4 draft

["Bernie Volz (volz)" <[e-mail]>]

BTW: How significant is the problem anyway? Has this been analyzed by anyone?

Sure, the clients broadcast these packets but this is the "good" direction in Wifi - the Wifi 'switch' can be told to drop them. Other switches can to?

Seems to me that this would be far better to leave to the networking infrastructure to just 'block' the DHCPv4 packets if IPv4 isn't enabled?

Or are there networks where the periodic DHCPv4 DHCPDISCOVERs will end up costing significant overhead?

I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TLV) already provide some information about whether v4, v6, or both are available?

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Monday, April 14, 2014 4:34 PM
To: 'Ted Lemon'; Owen DeLong
Cc: [e-mail]
Subject: RE: [v6ops] Please review the No IPv4 draft

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

Are the changes really so massive? (In total, yes there probably is a lot of code to tweak, but that will happen if it is done on the IPv6 or IPv4 side.)

To add this to DHCPv4, we would need a new option code that a client that supports the new "DHCPTURNOFF" message (or whatever it is called) includes in the PRL. The server would then know it can send it (if applicable). For clients that don't support this feature, the server would likely just ignore the packets (as if there was no server).

I think the main reasons for considering using IPv6 were:
1. IPv6 components are more likely to be updated (many people would probably prefer not to touch the v4 code if they don't have to anymore). Thus, this change can be rolled out with other changes.
2. For v6 only deployments (where there is no v4), this does require SOME v4 (i.e., to deploy the server - though "link-local" v4 addresses would be perfectly usable). There may also be relays to configure (which involves yet more v4) -- or new small server to implement to eliminate the relay. (If relays are used there might be some issues with whether all relays will relay the packet back to the client with the 'unknown' message type.)

If you have v4 and v6 available on your network, there's no clear winner. If you have only v6 on your network, using v6 to signal this has advantages.

There's one other minor consideration ... if v6 is used to signal this, it can also be used for manually configured IPv4 hosts (though of course you could just manually reconfigure those).

- Bernie

-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Ted Lemon
Sent: Monday, April 14, 2014 2:14 PM
To: Owen DeLong
Cc: [e-mail]
Subject: Re: [v6ops] Please review the No IPv4 draft

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.

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops