Re: [v6ops] Please review the No IPv4 draft

[Owen DeLong <[e-mail]>]

On Apr 14, 2014, at 9:36 AM, Ted Lemon <[e-mail]> wrote:

> On Apr 14, 2014, at 11:08 AM, Nick Hilliard <[e-mail]> wrote:
>> because you're using one protocol stack to send signals about another
>> protocol stack.  "layering violation" is possibly the wrong term.  Maybe
>> "protocol bleed" or some
> 
> There is no such thing, and this isn't a valid distinction, at least according to current practice.   This is like saying that an HTTP server that runs over IPv6 can't redirect to a URL that would be fetched over IPv4, or that you can't do a DNS query for a AAAA record over IPv4, or an A record over IPv6.

Not really…

An HTTP server shouldn’t be redirecting to an IP address at all. It should be redirecting via name. Since the address family that the name resolves to is opaque, a name is just a name.

Similarly, DNS is a database query, not a protocol signaling for configuration purposes.

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.

>>> And if you don't have IPv4, how do you have DHCPv4?
>> 
>> this is the thing: the whole proposal is a bit circular. If there's no
>> DHCPv4 server, argument 3.1 is irrelevant and argument 3.2 is almost
>> irrelevant because on any shared access medium, dhcp traffic which is
>> ignored is not going to make up significant amounts of traffic.  There's
>> some justification for 3.3 but that can be dealt with on e.g. radio devices
>> by coalescing requests so that control request like this / RA / etc are
>> send alongside each other.  3.4 is an application level problem and it's
>> not the job of the ietf to fix stupid / broken applications.
> 
> It's broadcast traffic, which is expensive for everyone sharing a Wifi AP.   If every host is doing it, that's a lot of traffic.

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

> Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this option, is the expectation that the client will shut down at that point?   That's a substantial protocol change, if so.   If we're going all the way to DHCPACK, now the client has an IP address.   What if it tries to use it?

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.

> Only a client that's IPv6-capable is ever going to act on this option, so doing it with DHCPv4 doesn't really make sense.

Only a client that’s going to try DHCPv4 is ever going to act on this option, so doing it in DHCPv6 doesn’t really make sense.

Owen