Registering Self-generated IPv6 Addresses using DHCPv6

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 17 November 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or forensics 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 printer's IPv4 address can be retrieved from the DHCP log or lease table 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. This works quite well for IPv4 addresses, as most addresses are either assigned by DHCP [RFC2131] or statically configured by the network operator. For IPv6, however, this practice is much harder to implement, as devices often self-configure IPv6 addresses via SLAAC [RFC4862].¶

This document provides a mechanism for a device to inform the DHCPv6 server that the device has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4, by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. 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. This document introduces a new Address Registration (OPTION_ADDR_REG_ENABLE) option which indicates that the server supports the registration mechanism. Before registering any addresses, the client MUST determine whether the network supports address registration. It can do this by including the Address Registration option code in the Option Request option (see Section 21.7 of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or Rebind messages it sends to the server as part of the regular stateless or stateful DHCPv6 configuration process. If the server supports address registration, it includes an Address Registration option in its Advertise or Reply messages. To avoid undesired multicast traffic, if the DHCPv6 infrastructure does not support (or is not willing to receive) any address registration information, the client MUST NOT register any addresses using the mechanism in this specification. Otherwise, the client registers addresses as described below.¶

After successfully assigning a self-generated or statically configured Valid ([RFC4862]) IPv6 address on one of its interfaces, a client implementing this specification multicasts an ADDR-REG-INFORM message (see Section 4.2) in order to inform the DHCPv6 server that this self-generated address is in use. Each ADDR-REG-INFORM message contains a DHCPv6 IA Address option [RFC8415] to specify the address being registered.¶

The address registration mechanism overview is shown in Fig.1.¶

+--------+        +------------------+       +---------------+
| CLIENT |        | FIRST-HOP ROUTER |       | DHCPv6 SERVER |
+--------+        +---------+--------+       +-------+-------+
    |      SLAAC            |                        |
    |<--------------------> |                        |
    |                       |                        |
    |                                                |
    |  src: link-local address                       |
    | -------------------------------------------->  |
    |    INFORMATION-REQUEST or SOLICIT/...          |
    |       - OPTION REQUEST OPTION                  |
    |          -- OPTION_ADDR_REG_ENABLE             |
    |                                                |
    |    ...                                         |
    |                                                |
    |                                                |
    |<---------------------------------------------  |
    |     REPLY or ADVERTISE MESSAGE                 |
    |       - OPTION_ADDR_REG_ENABLE                 |
    |                                                |
    |                                                |
    |  src: address being registered                 |
    | -------------------------------------------->  |
    |    ADDR-REG-INFORM MESSAGE                     |Register/
    |                                                |log addresses
    |                                                |
    |                                                |
    | <--------------------------------------------  |
    |        ADDR-REG-REPLY MESSAGE                  |
    |                                                |

Figure 1: Address Registration Procedure Overview¶

4. DHCPv6 Address Registration Procedure

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          option-code          |           option-len          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 option-code           OPTION_ADDR_REG_ENABLE (TBA0)

 option-len            0

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    msg-type   |               transaction-id                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 .                            options                            .
 .                           (variable)                          .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  msg-type             Identifies the DHCPv6 message type;
                       Set to ADDR-REG-INFORM (TBA1).

  transaction-id       The transaction ID for this message exchange.

  options              Options carried in this message.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    msg-type   |               transaction-id                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 .                            options                            .
 .                           (variable)                          .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  msg-type             Identifies the DHCPv6 message type;
                       Set to ADDR-REG-REPLY (TBA2).

  transaction-id       The transaction ID for this message exchange.

  options              Options carried in this message.

5. Client 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.¶

6. 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 containing spoofed DHCP Unique Identifiers (DUIDs) [RFC8415].¶

If a network is using FCFS SAVI [RFC6620], then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a client from registering an address configured on another client.¶

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.¶

7. Privacy Considerations

If the network doesn't have MLD snooping enabled, then IPv6 link-local multicast traffic is effectively transmitted as broadcast. In such networks, an on-link attacker listening to DHCPv6 messages might obtain information about IPv6 addresses assigned to the client. As ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID, the attacker may be able to track addresses being registered and map them to the same client, even if the client uses randomized MAC addresses. This privacy consideration is not specific to the proposed mechanism. Section 4.3 of [RFC7844] discusses using the DUID for device tracking in DHCPv6 environments and provides mitigation recommendations.¶

In general, hiding information about the specific IPv6 address from on-link observers should not be considered a security measure, as such information is usually disclosed via Duplicate Address Detection [RFC4862] to all nodes anyway, if MLD snooping is not enabled.¶

If MLD snooping is enabled, an attacker might be able to join the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to listen for address registration messages. However, the same result can be achieved by joining the All Routers Address (ff02::2) group and listen to Gratuitous Neighbor Advertisement messages [RFC9131]. It should be noted that this particular scenario shares the fate with DHCPv6 address assignment: if an attacker can join the All_DHCP_Relay_Agents_and_Servers multicast group, they would be able to monitor all DHCPv6 messages sent from the client to DHCPv6 servers and relays, and therefore obtain the information about addresses being assigned via DHCPv6. Layer 2 isolation allows mitigating this threat by blocking onlink peer-to-peer communication between nodes.¶

8. IANA Considerations

This document introduces the following new entities which require an allocation out of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group defined at http://www.iana.org/assignments/dhcpv6-parameters/:¶

• one new DHCPv6 option, described in Section 4.1 which requires an allocation out of the Option Codes registry:¶

  • Value: TBA0¶

  • Description: OPTION_ADDR_REG_ENABLE¶

  • Client ORO: Yes¶

  • Singleton Option: Yes¶

  • Reference: This document (draft-ietf-dhc-addr-notification)¶

• two new DHCPv6 messages which require an allocation out of the Message Types registry:¶

  • ADDR-REG-INFORM message (TBA1) described in Section 4.2¶

  • ADDR-REG-REPLY (TBA2) described in Section 4.3.¶

  • Reference: This document (draft-ietf-dhc-addr-notification)¶

Acknowledgments

Many thanks to Bernie Volz for significant review and feedback, as well as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian Carpenter, Stuart Cheshire, Roman Danyliw, Alan DeKok, James Guichard, James Guichard, Erik Kline, Mallory Knodel, Murray Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, Gunter Van de Velde, Eric Vyncke, Timothy Winters, Peter Yee for their feedback, comments and guidance. We apologize if we inadvertently forgot to acknowledge anyone's contributions.¶

Contributors

Authors' Addresses