Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Apr 2014 11:29:58 -0400

Page 4, paragraph 3:
OLD:
   DHCP clients may be running on CPE devices, end hosts or any other
   device that supports the DHCP client function.  At the time of
   writing, DHCP clients on CPE devices are comparatively easier to
   modify than those implemented on end hosts.  As a result, this
   document uses the CPE as an example for describing the mechanism.
   This does not preclude any end-host, or other device requiring IPv4
   configuration, from implementing DHCPv4 over DHCPv6 in the future.
NEW:
   DHCP clients may be running on CPE devices, end hosts or any other
   device that supports the DHCP client function.  This
   document uses the CPE as an example for describing the mechanism.
   This does not preclude any end-host, or other device requiring IPv4
   configuration, from implementing DHCPv4 over DHCPv6 in the future.

The assertion that CPE devices are easier than hosts isn't precisely true, although I understand what you mean.   In any case, it's not necessary to say this, and it's likely to get a DISCUSS, so why not just take it out? :)

In section 7:
   A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST
   message to either a broadcast or unicast address depending on its
   state.  For example, a client in the RENEWING state uses a unicast
   address to contact the DHCPv4 server to renew its lease.  A client in
   the REBINDING state uses a broadcast address.  If there is a DHCPv4
   relay agent in the middle, a client in the RENEWING state may send a
   DHCPREQUEST message to the unicast address of the relay agent.  In
   such a case, the server is unable to determine whether the client
   sent the message to a unicast or broadcast address and thus the
   server may be unable to correctly determine the client's state.
   [RFC5010] introduced the "Flags Suboption" that relay agents add to
   relayed messages to indicate whether broadcast or unicast was used by
   the client.

You say that the client unicasts to the relay agent in the RENEWING state, but it actually unicasts to the DHCP server.

Last paragraph on page 9:
   The server MAY include the 4o6 Server Address option in its response
   to the client.  If the client receives this option, it MUST enable
   the DHCPv4-over-DHCPv6 function.  The client MUST NOT enable the
   DHCPv4-over-DHCPv6 function if the server does not include the 4o6

I think you should say "If the client receives this option, it enables the DHCPv4-over-DHCPv6 function."   I don't think you need a MUST there.   The MUST NOT is necessary, however.

Same paragraph, top of page 10:
   Server Address option in its response.  If the client does not
   receive this option and DHCPv4 over DHCPv6 is already enabled, the
   client MUST disable the DHCPv4-over-DHCPv6 function.

This is underspecified—a client may be talking to more than one DHCPv6 server, and may have more than one DHCPv6-derived configuration active at the same time.   I think you need something like this:

   Server Address option in its response.   If the DHCPv6 configuration
   that contained the 4o6 Server Address option subsequently expires, the
   client MUST disable the DHCPv4-over-DHCPv6 function.   If, when the
   DHCPv6 configuration that contained the 4o6 Server Address option is
   renewed, the renewed configuration does not contain a 4o6 Server Address
   option, the client MUST disable the DHCPv4-over-DHCPv6 function.

   It is possible in a multi-homed configuration for there to be more than
   one DHCPv6 configuration active at the same time that contains a 4o6
   Server Address option.   In this case, the configurations are treated
   as being independent, so that when any such configuration is active, a
   DHCPv4-over-DHCPv6 function may be enabled for that configuration.

   An implementation may also treat such configurations as being
   exclusive, such that only one is kept active at a time.   In this case,
   the client keeps the same configuration active continuously as long
   as it is valid.  If that configuration becomes invalid but one or more
   other configurations remain valid, the client activates one of the
   remaining valid configurations.

   Which strategy to follow is dependent on the implementation: keeping
   multiple configurations active at the same time may provide useful
   redundancy in some applications, but may be needlessly complex in
   other cases.

Please let me know what you think.  I would like to last-call this document once we've addressed the above issues.

---

From: Qi Sun <[email-masked]>
Date: Mon, 14 Apr 2014 22:51:34 +0800

Dear Ted,

Many thanks for your review! We’ve updated the local version accordingly. 

> You say that the client unicasts to the relay agent in the RENEWING state, but it actually unicasts to the DHCP server.

There is a statement in The 3rd paragraph of the Introduction of RFC5010:
   In some situations, DHCP Clients may unicast their DHCPREQUEST/RENEW
   packets to the DHCP Relay Agent, which will forward the packet on to
   the DHCP server.  In these cases, the DHCP server cannot tell whether
   the packet was broadcast or unicast by the DHCP client, and so it may
   be unable to process the DHCP client packets in the manner that it
   would if it knew whether the original DHCP packet was broadcast or
   unicast.  For example, a server might be willing to NAK a client in
   the REBINDING state based on a determination that the client's
   address does not match its location in the network, but might not be
   willing to do so if the client is in the RENEWING state.

That’s why we wrote that text.
How about the following change:
OLD:
  If there is a DHCPv4
  relay agent in the middle, a client in the RENEWING state may send a
  DHCPREQUEST message to the unicast address of the relay agent. 

NEW:
   If there is a DHCPv4
   relay agent in the middle, [RFC5010] describes the possibility of a
   client in the RENEWING state sending a DHCPREQUEST message to the
   unicast address of the relay agent.

Would it be better? 

Thanks,
Qi

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 10:55:17 -0500

The only reason a client would ever unicast to a relay would be if the Server Override Suboption (RFC5107) were in use.   This can't be used in the case of DHCPv4-over-DHCPv6 because there isn't necessarily an IPv4 address for the relay agent, nor an IPv4 transport the client could use to reach it.   I think mentioning this is unnecessary and confusing.   I can't think of any situation where there would be confusion as to whether the server override option could be used with DHCPv4-over-DHCPv6.   You could forbid using the option if you think this needs to be addressed.

So I think the right thing to do is remove text, not change text.   Your new text is more confusing than the old text, but if the only reason you thought to mention this was to address the RFC5107/RFC5010 use case, I think you can skip it.

---

From: Qi Sun <[email-masked]>
Date: Tue, 15 Apr 2014 14:54:14 +0800

Dear Ted,

Many thanks for the suggestion. 

How about this one, with text/reference about RFC5010 removed:
OLD:
7.  Use of the DHCPv4-query Unicast Flag

   In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the
   DHCP 4o6 server.  There is no relation between the outer IPv6 address
   and the inner DHCPv4 message.  As a result, the server is unable to
   determine whether the received DHCPv4 messages should have been sent
   using broadcast or unicast in IPv4 by checking the IPv6 address.
   This is similar to the case addressed by [RFC5010].

   In order to allow the server to determine the client's state, the
   "Unicast" flag is carried in the DHCPv4-query message.  …

NEW:
7.  Use of the DHCPv4-query Unicast Flag

   the REBINDING state uses a broadcast address.  

   In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the
   DHCP 4o6 server.  There is no relation between the outer IPv6 address
   and the inner DHCPv4 message.  As a result, the server is unable to
   determine whether the received DHCPv4 messages should have been sent
   using broadcast or unicast in IPv4 by checking the IPv6 address.

   In order to allow the server to determine the client's state, the
   "Unicast" flag is carried in the DHCPv4-query message.  ...

Would this be clear enough? 

Best Regards,
Qi

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 09:53:29 -0500

> Would this be clear enough? 

Yes, I think that's much better.   Thanks!