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

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Ted Lemon , Sheng Jiang

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Ted Lemon , Sheng Jiang

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Ted Lemon , Sheng Jiang

[Ballot comment]
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]

[Ballot comment]
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 ]

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-dhc-rfc3315bis-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are six actions which we must complete.

First, on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page, we understand that the authors request us:

"to update the http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml page to add a reference to this document for definitions previously created by [RFC3315], [RFC3633], [RFC4242] and [RFC7083]."

IANA Question --> should all references to RFC3315 be replaced by the new [ RFC-to-be ]?

Second, the existing registry for Option Codes on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

http://www.iana.org/assignments/dhcpv6-parameters/

is to have some changes made.

IANA Question --> The table in section 24 of the current draft has the word OPTION removed from many, but not all, of the option names. Is the word OPTION to be removed from every entry in the Option Name column, or was this done in the interests of saving space in the draft (in which case the option names should remain as they are in the current registry)?

IANA Question --> What should the entry for Option Code 135, OPTION_RELAY_PORT, be in the revised registry?

IANA Question --> should the four notes, below Table 1 in the current draft, be included as footnotes to the revised registry?

IANA understand that the registry is to be modified to have two new columns. In addition, a "Reference" column will remain as the last column for the registry.

Without the "Reference" column, we understand that the modified Option Codes registry will be as follows:

+--------+--------------------------+---------------------+-----------+
| Option | Option Name (OPTION | Client ORO (1) | Singleton |
| | prefix removed) | | Option |
+--------+--------------------------+---------------------+-----------+
| 1 | CLIENTID | No | Yes |
| 2 | SERVERID | No | Yes |
| 3 | IA_NA | No | No |
| 4 | IA_TA | No | No |
| 5 | IAADDR | No | No |
| 6 | ORO | No | Yes |
| 7 | PREFERENCE | No | Yes |
| 8 | ELAPSED_TIME | No | Yes |
| 9 | RELAY_MSG | No | Yes |
| 11 | AUTH | No | Yes |
| 12 | UNICAST | Yes | Yes |
| 13 | STATUS_CODE | No | Yes |
| 14 | RAPID_COMMIT | No | Yes |
| 15 | USER_CLASS | No | Yes |
| 16 | VENDOR_CLASS | No | No (2) |
| 17 | VENDOR_OPTS | Optional | No (2) |
| 18 | INTERFACE_ID | No | Yes |
| 19 | RECONF_MSG | No | Yes |
| 20 | RECONF_ACCEPT | No | Yes |
| 21 | SIP_SERVER_D | Yes | Yes |
| 22 | SIP_SERVER_A | Yes | Yes |
| 23 | DNS_SERVERS | Yes | Yes |
| 24 | DOMAIN_LIST | Yes | Yes |
| 25 | IA_PD | No | No |
| 26 | IAPREFIX | No | No |
| 27 | NIS_SERVERS | Yes | Yes |
| 28 | NISP_SERVERS | Yes | Yes |
| 29 | NIS_DOMAIN_NAME | Yes | Yes |
| 30 | NISP_DOMAIN_NAME | Yes | Yes |
| 31 | SNTP_SERVERS | Yes | Yes |
| 32 | INFORMATION_REFRESH_TIME | Required for | Yes |
| | | Information-request | |
| 33 | BCMCS_SERVER_D | Yes | Yes |
| 34 | BCMCS_SERVER_A | Yes | Yes |
| 36 | GEOCONF_CIVIC | Yes | Yes |
| 37 | REMOTE_ID | No | Yes |
| 38 | SUBSCRIBER_ID | No | Yes |
| 39 | CLIENT_FQDN | Yes | Yes |
| 40 | PANA_AGENT | Yes | Yes |
| 41 | NEW_POSIX_TIMEZONE | Yes | Yes |
| 42 | NEW_TZDB_TIMEZONE | Yes | Yes |
| 43 | ERO | No | Yes |
| 44 | LQ_QUERY | No | Yes |
| 45 | CLIENT_DATA | No | Yes |
| 46 | CLT_TIME | No | Yes |
| 47 | LQ_RELAY_DATA | No | Yes |
| 48 | LQ_CLIENT_LINK | No | Yes |
| 49 | MIP6_HNIDF | Yes | Yes |
| 50 | MIP6_VDINF | Yes | Yes |
| 51 | V6_LOST | Yes | Yes |
| 52 | CAPWAP_AC_V6 | Yes | Yes |
| 53 | RELAY_ID | No | Yes |
| 54 | OPTION-IPv6_Address-MoS | Yes | Yes |
| 55 | OPTION-IPv6_FQDN-MoS | Yes | Yes |
| 56 | NTP_SERVER | Yes | Yes |
| 57 | V6_ACCESS_DOMAIN | Yes | Yes |
| 58 | SIP_UA_CS_LIST | Yes | Yes |
| 59 | OPT_BOOTFILE_URL | Yes | Yes |
| 60 | OPT_BOOTFILE_PARAM | Yes | Yes |
| 61 | CLIENT_ARCH_TYPE | No | Yes |
| 62 | NII | Yes | Yes |
| 63 | GEOLOCATION | Yes | Yes |
| 64 | AFTR_NAME | Yes | Yes |
| 65 | ERP_LOCAL_DOMAIN_NAME | Yes | Yes |
| 66 | RSOO | No | Yes |
| 67 | PD_EXCLUDE | Yes | Yes |
| 68 | VSS | No | Yes |
| 69 | MIP6_IDINF | Yes | Yes |
| 70 | MIP6_UDINF | Yes | Yes |
| 71 | MIP6_HNP | Yes | Yes |
| 72 | MIP6_HAA | Yes | Yes |
| 73 | MIP6_HAF | Yes | Yes |
| 74 | RDNSS_SELECTION | Yes | No |
| 75 | KRB_PRINCIPAL_NAME | Yes | Yes |
| 76 | KRB_REALM_NAME | Yes | Yes |
| 77 | KRB_DEFAULT_REALM_NAME | Yes | Yes |
| 78 | KRB_KDC | Yes | Yes |
| 79 | CLIENT_LINKLAYER_ADDR | No | Yes |
| 80 | LINK_ADDRESS | No | Yes |
| 81 | RADIUS | No | Yes |
| 82 | SOL_MAX_RT | Required for | Yes |
| | | Solicit | |
| 83 | INF_MAX_RT | Required for | Yes |
| | | Information-request | |
| 84 | ADDRSEL | Yes | Yes |
| 85 | ADDRSEL_TABLE | Yes | Yes |
| 86 | V6_PCP_SERVER | Yes | No |
| 87 | DHCPV4_MSG | No | Yes |
| 88 | DHCP4_O_DHCP6_SERVER | Yes | Yes |
| 89 | S46_RULE | No | No (3) |
| 90 | S46_BR | No | No |
| 91 | S46_DMR | No | Yes |
| 92 | S46_V4V6BIND | No | Yes |
| 93 | S46_PORTPARAMS | No | Yes |
| 94 | S46_CONT_MAPE | Yes | No |
| 95 | S46_CONT_MAPT | Yes | Yes |
| 96 | S46_CONT_LW | Yes | Yes |
| 97 | 4RD | Yes | Yes |
| 98 | 4RD_MAP_RULE | Yes | Yes |
| 99 | 4RD_NON_MAP_RULE | Yes | Yes |
| 100 | LQ_BASE_TIME | No | Yes |
| 101 | LQ_START_TIME | No | Yes |
| 102 | LQ_END_TIME | No | Yes |
| 103 | DHCP Captive-Portal | Yes | Yes |
| 104 | MPL_PARAMETERS | Yes | Yes |
| 105 | ANI_ATT | No | Yes |
| 106 | ANI_NETWORK_NAME | No | Yes |
| 107 | ANI_AP_NAME | No | Yes |
| 108 | ANI_AP_BSSID | No | Yes |
| 109 | ANI_OPERATOR_ID | No | Yes |
| 110 | ANI_OPERATOR_REALM | No | Yes |
| 111 | S46_PRIORITY | Yes | Yes |
| 112 | MUD_URL_V6 (TEMPORARY) | No | Yes |
| 113 | V6_PREFIX64 | Yes | No |
| 114 | F_BINDING_STATUS | No | (4) |
| 115 | F_CONNECT_FLAGS | No | (4) |
| 116 | F_DNS_REMOVAL_INFO | No | (4) |
| 117 | F_DNS_HOST_NAME | No | (4) |
| 118 | F_DNS_ZONE_NAME | No | (4) |
| 119 | F_DNS_FLAGS | No | (4) |
| 120 | F_EXPIRATION_TIME | No | (4) |
| 121 | F_MAX_UNACKED_BNDUPD | No | (4) |
| 122 | F_MCLT | No | (4) |
| 123 | F_PARTNER_LIFETIME | No | (4) |
| 124 | F_PARTNER_LIFETIME_SENT | No | (4) |
| 125 | F_PARTNER_DOWN_TIME | No | (4) |
| 126 | F_PARTNER_RAW_CLT_TIME | No | (4) |
| 127 | F_PROTOCOL_VERSION | No | (4) |
| 128 | F_KEEPALIVE_TIME | No | (4) |
| 129 | F_RECONFIGURE_DATA | No | (4) |
| 130 | F_RELATIONSHIP_NAME | No | (4) |
| 131 | F_SERVER_FLAGS | No | (4) |
| 132 | F_SERVER_STATE | No | (4) |
| 133 | F_START_TIME_OF_STATE | No | (4) |
| 134 | F_STATE_EXPIRATION_TIME | No | (4) |
| 143 | IPv6_ADDRESS-ANDSF | Yes | Yes |
+--------+--------------------------+---------------------+-----------+

Third, in the Site-Local Scope Multicast Addresses registry on the IPv6 Multicast Address Space Registry page located at:

https://www.iana.org/assignments/ipv6-multicast-addresses/

the entry for FF05:0:0:0:0:0:1:3 (All-dhcp-servers) will have its reference changed to [ RFC-to-be ].

Fourth, in the Link-Local Scope Multicast Addresses registry also on the IPv6 Multicast Address Space Registry page located at:

https://www.iana.org/assignments/ipv6-multicast-addresses/

the entry for FF02:0:0:0:0:0:1:2 (All-dhcp-agents) will have its reference changed to [ RFC-to-be ].

Fifth, in the Authentication Suboption (value 8) - Protocol identifier values registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

value 2 (DHCPv6 Delayed Authentication) will be marked OBSOLETE and its reference changed to [ RFC-to-be ].

Sixth, in the Protocol Name Space Values registry on the Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces registry page located at:

https://www.iana.org/assignments/auth-namespaces/

value 2 (Delayed Authentication) will be marked OBSOLETE and its reference changed to [ RFC-to-be ].

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

[Ballot comment]
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.

[Ballot comment]
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."

[Ballot comment]
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 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."

[Ballot comment]
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?

The following Last Call announcement was sent out (ends 2018-01-24):

From: The IESG
To: IETF-Announce
CC: dhc-chairs@ietf.org, Ralph Droms , rdroms.ietf@gmail.com, dhcwg@ietf.org, suresh@kaloom.com, draft-ietf-dhc-rfc3315bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) bis'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-01-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes the Dynamic Host Configuration Protocol for
  IPv6 (DHCPv6): an extensible mechanism for configuring nodes with
  network configuration parameters, IP addresses, and prefixes.
  Parameters can be provided statelessly, or in combination with
  stateful assignment of one or more IPv6 addresses and/or IPv6
  prefixes.  DHCPv6 can operate either in place of or in addition to
  stateless address autoconfiguration (SLAAC).

  This document updates the text from RFC3315, the original DHCPv6
  specification, and incorporates prefix delegation (RFC3633),
  stateless DHCPv6 (RFC3736), an option to specify an upper bound for
  how long a client should wait before refreshing information
  (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6
  service is not available (RFC7083), and clarifies the interactions
  between modes of operation (RFC7550).  As such, this document
  obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  The requested publication status is Proposed Standard.  This
  document is a revision of the DHCPv6 specification, and incorporates
  text from RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550, all of
  which are part of the core specification of DHCPv6.  While the
  original intent of the dhc WG in producing this document was to
  publish rfc3315bis as Internet Standard, there are some minor
  protocol changes from previous RFCs in rfc3315bis, and no
  implementation experience with the protocol as specified in
  rfc3315bis.

  The title page header show "Standards Track" as the intended
  status.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the Dynamic Host Configuration Protocol for
  IPv6 (DHCPv6).  It updates the text from RFC3315, the original
  DHCPv6 specification, and incorporates prefix delegation (RFC3633),
  stateless DHCPv6 (RFC3736), an option to specify an upper bound for
  how long a client should wait before refreshing information
  (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6
  service is not available (RFC7083), and clarifies the interactions
  between modes of operation (RFC7550).  As such, this document
  obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550.
 
Working Group Summary:

  The dhc WG undertook the development of rfc3315bis to move
  DHCPv6/RFC3315 to Internet Standard.  The process was scoped to do
  minimal updates to RFC 3315 and incorporate a few core followup RFCs
  into rfc3315bis for publication as an Internet Standard.  The bulk
  of the work on rfc3315bis was done be a design team, with frequent
  reports back to the full dhc WG.

  Because there are some minor protocol changes from previous RFCs in
  rfc3315bis, and no implementation experience with the protocol as
  specified in rfc3315bis, the dhc Working Group requests that
  rfc3315bis be published as Proposed Standard.

  There were no points or decisions about rfc3315bis that caused
  controversy or for which consensus was determined to be particularly
  rough.  The origin documents, RFC 3315 et al., were sufficiently
  well-written and have sufficient implementation and deployment
  experience to minimize the discussion about rfc3315bis.

Document Quality:

  Section 1 summarizes the relationship of rfc3315bis to several RFCs
  that define the current DHCPv6 specification.  Appendix A of
  rfc3315bis lists the changes in the DHCPv6 specification relative to
  RFC 3315.
 
  rfc3315bis has received significant review by the dhc Working Group
  in two Working Group last calls.  Summaries of the issues raised
  during the last calls is available at:

    https://github.com/dhcwg/rfc3315bis/blob/master/wglc-issues-draft-ietf-dhc-rfc3315bis-05.pdf
    https://github.com/dhcwg/rfc3315bis/blob/master/3315bis%20WGLC%20(draft-ietf-dhc-rfc3315bis-08)%20-%20June%202017%20-%20Sheet1.pdf

  The Acknowledgments section cites individuals who contributed
  thorough and helpful reviews.

  There are no implementations of DHCPv6 that include the changes to
  the protocol specified in rfc3315bis.  There are, of course, many
  implementations of DHCPv6 based on RFC 3315 and subsequent RFCs.
  rfc3315bis incorporates updates to the DHCPv6 specification based on
  interop tests among several DHCPv6 implementations.  At least four
  vendors are interested in updating their implementations: Cisco,
  Huawei, ISC and Nominum.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd: Ralph Droms, rdroms.ietf@gmail.com
  Area Director: Suresh Krishnan, suresh@kaloom.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has read the entire rfc3315bis document.  It
  is ready for publication. 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.  rfc3315bis has gone through multiple dhc WG last
  calls.  There were sufficient detailed reviews in the first dhc WG
  last call to warrant a subsequent last call after the issues from
  the initial last call were resolved.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  There are no sections of the document that require more detailed
  review.  Security and privacy issues were considered in detail by
  the Working Group during the work on rfc3315bis.  The consensus of
  the Working Group regarding security and privacy is reflected in
  rfc3315bis.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  All authors have replied that no IPR disclosures are required,
  to their knowledge.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is broad consensus in the dhc working group to publish this
  document.  There was significant response to the initial working
  group last call.  While there was less discussion of subsequent
  working group last calls, the bulk of the revisions to the document
  were a result of the extensive discussion following the initial last
  call.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  The Document Shepherd is not aware of any expected appeals or of any
  extreme reservations regarding publication of rfc3315bis.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  There is a disclaimer for pre-RFC5378 work because rfc3315bis
  contains significant text from RFC 3315.

  There are two references to obsoleted documents that should be
  updated.  These references (and, potentially, references to other
  newly obsoleted documents) can be updated in the next revision or
  during the RFC Editor process.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  The references are all in order (with the two exceptions as noted
  above).

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  This document will obsolete several RFCs whose contents will either
  be updated or included in this document.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  rfc3315bis does not define any new IANA registries.  It does request
  changes to some existing IANA registries to recognize the
  publication of rfc3315bis and to mark the deprecated "DHCPv6 Delayed
  Authentication" as obsolete.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  rfc3315bis does not create any new registries.  It does update some
  existing registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No reviews or automated checks were necessary.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  The requested publication status is Proposed Standard.  This
  document is a revision of the DHCPv6 specification, and incorporates
  text from RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550, all of
  which are part of the core specification of DHCPv6.  While the
  original intent of the dhc WG in producing this document was to
  publish rfc3315bis as Internet Standard, there are some minor
  protocol changes from previous RFCs in rfc3315bis, and no
  implementation experience with the protocol as specified in
  rfc3315bis.

  The title page header show "Standards Track" as the intended
  status.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the Dynamic Host Configuration Protocol for
  IPv6 (DHCPv6).  It updates the text from RFC3315, the original
  DHCPv6 specification, and incorporates prefix delegation (RFC3633),
  stateless DHCPv6 (RFC3736), an option to specify an upper bound for
  how long a client should wait before refreshing information
  (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6
  service is not available (RFC7083), and clarifies the interactions
  between modes of operation (RFC7550).  As such, this document
  obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550.
 
Working Group Summary:

  The dhc WG undertook the development of rfc3315bis to move
  DHCPv6/RFC3315 to Internet Standard.  The process was scoped to do
  minimal updates to RFC 3315 and incorporate a few core followup RFCs
  into rfc3315bis for publication as an Internet Standard.  The bulk
  of the work on rfc3315bis was done be a design team, with frequent
  reports back to the full dhc WG.

  Because there are some minor protocol changes from previous RFCs in
  rfc3315bis, and no implementation experience with the protocol as
  specified in rfc3315bis, the dhc Working Group requests that
  rfc3315bis be published as Proposed Standard.

  There were no points or decisions about rfc3315bis that caused
  controversy or for which consensus was determined to be particularly
  rough.  The origin documents, RFC 3315 et al., were sufficiently
  well-written and have sufficient implementation and deployment
  experience to minimize the discussion about rfc3315bis.

Document Quality:

  Section 1 summarizes the relationship of rfc3315bis to several RFCs
  that define the current DHCPv6 specification.  Appendix A of
  rfc3315bis lists the changes in the DHCPv6 specification relative to
  RFC 3315.
 
  rfc3315bis has received significant review by the dhc Working Group
  in two Working Group last calls.  Summaries of the issues raised
  during the last calls is available at:

    https://github.com/dhcwg/rfc3315bis/blob/master/wglc-issues-draft-ietf-dhc-rfc3315bis-05.pdf
    https://github.com/dhcwg/rfc3315bis/blob/master/3315bis%20WGLC%20(draft-ietf-dhc-rfc3315bis-08)%20-%20June%202017%20-%20Sheet1.pdf

  The Acknowledgments section cites individuals who contributed
  thorough and helpful reviews.

  There are no implementations of DHCPv6 that include the changes to
  the protocol specified in rfc3315bis.  There are, of course, many
  implementations of DHCPv6 based on RFC 3315 and subsequent RFCs.
  rfc3315bis incorporates updates to the DHCPv6 specification based on
  interop tests among several DHCPv6 implementations.  At least four
  vendors are interested in updating their implementations: Cisco,
  Huawei, ISC and Nominum.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd: Ralph Droms, rdroms.ietf@gmail.com
  Area Director: Suresh Krishnan, suresh@kaloom.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has read the entire rfc3315bis document.  It
  is ready for publication. 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.  rfc3315bis has gone through multiple dhc WG last
  calls.  There were sufficient detailed reviews in the first dhc WG
  last call to warrant a subsequent last call after the issues from
  the initial last call were resolved.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  There are no sections of the document that require more detailed
  review.  Security and privacy issues were considered in detail by
  the Working Group during the work on rfc3315bis.  The consensus of
  the Working Group regarding security and privacy is reflected in
  rfc3315bis.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  All but one of the authors have replied that no IPR disclosures are
  required, to their knowledge.  We are still waiting to hear from
  Marcin Siodelski.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is broad consensus in the dhc working group to publish this
  document.  There was significant response to the initial working
  group last call.  While there was less discussion of subsequent
  working group last calls, the bulk of the revisions to the document
  were a result of the extensive discussion following the initial last
  call.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  The Document Shepherd is not aware of any expected appeals or of any
  extreme reservations regarding publication of rfc3315bis.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  There is a disclaimer for pre-RFC5378 work because rfc3315bis
  contains significant text from RFC 3315.

  There are two references to obsoleted documents that should be
  updated.  These references (and, potentially, references to other
  newly obsoleted documents) can be updated in the next revision or
  during the RFC Editor process.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  The references are all in order (with the two exceptions as noted
  above).

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  This document will obsolete several RFCs whose contents will either
  be updated or included in this document.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  rfc3315bis does not define any new IANA registries.  It does request
  changes to some existing IANA registries to recognize the
  publication of rfc3315bis and to mark the deprecated "DHCPv6 Delayed
  Authentication" as obsolete.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  rfc3315bis does not create any new registries.  It does update some
  existing registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No reviews or automated checks were necessary.

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Sheng Jiang , Ted Lemon

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Sheng Jiang , Ted Lemon

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Sheng Jiang , Ted Lemon

Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Marcin Siodelski , Tomek Mrugalski , Timothy Winters , dhc-chairs@ietf.org, Michael Richardson , Bernie Volz , Sheng Jiang , Ted Lemon

Request for posting confirmation emailed to previous authors: "Bernie Volz" , "Tomek Mrugalski" , dhc-chairs@ietf.org, "Sheng Jiang" , "Andrew Yourtchenko" , "Timothy Winters" , "Marcin Siodelski" , "Michael Richardson" , "Ted Lemon"