Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-rfc3315bis-13

I have a few comments:

1: Section 4.1.  IPv6 Terminology
"link-local address: An IPv6 address having a link-only scope,  indicated by having the prefix (fe80::/10), that can be used to reach neighboring nodes attached to the same link.  Every interface has a link-local address."
Surely this is "Every IPv6 interface..."? I was unable to find this definition in any of RFC2460, RFC4291, RFC4862, not sure if it was lifted from elsewhere?

2: Section 4.2.  DHCP Terminology
"binding: A binding (or, client binding) is a group of server data records containing the information the server has about the addresses or delegated prefixes in an IA or ..."
I think it would be helpful to have a "(see below)" (or similar) near IA - I went searching to try find where this was expanded earlier in the document.

3: 
"DHCP client (or client): A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers.  Depending on the purpose of the client, it may feature the requesting router functionality, if it supports prefix delegation."
"... may feature the requesting router functionality" reads really oddly -- I think that '... may feature the "requesting router" functionality...' would be much clearer - it took me a few reads to figure out what was meant. Or, perhaps using the 'delegating router' term here would be cleaner?


[ Unfortunately, I ran out of time and didn't review past Section 6 - apologies ]

Thanks for everyone who worked on this update. I have a handful of comments
(many of which are simple editorial nits that you can accept or ignore as you
see fit), described in document order below.

One general editorial nit that I found is the use of the plural form of
"octets" when appearing as a noun adjunct (e.g., "A four octets long field"
rather than "a four octet long field") is awkward and distracting. The
conventional form here is singular.

-------------------------------------------------------------------------------

In section 4.1:


>  link-layer identifier     A link-layer identifier for an interface.
>                            Examples include IEEE 802 addresses for
>                            Ethernet or Token Ring network interfaces,
>                            and E.164 addresses for ISDN links.

It's been a while since I worked with ISDN, but this doesn't match my
recollection at all. ISDN uses LAPD as its underlying link protocol and LAPD
uses TEIs as link addresses. On a quick double-check, I don't find a reference
to E.164 from Q.921. I think you want to replace "E.164 addresses" with "TEIs"
above.


-------------------------------------------------------------------------------

In section 4.2:

>  binding                   A binding (or, client binding) is a group
>                            of server data records containing the
>                            information the server has about the
>                            addresses or delegated prefixes in an IA or

I get that these are in alphabetical order, but it's impossible to understand
this definition without understanding the meaning of "IA". Consider adding
"(Identity Association, see below)" after "IA"

-------------------------------------------------------------------------------

In section 4.2:

>  T1                        The time at which the client contacts the
>                            server from which the addresses in the
>                            IA_NA or prefixes in the IA_PD were
>                            obtained to extend the lifetimes of the
>                            addresses assigned to the IA_NA or prefixes
>                            delegated to the IA_PD.
>
>  T2                        The time at which the client contacts any
>                            available server to extend the lifetimes of
>                            the addresses assigned to the IA_NA or
>                            prefixes delegated to the IA_PD.

I was initially confused about the epoch used for these times, then concerned
about the impending year 2038 problem when I realized these were only 32 bits.
It took me an additional 40 pages of reading before I figured out that these
were not *times*, but *timers*. Please be careful, here and elsewhere, to refer
to these as timers rather than times (e.g., section 21.4 refers to T1 as "The
time at which the client should...", rather than, e.g., "The number of seconds
in which the client should...")


-------------------------------------------------------------------------------

Section 7.2 describes the ports used for communicating with clients, servers,
and relays. These ports in the IANA port registry don't currently point to any
defining document. I would suggest adding a request in the IANA Considerations
section to request that the UDP port entries for 546 and 547 be updated to point
to this document.

-------------------------------------------------------------------------------

In section 11.2:

>  The link-layer
>  address is stored in canonical form, as described in [RFC2464].

I think you want to prefix this sentence with "For Ethernet hardware types," --
I don't see any discussion in RFC 2464 of representation of non-Ethernet
link-layer addresses.

-------------------------------------------------------------------------------

In section 13.2:

>  Clients ask for temporary addresses and servers assign them.
>  Temporary addresses are carried in the Identity Association for
>  Temporary Addresses (IA_TA) option (see Section 21.5).  Each IA_TA
>  option contains at lease one temporary address

Typo: replace "lease" with "least"

-------------------------------------------------------------------------------

In section 18.2:

>  If the client has a source address of sufficient scope that can be
>  used by the server as a return address, and the client has received a
>  Server Unicast option Section 21.12 from the server, the client

For readability, I suggest you place parentheses around "Section 21.12".

-------------------------------------------------------------------------------

In section 18.2.1:

>  The first Solicit message from the client on the interface SHOULD be
>  delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
>  mechanism is essential for devices that are not battery powered, as
>  they may suffer from power failure.  After recovering from a power
>  outage, many devices may start their transmission at the same time.
>  This is much less of a concern for battery powered devices.

I'm not sure this last sentence is true, and it seems to encourage producers
of battery-operated devices to ignore the advice to delay its initial Solicit.
For wireless networks recovering from a power outage, the time between boot
and sending an initial beacon is going to be pretty uniform for any given
access point/firmware combination. It is highly probable that a large campus
with uniform access points coming on line will result in all the access points
sending their initial beacon frame out all at the same time, that all
battery-powered devices on the network will observe this beacon at the same
moment, and eventually all attempt to send their Solicit messages
simultaneously.

For the cases of battery-powered devices with wired network interfaces, the
same will hold true for their upstream network device coming online and
activating the network link for all devices simultaneously.

I suggest removing discussion of battery-powered devices altogether, as I think
they need to observe the same random delay as all other devices.

-------------------------------------------------------------------------------

In section 18.2.1: the discussion of Reply with Rapid Commit doesn't mention the
possibility of clients performing a Release for any committed resources they
don't use (i.e., from servers other than the one they elect to use). It wasn't
clear to me whether such behavior was permissible until the discussion in
section 21.14. Since section 18.2.1 defines procedures while 21.14 defines
syntax, it probably makes more sense to move the discussion from 21.14 into
section 18.2.1. If you elect not to do so, at least consider referring readers
to the discussion (e.g., "Clients may choose to release unused committed
addresses, as described in section 21.14")

Because client handling of rapid commit is described in several places, this
comment applies elsewhere as well. I call these out below.

-------------------------------------------------------------------------------

In section 18.2.3:

>  The client uses a Confirm message when is has only addresses (no

Typo: "it" instead of "is"


-------------------------------------------------------------------------------

Section 18.2.10.1, like section 18.2.1, would also benefit from a mention of
Release in the multiple-rapid-commit Reply case.

-------------------------------------------------------------------------------

In Section 18.2.12:

>  addresses assigned to the interfaces on that link may no longer be
>  appropriate for the link to which the client is attached.  Examples
>  of times when a client may have moved to a new link include:

[list of examples removed]

>  When the client detects one of the above conditions and it has
>  obtained addresses and no delegated prefixes from a server, the
>  client SHOULD initiate a Confirm/Reply message exchange.

Basing a normative statement on a (presumably non-exhaustive) list of examples
is confusing. I think you want to change the normative sentence to start with
"When the client detects that it may have moved to a new link and it has
obtained addresses..."

-------------------------------------------------------------------------------

Section 22.11:

>     protocol             The authentication protocol used in this
>                          authentication option.  A one octet long
>                          field.
>
>     algorithm            The algorithm used in the authentication
>                          protocol.  A one octet long field.
>
>     RDM                  The replay detection method used in this
>                          authentication option.  A one octet long
>                          field.

The potential values for these fields needs to be indicated in this section. I
would also strongly encourage the creation of an IANA registry for these three
fields (similar to what RFC4030 does), in *particular* to address the need to
eventually move away from MD5.

-------------------------------------------------------------------------------

Section 21.13:

>     status-code          The numeric code for the status encoded in
>                          this option.  A two octets long field.

Since we're cleaning things up, this document should take action to fix the
IANA registry for status-code. Currently, IANA indicates that 23-255 are
unassigned, without mentioning the disposition of codes 256-65535. Presumably,
the "Unassigned" entry should read "23-65535".


-------------------------------------------------------------------------------

Section 21.13:

>     status-message       A UTF-8 encoded text string suitable for
>                          display to an end user, which MUST NOT be
>                          null-terminated.  A variable length field (2
>                          octets less than the value in option-len).

Given the "display to an end user" behavior described here, I would have
expected to see some discussion of localization of this string.

-------------------------------------------------------------------------------

Section 24:

>  (4)   See RFC8156 for details.

Typo: missing brackets around [RFC8156]

Many thanks to the Gen-ART reviewer for a thorough review. It sounds like the authors plan to incorporate edits in response but I wanted to particularly call out these bits from his summary with which I agree:

"I also found that the new document did not do a good job on the interactions between relay-agents and
servers.  Particularly on the processing of options between relays and servers
and details of reception of Relay-forward messages a little more detail would
help naive readers.  

Finally the draft has not made much of an effort to
support possible alternative security algorithms - IETF policy now encourages
protocols to deal with algorithm flexibility  - DHCPv6 as it stands is pretty
thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA
improvements plus some thought to cope with different algorithms."

I agree with Alissa's comments regarding the Gen-ART review. I suspect the resulting update will be substantial. I am a bit uncomfortable approving the draft prior to having a chance to review the update. My discomfort does not quite rise to the level of a DISCUSS, so I am balloting "No Objection".

-2: RFC 8174 has boilerplate that includes the ALL CAPs constraint; please consider using that rather than rolling your own.

Thanks for the new "Operational Models" section 6. x.
Nicely structured.

Document: draft-ietf-dhc-rfc3315bis-10.txt

This document was quite clear and well written. A few small comments
below.

It would have been easier for me to have a bit of intro about why
both the 4-message and 2-message rapid commit exchanges exist
and maybe some guidance about when to use each one.

I am finding the guidance on DUIDs a bit confusing. Rather than
having a bunch of constructions that produce variable length
things that are intended to be unique, why not just take all
those values and feed them into a hash function and then you
could just have UUIDs?

I'm a little sad that the transaction ID is so short. This doesn't
seem like really enough to provide uniqueness against guessing
attacks.

We're trying to discourage HMAC-MD5. Do you have any way to
transition to something stronger?

The description of how to actually do replay detection seems pretty
thin. Do you think more detail would be helpful here.


Editorial:


S 1.
   DHCPv6 can also provide only other configuration options (i.e., no
   addresses or prefixes).  That implies that the server does not have

Perhaps "DHCP can also be used just to provide..."


S 2.
Nit: do you want to cite 8174.


S 4.2.
When acronyms are used ahead of their definition, it would be good to
expand them.

  
S 21.22.
What is the part of the IPv6-prefix after prefix-length filled with?
Does it matter?

Thanks for your work updating this draft.  I'd like to see the lack of encryption from client to server explicitly mentioned in the security considerations section.  Hijacking, tampering, and eavesdropping attacks are all possible as a result.

I also agree with the SecDir reviewer (Kyle Rose) comments and recommendations, but saw your response to Eric's comments in that a draft to move from MD5 was dropped.  It would be good to see how we can better secure this protocol is a practical and deployable way.

Thanks for adding setion 14.1.!