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

[Qi Sun <[e-mail]>]

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

   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.

   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

   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.  

   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

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

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