Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

["Bernie Volz (volz)" <[e-mail]>]

Hi:

As the assigned document shepherd for this work, I have reviewed it fairly carefully. And, I have the follow more significant comments regarding this draft:


1.       I've already commented on the two vs. one option issue. I think simplifying this to use a single option which is returned by the server to enable this feature and, optionally, specify a list of IPv6 addresses to which to send the packets.

2.       I think we should rename the messages to be BOOTP, not BOOT. BOOTPREQUESTV6 and BOOTPREPLYV6 (and Bootp-request-v6, Bootp-reply-v6). (I also wonder whether we really need the v6, but it may help in clarifying this from standard BOOTP packets, so OK to leave it.)

3.       At the end of section 7 (Use of the Boot-request-v6 Unicast flag), I think it would be useful to add a note to make it clear that this flag represents how the DHCPv4 packet would have been sent, not how the v6 packet is sent. (Note: The "Unicast" flag reflects the how the DHCPv4 packet would have been sent; not how the DHCPv6 packet itself is sent.)

4.       In section 8 (4o6 DHCP Client Behavior), should we be clear that everything is 'interface' specific? 'Client' here is a bit open to its meaning. Though on the other hand, everything with respect to DHCP is typically interface specific so perhaps clarifying this isn't that critical.

5.       Also in section 8, it may be useful to add something about IPv6 source address considerations ... Section 13 of RFC3315 doesn't mention the IPv6 source address, but it is important that packets sent to a global address have sufficient scope. Though in most cases, this can be left to the kernel (if the source address is unspecified).

6.       Also in section 8, for "There are no explicit transmission parameters associated with a Boot[p]-request-v6 message." I think adding ", as this is governed by the DHCPv4, [RFC2131], "state machine"." Or something like that.

7.       In section 10, 2nd paragraph, I wonder if "...broadcast or unicast address if DHCPv4 protocol was used" should be "broadcast or unicast address if IPv4 has been used." The packet is transmitted over IPv4. But this is minor.

8.       In section 12 (IANA Considerations), please improve this to make it clear exactly what registry. You may want to look at the SOLMAX draft text:

IANA is requested to assign one option code each for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT from the "DHCP Option Codes" table of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry.

There have been a few cases where IANA used the wrong table; while we will hopefully catch that ...

You could even provide the URL for the table (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml).

9.       A general issue ... I wonder whether we have a kind of catch-22. As DHCP is interface specific, and the tunnel interface may not be able to 'come up' until after the address is assigned, what interface is this 'DHCPv4' (4o6) client associated with? Is it the v6 interface? Or a 'provisional' tunnel interface? Or, is this left up to the implementation to deal with (since in one sense it probably doesn't matter much - except of course if one was trying to bring up multiple tunnel interfaces over the same v6 interface; but that requires other special logic so may not be a concern).


As well as the following minor nits (note that I did NOT apply changes to the message names as indicated in 2 above):

In section 1, Introduction:

   This document describes a transport mechanism to carry DHCPv4
   messages using DHCPv6 protocol, for the dynamic provisioning of IPv4
   addresses and other DHCPv4 specific configuration parameters across
   IPv6-only networks.  It leverages the existing infrastructure for
   DHCPv4, e.g. failover, DNS updates, leasequery, etc.

Line 2, should be (add the, remove comma):

   messages using the DHCPv6 protocol for the dynamic provisioning of IPv4

In section 3, Terminology:


   CPE:                  Customer Premises Equipment (also known as

                         Customer Provided Equipment), which provides

                         the access of devices connected to Local Area

                         Network (typically at customer's site/home) to

                         Internet Service Provider's network.
Should be (add a and the twice):


   CPE:                  Customer Premises Equipment (also known as

                         Customer Provided Equipment), which provides

                         the access of devices connected to a Local Area

                         Network (typically at the customer's site/home) to

                         The Internet Service Provider's network.

In section 4, Architecture Overview:


   Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers

   using well-known All_DHCP_Relay_Agents_and_Servers multicast address.

Should be (add the):


   Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers

   Using the well-known All_DHCP_Relay_Agents_and_Servers multicast address.

And also:


   Client SHOULD request the 4o6 Server Address Option from a DHCPv6

   server and the server may be configured to respond to the client with

   one such option that contains one or more unicast addresses of the

   4o6 DHCP Servers.  The server includes 4o6 Server Address Option in

   Advertise and Reply messages.  The format of the option is defined in

   Section 6.3<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-6.3>.

Should be (add the twice):


   The client SHOULD request the 4o6 Server Address Option from a DHCPv6

   server and the server may be configured to respond to the client with

   one such option that contains one or more unicast addresses of the

   4o6 DHCP Servers.  The server includes the 4o6 Server Address Option in

   Advertise and Reply messages.  The format of the option is defined in

   Section 6.3<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-6.3>.

In section 5.2, Message formats:


   msg-type        Identifies message type.  It can be either

                   BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which

                   corresponds to the Boot-request-v6 or Boot-reply-v6,

                   respectively.

Should be (add the):


   msg-type        Identifies the message type.  It can be either

                   BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which

                   corresponds to the Boot-request-v6 or Boot-reply-v6,

                   respectively.

In section 7, Use of the Boot-Request-v4 Unicast Flag


   A DHCPv4 client conforming to the [RFC2131<http://tools.ietf.org/html/rfc2131>] may send its DHCPREQUEST

   message to either broadcast or unicast address depending on its

   state.  For example, the client in the RENEWING state uses a unicast

   address to contact a DHCPv4 server to renew its lease.  The 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 case the server can't find out whether the client sent a message

   to a unicast or broadcast address and thus it can't determine the

   client's state.  [RFC5010<http://tools.ietf.org/html/rfc5010>] introduced the "Flags Suboption" which

   relay agents add to relayed messages to indicate whether broadcast or

   unicast was used by the client.

Should be (remove the, replace "it can't find out" with "the server may be unable to", replace "can't" with "is unable to"):


   A DHCPv4 client conforming to[RFC2131<http://tools.ietf.org/html/rfc2131>] may send its DHCPREQUEST

   message to either broadcast or unicast address depending on its

   state.  For example, the client in the RENEWING state uses a unicast

   address to contact a DHCPv4 server to renew its lease.  The 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 case the server is unable to determine whether the client sent a message

   to a unicast or broadcast address and thus the server may be unable to determine the

   client's state.  [RFC5010<http://tools.ietf.org/html/rfc5010>] introduced the "Flags Suboption" which

   relay agents add to relayed messages to indicate whether broadcast or

   unicast was used by the client.

And in the following, drop "the" before the RFC?


   In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the

   4o6 DHCP Server.  There is no relation between the outer IPv6 address

   and the inner DHCPv4 message.  So the server is not able to know

   whether the 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 the [RFC5010<http://tools.ietf.org/html/rfc5010>].

And in the following add "The" before Client (The client MUST...):


   In order to allow the server to determine the client's state, the

   "Unicast" flag is carried in the Boot-request-v6 message.  Client

   MUST set this flag to 1 when the DHCPv4 message would have been sent

In section 8, 4o6 DHCP Client Behavior:

In the first bullet, change doesn't to does not.

And:


   o  If the client receives both options, it SHOULD enable the DHCPv4

      -over-DHCPv6 function and send requests to the unicast address(es)

      in the 4o6 Server Address Option.

Should be (add SHOULD and add each of):


   o  If the client receives both options, it SHOULD enable the DHCPv4

      -over-DHCPv6 function and SHOULD send requests to each of the unicast address(es)

      in the 4o6 Server Address Option.

Add "the" before "DHCP protocol" in:


   The client signaled by the server to use DHCPv4 over DHCPv6 SHOULD

   cease to send DHCPv4 messages using DHCP protocol described in

Also:


   Client MUST follow rules defined in Section 7<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-7> when setting Unicast

   flag.

May be improved by adding "based on the DHCPv4 destination):


   Client MUST follow rules defined in Section 7<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-7> when setting Unicast

   Flag based on the DHCPv4 destination.

And in:


   On receiving a Boot-reply-v6 message, the client MUST look for the

   BOOTP Message option within this message.  If this option is not

   found, the Boot-reply-v6 message is discarded.  If the BOOTP Message

   Option presents, the client extracts the DHCPv4 message it contains

   and processes it as described in section 4.4 of [RFC2131]<http://tools.ietf.org/html/rfc2131#section-4.4>.

The "presents" is odd. Did you mean "is present"?

And finally, in section 11:


   which can cause an amplification attack.  To avoid this, the client

   MUST check if there are repeated IPv6 addresses in a 4o6 Server

   Address Option when receiving one.  The client MUST ignore those

   duplicated unicast IPv6 addresses.

Perhaps change 'repeated' to 'duplicate'? As you use that in the next sentence, so better to be consistent?


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, November 24, 2013 5:03 PM
To: [e-mail]
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013


Folks, the authors of draft-ietf-dhc-dhcpv4-over-dhcpv6-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt) believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 9th, 2013.



At the time of this writing, there is no IPR reported against this draft.



Bernie will be the document shepherd.



Thanks,


-          Tomek & Bernie