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

[Ted Lemon <[e-mail]>]

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.