]> Google, LLC

warren@kumari.net

Cisco Systems, Inc.

suresh.krishnan@gmail.com

Cisco Systems, Inc.

7025 Kit Creek road Research Triangle Park 27709-4987 USA rajiva@cisco.com

Google, LLC

Shibuya 3-21-3 Japan lorenzo@google.com

Google, LLC

1 Darling Island Rd Pyrmont 2009 Australia furry@google.com

Beijing University of Posts and Telecommunications

No. 10 Xitucheng Road Beijing Haidian District 100083 China shengjiang@bupt.edu.cn

Internet Dynamic Host Configuration Internet-Draft This document defines a method to inform a DHCPv6 server that a device has a self-generated or statically configured address. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Dynamic Host Configuration Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or security purposes. Examples of this include a help desk dealing with a ticket such as "The CEO's laptop cannot connect to the printer"; if the MAC address of the printer is known (for example from an inventory system), the IPv4 address can be retrieved from the DHCP logs and the printer pinged to determine if it is reachable. Another common example is a Security Operations team discovering suspicious events in outbound firewall logs and then consulting DHCP logs to determine which employee's laptop had that IPv4 address at that time so that they can quarantine it and remove the malware. This operational practice relies on the DHCP server knowing the IP address assignments. Therefore, the practice does not work if static IP addresses are manually configured on devices or self-assigned addresses (such as when self-configuring an IPv6 address using SLAAC ) are used. The lack of this parity with IPv4 is one of the reasons which may be hindering IPv6 deployment, especially in enterprise networks. This document provides a mechanism for a device to inform the DHCPv6 server that it has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4 in this aspect.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Registration Mechanism Overview The DHCPv6 protocol is used as the address registration protocol when a DHCPv6 server performs the role of an address registration server. The DHCPv6 IA Address option is used to specify the address to be registered. After successfully assigning a self-generated IPv6 address on one of its interfaces, a client implementing this specification SHOULD multicast an ADDR-REG-INFORM message in order to inform the DHCPv6 server that this self-generated address is in use (as shown in Fig.1).

Address Registration Procedure | | | | | | | ADDR-REG-INFORM | |------------------------------------------------->| | | |Register / log | | ADDR-REG-REPLY |address |<------------------------------------------------- ]]>

DHCPv6 Address Registration Procedure

DHCPv6 Address Registration Request The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is in use. The format of the ADDR-REG-INFORM message is described as follows:

DHCPv6 ADDR-REG-INFORM message

The client MUST generate a transaction ID and insert this value in the "transaction-id" field. The client MUST include a Client Identifier option in the ADDR-REG-INFORM message. The ADDR-REG-INFORM message MUST NOT contain the Server Identifier option and MUST contain exactly one IA Address option containing the address being registered. The valid-lifetime and preferred-lifetime fields in the option MUST match the current Valid Lifetime and Preferred Lifetime of the address being registered. The ADDR-REG-INFORM message is dedicated for clients to initiate an address registration request toward an address registration server. Consequently, clients MUST NOT put any Option Request Option(s) in the ADDR-REG-INFORM message. Clients MAY include other options, such as the Client FQDN Option . The client sends the DHCPv6 ADDR-REG-INFORM message to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The client MUST send separate messages for each address being registered. Unlike other types of messages, which are sent from the link-local address of the client, then ADDR-REG-INFORM message MUST be sent from the address being registered. This is primarily for "fate sharing" purposes - for example, if the network implements some form of L2 security to prevent a client from spoofing other clients' addresses this prevents an attacker from spoofing ADDR-REG-INFORM messages. On clients with multiple interfaces, the client MUST only send the packet on the network interface that has the address being registered, even if it has multiple interfaces with different addresses. If the same address is configured on multiple interfaces, then the client MUST send ADDR-REG-INFORM each time the address is configured on an interface that did not previously have it, and refresh each registration independently from the others. The client MUST only send the ADDR-REG-INFORM message for valid () addresses of global scope (). This includes ULA addresses, which are defined in to have global scope. The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6. The client SHOULD NOT send the ADDR-REG-INFORM message if it has not received any Router Advertisement message with either M or O flags set to 1. Clients MUST discard any received ADDR-REG-INFORM messages.

Server message processing Servers MUST discard any ADDR-REG-INFORM messages that meet any of the following conditions:

• the message does not include a Client Identifier option;
• the message includes a Server Identifier option;
• the message does not include the IA Address option, or the IP address in the IA Address option does not match the source address of the original ADDR-REG-INFORM message sent by the client.
• the message includes an Option Request Option.

After receiving this ADDR-REG-INFORM message, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by . If the server believes that the address being registered is not appropriate to the link , it MUST drop the message, and SHOULD log this fact. Otherwise, the server:

• SHOULD register or update a binding between the provided Client Identifier and IPv6 address in its database. If there is already a binding between the registered address and another another client, the server SHOULD log the fact and update the binding.
• SHOULD log the address registration information (as is done normally for clients which have requested an address), unless configured not to do so.
• SHOULD mark the address as unavailable for use and not include it in future ADVERTISE messages.
• SHOULD send back an ADDR-REG-REPLY message.

DHCPv6 relay agents and switches that relay address registration messages directly from clients SHOULD include the client's link-layer address in the relayed message using the Client Link-Layer Address option ().

DHCPv6 Address Registration Acknowledgement The server SHOULD acknowledge receipt of a valid ADDR-REG-INFORM message by sending a ADDR-REG-REPLY message back. The format of the ADDR-REG-REPLY message is described as follows:

DHCPv6 ADDR-REG-REPLY message

If the ADDR-REG-INFORM message that the server is replying to was not relayed, then the IPv6 destination address of the message MUST be the address being registered. If the ADDR-REG-INFORM message was relayed, then the server MUST construct the Relay-reply message as specified in section 19.3. The server MUST copy the transaction-id from the ADDR-REG-INFORM message to the transaction-id field of the ADDR-REG-REPLY. The ADDR-REG-REPLY message MUST contain an IA Address option for the address being registered. The option MUST be identical to the one in the ADDR-REG-INFORM message that the server is replying to. Servers MUST ignore any received ADDR-REG-REPLY messages. Clients MUST discard any ADDR-REG-REPLY messages that meet any of the following conditions:

• The IPv6 destination address does not match the address being registered.
• The IA-Address option does not match the address being registered.
• The address being registered is not assigned to the interface receiving the message.
• The transaction-id does not match the transaction-id the client used in the corresponding ADDR-REG-INFORM message.

The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM message has been received. The ADDR-REG-REPLY message MUST NOT be considered as any indication of the address validity and MUST NOT be required for the address to be usable. DHCPv6 relays, or other devices that snoop ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or security state based on the ADDR-REG-REPLY message.

Registration Expiry and Refresh The client MUST refresh the registration every AddrRegRefresh seconds, where AddrRegRefresh is min(1/3 of the Valid Lifetime filed in the very first PIO received to form the address; 4 hours). Registration refresh packets SHOULD be retransmitted using the same logic as described in the 'Retransmission' section below. In particular, retransmissions SHOULD be jittered to avoid synchronization causing a large number of registrations to expire at the same time. The client SHOULD generate a new transaction ID when refreshing the registration. If the address registration server does not receive such a refresh after the Valid Lifetime has passed, it SHOULD remove the record of the Client-Identifier-to-IPv6-address binding. The client MAY choose to notify the server when an address is no longer being used (e.g., if the client is disconnecting from the network, the address lifetime expired, or the address is being removed from the interface). To indicate that the address is not being used anymore the client MUST set the preferred-lifetime and valid-lifetime fields of the IA Address option to zero. If the server receives a message with a valid-lifetime of zero, it SHOULD act as if the address has expired.

Retransmission To reduce the effects of packet loss on registration, the client SHOULD retransmit the registration message. Retransmissions SHOULD follow the standard retransmission logic specified by section 15 of with the following default parameters:

• IRT 1 sec
• MRC 3

The client SHOULD allow these parameters to be configured by the administrator. To comply with section 16.1 of , the client MUST leave the transaction ID unchanged in retransmissions of an ADDR-REG-INFORM message. If an ADDR-REG-REPLY message is received for the address being registered, the client MUST stop retransmission. However, the client cannot rely on the server acknowledging receipt of the registration message, because the server might not support address registration.

Host configuration DHCP clients SHOULD allow the administrator to disable sending ADDR-REG-INFORM messages. This could be used, for example, to reduce network traffic on networks where the servers are known not to support the message type. Sending the messages SHOULD be enabled by default.

Security Considerations An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration server and / or fill up log files. Similar attack vectors exist today, e.g. an attacker can DoS the server with messages contained spoofed DUIDs. If a network is using FCFS SAVI , then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a host from registering an address owned by another host. One of the use-cases for the mechanism described in this document is to identify sources of malicious traffic after the fact. Note, however, that as the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised device can simply not send the ADDR-REG-INFORM message. This is an informational, optional mechanism, and is designed to aid in troubleshooting and forensics. On its own, it is not intended to be a strong security access mechanism. In particular, the ADDR-REG-INFORM message MUST not be used for authentication and authorization purposes, because in addition to the reasons above, the packets containing the message may be dropped.

IANA Considerations This document defines two new DHCPv6 messages, ADDR-REG-INFORM message (TBA1) described in Section 4, and ADDR-REG-REPLY (TBA2) described in Section 5, that requires an allocation out of the registry of Message Types defined at http://www.iana.org/assignments/dhcpv6-parameters/.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK] This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option. 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 RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK] Informative References This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]

Acknowledgments Much thanks to Bernie Volz for significant review and feedback, as well as Hermin Anggawijaya, Stuart Cheshire, Alan DeKok, Ryan Globus, Erik Kline, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Jim Reid, Michael Richardson, Mark Smith, Eric Vynke, Timothy Winter for their feedback, comments and guidance. This document borrows heavily from a previous document, draft-ietf-dhc-addr-registration, which defined "a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server". That document was written Sheng Jiang, Gang Chen, Suresh Krishnan, and Rajiv Asati.

Contributors China Mobile

53A, Xibianmennei Ave. Xuanwu District Beijing P.R. China phdgang@gmail.com