RFC 8415
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Pages: 154
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Part 13 of 14 – Pages 130 to 145
22. Security Considerations
This section discusses security considerations that are not related to privacy. See Section 23 for a discussion dedicated to privacy. The threat to DHCP is inherently an insider threat (assuming a properly configured network where DHCP ports are blocked on the perimeter gateways of the enterprise). Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same. DHCP lacks end-to-end encryption between clients and servers; thus, hijacking, tampering, and eavesdropping attacks are all possible as a result. Some network environments (discussed below) can be secured through various means to minimize these attacks. One attack specific to a DHCP client is the establishment of a malicious server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to mount a "man in the middle" attack that causes the client to communicate with a malicious server instead of a valid server for some service (such as DNS or NTP). The malicious server may also mount a DoS attack through misconfiguration of the client; this attack would cause all network communication from the client to fail. A malicious DHCP server might cause a client to set its SOL_MAX_RT and INF_MAX_RT parameters to an unreasonably high value with the SOL_MAX_RT (see Section 21.24) and INF_MAX_RT (see Section 21.25) options; this may cause an undue delay in a client completing its DHCP protocol transaction in the case where no other valid response is received. Assuming that the client also receives a response from a valid DHCP server, large values for SOL_MAX_RT and INF_MAX_RT will not have any effect. A malicious server can also send a Server Unicast option (see Section 21.12) to a client in an Advertise message, thus potentially causing the client to bypass relays and communicate only with the malicious server for subsequent Request and Renew messages. Another threat to DHCP clients originates from mistakenly or accidentally configured DHCP servers that answer DHCP client requests with unintentionally incorrect configuration parameters. A DHCP client may also be subject to attack through the receipt of a Reconfigure message from a malicious server that causes the client to obtain incorrect configuration information from that server. Note that although a client sends its response (Renew, Rebind, or Information-request message) through a relay agent and, therefore,
that response will only be received by servers to which DHCP messages are relayed, a malicious server could send a Reconfigure message to a client, followed (after an appropriate delay) by a Reply message that would be accepted by the client. Thus, a malicious server that is not on the network path between the client and the server may still be able to mount a Reconfigure attack on a client. The use of transaction IDs that are cryptographically sound and cannot easily be predicted will also reduce the probability that such an attack will be successful. Because of the opportunity for attack through the Reconfigure message, a DHCP client MUST discard any Reconfigure message that does not include authentication or that does not pass the validation process for the authentication protocol. RKAP, described in Section 20.4, provides protection against the use of a Reconfigure message by a malicious DHCP server to mount a DoS or man-in-the-middle attack on a client. This protocol can be compromised by an attacker that can intercept the initial message in which the DHCP server sends the key "in plain text" to the client. Many of these attacks by rogue servers can be mitigated by making use of the mechanisms described in [RFC7610] and [RFC7513]. The threat specific to a DHCP server is an invalid client masquerading as a valid client. The motivation for this may be for theft of service, or to circumvent auditing for any number of nefarious purposes. The threat common to both the client and the server is the "resource- exhaustion" DoS attack. These attacks typically involve the exhaustion of available assigned addresses or delegatable prefixes, or the exhaustion of CPU or network bandwidth, and are present any time there is a shared resource. Some forms of these exhaustion attacks can be partially mitigated by appropriate server policy, e.g., limiting the maximum number of leases any one client can get. The messages exchanged between relay agents and servers may be used to mount a man-in-the-middle or DoS attack. Communication between a server and a relay agent, and communication between relay agents, can be authenticated and encrypted through the use of IPsec, as described in [RFC8213].
However, the use of manually configured pre-shared keys for IPsec
between relay agents and servers does not defend against replayed
DHCP messages. Replayed messages can represent a DoS attack through
exhaustion of processing resources but not through misconfiguration
or exhaustion of other resources such as assignable addresses and
delegatable prefixes.
Various network environments also offer levels of security if
deployed as described below.
- In enterprise and factory networks, use of authentication per
[IEEE-802.1x] can prevent unknown or untrusted clients from
connecting to the network. However, this does not necessarily
assure that the connected client will be a good DHCP or network
actor.
- For wired networks where clients typically are connected to a
switch port, snooping DHCP multicast (or unicast) traffic becomes
difficult, as the switches limit the traffic delivered to a port.
The client's DHCP multicast packets (with destination address
fe02::1:2) are only forwarded to the DHCP server's (or relay's)
switch port -- not all ports. Also, the server's (or relay's)
unicast replies are only delivered to the target client's port --
not all ports.
- In public networks (such as a Wi-Fi network in a coffee shop or
airport), it is possible for others within radio range to snoop
DHCP and other traffic. But in these environments, there is very
little if anything that can be learned from the DHCP traffic
itself (either from client to server or from server to client) if
the privacy considerations provided in Section 23 are followed.
Even for devices that do not follow the privacy considerations,
there is little that can be learned that would not be available
from subsequent communications anyway (such as the device's Media
Access Control (MAC) address). Also, because all clients will
typically receive similar configuration details, a bad actor that
initiates a DHCP request itself can learn much of such
information. As mentioned above, one threat is that the RKAP key
for a client can be learned (if the initial
Solicit/Advertise/Request/Reply exchange is monitored) and trigger
a premature reconfiguration, but this is relatively easily
prevented by disallowing direct client-to-client communication on
these networks or using [RFC7610] and [RFC7513].
23. Privacy Considerations
For an extended discussion about privacy considerations for the client, see [RFC7824]: - In particular, its Section 3 discusses various identifiers that could be misused to track the client. - Its Section 4 discusses existing mechanisms that may have an impact on a client's privacy. - Finally, its Section 5 discusses potential attack vectors. For recommendations regarding how to address or mitigate those issues, see [RFC7844]. This specification does not define any allocation strategies for servers. Implementers are expected to develop their own algorithm for the server to choose a resource out of the available pool. Several possible allocation strategies are mentioned in Section 4.3 of [RFC7824]. Please keep in mind that the list in [RFC7824] is not exhaustive; there are certainly other possible strategies. Readers are also encouraged to read [RFC7707] -- in particular, its Section 4.1.2, which discusses the problems with certain allocation strategies.24. IANA Considerations
This document does not define any new DHCP name spaces or definitions. The publication of this document does not change the assignment rules for new values for message types, option codes, DUID types, or status codes. The list of assigned values used in DHCPv6 is available at <https://www.iana.org/assignments/dhcpv6-parameters>. IANA has updated <https://www.iana.org/assignments/dhcpv6-parameters> to add a reference to this document for definitions previously created by [RFC3315], [RFC3633], [RFC4242], and [RFC7083]. IANA has added two columns to the DHCPv6 "Option Codes" registry at <https://www.iana.org/assignments/dhcpv6-parameters> to indicate which options are allowed to appear in a client's Option Request option (see Section 21.7) and which options are singleton options
(only allowed to appear once as a top-level or encapsulated option; see Section 16 of [RFC7227]). Table 4 provides the data for the options assigned by IANA at the time of writing this document. +---------+--------------------------+------------------+-----------+ | 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 | No | 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 | IPv6_Address-MoS | Yes | Yes |
| 55 | 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 | No |
| 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 | No | Yes |
| 113 | V6_PREFIX64 | Yes | No |
| 114 | F_BINDING_STATUS | No | Yes |
| 115 | F_CONNECT_FLAGS | No | Yes |
| 116 | F_DNS_REMOVAL_INFO | No | Yes |
| 117 | F_DNS_HOST_NAME | No | Yes |
| 118 | F_DNS_ZONE_NAME | No | Yes |
| 119 | F_DNS_FLAGS | No | Yes |
| 120 | F_EXPIRATION_TIME | No | Yes |
| 121 | F_MAX_UNACKED_BNDUPD | No | Yes |
| 122 | F_MCLT | No | Yes |
| 123 | F_PARTNER_LIFETIME | No | Yes |
| 124 | F_PARTNER_LIFETIME_SENT | No | Yes |
| 125 | F_PARTNER_DOWN_TIME | No | Yes |
| 126 | F_PARTNER_RAW_CLT_TIME | No | Yes |
| 127 | F_PROTOCOL_VERSION | No | Yes |
| 128 | F_KEEPALIVE_TIME | No | Yes |
| 129 | F_RECONFIGURE_DATA | No | Yes |
| 130 | F_RELATIONSHIP_NAME | No | Yes |
| 131 | F_SERVER_FLAGS | No | Yes |
| 132 | F_SERVER_STATE | No | Yes |
| 133 | F_START_TIME_OF_STATE | No | Yes |
| 134 | F_STATE_EXPIRATION_TIME | No | Yes | | 135 | RELAY_PORT | No | Yes | | 143 | IPv6_Address-ANDSF | Yes | Yes | +---------+--------------------------+------------------+-----------+ Table 4: Updated Options Notes for Table 4: (1) In the "Client ORO" column, a "Yes" for an option means that the client includes this option code in the Option Request option (see Section 21.7) if it desires that configuration information, and a "No" means that the option MUST NOT be included (and servers SHOULD silently ignore that option code if it appears in a client's Option Request option). (2) For each Enterprise Number, there MUST only be a single instance. (3) See [RFC7598] for details. IANA has corrected the range of possible status codes in the "Status Codes" table at <https://www.iana.org/assignments/dhcpv6-parameters> by replacing 23-255 (as Unassigned) with 23-65535 (the codes are 16-bit unsigned integers). IANA has updated the All_DHCP_Relay_Agents_and_Servers (ff02::1:2) and All_DHCP_Servers (ff05::1:3) table entries in the "IPv6 Multicast Address Space Registry" at <https://www.iana.org/assignments/ ipv6-multicast-addresses> to reference this document instead of [RFC3315]. IANA has added an "Obsolete" annotation in the "DHCPv6 Delayed Authentication" entry in the "Authentication Suboption (value 8) - Protocol identifier values" registry at <https://www.iana.org/assignments/bootp-dhcp-parameters> and has added an "Obsolete" annotation in the "Delayed Authentication" entry in the "Protocol Name Space Values" registry at <https://www.iana.org/assignments/auth-namespaces>. IANA has also updated these pages to reference this document instead of [RFC3315]. IANA has added a reference to this document for the RDM value of 0 to the "RDM Name Space Values" registry at <https://www.iana.org/assignments/auth-namespaces>.
IANA has updated the "Service Name and Transport Protocol Port Number Registry" at <https://www.iana.org/assignments/ service-names-port-numbers> as follows: 546/udp This document 547/udp This document 547/tcp [RFC5460] 647/tcp [RFC8156]25. Obsoleted Mechanisms
This specification is mostly a corrected and cleaned-up version of the original specification -- [RFC3315] -- along with numerous additions from later RFCs. However, there are a small number of mechanisms that were not widely deployed, were underspecified, or had other operational issues. Those mechanisms are now considered deprecated. Legacy implementations MAY support them, but implementations conformant to this document MUST NOT rely on them. The following mechanisms are now obsolete: Delayed authentication. This mechanism was underspecified and presented a significant operational burden. As a result, after 10 years its adoption was extremely limited at best. Lifetime hints sent by a client. Clients used to be allowed to send lifetime values as hints. This mechanism was not widely implemented, and there were known misimplementations that sent the remaining lifetimes rather than total desired lifetimes. That in turn was sometimes misunderstood by servers as a request for ever-decreasing lease lifetimes, which caused issues when values started approaching zero. Clients now SHOULD set lifetimes to 0 in IA Address and IA Prefix options, and servers MUST ignore any requested lifetime value. T1/T2 hints sent by a client. These had issues similar to those for the lifetime hints. Clients now SHOULD set the T1/T2 values to 0 in IA_NA and IA_PD options, and servers MUST ignore any T1/T2 values supplied by a client.
26. References
26.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <https://www.rfc-editor.org/info/rfc6221>. [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10.17487/RFC6355, August 2011, <https://www.rfc-editor.org/info/rfc6355>. [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, <https://www.rfc-editor.org/info/rfc7283>. [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged between Servers and Relay Agents", RFC 8213, DOI 10.17487/RFC8213, August 2017, <https://www.rfc-editor.org/info/rfc8213>.26.2. Informative References
[IANA-HARDWARE-TYPES] IANA, "Hardware Types", <https://www.iana.org/assignments/arp-parameters>. [IANA-PEN] IANA, "Private Enterprise Numbers", <https://www.iana.org/assignments/enterprise-numbers>. [IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", <https://www.iana.org/assignments/ipv6-interface-ids>. [IEEE-802.1x] IEEE, "IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control", IEEE 802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813, <https://ieeexplore.ieee.org/servlet/ opac?punumber=5409757>. [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, DOI 10.17487/RFC3162, August 2001, <https://www.rfc-editor.org/info/rfc3162>. [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, DOI 10.17487/RFC3290, May 2002, <https://www.rfc-editor.org/info/rfc3290>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <https://www.rfc-editor.org/info/rfc3633>. [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004, <https://www.rfc-editor.org/info/rfc3736>. [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, <https://www.rfc-editor.org/info/rfc3769>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>. [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 2005, <https://www.rfc-editor.org/info/rfc4242>. [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, DOI 10.17487/RFC4477, May 2006, <https://www.rfc-editor.org/info/rfc4477>. [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, <https://www.rfc-editor.org/info/rfc4704>. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>. [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, DOI 10.17487/RFC4943, September 2007, <https://www.rfc-editor.org/info/rfc4943>. [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, "DHCPv6 Relay Agent Echo Request Option", RFC 4994, DOI 10.17487/RFC4994, September 2007, <https://www.rfc-editor.org/info/rfc4994>. [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <https://www.rfc-editor.org/info/rfc5007>. [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, <https://www.rfc-editor.org/info/rfc5453>. [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <https://www.rfc-editor.org/info/rfc5460>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) Server Option for DHCPv6", RFC 5908, DOI 10.17487/RFC5908, June 2010, <https://www.rfc-editor.org/info/rfc5908>. [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, DOI 10.17487/RFC6422, December 2011, <https://www.rfc-editor.org/info/rfc6422>. [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, <https://www.rfc-editor.org/info/rfc6603>. [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, <https://www.rfc-editor.org/info/rfc6879>. [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, May 2013, <https://www.rfc-editor.org/info/rfc6939>. [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 2013, <https://www.rfc-editor.org/info/rfc7083>. [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>. [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <https://www.rfc-editor.org/info/rfc7341>. [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>. [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>. [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and Recommendations with Multiple Stateful DHCPv6 Options", RFC 7550, DOI 10.17487/RFC7550, May 2015, <https://www.rfc-editor.org/info/rfc7550>. [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <https://www.rfc-editor.org/info/rfc7598>. [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>. [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <https://www.rfc-editor.org/info/rfc7707>. [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>. [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>. [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP Configuration on the Basis of Network Topology", RFC 7969, DOI 10.17487/RFC7969, October 2016, <https://www.rfc-editor.org/info/rfc7969>. [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", RFC 8156, DOI 10.17487/RFC8156, June 2017, <https://www.rfc-editor.org/info/rfc8156>. [RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, <https://www.rfc-editor.org/info/rfc8168>. [TR-187] Broadband Forum, "TR-187 - IPv6 for PPP Broadband Access", February 2013, <https://www.broadband-forum.org/ technical/download/TR-187_Issue-2.pdf>.
(next page on part 14)