Subject: [dhcwg] draft-scskf-dhc-dhcpv4-over-dhcpv6-01 comments

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 2 May 2013 17:24:22 +0000

Hi:

Some comments on the 01 draft:

- In 1. Introduction:

   Several approaches for provisioning such information have been
   already been proposed.  This document describes one such approach

Is this really worth adding? Especially without providing references? Also, if we are to abandon those other approaches, why would we want the RFC (assuming this becomes one) to confuse people into thinking they may have alternatives?

- In 3. Terminology

This seems an odd section title to define new messages? Could this not just be "New Messages" or something like that? It may also make sense to move this to after current section 4?

I also think it would be best to clearly indicate that these messages are formatted as show in Section6 of RFC 3315 (yes, that may be obvious to us, but best to be explicit).

This would also mean you could remove the "A new type of ..." in the definition.

And, "Each BOOTP Message Option" makes it appear there could be more than one in a message, which is not something I think we want.

So, how about:

3. New DHCPv6 Messages

The following new DHCPv6 Client/Server messages are defined by this document. These are formatted as specified in Section 6 of [RFC 3315].

   BOOTREQUESTV6 (TBD):  A client sends a
                         BOOTREQUESTV6 message to a server, which
                         contains a BOOTP Message Option.  The BOOTP
                         Message Option contains a BOOTREQUEST message
                         that the client uses to request IPv4
                         configuration parameters from the server.

   BOOTREPLYV6 (TBD):    A server sends a
                         BOOTREPLYV6 message containing a BOOTP Message
                         Option in response to a client's BOOTREQUESTV6
                         message.  The BOOTP Message Option contains a BOOTREPLY
                         message in response to a BOOTREQUEST received by the
                         server in the BOOTP Message Option of a  BOOTREQUESTV6
                         message.

-- End --

- In section 6, Client Behavior:

I'd suggest changing " The Client sends out the BOOTREQUESTV6 message to the Well-Known multicast address, i.e.  All_DHCP_Relay_Agents_and_Servers on multicast address defined in [RFC3315]." To "The Client transmits the BOOTREQUESTV6 message as specified in Section 13 of [RFC3315]."

I think it is also important to add here that there are no explicit transmission parameters associated with a BOOTPREQUESTV6 message (see Section 14 of [RFC 3315]) as the client SHOULD follow the normal DHCPv4 retransmission requirements as appropriate for the message(s) it is sending.

One thing we MIGHT want to think about in relation to requiring RFC 4361 is whether the BOOTREQUESTV6 message may contains a DHCPv6 client-identifier option? This might be useful and then could relax the need for using RFC 4361 (as that might require more of a change to the DHCPv4 client -- as it may be possible to avoid any changes to the DHCPv4 client by intercepting the packets / injecting the packets).

- In section 7, Relay Agent Behavior

   The above logic only allows for separate relay destinations
   configured on the relay agent closest to the client (single relay
   hop).  Multiple relaying hops are not considered in this document.

Why not? Seems that the logic just requires deeper inspection - following the Relay Message options until the encapsulated message isn't a Relay-Forw and making the decision on that message's message type? It may be worth indicating that a relay may want to limits the depth of its inspection.

- In section 8, for the last paragraph, why not just refer to Section 20.3 of [RFC 3315].

    If the BOOTREQUESTV6 message was received in a Relay-forward message,
    the server responds as described in section 20.3 of [RFC 3315].

- Bernie