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

[Qi Sun <[e-mail]>]

Dear Ted,

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

As for the text in Section 7:
> 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.

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



On Apr 11, 2014, at 11:29 PM, Ted Lemon <[e-mail]> wrote:

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