[dhcwg] Comments on draft-ietf-dhc-dhcpv6-23.txt and authors' response (part 2)

[Ralph Droms <[e-mail]>]

Here's the second part of Thomas Narten's comments, with the author's 
comments in line.  We are still on schedule to publish the -24 rev of the 
draft on 4/19.

- Ralph

 > >    If the server cannot determine if the information in the Confirm
 > >    message is valid or invalid, the server MUST NOT send a reply to the
 > >    client.  For example, if the server does not have a binding for the
 > >    client, but the configuration information in the Confirm message
 > >    appears valid, the server does not reply.
 >
 >Is it the case that the server should not reply because the intent
 >here is that another server (the correct one) will respond, and if
 >this one does, the client will get confused? Would it be good to just
 >say something like this, so it's clear why the MUST NOT applies?

It's not so much that the client will get confused as that the server
cannot respond definitively ACK or definitively NAK.  We can
add a sentence or a clause with additional explanation.

 > >    The server SHOULD process each option for the client in an
 > >    implementation-specific manner.  The server MUST construct a Reply
 >
 >might be good to change the "implementation-specfic" wording. The
 >processing of each option should be clearly defined and not be
 >"implementation-specific". This wording appears in a lot of places.

Agreed.

 > >    The server MAY choose to discard Renew messages received via unicast
 > >    from a client to which the server has not sent a unicast option.
 >
 >Would be good to say why/when. This isn't an arbitrary MAY (i.e.,
 >implementation choice).

Add: "..., for example, when the server requires options from the
relay agent on the client's link."

 > >    When the server receives a Renew and IA option from a client it
 > >    SHOULD locate the clients binding and verify the information in the
 > >    IA from the client matches the information stored for that client.
 >
 >SHOULD seems wrong. Isn't this a MUST. Also, why upper case? This is
 >just normal processing, I would think...

Yeah; change to "...client, it locates the client's binding..."

 > >    If the server cannot find a client entry for this IA the server
 > >    SHOULD return an IA containing no addresses with status set to
 > >    NoBinding.
 >
 >SHOULD as opposed to what? If this is the normal response, it
 >shouldn't be SHOULD (read the 2119 definition of SHOULD). I.e, why not
 >MUST? (and upper case wording seems overkill to me).

Change to "...server returns an IA option containing..."

 >also "return an IA". Shouldn't this be "an IA for each IA in the
 >client's message"?

Agreed.

 > >    If the server cannot Renew addresses for the client it SHOULD send
 > >    back an IA containing no addresses to the client with the status
 > >    field set to AddrUnavail.
 >
 >SHOULD? as opposed to what?

Will change to MUST.

 > >    If the server finds the addresses in the IA for the client then the
 > >    server SHOULD send back the IA to the client with new lifetimes and
 >
 >ditto.

Edit to:

     If the server finds the addresses in the IA for the client then the
     server sends back the IA to the client with new lifetimes and

 > >    The server SHOULD process each option for the client in an
 > >    implementation-specific manner.  The server MUST construct a Reply
 > >    message containing the following values:
 >
 >first sentence could be worded better (this occurs multiple times in
 >the document). Also, use of MUST here seems silly. Can't you just say
 >"The server constructs..." I.e, this is normal processing.
 >
 >XXX overuse of MUST/SHOULD?

Agreed - first sentence should be rewritten (not clear exactly what
it means) and SHOULD/MUST are unneeded here.

 > >    If the server finds that the addresses in the IA for the client
 > >    do not match the client binding the server should return an IA
 > >    containing no addresses with status set to RebdNoMatch.
 > >
 > >    If the server cannot Rebind addresses for the client it SHOULD send
 > >    back an IA containing no addresses to the client with the status
 > >    field set to AddrUnavail.
 >
 >What is the difference between the two paragraphs above? Seems like
 >either would apply to the case where the server can't provide the
 >requested addresses...

We will drop the second paragraph.

 > >    When the server receives an Information-request message, the client
 > >    is requesting configuration information that does not include
 > >    the assignment of any addresses.  The server SHOULD determine all
 > >    configuration parameters appropriate to the client, based on the
 > >    server configuration policies known to the server.
 >
 >SHOULD? As opposed to ...

Change to "The server determines all...".

 > >    The server MAY choose to discard Release messages received via
 > >    unicast from a client to which the server has not sent a unicast
 > >    option.
 >
 >Would be good to say under what conditions the MAY might be needed.

We have the same issue for each message that can be unicast.  I propose
we apply the same fix (I think I suggested some text about the
server requiring relay agent options) to the text for each of those
messages.

 > >    A server is not required to (but may choose to as an implementation
 > >    strategy) retain any record of an IA from which all of the addresses
 > >    have been released.
 >
 >Hmm... more words? What is the intent here? And, shouldn't the
 >document include  some words discouraging reusing the same address for
 >a new client *immediately*? I.e., don't we want the same address to be
 >returned in most cases, even if the client goes away for a few days?

We will change the text to:
A server may choose to retain a record of assigned addresses and IAs
after the lifetimes on the addresses have expired to allow the server
to reassign the previously assigned addresses to a client.

 > >    the addresses from the IAs.  The server SHOULD mark the addresses
 > >    declined by the client so that those addresses are not assigned to
 > >    other clients, and MAY choose to make a notification that addresses
 > >    were declined.
 >
 >Wording above could be stronger. If the declined address is a
 >duplicate, it shouldn't be used any more. The wording could make this
 >stronger above.

We don't think the wording needs to be stronger.

 > >    exchange when links in the DHCP domain are to be renumbered.  Other
 > >    examples include changes in the location of directory servers,
 > >    addition of new services such as printing, and availability of new
 > >    software (system or application).
 >
 >Do you have an example of the latter? If not, drop the example?

We will drop the phrase in parentheses.

 > >    The server sets the "msg-type" field to RECONFIGURE. The server
 > >    generates a transaction-ID and inserts it in the "transaction-ID"
 > >    field.  The server places its identifier in a Server Identifier
 > >    option.
 >
 >Hmm. The client doesn't echo this back to the server. Does it matter
 >what id the server uses? I think not. Except the retransmissions use
 >the same ID, new ones don't. But its not really used.

We will change this to make the transaction-id MBZ in this message.

 > >    The server MUST include an authentication option with the appropriate
 > >    settings and add that option as the last option in the "options"
 > >    field of the Reconfigure message.
 >
 >So, authentication is mandatory to implement. We really need a mode
 >where the server is authenticated.

I don't understand the comment - the authentication mechanism
authenticates both the client and the server.

We will remove the restriction that the option be the last option in
the message. Placement of the authentication option will be specified
in the section on authentication.

 > >    It is possible that the client may send a Renew message after the
 > >    server has sent a Reconfigure but before the Reconfigure is received
 > >    by the client.  In this case, the Renew message from the client
 > >    may not include all of the IAs and requests for parameters to be
 > >    reconfigured by the server.  To accommodate this scenario, the server
 > >    MAY choose to send a Reply with the IAs and other parameters to be
 > >    reconfigured, even if those IAs and parameters were not in the Renew
 > >    message from the client.
 >
 >This seems pretty ambiguous and unclear. I think we want very well
 >defined behavior  here, not a "MAY". Can't this be simplified into a
 >clear rule?

We will change the text to read:

    The server MAY choose to send IAs and other parameters to be
    reconfigured, even if those IAs and parameters were not in the Renew
    message from the client.

 > > 20.2. Receipt of Information-request messages
 > >
 > >    If the server has assigned addresses to one or more IAs that belong
 > >    to the responding client, the server MUST silently discard the
 > >    Information-request message.
 >
 >Why? Seems unrobust. Will the client now get no responses and
 >retransmit? Better to include an error, or return the requested info
 >(perhaps with a code indicating, BTW, I have addresses but didn't
 >include them...)

We will delete this sentence.

 > >    It is possible that the client may send an Information-request
 > >    message after the server has sent a Reconfigure but before
 > >    the Reconfigure is received by the client.  In this case, the
 > >    Information-request message from the client may not request all of
 > >    the parameters to be reconfigured by the server.  To accommodate
 > >    this scenario, the server MAY choose to send a Reply with the other
 > >    parameters to be reconfigured, even if those parameters were not
 > >    specified in the Information-request message from the client.
 >
 >Same comment as before. This seems ripe for ambiguity and
 >ineroperability problems.
 >
 >Why not just require the last sentence be the standard behavior?

We will edit this text to:

    The server MAY choose to send IAs and other parameters to be
    reconfigured, even if those IAs and parameters were not in the Renew
    message from the client.

 > >    A client MUST always monitor UDP port 546 for Reconfigure messages
 > >    on interfaces for which it has acquired DHCP parameters.  Since the
 >
 >Wording could be better. Do you mean "MUST accept packets sent to port
 >546. These packets may be sent at any time." ?

We will edit the text to:

   A client MUST accept Reconfigure messages sent to UDP
   port 546 on interfaces for which it has acquired
   configuration information through DHCP. These messages may be sent at
   any time.  Since the results of a reconfiguration event may affect
   application layer programs, the client SHOULD log these events, and
   MAY notify these programs of the change through an
   implementation-specific interface.

 > >    Upon receipt of a valid Reconfigure message, the client initiates a
 > >    transaction with the server.  While the transaction is in progress,
 > >    the client silently discards any Reconfigure messages it receives.
 >
 >What kind of transaction is initiated?

Add text specifying Renew or Information-Request.

 > >    If the client has IAs with addresses that have been assigned by the
 > >    server from which the Reconfigure message was received, the client
 > >    MUST respond with a Renew message.  Otherwise, the client responds
 > >    with an Information-request message.
 >
 >Would it be clearer for the reconfigure to have a flag (or two) that
 >says "just addresses" and/or "just other parameters"? This way there
 >is no guessing about how the client needs to respond.

We will define an option that specifies whether a client should
respond to a Reconfigure message with a Renew or an
Information-request message.

 > >    If the configuration parameters changed were requested by the
 > >    application layer, the client notifies the application layer of the
 > >    changes using an implementation-specific interface.
 >
 >Hmm. Is this a requirement with some big unstated implications?
 >Might be better to remove this wording. At best, it is a MAY.

We will delete this paragraph.

 > > 21. Relay Behavior
 > >
 > >    For this discussion, the Relay MAY be configured to use a list of
 > >    server destination addresses, which MAY include unicast addresses,
 > >    the All_DHCP_Servers multicast address, or other multicast addresses
 > >    selected by the network administrator.  If the Relay has not been
 > >    explicitly configured, it MUST use the All_DHCP_Servers multicast
 > >    address as the default.
 >
 >There should be some clear MUST rules on what is required of relay in
 >terms of configuration. I.e., isn't the first MAY a de facto MUST in
 >IPv4?

The multicast address is a default,
and the implementation ought to allow configuration with other addresses.
Does this text need to be clarified?

 > >    When a Relay receives a valid client message, it constructs a
 > >    Relay-forward message.  The relay places an address with a prefix
 > >    assigned to the link on which the client should be assigned an
 > >    address in the link-address field.  This address will be used by the
 >
 >reword: places a global or site-local address ... from the interface
 >on which the client packet was received...

We will add text to specify that the address should be a global or
site-local address.  The remaining text in the sentence is OK.

 > >    If the relay cannot use the address in the link-address field to
 > >    identify the interface through which the response to the client will
 > >    be forwarded, the relay MUST include an Interface-id option (see
 > >    section 23.17) in the Relay-forward message.  The server will include
 > >    the Interface-id option in its Relay-reply message.
 >
 >MUST seems too strong. This option is used if it makes sense to. It
 >isn't required in some cases...

The relay agent doesn't need to use the Interface-id option when it
can otherwise identify the link to which the client is attached, which
is what the first phrase is about.

 >Also, what gets placed in the link-address field if the Interface-id
 >option is included?

The link-address field is still set with a prefix from the link.  In
some technologies, the prefix from the link is not sufficient to
identify the physical interface to which the client is attached.

 > > 23.17. Interface-Id Option
 >
 >Seems underspecified. If this option is used, does the server use
 >it (rather than the client-return-address) to figure out which link
 >the client is on, and hence, what address pool to select an address
 >from? there are no words about what the server does with this option,
 >other than echo it back.

We will add text stating clearly that this option is primarily for use
by the relay agent in facilitating or expediting the return of the
server's response to a client request. It is not used by the server to
determine where the client is - the link-address field is used for
that.

 >Also, should the text more clearly state that the relay removes this
 >option before forwarding the packet to the client?

We will add text explicitly specifying that the relay agent discards
any option in the message from the server when it unencapsulates and
forwards the client message.

 > >    message.  The Relay MUST send the Relay-forward message to the list
 > >    of server destination addresses with which it has been configured.
 >
 >MUST? but it's not clear that any server addresses have even been
 >configured (what is the requirement that this be done?)

We will add text: "The Relay Agent MUST send the Relay-forward message
to the list of server destination addresses with which it has been
configured or to the All_DHCP_Servers multicast address if it was
not explicitly configured with server destination addresses."

 > > 22.1. DHCP threat model
 > >
 > >    The threat to DHCP is inherently an insider threat (assuming a
 > >    properly configured network where DHCPv6 ports are blocked on the
 > >    perimeter gateways of the enterprise).  Regardless of the gateway
 > >    configuration, however, the potential attacks by insiders and
 > >    outsiders are the same.
 >
 >Note: this is somewhat at odds with the idea of a mobile node that can
 >still talk to its DHCP server about releasing addresses and such...

We would say that a mobile node talking to its home DHCP server (or
to its previous DHCP server) is still an "insider threat", as it must
be, in some sense, a trusted member of the network to which the DHCP
server belongs...

 > >    The threat common to both the client and the server is the resource
 > >    "denial of service" (DoS) attack.  These attacks typically involve
 > >    the exhaustion of valid addresses, or the exhaustion of CPU or
 > >    network bandwidth, and are present anytime there is a shared
 > >    resource.  In current practice, redundancy mitigates DoS attacks the
 > >    best.
 >
 >Not sure I understand the last sentence or necessarily even agree with
 >it.

We will drop the last sentence.

 > > 22.2. Security of messages sent between servers and relay agents
 > >
 > >    Relay agents and servers that choose to exchange messages securely
 > >    use the IPsec mechanisms for IPv6 [10].  The way in which IPsec
 > >    is employed by relay agents and servers is not specified in this
 > >    document.
 >
 >If this is a MUST, please just say so. Also, do you want to scope
 >this? Is this just IPsec (with manual keying) or full IKE?

It is not a requirement that relay agents and servers use any
authentication.  If relay agents and servers use IPsec, they may
choose manual keying or IKE.

 > > 22.3. Summary of DHCP authentication
 >
 >Note: in this section and onwords, you talk about specific fields in
 >the option, but those fields have not even been described yet... this
 >is confusing.

We will add a reference to the section in which the authentication option
is defined.

 > >    If the RDM field contains 0x00, the replay detection field MUST be
 > >    set to the value of a monotonically increasing counter.  Using a
 > >    counter value such as the current time of day (e.g., an NTP-format
 > >    timestamp [12]) can reduce the danger of replay attacks.  This method
 > >    MUST be supported by all protocols.
 >
 >MUST even in the stateless case? I would guess yes...

We don't understand this comment...

 > > 22.5. Configuration token protocol
 >
 >I wonder if this should just be dropped as less than useful. Would be
 >better to have a public key based one?

We will drop this protocol.  The authors would gratefully accept the
contribution of a public key authentication protocol

 > >    Replay Detection  - as defined by the RDM field
 > >    K                 - a secret value shared between the source and
 > >                        destination of the message; each secret has a
 > >                        unique identifier (secret ID)
 > >    secret ID         - the unique identifier for the secret value
 > >                        used to generate the MAC for this message
 > >    HMAC-MD5          - the MAC generating function.
 >
 >Show these fields? how big are they, for instance? Where in the packet
 >do these go?

This problem will be fixed with a reference to the authentication
option definition.

 > >    to the replay detection method specified by the RDM field.  Next,
 > >    the receiver computes the MAC as described in [11].  The receiver
 > >    MUST set the 'MAC' field of the authentication option to all 0s for
 > >    computation of the MAC. If the MAC computed by the receiver does not
 > >    match the MAC contained in the authentication option, the receiver
 > >    MUST discard the DHCP message.
 >
 >This doesn't seem right. Earlier, the document says:
 >
 > >    The sender computes the MAC using the HMAC generation algorithm [11]
 > >    and the MD5 hash function  [20].  The entire DHCP message (except
 > >    the MAC field of the authentication option itself), including the
 > >    DHCP message header and the options field, is used as input to the
 > >    HMAC-MD5 computation function.  The 'secret ID' field MUST be set to
 > >    the identifier of the secret used to generate the MAC.
 >
 >I.e, the MAC field is not included. The receiver shouldn't check it
 >either.

Agreed.

 > >    Each DHCP server MUST know, or be able to obtain in a secure manner,
 > >    the keys for all authorized clients.  If all clients use the same
 > >    key, clients can perform both entity and message authentication for
 > >    all messages received from servers.  However, the sharing of keys
 > >    is strongly discouraged as it allows for unauthorized clients to
 > >    masquerade as authorized clients by obtaining a copy of the shared
 > >    key.  To authenticate the identity of individual clients, each client
 > >    MUST be configured with a unique key.
 >
 >Note, using a single shared key also allows trivial spoofing of the
 >server. (this should be mentioned).

Agreed.

 >change last MUST to must?

Agreed.

 > >    A client MUST be configurable to discard unauthenticated messages,
 > >    and SHOULD be configured by default to discard unauthenticated
 > >    messages.  A client MAY choose to differentiate between Advertise
 > >    messages with no authentication information and Advertise messages
 > >    that do not pass the validation test; for example, a client might
 > >    accept the former and discard the latter.  If a client does accept an
 > >    unauthenticated message, the client SHOULD inform any local users and
 > >    SHOULD log the event.
 >
 >Per the above, clients won't work out of the box. I.e, they must drop
 >unauthenticated stuff, but they also don't have any keying
 >material. Seems like a bad thing to specify... :-(

We will change the text to read:

       SHOULD be configured by default to discard unauthenticated
       messages *if the client has been configured with an
       authentication key or other authentication information*.

 > >    If the client authenticated the Advertise message through which the
 > >    client selected the server, the client MUST generate authentication
 > >    information for subsequent Request, Confirm, Renew, Rebind or Release
 > >    messages sent to the server as described in section 22.6.  When the
 > >    client sends a subsequent message, it MUST use the same secret used
 > >    by the server to generate the authentication information.
 >
 >Need better terminology than "same secret". you want it to use the
 >same "security association" I think, where SA could mean shared
 >secret, but also public/private, etc.

This text is from the delayed authentication protocol using a shared key,
so the text need not be generalized to "security association".  We
will change the text to read "same key".

 > > 22.6.5.4. Sending Information-request messages
 > >
 > >    If the client has negotiated a secret with the server through a
 > >    previous message exchange, the client MUST use the same secret used
 > >    by the server to generate the authentication information.  If the
 > >    client has not negotiated a secret with the server, the client MUST
 > >    use a secret that has been selected for the client through some
 > >    external mechanism.
 >
 >Terminology? a "secret" has been "negotiated"? if the key is
 >negotiated, isn't this then a "session key"? Also, I don't think  you
 >are really negotiating keys...
 >
 >Need to fix the "secret" terminology throughout I think.

Agreed.

 >22.6.5.6. Receiving Reconfigure messages
 >
 >    The client MUST validate the Reconfigure message from the server.
 >
 >What does this mean, and isn't this a requirement earlier per normal
 >processing rules?

We will delete this sentence.

 > >    The server uses the secret identified in the message and validates
 > >    the message as specified in section 22.6.3.  If the message fails to
 > >    pass validation or the server does not know the secret identified by
 > >    the 'secret ID' field, the server MUST discard the message and MAY
 > >    choose to log the validation failure.
 >
 >What is the "secret ID" field?

We will add a reference to authentication option section of the draft.

 > > 22.6.6.3. Sending Reconfigure messages
 > >
 > >    The server MUST include authentication information in a Reconfigure
 >
 >Better to say "Authentication Option" ...

Agreed.

 > >    If the server has not previously negotiated a secret with the client,
 > >    the server MUST use a secret that has been selected for the client
 > >    through some external mechanism.
 >
 >"negotiated ... secret" terminology is odd.

We will reword this text for clarity.

 > >    described in section 23.1.  All values in options is represented in
 >
 >s/is/are/

Agreed.

 > >       option-code   OPTION_CLIENTID (TBD)
 >
 >Go ahead and fill in the TBDs you create in this document. Then, in
 >the IANA considerations, just list them in a table and say "these are
 >the initial values for this name space". IANA provides values for
 >existing name spaces, but its OK to define them yourself if you are
 >creating the namespace for the first time. Do this throughout for the
 >TBDs.

Agreed; we will put all numbers here in IANA section.

 > >    The identity association option is used to carry an identity
 > >    association, the parameters associated with the IA and the addresses
 > >    assigned to the IA.
 >
 >s/assigned to/associated with/ ?

Agreed.

 > >      IAID                 The unique identifier for this IA.
 >
 >Would be good here to describe the properities the "uniqueness" needs
 >to satisfy.

Agreed; in particular, the IAID must be unique across all of the
client's links.

 > >       T1                   The time at which the client contacts the
 > >                            server from which the addresses in the IA
 > >                            were obtained to extend the lifetimes of the
 > >                            addresses assigned to the IA.
 >
 >Would be good here to describe the time units.
 >
 > >       T2                   The time at which the client contacts any
 > >                            available server to extend the lifetimes of
 > >                            the addresses assigned to the IA.
 > >
 >
 >ditto

Agreed.

 > >       IA status            Status of the IA in this option.
 >
 >needs more explanation.

Agreed.

 > >    The server MUST set the T1 and T2 times to values that will allow
 > >    the client to extend as appropriate the lifetimes of any addresses
 > >    in the IA. If the server does not intend for a client to extend the
 > >    lifetimes of a particular address in an IA, the server MAY set the
 > >    renewal time values to occur after the lifetimes on that address
 > >    expire.
 >
 >recommended guidelines would be good here. They should be such that
 >the T1 and T2 rules the client use will result in the address being
 >renewed before it expires, even if there are some errors (server
 >unavailable for a short amount of time, etc. We have IPv4 experience
 >here, just use the same guidelines I would think.

Agreed.

 > >    T1 is the time at which the client SHOULD begin the lifetime
 > >    extension process by sending a Renew message to the server that
 > >    originally assigned the addresses to the IA. T2 is the time at which
 >
 >why not MUST?

We will change SHOULD to MUST.

 > >    the client SHOULD start sending a Rebind message to any server.  A
 >
 >ditto

OK.

 > >    client MAY begin the lifetime extension process prior to T1 if it
 > >    needs additional addresses for some reason.
 >
 >don't follow. Renewing existing addresses is different than getting
 >"additional addresses" T1/T2 are for extending existing
 >lifetimes. Right?

We will delete this text.

 > > 23.5. IA Address option
 >
 >IMO, this should be a suboption, not a regular option.

This draft does not differentiate between options and sub-options.  We
will add text to the intro section on options to clarify the use of
options.

 > >       option-len    See section 23.
 >
 >Better to just say what the len is in *this* case. This comment
 >applies to all the option descriptions.

Agreed.

 > >       addr status   Status of this address in this IA.
 >
 >say what this is? What values can be returned?

We will add text to specify what status codes are returned and why
each status code is returned.

 > >       prefix length Prefix length for this address.
 >
 >What is this and why is it needed? I suspect it would be better to not
 >need this. The client *shouldn't* know this information.
 >
 >I don't see any text right off that explains why this is needed  or
 >how it is used.

We will delete the prefix length field.

 > >    lifetime fields for the preferred and valid lifetimes.  The values in
 > >    the preferred and valid lifetimes are the number of seconds remaining
 > >    in each lifetime.
 >
 >Units of time should be defined earlier, where the  field is initially
 >described.

Agreed.

 > > 23.6. Requested Temporary Addresses (RTA) Option
 >
 >Per earlier comments, I think each temporary address should be
 >identified individually, rather than as a group (i.e., with
 >num-requested).

We will make significant changes to the handling of temporary
addresses.

 > >    within an Identity association option.  A client MUST only include
 > >    this option when it wants to have additional temporary address
 > >    allocated; a client SHOULD NOT send this option if 'num-requested' is
 > >    0.
 >
 >why not MUST NOT?

This text will be deleted in the next draft because of changes to the
handling of temporary addresses.

 >23.8. Preference option
 >
 >Seems to me like this should be in the header, i.e, fixed for easy
 >location. I'll note that the Client Identifier option is required to
 >be the first option (presumably so it can be located easily). But this
 >option is not? So a client needs to parse the entire message before it
 >can even decide whether to process it (i.e., select this message over
 >another one)? Seems like this should be the first option, or in the
 >fixed header.

The preference option is only used in the Advertise message so we have
not put it in the message header.  Advertise messages are used
relatively infrequently and only processed by clients so we don't need
to worry (much) about scaling and processing efficiency.

 > > 23.9. Elapsed Time
 >
 >What is this option used for? Not immediately clear. Either get rid of
 >it, or explain what it is used for.

We will add text explaining the use of the elapsed time option to
allow a secondary DHCP server to respond to a request when a primary
hasn't answered in a reasonable time.

 > >    A client MAY include an Elapsed Time option in messages to indicate
 >
 >Is MAY appropriate? seems like it should be a MUST/SHOULD. I.e, here
 >is a client MAY include it, the server MAY act on it. Sounds like a
 >recipe for lack of usefulness do to lack of implementatoins. i.e, at
 >very least, servers MUST implement it. If they don't why would a
 >client ever bother including it?

We will strengthen the text requiring this option...

 > > 23.12. Authentication option
 > >
 > >    The Authentication option carries authentication information to
 > >    authenticate the identity and contents of DHCP messages.  The use of
 > >    the Authentication option is described in section 22.  If present,
 > >    the Authentication option MUST appear as the first option in the DHCP
 > >    message.
 >
 >Note. Does this document say whether the same option can be included
 >multiple times, and what the  semantics of that would be? It needs to.

Agreed.

 >Last sentence  seems wrong. Shouldn't it be the *last* option?

We want it first (or early) to allow a client (or server) to
quickly determine whether it should process this message (whether
it is authenticated). This doesn't mean it CAN'T be at the end,
we should just point out that putting it early means a client or
server can find it quickly to authenticate the message before
having to parse all of the options.

 >Doesn't this option need a way to name security associations? I.e., a
 >way for the server/client to easily identify *which* keys are being
 >used? This seems to assume that the protocol/algorith is sufficient
 >for this. Seems to me this doesn't allow for the same
 >protocol/algorithm but different keys.

Security associations are identified within the authentication
information for a specific protocol.  For example, the delayed
authentication protocol includes a "Secret ID" which identifies the
secret used to generate the MAC in a message.

 > > 23.13. Server unicast option
 > >
 > >    The server MAY send this option to a client to indicate to the client
 >
 >s/MAY send/sends/

Agreed.

 > >    messages in the server-address field.  When a client receives this
 > >    option, where permissible, the client MAY send messages directly to
 > >    the server using the IPv6 address specified in the server-address
 > >    field of the option.
 >
 >ditto on MAY. Also, add "as appropriate" to end of sentence?

Agreed.

 > > 23.14. Status Code Option
 > >
 > >    This option returns a status indication related to the DHCP message
 > >    in which it appears.
 >
 >Only one of these may appear in a message?

Yes; we will add text to specify that requirement.

 > >    The data area of the user class option MUST contain one or more
 > >    instances of user class data.  Each instance of the user class data
 > >    is formatted as follows:
 > >
 > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
 > >      |        user class len         |         user class data       |
 > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
 >
 >note: these are effectively sub options. Yet in other places, you
 >don't define sub-options. Rather you just use existing
 >options. Consistency? When one vs. the other?

They may be effectively sub-options, but they are not DHCP options
and are not formally defined anywhere.

 > >    be used to process that User class option.  Servers not equipped to
 > >    interpret the user class information sent by a client MUST ignore it
 > >    (although it may be reported).
 >
 >Isn't it the case that the server MUST ignore options it doesn't
 >understand in general? Better to say this once and be sure the text is
 >clear that it applies to all options.

In fact, the last sentence is a cut-and-paste from the DHCPv4 user
class option, which was added to the protocol in a separate RFC.  We
don't need the caveat in DHCPv6 because the option is defined in the
base spec and all servers will be able to process it.

 > >       vendor-id            A domain name belonging to the vendor used to
 > >                            identify the vendor that defined this vendor
 > >                            class option.
 >
 >use the enterprise identifier?

We will rewrite the Vendor-specific option and add a Vendor Class
option.

 > >    The Encapsulated vendor-specific options field MUST be encoded as
 > >    a sequence of code/length/value fields of identical format to the
 > >    DHCP options field.  Each of the encapsulated options is formatted as
 > >    follows.
 >
 >Mumble. Here you define yet a different  sub-option format. Can't we
 >just do this once in a consistent manner?

We will edit the sentence to read:

"The Encapsulated vendor-specific options field is encoded
using the same option-code/option-len/option-data format as the
DHCP options, described in Section 23.1."

We will add text that the option codes are assigned by the vendor and
not managed by IANA.

 > >       opt-code             The code for the encapsulated option
 >
 >What is the numbering space for this option? I.e., is this a new name
 >space (and does it need an IANA section)  or is this actually just a
 >normal option? I can't quite tell.

Add text to indicate the number space is up to the vendor.

 > > 26.2. DHCPv6 message types
 > >
 > >    IANA is requested to record the message types defined in section 7.3.
 > >    IANA is requested to manage definition of additional message types in
 > >    the future.
 >
 >Summarize what the initial values are and indicate what the rules are
 >for assigning new values. Ditto for remaining spaces in this section.

Agreed.

 > > 27. Acknowledgments
 >
 >I suspect this needs updating. Aren't there some recent contributers (last
 >year or so) worth mentioning?

I think I've added recent contributors - e.g., Thirumalesh Bhat, 
Vijayabhaskar,
Mark Stapp (?) - are there others?

 > > Authors' Addresses
 >
 >Note that there is a new RFC editor policy in effect about long lists
 >of authors. Should there be a single editor listed on the cover page?
 >You should look at the RFC Editor policy on this.

We should look at the policy (I don't think it has been formally published
yet).  On the other hand, we think that the list of authors is
appropriate because of the particular history of this doc.


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg