Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-23.txt and authors' response

From: Ralph Droms <[email-masked]>
Date: Wed, 17 Apr 2002 16:16:30 -0400

Thomas Narten has written a detailed comments based on his review of 
draft-ietf-dhc-dhcpv6-23.txt.  I've included the first part (of two) of 
Thomas' comments below, with the author's comments in line.  We are 
revising the draft based on our responses and the revision of the draft 
will be published this Fri, 4/19.

Thanks, Thomas, for your thorough, careful and thoughtful review.  Your 
input will help us make the DHCPv6 spec a much better document.

- Ralph

 > General:
 >
 > 1) what is the difference between confirm and renew. Do we need
 > both?

Yes. The client is in different states when sending the two messages
and the server can make use of that differentiation.

 > 2) I'd suggest reorganizing sections 18 and 19 somewhat. Currently,
 >    the server stuff is in 18, the client stuff in 19. I think it would
 >    actually be more readable if the related messages were grouped
 >    together in much the same way the message flows go. E.g., talk
 >    about the client aspects of Solicit message generation in one
 >    subsection, followed by the server processing of that message,
 >    followed by the server generation of the Advertise, then the client
 >    processing of it, etc. Its still the case that the server (or
 >    client) processing rules for dealing with the message are
 >    localized, which helps implementors. So I think this is just moving
 >    subsections around rather than changing text. As it is now, one has
 >    to jump around a lot to follow the processing of normal message
 >    flows.

The authors discussed this suggestion at some length.  We came to the
conclusion that doing this right is a lot of effort, and nobody has
the bandwidth to do it right now.  The current organization doesn't
prevent comprehension and we can fix it before PS if there is
significant pushback during IETF last call.  So, we're going to focus
on the parts of the spec that need to be fixed and leave the
organization of sections 18, 19 and 20 as is for now.

 > 3) it could use an overview that describes the basic message flows and
 >    operations. I'm willing to give a shot at doing this, (if I ever
 >    get to it...)

Some of us expressed concern about an overview that would describe
part of the specification and therefore represent a potential for
parts of the spec to be out of sync with each other.  We agreed on
writing a very high level overview that explains some typical message
flows.  Here's a candidate outline for a four para overview:

    client uses information-request to obtain parameters
    such as DNS configuration.  server responds with reply.

    when configuration is pre-assigned to client, can use
    "Rapid Commit" two message exchange: Solicit, Committed-Reply

    DHCPv6 does address assignment, which is useful in
    situations where net admin needs control and auditing
    of addresses in use

    Client uses Rebind/Reply message exchange to extend lease on
    addresses

 > Review of -23
 >
 > > 1. Introduction
 > >
 > >    This document describes DHCP for IPv6 (DHCP), a UDP [19]
 > >    client/server protocol designed to reduce the cost of management
 > >    of IPv6 nodes in environments where network managers require more
 > >    control over the allocation of IPv6 addresses and configuration
 > >    of network stack parameters than that offered by "IPv6 Stateless
 >
 > Redo the above based on the more recent thinking on stateful
 > vs. stateless DHCP? Remember, the intro may be the first and only
 > opportunity to set the right tone for what DHCP is useful for and
 > whether it solves a particular problem.
 >
 > >    DHCP reduces the cost of ownership by centralizing the management
 > >    of network resources such as IP addresses, routing information, OS
 > >    installation information, directory service information, and other
 > >    such information on a few DHCP servers, rather than distributing such
 > >    information in local configuration files among all network node.
 >
 > I dunno about the cost of ownership thing. This may be true for v4,
 > but does it hold for IPv6 with its stateless autoconfig? Seems like a
 > minor point anyway.
 >
 > Also, the example about centralizing the management of "routing
 > information" is not so good. IMO, this is a bit of a misuse of
 > DHCP. Let the routers do this (and with ND they are in a much better
 > position to than with IPv4).
 >
 > >    of the IPv6 address space.  Two advantages of IPv6 are that support
 > >    for multicast is required, and nodes can create link-local addresses
 >
 > Note: there has been recent discussion about whether mcast can be
 > assumed. I think it is safe to assume that link-local multicast is
 > available, but less so for broader scope. It turns out that DHCP
 > doesn't rely on the wider scope mcast so much. This could maybe made
 > clearer here, so that folks to say "uh oh", I can't assume multicast,
 > therefore, I can stop reading now...
 >
 > >    communications to discover neighbors on the link.  For instance, a
 > >    client can send a Solicit message and locate a server or relay.
 >
 > s/a server/an on-link server/

We will rewrite the introduction to focus on recent discussion of
applicability of DHCP to configuration (e.g., DNS configuration) and
de-emphasize address assignment.

 > > 4. Design Goals
 >
 > This entire section seems of dubious value. It's largely incomplete, I
 > suspect, and has some somewhat random things in it. Move to an
 > appendix? Delete? I understand its there from history, but is it
 > needed at this point in time?
 >
 > >     -  A DHCP client can make multiple, different requests for
 > >        configuration parameters when necessary from one or more DHCP
 > >        servers at any time.
 >
 > Does this need to be stated? Where in the document is it recommended
 > that clients do this? I.e., I think its good to be sure this is not
 > disallowed, but do we want to say more? (more on this below.)
 >
 > >     -  DHCP will contain the appropriate time out and retransmission
 > >        mechanisms to efficiently operate in environments with high
 > >        latency and low bandwidth characteristics.
 >
 > Oh really?
 >
 > >     -  How a DHCP relay is configured or what sort of information it may
 > >        log.
 >
 > The document should make clearer just what is required to be
 > implemented on relay agents in terms of configuration. Section 21 has
 > some MAYs, but it really should be specified what a relay agent needs
 > to do to be compliant with this spec.  Is it required (MUST?) that
 > relay agents be configurable with a list of unicast addresses, for
 > instance, or is this just a MAY?

We will delete design goals section from the document.

 > >       link-local address        An IPv6 address having link-only
 > >                                 scope, indicated by having the prefix
 > >                                 (FE80::0000/64), that can be used to
 >
 > should be /10, not /64.

Agreed; good catch.

 > >       agent address             The address of a neighboring DHCP Agent
 > >                                 on the same link as the DHCP client.
 >
 >
 > By my check, the use of the term "agent" by itself (meaning either
 > relay or server) is a handful. I would suggest deleting use of the
 > term "agent" (when refering to either the relay or a server) and
 > always use "relay agent" or "server" (or list both) rather than the
 > generic "agent". In earlier versions of the document, having the term
 > might have made more sense. But not anymore.

We will rewrite to replace "agents" with "relay agents" and "servers"
throughout as appropriate.

 > >       binding                   A binding (or, client binding) is a
 > >                                 group of server data records containing
 > >                                 the information the server has about
 > >                                 the addresses in an IA and any other
 > >                                 configuration information assigned to
 > >                                 the client.  A binding is indexed by the
 > >                                 tuple <DUID, IAID>.
 >
 > You've got acronyms here that have not yet been defined (IA, DUID,
 > IAID).

The terminology section is in alphabetic order (or will be, with a few
fixes), so forward references are unavoidable.

 > >       DHCP relay (or relay)     A node that acts as an intermediary to
 > >                                 deliver DHCP messages between clients
 > >                                 and servers, and is on the same link as
 > >                                 a client.
 >
 > Why not just use the term "relay agent" (ala DHCPv4) since this is
 > exactly what it is?

Agree.

 > >       DHCP agent (or agent)     Either a DHCP server on the same link as
 > >                                 a client, or a DHCP relay.
 >
 > Unneeded, drop.

Agreed.

 > >       DUID                      A DHCP Unique IDentifier for a DHCP
 > >                                 participant; each DHCP client and server
 > >                                 has exactly one DUID.
 >
 > Add: "For example, a MAC address, IEEE identifier, etc." (or some
 > such)

We will add a reference to the section where DUIDs are defined, as
they are not simply described as a MAC address, etc.

 > >       Identity association (IA) A collection of addresses assigned to
 > >                                 a client.  Each IA has an associated
 > >                                 IAID. An IA may have 0 or more addresses
 > >                                 associated with it.
 >
 > Forward reference to IAID. Also, the description could be better. For
 > example, it's not just a collection assigned to a "client". A client
 > might have multiple ones. Maybe something like:
 >
 >       A collection of addresses assigned to a client.  Each IA has an
 >       associated IAID. A client may have more than one IA assigned to
 >       it, e.g., one for each of its interfaces.

The forward reference is a result of alphabetic order.  Your
text is much better and we will use it.

 > >       All_DHCP_Agents (FF02::1:2) This link-scoped multicast address
 > >                         is used by clients to communicate with the
 > >                         on-link agent(s) when they do not know the
 > >                         link-local address(es) for those agents.  All
 > >                         agents (servers and relays) are members of this
 > >                         multicast group.
 >
 > remove "agent(s)": wording, e.g.,
 >
 >        All_DHCP_Agents (FF02::1:2) A link-scoped multicast address
 >                          used by clients to communicate with
 >                          neighboring (i.e. on-link) relay agents and
 >                          servers when they do not know the unicast
 >                          addresses of those entities. All relay agents
 >                          and DHCP servers are members of this
 >                          multicast group.

Agreed.

 > > 7.2. UDP ports
 > >
 > >    DHCP uses the following destination UDP [19] port numbers.  While
 > >    source ports MAY be arbitrary, client implementations SHOULD permit
 > >    their specification through a local configuration parameter to
 > >    facilitate the use of DHCP through firewalls.
 >
 > This requires configuration of clients. Totally useless (what
 > requirement/problem does this address?). Remove. Definitely not a
 > SHOULD.
 >
 > >       546        Client port.  Used by servers as the destination port
 > >                  for messages sent to clients and relays.  Used by relay
 > >                  agents as the destination port for messages sent to
 > >                  clients.
 >
 > Note: if all DHCP messages from the server to client are required to
 > be sent to destination port 546, just make it required that the source
 > port be 546 for messages from client to server. This simplfies things.
 >
 > >       547        Agent port.  Used as the destination port by clients
 > >                  for messages sent to agents.  Used as the destination
 > >                  port by relays for messages sent to servers.
 >
 > Question: what is the source UDP port for relay agent to server
 > traffic? does it matter? Why not just make it 546 per above?
 >
 > Note: would it make life easier if the relay agent used a different
 > port (on source to server, and  on destination FROM server?) This
 > *might* simplify implementations when the relay agent is first booting
 > and itself used DHC to assign its addresses. Or is this a non-problem?
 > What happens in DHCPv4? Always just statically configured?

We've agreed to rewrite this section to say simply "the client listens
on port 546; servers and relay agents listen on port 547".

 > > 7.3. DHCP message types
 >
 > General comment. It would be clearer to say who sends which message
 > rather than "uses". This should be fixed in all the messages in this
 > section. Also, it would be good to make it clear which messages are
 > paired together. I.e., "X message is sent by client in response to a Y
 > message from server".
 >
 > E.g.:
 >
 > >       CONFIRM (4)        The Confirm message is used by clients to
 > >                          confirm that the addresses assigned to an IA
 > >                          and the lifetimes for those addresses, as
 > >                          well as the current configuration parameters
 > >                          assigned by the server to the client are still
 > >                          valid.
 >
 > Not clear who sends this and when. Is it a response to a message from
 > the server? Not clear to me.

We will rewrite these descriptions for clarity.

 > >       INFORMATION-REQUEST (11) The Information-request message is sent
 > >                          by clients to request configuration parameters
 > >                          without the assignment of any IP addresses to
 > >                          the client.
 >
 > Mention that this can be used for stateless?

We will mention stateless DHCPv6 in the revised introduction.

 > >    description.  Note that the numeric values do not start at 1, nor are
 > >    they consecutive.  The status codes are organized in logical groups.
 >
 > This ought to be explained/justified. I can imagine the usefullness of
 > having ranges of codes, where all the values within a range are
 > treated the same way, e.g., "hard error", "soft error", etc. so that
 > one can easily define new codes later that just "work". But there is
 > not text here saying this (so implementations won't code things this
 > way). Also, will you need to define an IANA considerations for when to
 > assign new error codes?

We will collapse the list of status codes (numbering 0, 1, 2,
... without grouping), move the list to the IANA considerations
section and add a brief explanation of each status code to the table.
The status codes will be defined to be 8 bit values, to fit in the
various status code fields.

We will also take a pass across the spec and delete any unused status
codes.

 > XXX listing the codes here is not helpful. There is insufficient
 > context for a listing of them to be useful here. It would be better to
 > just list the table of codes nearer the end of the document, perhaps
 > in the IANA  considerations section.
 >
 > XXX I need to check retransmit values

???

 > > 8. Message Formats
 >
 > This section might benefit from being reorganized somewhat. Right now,
 > it takes up several pages but its mostly repetetive stuff. Plus, it
 > doesn't contain all that much useful info, IMO.
 >
 > E.g.:
 >
 > > 8.1. DHCP Solicit Message Format
 > >
 > >       msg-type         SOLICIT
 > >
 > >       transaction-ID   An unsigned integer generated by the client used
 > >                        to identify this Solicit message.
 > >
 > >       options          See section 23.
 >
 > All the subsections say the same thing, and this is pretty much
 > useless information by itself.
 >
 > I think a "message formats" section can be quite useful. But, it needs
 > to include enough of the relevant message fields and say what they all
 > contain, so that one has a rough idea of what is in a message. In the
 > case of DHCP this is problematical because much of the meat of the
 > message is actually in the extensions. Take a look at (say RFC 2461,
 > section 4). There, just the formats are presented, the processing is
 > defined later.

We will rewrite this section to improve clarity and to eliminate
redundancy.

 > >       client-return-address   The IPv6 source address in which the
 > >                               message from the client was received by
 > >                               the relay agent
 >
 > Pick a better name than "client-return-address"? Perhaps just say
 > "client-address"? It *is* the client address (or say
 > 'client-ll-address" with ll for link-local?

We will use "client-address".

 > >       client-return-address   The source address from the IP datagram
 > >                               in which the message from the client was
 > >                               received by the relay agent
 > >
 >
 > Better to just say "copied from "relay-forward" message, since that is
 > what is infact supposed to happen.

Agreed.

 > > 10. Representation and use of domain names
 > >
 > >    So that domain names may be encoded uniformly and compactly, a
 > >    domain name or a list of domain names is encoded using the technique
 > >    described in sections 3.1 and 4.1.4 of RFC1035 [14].  Section 4.1.4
 > >    of RFC1035 describes how more than one domain name can be represented
 > >    in a list of domain names.  For use in this specification, in a
 > >    list of domain names, the compression pointer (see section 4.1.4 of
 > >    RFC1035) refers to the offset within the list.
 > >
 > >    If a single domain name is being used by a vendor as a vendor
 > >    identifier, then the vendor MUST ensure that the domain name has not
 > >    previously been used by a different vendor.
 >
 > This section seems out of place here. Middle of nowhere with no
 > context. But, I think it should all be deleted.  Rather than using DNS
 > names, use Enterprise Identifiers.
 >
 > http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers

We weren't sure if you meant all of section 10 or just the second
paragraph is out of place.  The section is here because the encoding
is used in the definition of the vendor-assigned DUID in the next
section.  The second paragraph should be moved down into section 11.3
on vendor-assigned DUID.

We will define a new DUID that uses Enterprise Identifiers.

 > >    Clients and servers that use this DUID SHOULD attempt to configure
 > >    the time prior to generating the DUID, if that is possible, and MUST
 > >    use some sort of time source (e.g., a real-time clock) in generating
 > >    the DUID, even if that time source could not be configured prior to
 > >    generating the DUID. The use of a time source makes it unlikely that
 > >    two identical DUIDs will be generated if the network interface is
 > >    removed from the client and another client then uses the same network
 > >    interface to generate a DUID. A DUID collision is very unlikely even
 > >    if the clocks haven't been configured prior to generating the DUID.
 >
 > It might be good to in this section make clear that the Time is not
 > really required to be a time, but is just an attempt to ensure that if
 > two nodes generate a DUID from *this* link-layer address, they are
 > likely to generate different "time values". That is what the actual
 > requirement seems to be.

(Author consensus: no changes required here.)
We will retain the use of an explicit time value in this DUID.  Other
DUIDs are available for clients that cannot generate a time value.

 > >    The source of the identifier is left up to the vendor defining it,
 > >    but each identifier part of each VUID MUST be unique to the device
 > >    that is using it, and MUST be assigned to the device at the time of
 > >    manufacture and stored in some form of non-volatile storage.  The
 > >    VUID SHOULD be recorded in non-erasable storage.  The domain name
 > >    is simply any domain name that has been legally registered by the
 > >    vendor in the domain name system [13], stored in the form described
 > >    in section 10.
 >
 > Use the Enterprise Number instead?

See above.

 > >    This type of DUID consists of two octets containing the DUID type 3,
 > >    a two octet network hardware type code, followed by the link-layer
 > >    address of any one network interface that is permanently connected
 > >    to the client or server device and cannot be removed.  The hardware
 > >    type MUST be a valid hardware type assigned by the IANA as described
 > >    in the section on ARP in RFC 826.  The hardware type is stored in
 > >    network order.
 >
 > Clarify what  "cannot be removed" means. For example do you mean to
 > say "a built in chip on the motherboard that is unlikely to be removed
 > and used elsewhere". or something like that?

Your text is the right idea and we will fix the spec appropriately.

 > Finally, it would be good to give guidelines on which of the DUIDs you
 > expect folks to use under what conditions. There is none at present.

The sections describing the DUIDs each has a closing paragraph that
describes when that DUID should be used.  Do we need more?

 > >    A client must associate at least one distinct IA with each of
 > >    its network interfaces and uses that IA to obtain configuration
 > >    information from a server for that interface.  Other distinct IAs may
 > >    be associated with applications.  Each IA must be associated with
 > >    exactly one interface.
 >
 > Perhaps remove that reference to "applications"? We don't disallow
 > this, but I think its confusing to mention it.

We will delete the sentence with the reference to "applications".

 > >    The configuration information in an IA consists of one or more IPv6
 > >    addresses and other parameters.  The parameters are specified as DHCP
 >
 > Which parameters are associated with an IA as opposed to the client as
 > a whole (or more specifically, with a particular network link)? I
 > don't think the document talks about this point at all.

DHCPv6 can't really speak to the ways in which a client might choose
to use the parameters.

 > >    An address whose valid lifetime has expired MAY be discarded from the
 > >    IA.
 >
 > What does this mean? Why does it need to be said?

We will delete this sentence.

 > >    A server selects addresses to be assigned to an IA according to the
 > >    address assignment policies determined by the server administrator
 > >    and the specific information the server determines about the client
 > >    from the following sources:
 >
 > s/from the/from some combination of the/ ?

OK.

 > >     -  If the server receives the message directly from the client and
 > >        the source address in the IP datagram in which the message was
 > >        received is not a link-local address, then the client is on the
 > >        link identified by the source address in the IP datagram (note
 > >        that this situation can occur only if the server has enabled the
 > >        use of unicast message delivery by the client and the client has
 > >        sent a message for which unicast delivery is allowed)
 >
 > Move this text up to immediately after:
 >
 > >         *  If the server receives the message from a forwarding relay
 > >            agent, then the client is on the same link as the one to
 > >            which the interface identified by the link-address field in
 > >            the message from the relay is attached
 >
 > It seems to fit there better.

Agreed.

 > >    The addresses that the server selects for the client MUST be valid on
 > >    the link to which the interface is attached, regardless of the way in
 > >    which the server selects the addresses.
 >
 > Too strong? what about tunnels? remote access scenarios?

(Author consensus: Last sentence to be deleted)
The tunnel is the link, so an assigned tunnel endpoint is valid for
the link to which it's assigned.

Three out of four of us think it's OK to delete this sentence.

 > > 14. Management of temporary addresses
 >
 >
 > >    Clients ask for temporary addresses and servers assign them.  When
 > >    a client sends an IA to a server, the client lists all of the
 > >    temporary addresses it knows about and optionally indicates how many
 > >    additional temporary addresses it wants in the Requested Temporary
 > >    Addresses Option(see section 23.6).  The server compares the number
 > >    of requested additional temporary addresses against any previously
 > >    allocated temporary addresses for the IA that were not reported
 > >    by the client in the IA but still have some reasonable preferred
 > >    lifetime left.  If the number of temporary addresses is less than the
 > >    requested number, the server adds additional temporary addresses to
 > >    the IA to satisfy the requested number (subject to server policy).
 > >
 > >    DISCUSSION:
 > >
 > >       It is important that the server include any allocated
 > >       temporary addresses that were not reported by the client as
 > >       it is possible the client never received an earlier Reply
 > >       that contained these additional temporary addresses.  If
 > >       the server did not consider these, a client that fails to
 > >       receive a server's reply might cause the server to allocate
 > >       many temporary addresses.
 >
 > The above seems a bit confusing and maybe unclear. My understanding is
 > that the client requests a number of addresses. I think that model
 > runs the risk of the client and server getting confused.  Maybe a
 > better model for temp addresses is that the client requests them
 > indidually as sets, rather than by saying "how many" it wants. That
 > is, it requests them individually, one at a time, using a separate IA
 > to indentify them. This corresponds to a simple model where the client
 > decides how its using them and when, and just says it wants a new set
 > (or to extend the lease on a current set) or to release one it had
 > already used. Maybe we should talk about this.

(Author consensus: Use this summary from Bernie)

1. The IA Option would be used for "regular" (non-temporary) addresses only.

2. A new IA Option for temporary addresses would be created. This
    option would NOT need T1 and T2 times as temporary addresses are
    not renewable. Vijay had proposed a format for this as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_TMP_IA           |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IAID (4 octets)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  IA  Status   |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      .                            Options                            .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       option-code          OPTION_TMP_IA (TBD)

       option-len           See section 23.

       IAID                 The unique identifier for this TMP_IA.

       IA status            Status of the IA in this option.

       options              Options associated with this IA.

Each TMP_IA option can carry one "set" of temporary addresses (in the
IA_Address Options). Essentially, a "set" refers to ONE temporary
address per each prefix for a link - not multiple temporary addresses
on a single prefix. This supports the case where there are several
global prefixes on a single link such as in the multi-homed case.

When a client wants multiple temporary addresses, it must Request them
using a new IAID.

We might want to state that the TMP_IA option MUST NOT appear in a
Renew or Rebind message? Or, should we allow these there to piggyback
a request for a new temporary address with a normal renewal operation?
I just don't view these events as very likely to occur simultaneously
so I'm not sure if there is much value? But, on the other hand being
flexible may be good.

I'm inclined to require them in Confirms as a client might *JUST* ask
for temporary addresses and need to know if it is still on the same
link and thus can continue using the addresses (until the lifetime
expires). After all, if it just crashed and rebooted, it may still
want to carry on some transaction it initiated before crashing using
the same temporary address. Or, the lifetime on the non-temporary
addresses may have expired but not on the temporary while it was down?

We may want to document Solicit / Advertise behavior. I don't think a
client that wants to potentially get temporary addresses down the road
needs to Solicit this. However, a client may ONLY want temporary
addresses and hence many want to Solicit with just these.

Anyway, we should discuss and resolve the exact rules regarding the
TMP_IA (perhaps we don't need to go into significant detail but ...)?

3. IAID values would be unique within an IA option type PER
    client. So, IAID of 0 for an IA Option and IAID of 0 for a TMP_IA
    option are two different IA numbers. This avoids some issues with
    these numbers.

4. The RTA Option is dropped as it is no longer needed. If the client
    wants 5 (sets of) temporary addresses active at time, it must send
    5 TMP_IA options with 5 unique IAIDs for those options.

5. Drop the "T" bit in the "addr status" field of the IA Address
    option. Make the addr status field an 8-bit status code.

I probably forgot something ... and I'm sure you'd ideally like text
to cut and paste.

In addition, I'd recommend having a new DSTM_IA option that is
basically the same as the IA Option. The DSTM IAID follows the same
rules (it a totally separate number space from the IA Option and
TMP_IA option). Of course, this is a different draft and we can update
it after dealing with -23.

 > >    The client retransmission behavior is controlled and described by the
 > >    following variables:
 > >
 > >       RT     Retransmission timeout
 > >
 > >       IRT    Initial retransmission time
 > >
 > >       MRC    Maximum retransmission count
 > >
 > >       MRT    Maximum retransmission time
 > >
 > >       MRD    Maximum retransmission duration
 > >
 > >       RAND   Randomization factor
 >
 > I assume that none of the above are configurable? I.e, implementations
 > aren't required to support admins reconfiguring these?

These variables are used to describe the timeout and retransmission
behavior and are not configurable.

 > >    Clients MUST discard any received messages that include
 > >    authentication information and fail the authentication check by the
 > >    client, except as noted in section 22.6.5.2.
 >
 > Seems like the client per its own policy, decides when to accept
 > unauthenticated packets.

Agreed.

 > > 16. Message validation
 >
 > I don't think this section is so useful standalone. It would  probably
 > be more clear to just put the individual subsections in the place in
 > the document where you deal with processing incoming  messages. In
 > some cases, for example, those section add more checks than what you
 > have listed here.

(Author consensus: Leave chapter 16 where it is; check for correctness
and completeness)
Some validation checks don't really fit elsewhere; authors will retain
the current organization.

 > >    Relay agents MUST discard any Solicit messages received through port
 > >    546.
 >
 > the wording "received through" is not clear. Better to say something
 > like "received with destintation port 546" (if that is the
 > intent). Fix this throughout.

Agreed.

 > >    Servers MAY choose to discard any received Information-request
 > >    messages that do not include a Client Identifier option.
 >
 > then later:
 >
 > >    The client SHOULD include a Client Identifier option to identify
 > >    itself to the server.  If the client does not include a Client
 > >    Identifier option, the server will not be able to return any
 > >    client-specific options to the client.
 >
 > Even worse, the server may drop the request. This seems like a
 > potential problem area. Better to give stronger guideance on whether
 > the server really can drop these, since client is only a SHOULD. Or
 > should that be a MUST?

(Author consensus: Rewrite for clarity)
Authors will clarify the text to specify that if the client does not
include a Client Identifier, the best the server can return is options
that are not customized to the client, and the server may have a
policy of not replying at all to messages without a client identifier.

 >
 > >    addresses for which the client has a preference.  The client MAY
 > >    include an Option Request Option in the Solicit message.  The client
 > >    MUST NOT include any other options except those specifically allowed
 > >    as defined by specific options.
 >
 > Seems like it would be useful to allow servers to send options that
 > the client didn't request, so long as they are just ignored if not
 > understood. Or, shouldn't the client just be required to include the
 > ORO in the solicit? I'm thinking of ease of deployment issues
 > here. Are the semantics here inherited from DHCPv4 (i.e, under
 > assumptions that may not hold for DHCPv6?)

Agreed; we will clarify the verbiage to clarify this issue.

 > >    The first Solicit message from the client on the interface MUST
 > >    be delayed by a random amount of time between MIN_SOL_DELAY and
 > >    MAX_SOL_DELAY. This random delay desynchronizes clients which start
 > >    at the same time (e.g., after a power outage).
 >
 > This delay should be tied to specific actions in the ND spec, i.e.,
 > after receipt of an RA that say 'use dhc'. See RFC 2461.

Agreed.

 > >    A client MUST collect Advertise messages for IRT seconds, unless
 > >    it receives an Advertise message with a preference value of 255.
 > >    The preference value is carried in the Preference option (section
 > >    23.8).  Any Solicit that does not include a Preference option is
 > >    considered to have a preference value of 0.  If the client receives
 > >    an Advertise message with a preference value of 255, then the client
 > >    MAY act immediately on that Advertise message without waiting for any
 > >    additional Advertise messages.
 >
 > Last MAY seems like it should be a SHOULD. MAY isn't helpful.

Agreed.

 > > 18.1.3. Receipt of Advertise messages
 >
 > Seems like the message checks in 16.3 should just go here.

See earlier response.

 > >    Once a client has selected Advertise message(s), the client will
 > >    typically store information about each server, such as server
 > >    preference value, addresses advertised, when the advertisement was
 > >    received, and so on.  Depending on the requirements of the user that
 > >    invoked the DHCP client, the client MAY initiate a configuration
 > >    exchange with the server(s) immediately, or MAY defer this exchange
 > >    until later.
 >
 > This last MAY seems like it might lead implementors to just skip the
 > "wait until you get a bunch of responds then pick one", which woudl be
 > bad. More text to say when this MAY  should be invoked?

The preference value 255 gives the net admin a way to bypass the
Advertise collection step so the last sentence is not needed; we will
delete it.

 > >    The server MUST include IA options in the Advertise message
 > >    containing any addresses that would be assigned to IAs contained in
 > >    the Solicit message from the client.  The server MAY include some or
 > >    all of the IA options from the client in the Advertise message.
 >
 > Clarify. last sentence seems to be different than previous one. Can a
 > server not include an IA the client requested? Seems like it can't,
 > but that the IA might be empty (can't assign addresses). Right?

We will delete the second sentence.

 > >    If the server will not assign any addresses to IAs in a subsequent
 > >    Request from the client, the server SHOULD either send an Advertise
 > >    message to the client that includes only a status code option with
 > >    the status code set to AddrUnavail and a status message for the user
 > >    or not respond to the Solicit message.
 >
 > SHOULD? You want it clear what is to be done. Also, there is a choice
 > here. Which one should be done under which circumstances? If its just
 > left to implementors, will something reasonable happen?

We will change SHOULD to MUST and delete the alternative.

 > > 19. DHCP Client-Initiated Configuration Exchange
 > >
 > >    A client initiates a message exchange with a server or servers to
 > >    acquire or update configuration information of interest.  The client
 > >    may initiate the configuration exchange as part of the operating
 > >    system configuration process or when requested to do so by the
 > >    application layer.
 >
 > Also, when addresses are about to expire.

We will add text to include Rebind and Renew time.

 > >    Advertise messages for use in constructing Request messages.  Note
 > >    that a client may request configuration information from one or more
 > >    servers at any time.
 >
 > Do we need to include this last sentence? I think this may be
 > confusing.  Or would it make sense to just say (somewhere in its own
 > paragraph/section) that the DHCP mechanisms allow one to query multiple
 > servers simultaneoiusly, but that the exploitation of that is future
 > work and is not needed for basic clients. Basic clients will just be
 > conversing with one server.

We will delete the second sentence.

 > >        e.  g., servers that responded with an Advertise message
 >
 > spacing

We'll figure out how to make LaTeX do the right thing here.

 > >    The client SHOULD respond to the server with a Release message for
 > >    any addresses in the Reply message that have a valid lifetime of 0.
 > >    The client constructs and transmits this message as described in
 > >    section 19.1.7.
 >
 > why SHOULD vs. MUST? Also, this doesn't seem like an overloading of
 > semantics. If the server is saying the Lifetime is 0, then it is
 > 0. Right? Why doesn't the client just accept that as fact?

Agreed that this requirement is superfluous; we will delete it.

 > >    If the Reply was received in response to a Renew or Rebind message,
 > >    the client must update the information in any IA option contained in
 > >    the Reply message.  The client adds any new addresses from the IA
 > >    option to the IA, updates lifetimes for existing addresses in the IA
 > >    from the IA option and discards any addresses with a lifetime of zero
 > >    in the IA option.
 >
 > Is an lifetime of 0 supposed to indicate "request denied" for that
 > address, or is it supposed to mean "although the address was valid at
 > one point, its current lifetime is 0". Seems like the two cases might
 > not be the same, and you should use differnet messages/codes to
 > distinguish.

The server indicates "request denied" by returning the current
remaining lifetime.  The server indicates "stop using this address
immediately" by returning lifetime 0.  Do we need some additional
text to clarify?

 > >    When the client receives a NoBinding status in an IA from the server
 > >    for a Confirm message the client can assume it needs to send a
 > >    Request to reestablish an IA with the server.
 >
 > Clarify: what are the next steps a client needs to take?

We will rewrite this as follows:

When the client receives a NoBinding status in an Ia from the server
for a Confirm message, the client sends a Solicit message to locate a
server that is willing to configure the IA for the client.
 >
 > >    When the client receives a ConfNoMatch status in an IA from the
 > >    server for a Confirm message the client can send a Renew message to
 > >    the server to extend the lifetimes of the addresses.
 >
 > This seems confusing. Maybe if I understood better the difference
 > between Confirm and Renew, this would be clear.

We will delete this paragraph.

 > >    A client MAY choose to wait for a Reply message from the server in
 > >    response to the Release message.  If the client does wait for a
 > >    Reply, the client MAY choose to retransmit the Release message.
 >
 > Shouldn't this be a SHOULD?

We will rewrite this paragraph to read:

    The client SHOULD choose to guarantee the delivery
    of the Release message using the retransmission
    strategy in section 15.  An example of a situation
    in which a client would not guarantee delivery would
    be when the client is powering down or restarting
    because of some error condition.

The paragraph immediately following this paragraph in 19.1.7 gives
the retransmission parameters.

 > > 19.2.1. Receipt of Request messages
 > >
 > >    The server MAY choose to discard Request messages received via
 > >    unicast from a client to which the server has not sent a unicast
 > >    option.
 >
 > Better to always respond, but include an indication of "go through
 > relay agent"?

We will change to:

When the server receives a Request message via unicast from a client
to which the server has not sent a unicast option, the server responds
with a Request message containing a status code UseRelayAgent.

 > >    When the server receives a Request the client is requesting the
 > >    configuration of a new IA by the server.  The server MUST take the
 >
 > Strictly speaking, not "a new IA". Maybe the IA exists already from
 > before...

Agreed.

 > >    configuration of a new IA by the server.  The server MUST take the
 > >    IA from the client and associate a binding for that client in an
 > >    implementation-specific manner within the configuration parameter
 > >    database for DHCP clients managed by the server.
 >
 > saying "implementation-sepecific manner" seems like poor words. You
 > mean, it will creates a binding according to  its policy/config
 > information, etc.

Agreed.

 > >    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 SHOULD seems like empty words. Second MUST seems silly to. Of
 > course one needs to respond to the message...

Agreed.

 > >    If the server finds that the prefix on one or more IP addresses in
 > >    any IA in the message from the client is not a valid prefix for the
 > >    link to which the client is connected, the server MUST return the IA
 > >    to the client with the status field set to NoPrefixMatch.
 >
 > Wouldn't it be better then to call the return code "NotOnLink"?

OK.

 > >    If the server cannot assign any addresses to any of the IAs in
 > >    the message from the client, the server SHOULD include the IAs in
 > >    the Reply message with the status field set to AddrUnavail and no
 > >    addresses in the IA.
 >
 > As opposed to doing what? I.e., SHOULD implies there may be alternate
 > response. What is it?

We will change SHOULD to MUST.

 > >    For any IAs to which the server can assign addresses, server includes
 > s/server/the server/

OK.

 > >    the IA with addresses and other configuration parameters a status of
 > >    Success, and add the IA as a new client binding.
 > s/add/adds/

OK.

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