Subject: [dhcwg] Reminder - WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 22nd

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 15 Aug 2016 13:26:00 +0000

Hi:

Just a friendly reminder that this (extended) WGLC is scheduled to end in a week (August 22nd).

Thanks much to all those that have responded so far!!

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, August 08, 2016 9:38 AM
To: dhcwg <[email-masked]>
Subject: [dhcwg] Extended - WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 22nd

Hi:

In discussions with Ralph and Tomek, we have decided to extend the WGLC for this document by 2 weeks. So comments are due Monday 8/22.

Thanks to all those that have sent review comments so far!!!

- Bernie (for Ralph and Tomek)

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, July 28, 2016 11:14 AM
To: dhcwg <[email-masked]>
Subject: [dhcwg] Reminder - WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Hi:

Just a reminder about this WGLC ... please review and respond by August 8th. For a reminder as to the goals and key areas of change, please see https://www.ietf.org/proceedings/96/slides/slides-96-dhc-2.pdf.

As a reminder, the following people agreed to review during WGLC:

>From https://www.ietf.org/proceedings/95/minutes/minutes-95-dhc:

    Volunteers for review: Ted Lemon, Bernie Volz, Mohammed Boucadair, Tim Winters, 
    Tim Chown, Francis Dupont, Paul Ebersman
    Co-authors (who are supposed to review without explicitly voluneering): Bernie Volz,
    Sheng Jiang, Marcin Siodelski,
    Ian - I also volunteered to review

And, at IETF-96:

   Yogendra Pal volunteered to review the draft.

Thanks much!

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, July 08, 2016 1:03 PM
To: dhcwg <[email-masked]>
Subject: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Hi all,

So the day finally has come. Authors working on RFC3315bis believe that after over two years of work, this document is ready for working group last call. This call initiates the working group last call on
draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document (130+ pages), there's upcoming meeting and a holiday period, chairs decided to do an extended last call that will last 4 weeks. Please post your comments by August 8th.

We do have a slot reserved for this work in Berlin. We will present the overview of the document (some areas are organized differently than original 3315), go over the most important changes and will discuss any comments raised to date.

If you would like to review more important changes, looking at appendices A anb B seems like a good place to start. If you like to see the list of tickets addressed, see [2]. Many smaller issues were discussed on dhcpv6bis mailing list [3].

This is the most important document the DHC working group is currently working on. Please review it thoroughly. Since both co-chairs are also co-authors, our shepherd, Ralph Droms, will determine consensus and wrap up the WGLC. Thank you Ralph for stepping up and helping with this!

1. https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05
2. https://tools.ietf.org/group/dhcpv6bis/
3. https://www.ietf.org/mailman/listinfo/dhcpv6bis

Cheers,
Bernie & Tomek

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 19 Aug 2016 16:06:38 -0400

I have read this document, and reviewed it lightly (minor comments below).
I commend the folks that worked on it for their efforts, and strongly
support its moving forward in the standards process.

My comments:

1.2 Seems odd that v4 should be used for v4, not v6, but then RFC7341 is quoted.
Left up to the reader to decide what to do?  Some guidance might be useful here.
 
5.2 First sentence.  Perhaps "... and is the "stateful address autnconfiguration protocol"  
for IPv6 which is discussed in [RFC2462]." would better
   
5.4 Figure 1.  I would replace "DSL to subscriber..." with "Network link to subscriber...". 
Or someething like that.  I think DSL isn't going to aid understanding now or into the
future.
 
13.1  First paragraph.  "This loops can repeat ..." -> "This loop can repeat..."
 
13.2 "Client MUST choose..." -> "Clients MUST choose ..."
 
15. I think that "A server MUST discard any Solicit ..." should be "A server SHOULD discard ..."
MUST seems overly restrictive to me, despite being in RFC3315. Not that I expect anyone to
change it based on this comment...

17. Second paragraph after the list. "... solicitation process to obtain the bindings from a..."
-> "... solictation process to obtain the same bindings from a ..."

17.1  I would remove "DISCUSSION:" and just make this a regular paragraph.

17.1.1 "The client MUST include an Option Request option ..." but section 20.7 says
"MAY" include an Option Request option.  The implication in 17.1.1 is that you
have to have an ORO with SOL_MAX_RT in it, or ... what, exactly, will happen?   
Packet dropped?  Seems like either MUST -> MAY, or some additional clarity would
be good here.  This is in 17.1.2 as well.

17.1.11 Here the "DISCUSSION" seems appropriate.  Not clear why that seems to be
the case, as opposed to 17.1.

20.7 "... or the will not ..." -> "... or they will not ..."

Regards -- Kim

> On Aug 15, 2016, at 9:26 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 22 Aug 2016 21:50:47 +0200

> end in a week (August 22nd).
Due to my poor time management and other duties in my day job, I failed
to review the complete document. Here's a partial review I managed to
complete so far. I plan to review the remainder of the text in the
coming days.

While I have many comments, they are mostly editorial in nature. With my
co-chair hat off, I strongly support this work.

Here's my review for pages 1 through 50.

Abstract : => ,
hosts => IPv6 nodes (as the PD is used by routers)

Section 1. The text should mention requestor and leasequery mechanism.
One paragraph somewhere in the introduction with references to RFC5007,
RFC5460 and RFC7653 should do the trick. Maybe somewhere around the text
that mentions servers, clients and relays. If you think it's
inappropriate to mention it that early, we can add one paragraph long
section 1.6 that explains it and then point to that in Section 1.

Need parentheses around section references in the last paragraph of
Section 1.

Section 1.1: extensions published => extensions were published

Section 1.4 seems to mention some more common exchanges (inf-req ->
reply), (solicit -> reply), (renew -> reply). It does not mention
others: (release -> reply), (rebind -> reply), (decline -> reply),
(confirm -> reply). Maybe adding a text similar to: "There are other two
message exchanges defined when the client and the server have
established a relationship: to renew or rebind existing leases (renew
and rebind messages), to release them (release message) or to inform the
server that the address leased is being used by other devices (decline
message)."?

Section 1.5 (4 messages exchanges) mentions Renewal mechanism. It
shouldn't, because it's a 2 messages exchange.

Section 4.1: "Every interface has a link-local address." Is this still
true these days? I recall some discussion on v6ops (or was it 6man?)
about certain tunneling interfaces lacking link-local address. IIRC it
was 6rd tunnel, but I may be wrong.

Section 4.2 binding definition should mention prefixes in its first
sentence.

Section 4.2 delegating router definition "responding to prefix request".
No such thing as prefix request is defined. Need to reword this one
slightly.

'DHCP realm' this definition was used in Delayed Auth protocol, which
is now removed. We should remove that definition as well.

DUID definition - it mentions that each client and server has one. Do
we want to mention that relays optionally may have one as well (see RFC5460)

IA definition - "holds one type of address" => "holds one type of
addresses or prefixes". I would also add "one IA may hold more than one
address or prefix of the same type, e.g. multiple temporary addresses".

Section 6 is called DHCP constants, but it does not contain the most
frequently used constants - the option codes. I think there should be a
pointer to Section 22, which defines the option codes, which are another
type of constants.

Section 6.3: request, renew, rebind, reply, release, inf-request
descriptions should mention prefixes as well.

The link in section 6.4 is incorrect. Status codes are not defined in
20.12, but in 20.13.

Section 8.1. link-address definition. "An address that will be used" =>
"An address that may be used". There are cases when it is not used,
for example when the relay inserts interface-id or it's not the relay
closest to the client.

What should be the hop-count set to when a relay forward client's
message? Text in 8.1 suggests 1 ("Number of relay agents that have
relayed this message", but text in 18.1.1 suggests 0 ("The hop-count in
the Relay-forward message is set to 0.")

Section 10. I think we should remove this sentence: "Clients and servers
MUST NOT in any other way interpret DUIDs.". This is a fiction that many
servers are violating for very good reasons. Removing it would settle
the issue raised in ticket #162. If you're not comfortable with removing
it completely, maybe substituting it with "Servers MAY interpret DUIDs
for policy, logging and other purposes, but MUST use the whole DUID to
identify clients." would be better?

Section 10.4: "DUID-LL MUST NOT be used by DHCP clients or servers that
cannot tell whether or not a network interface is permanently attached
to the device on which the DHCP client is running." I think we should
replace MUST NOT with SHOULD NOT for couple reasons. First, with enough
engineering time everything is replaceable. Second, with the advent of
virtualization software (and virtualization-like techniques, like
docker) it's increasingly difficult to say what is permanently attached
and what is not. Who knows what SDN will allows in couple years?

Section 11.1 "The configuration information in an IA consists of one or
more IPv6 addresses along with the times T1 and T2 for the IA." That's
not true for IA_TA, which does not have T1/T2 timers.

Section 12.1 could use a reference to ietf-dhc-topo-conf (currently in
RFC-Ed queue).

Section 12.3: Add "The same is true for IA_PD." after "The IAID number
space for the IA_TA option IAID number space is separate from the IA_NA
option IAID number space."

Section 13: "sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers." => "sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers multicast address."

Section 13.1 "the server still has the lease that was requested just
previously" The word 'just' doesn't seem to fit there. The sentence
should be rephrased.

"This loops can" => "This loop can"

Section 14 "A client is not expected to listen for a response during the
entire period between transmission of Solicit or Information-request
messages." I would add " and may turn off listening capabilities after
a certain time due to power consumption saving or other reasons."

Section 15.1 Add this text: "The exception is Reconfigure message, which
is sent by by the server and the transaction ID is set to zero."

Section 17 mentions that solicit exchange is called server discovery or
server solicitation. Maybe we should stick to one name? "server
discovery" phase has 5 occurrences, while "server solicitation" has only
4. Discovery seems to be also intuitively better understood by
non-native speakers.

Section 17.1 "When a client requests multiple IA option types" =>
"When a client requests multiple IA option types or multiple instances
of the same IA types"

"this situation should be rare or a temporary operational error." =>
"this situation should be rare or a result of temporary operational error."

Section 17.1.1 - we need to reorder the text (basically move paragraph
7 further down, maybe after 9th paragraph). Currently the text says "the
client MUST NOT include any other options..." and the following
paragraphs continue discussing which extra options to include.
Technically the current text is correct (because of the except clause),
but it's confusing.

Section 17.1.1 replace "an Advertise message" with "a valid Advertise
message" in this text: "If the client receives an Advertise message that
includes  a Preference option with a preference value of 255...". The
same is true for the following text "If the first RT elapses and the
client has  received an Advertise message...". And again in "If the
client does not receive any Advertise messages...".

Section 17.1.2 Clarification: After "The client generates a transaction
ID and inserts this value in the "transaction-id" field." add "This
value is likely to be different than the one used in Solicit". I vaguely
recall someone considering the whole solicit-adv-req-reply as a single
transaction. We should clarify that these are two separate transactions.

Not related to any specific text:
The maximum time allowed to be specified in Elapsed is 655.35 seconds.
The MAX_INF_RT and SOL_MAX_RT are 3600 seconds. What value should the
client set in Elapsed option when transmitting after 655 seconds?
The text doesn't specify that.

Tomek

---

From: "Yogendra Pal (yogpal)" <[email-masked]>
Date: Mon, 22 Aug 2016 21:36:32 +0000

Hi,

  *   Been a very lengthly document, quick read of version (05) and I have few comments.
  *   Appreciate efforts of all the authors bringing this document into collating form of rfc. 3315, prefix delegation (3633) and

Others.

  *   Strongly support moving forward into standards.

Comments below [YP]:

Chapter-1:

>>delegating router can delegate prefixes to requesting routers

[YP]Can we make document reflect the DHCPv6 client/server/relay

instead of routers. Since Delegating entity can be any device in n/w.

Chapter-1.1:

>>Understanding a protocol which definition is

>>spread between large number of documents may be cumbersome.

[YP]Could not connect with this text, is there some typo or can be rephrased ?

Chapter-1.4:

>>the client can obtain configuration information

[YP]Not consistent with text “other configuration information” in many

places in this section. Can be consistent w/ text “other configuration information”.

>>This message includes an indication that the client is

>>willing to accept an immediate Reply message from the server.

[YP] Can we update above text to:

This message includes an indication (i.e. Rapid Commit option (see

Section 20.14<https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05#section-20.14>) that the client is willing to accept an

immediate Reply message from the server.

Chapter-5.4

>>If the requesting router assigns a delegated prefix to a link to

>>which the router is attached, and begins to send router

>>advertisements for the prefix on the link, the requesting router MUST

>>set the valid lifetime in those advertisements to be no later than

>>the valid lifetime specified in the IA_PD Prefix option.  A

>>requesting router MAY use the preferred lifetime specified in the

>>IA_PD Prefix option.

[YP] Addition of following text for adding operational experience to above:

Operator MUST configure requesting router with periodic RA lifetime to be less than

preferred lifetime so that renewed prefix(s) can be advertised within limits and there

is no operational traffic drop experience to subscribers.

Regards, Yogendra

From: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Date: Mon, Aug 15, 2016 at 6:56 PM
Subject: [dhcwg] Reminder - WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 22nd
To: dhcwg <[email-masked]<mailto:[email-masked]>>

Hi:

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernie Volz (volz)
Sent: Monday, August 08, 2016 9:38 AM
To: dhcwg <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] Extended - WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 22nd

Hi:

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernie Volz (volz)
Sent: Thursday, July 28, 2016 11:14 AM
To: dhcwg <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] Reminder - WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Hi:

And, at IETF-96:

Thanks much!

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Friday, July 08, 2016 1:03 PM
To: dhcwg <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Hi all,

Cheers,
Bernie & Tomek

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 30 Aug 2016 21:23:09 +0200

Here is the second part that concludes my review. Apologies for sending
them so late after the deadline.

Missed comment for 17.1.1.
The text says "The first Solicit message from the client on the
interface MUST be delayed by a random amount of time between 0 and
SOL_MAX_DELAY." This mechanism was defined to avoid packet storm after a
network recovers from blackout, but it makes no sense when booting
wireless device. We should make an exception for wireless devices here.

Section 17.1.10.1
in order avoid => in order to avoid

Section 17.1.10.3
The references look odd "the client performs DHCP server solicitation,
as described in Section 17, and client-initiated configuration, as
described in Section 17." More specific sections should be referenced.

Section 17.1.6
"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, or the server may choose not to
respond to the message at all." It would be better to use MAY.
I'm also not fond of the text that says the server may not respond
at all. This is especially important from the privacy context.
THere may be clients that protect their privacy, don't want to
reveal their client-id and expect to get only basic configuration
options, like DNS servers information.

This is also in conflict with text in 17.2.6 ("the server SHOULD respond").

Note that draft-ietf-dhc-sedhcpv6 draft relies on anonymous
information-requests when bootstrapping encryption.

As such, I think the text about server dropping the message should
be removed.

Section 17.2, third paragraph
"In most instances, the server will send a Reply in response to a
Request, Confirm, Renew, Rebind, Decline and Information-request
messages sent by a client." Add Release here.

Section 17.2.1
What should the server do when it receives a unicasted Solicit? There's
no text for sending back UseMulticast status for Solicit, but there
are for other message types.

"...send a Request message for those addresses." Add "or prefixes".

"may useful using server selection process." => "may be useful during
the server selection process."

The last paragraph in 17.2.1 is confusing. The text needs to emphasize
somehow that the paragraph only applies to case when rapid-commit was
sent. Maybe we could move the rapid-commit response paragraphs to a
separate sub-section?

Section 17.2.2
"...and a Status Code option containing status code NoAddrsAvail.". The
text should be clarified as to whether send this status option within
IA or as top level option.

Section 17.2.5
There's no text for unicast Rebind and sending UseMulticast. Sending
unicasted rebind is wrong on so many levels BTW.

"Therefore, the server SHOULD only create new bindings during processing
of a Rebind message if the server is configured to respond with a Reply
message to a Solicit message containing the Rapid Commit option."
I disagree with this text. Responding to Solicit with rapid-commit and
creating leases when responding to Rebind are two similar scenarios,
but they're not the same. I can certainly see deployments that would
want to deploy only one or the other, but not both. For specific
example, there's one server that does not support rapid commit. The
server crashed and lost its database. The server is restarted with empty
database, but it knows there are clients in various Renew/Rebind stages
and it know it's the only server in the network. There should be a way
to recreate the leases (at least those that clients still attempt to
rebind) without enforcing clients go get new ones.

To conclude, I think the sentence should be removed completely.

Section 17.2.6
There's no text for unicast Information-request and sending back
UseMulticast. I can some reasons why we may allow that behavior,
so I don't insist strongly on adding such text, but maybe we need
to have some explanatory text when unicasted Information-request
is ok and when it's not.

Section 17.2.9
I have a problem with this text "If the Solicit message from the client
included one or more IA options, the server MUST include...", especially
with the "if". The conditional nature of that expression may be
suggest that it's ok to send Solicit without any Ia options. That's
definitely not the case. If the Solicit didn't include any IAs,
it's a valid Solicit and should be dropped, and the implementer should
not be following the section about creation and transmission of
Advertise messages.

(IA_NA or IA_IA) => (IA_NA or IA_TA)

Possible additional text at the end of 17.2.9 and 17.2.10
"The server MAY include additional options if configured to do so or
when supporting additional mechanisms, e.g. Relay Supplied Options
(RFC6422) or Echo Request Option (RFC4994)."

I like the idea of mentioning other existing mechanisms to get better
exposure to what is currently defined in other RFCs.

Section 18.1.1
RFC3879 deprecated site scope unicast addresses. Do we still want to
mention them in the first sentence? The second sentence needs
improvement: "If not addresses of other scopes are available the relay
agent..." => "If no such addresses are available, the relay agent..." =>

"as described in the previous paragraph" =>
"as described in the earlier paragraphs"

Section 20.1
"DHCP options are scoped by using encapsulation.  Some options apply
generally to the client, some are specific to an IA, and some are
specific to the addresses within an IA." This text, while true, it does
not cover all cases. We have other encapsulated options that have
nothing to do with addresses, e.g. MAP options defined in RFC7598.

Sections 20.4 and 20.5.
"This option MAY appear in a Confirm message if the lifetimes on the
non-temporary addresses in the associated IA have not expired." This
sentence appears out of place. We should either mention all other
messages it may appear in or not mention Confirm at all.

Section 20.7
I saw quite a few client messages that request Preference and
Rapid-Commit options in their Solicit messages. I suspect that by saying
that the client MUST NOT request it will make many clients non-conformant.

"the container MUST NOT by in the Option Request" =>
"the container MUST NOT be in the Option Request"

Section 20.13

There are more status codes defined than listed in this section. A text
similar to "Additional status codes have been defined in other
documents. Additional status codes may be defined in the future." and a
link to IANA page listing currently defined status codes would be useful
here.

Somewhere after 20.25 we must put a text similar to "Other options
are defined in other documents. Additional options will be defined in
the future. For the complete up to date list of currently defined
option, see IANA page [link].". This is important, especially due to the
remark made in 20.25: "This [Information Refresh Time Option] is listed
here for completeness." can be misinterpreted as "these are all the
DHCPv6 options that are currently defined".

General comment:
The header appearing on each page is "RFC 3315 bis". It's ok for the
time this draft is discussed in WG phase, but we should change this to
"DHCP for IPv6" before sending it to the IESG.

Section 21
I don't understand this paragraph: "In the case where relay agents add
additional options to Relay Forward messages, the messages exchanged
between relay agents and servers may be used to mount a "man in the
middle" or denial of service attack."

It doesn't make sense to me. If a relay agent is compromised (or
attackers manages to introduce a node he controls into the path, both
DOS and MITM attacks are possible, regardless of the original relay
agent inserted any options or not.

"in which the DHCP server sends the key to the client." =>
"in which the DHCP server sends the key in plain text to the client."

"A malicious requesting router may be able to mount a denial of
service attack by repeated requests for delegated prefixes that
exhaust the delegating router's available prefixes.". We should add
something similar to: "Some forms of this exhaustion attack can be
mitigated by appropriate server policy, e.g. limiting maximum number of
leases one client can get.".

Unless I missed something, we can probably remove this sentence:
"The details of using IPsec for DHCP are under development.". Or replace
it with a link to draft-ietf-dhc-sedhcpv6.

Section 22
"Section 3 of said document discuss..." =>
"Section 3 of said document discusses...".

Section 23
Do we want a separate column in IANA registry that explains which
options are singletons?

Section 24
"The following mechanism are..." =>
"The following mechanisms are..."

Section 26
I think we have way too many normative references. It's a bit of a
judgement call, but in my opinion, the following should be informative
rather than normative: 826, 2131, 2132, 2136, 2464, 3646, 4075, 4291,
4301, 4941, 5905, 6724, 7227.

Appendix A
I'm not sure if removing this is a good idea. There will be lots of
implementers and operators that don't participate in IETF at all. Once
the RFC is published, they'll be wondering what has changed and having
such a list may be of use for them. If we keep that list, we should add
a link to the dhcpv6bis tracker, so the ticket numbers would remain to
be useful.

Possible Appendix E
We could add a list of options with explicit specification which options
are singletons and which are not. This information could be also added
to the IANA registry. If anyone objects, I won't insist on that, though.

Ok, that's it. I have not further comments.

Tomek