DHC Working Group Rajiv Asati Internet Draft Cisco Systems Intended status: Standards Track Expires: July 2013 Dan Wing Cisco Systems December 31, 2012 Tracking of Static/Autoconfigured IPv6 addresses draft-asati-dhc-ipv6-autoconfig-address-tracking-00.txt Abstract Network operators commonly use Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to the hosts, and track them. However, the tracking capability is lost when stateless autoconfiguration or manual methods are used to assign IPv6 addresses. This document proposes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) based mechanism that the last hop router can use to convey the hosts' IPv6 addresses for the tracking and logging purposes, without requiring any changes to the hosts. 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 http://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 July 2, 2013. Asati, et al. Expires July 2, 2013 [Page 1] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 Copyright Notice Copyright (c) 2013 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Scope..........................................................3 4. Protocol Operation.............................................4 4.1. Host Behavior.............................................4 4.2. Router Behavior...........................................4 4.3. DHCP Server Behavior......................................5 5. DHCP Messages and Options......................................5 5.1. DHCPv6 Messages...........................................5 5.1.1. RECORD-CLIENTBINDING message.........................6 5.1.2. RECORD-CLIENTBINDING-ACK message.....................6 5.2. DHCPv6 Options............................................7 5.2.1. CLIENT_BINDING Option................................7 6. Security Considerations........................................9 7. IANA Considerations............................................9 8. References.....................................................9 8.1. Normative References......................................9 8.2. Informative References....................................9 9. Acknowledgments...............................................10 1. Introduction As network operators leverage SLAAC (Stateless Address auto configuration) [RFC4862] or static methods to assign the IPv6 address to the hosts (e.g. subscribers/users), they can no longer track or figure out which IPv6 address is used by which host. This potentially impacts the operator's operational aspects (e.g. Asati, et al. Expires July 2, 2013 [Page 2] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 subscriber management) and forces the operators to postpone the IPv6 roll-out until all the hosts can support DHCPv6 [RFC3315]. Note that the operators rely on DHCP server's lease assignments to keep track of IP address assigned to hosts by creating the mapping of MAC address and IP address(es) pertaining to each host. This assumes DHCP support on the hosts, of course. This document describes a Dynamic Host Configuration Protocol version 6 (DHCPv6) mechanism that the first hop router (or switch) can use to convey the IPv6 addresses obtained by the hosts using stateless address autoconfiguration (SLAAC) [RFC4862] or static methods, to the DHCPv6 server for tracking and/or logging purposes. This document does NOT propose any changes to the hosts. 2. Terminology In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Scope This document caters to the following sample network topology that could be mapped to a residential broadband network topology or enterprise network topology or data center. Host11-----Node11-------Network-------Router2-----DHCP Server(s) Host12------// | Host13=======---Node12------| Figure 1 Sample Network The above topology could be illustrated a bit differently in figure 2 - Asati, et al. Expires July 2, 2013 [Page 3] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 Host11----CE11-----PE11---Network----Router2-----DHCP Server(s) Host12------// | Host13=======------PE12-----| Figure 2 Network In case of residential broadband homes, CE11 could be a residential gateway (RGW) or CPE router, whereas PE11 could be a Broadband Network Gateway (BNG) or Cable Modem Termination System (CMTS) or 3GPP Packet Data Network (PDN) Gateway aka PGW. In case of enterprise network, CE11 could be a Customer Edge Router or Switch connecting to the hosts. CE11 could also be dubbed as the requesting router. 4. Protocol Operation This section describes the protocol operation in terms of changes needed on Host, router and DHCP server. 4.1. Host Behavior This document assumes hosts' support for [RFC4861], and does not require any changes to the host behavior. Per [RFC4861], a host MUST perform Neighbor Discovery and Router Discovery as soon as IPv6 is enabled on any of its interfaces. As part of Neighbor Discovery, a host must perform DAD for each of the IPv6 addresses (unless interface-identifier is negotiated to be unique, as may be the case with IPv6 over PPP [RFC5072]). A host can have one or more IPv6 addresses belonging to one or more prefixes that it learned dynamically (i.e. SLAAC) [RFC4862] or statically. 4.2. Router Behavior The router that is connected to the hosts via zero or more layer2 switches maintains the neighbor cache, which comprises of one or more bindings between host's identifier (e.g. MAC address, interface-identifier etc.) and assigned IPv6 addresses. Asati, et al. Expires July 2, 2013 [Page 4] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 This is true even if the host to host communication does not involve the first-hop router (assuming one or more layer2 switches between router and hosts). The router periodically exports these bindings pertaining to IPv6 GUA [RFC4291] and/or ULA [RFC4193] using the RECORD_CLIENTBINDING message to the DHCPv6 server. The periodicity is decided by the lift-time of each neighbor cache entry. When the router deletes one or more neighbor cache entries for whatever reason (e.g. host disconnected), it notifies the DHCP server using the RECORD_CLIENTBINDING message with lifttime of zero for the relevant clients. The server may decide to purge those entries. The router expects the acknowledgement from the server in form of RECORD-CLIENTBINDING-ACK to ensure that the message was delivered. This is in accord with rest of the DHCPv6 messages. 4.3. DHCP Server Behavior The DHCP sever, upon receiving the RECORD-CLIENTBINDING message, records the binding between host's identifier (e.g. MAC address) and IPv6 address(es). DHCP server also records the identity of the router that sent the RECORD-CLIENTBINDING message for a given client. The DHCP server sends RECORD-CLIENTBINDING-ACK message to the router to acknowledge the receipt of the router sent information. Each binding is maintained with a lifetime and is expected to be refreshed prior to the expiration. If the server does not receive a RECORD-CLIENTBINDIG message prior to expiration, then the server deletes that binding. 5. DHCP Messages and Options 5.1. DHCPv6 Messages This section details one or more messages. Asati, et al. Expires July 2, 2013 [Page 5] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 5.1.1. RECORD-CLIENTBINDING message This message is used by the router to inform (export, really) the information (e.g. bindings) from its neighbor cache. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RECORD-CLIENTBINDING | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Client-Binding-options : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 'Record Client Binding' Message msg-type RECORD-CLIENTBINDING message (IANA TBD) transaction-id The transaction ID for this message exchange Client-Binding-options MUST include at least one 'Client Binding option' (see section 5.2) 5.1.2. RECORD-CLIENTBINDING-ACK message This message is used by the DHCPv6 server to acknowledge the receipt of RECORD-CLIENTBINDING message sent by the router. Asati, et al. Expires July 2, 2013 [Page 6] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RECORD-CLIENTBINDING-ACK| transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Client-Binding-Ack-options : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 'Record Client Binding Ack' Message msg-type RECORD-CLIENTBINDING-ACK message (IANA TBD) transaction-id The transaction ID for this message exchange Client-Binding-Ack-options None defined by this document. 5.2. DHCPv6 Options This section discusses one or more options used by the messages defined earlier. 5.2.1. CLIENT_BINDING Option This specification assumes host compliance of [RFC4861], and does not require any changes to the host behavior. Asati, et al. Expires July 2, 2013 [Page 7] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 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_CLIENT_BINDING | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Client Identifier (variable) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : IPv6 Addresses (n x 16 octets) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Client Binding Option option-code OPTION_CLIENT_BINDING (IANA allocation TBD) option-len Length, in octets Client Identifier Link-layer Address of the host. Encoded as the DUID-LL as defined in section 9.4 of [RFC3315] in case of neighbor cache entry containing host's MAC address. Lifetime Expiration time of the binding. This conveys to the DHCP server whether the binding needs to be refreshed (since host is still connected to the router) or deleted (since the host is disconnected to the router). IPv6 addresses Zero or more IPv6 addresses assigned to the same Link-layer Address of the host. Zero IPv6 address is valid only if the lifetime field equals zero. In other words, if the router intends for the server to delete all the addresses pertaining to the device identified by the client identifer, then it could do so by setting the lifetime to zero and not including any IPv6 addresses. Asati, et al. Expires July 2, 2013 [Page 8] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 6. Security Considerations None. 7. IANA Considerations This document defines two new DHCPv6 messages and one DHCPv6 option, and requests their IANA assignments. RECORD-CLIENTBINDING RECORD-CLIENTBINDING-ACK OPTION_CLIENT_BINDING 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 8.2. Informative References [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. [RFC4862] Thomson, et al., "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4861] Narten, et al., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007. [RFC5072] Varada, et al., "IP Version 6 over PPP", RFC 5072, September 2007. Asati, et al. Expires July 2, 2013 [Page 9] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 9. Acknowledgments The authors would like to thank Bernie Volz. This document was prepared using 2-Word-v2.0.template.dot. Asati, et al. Expires July 2, 2013 [Page 10] Internet-Draft Static/Stateless IPv6 Address Tracking January 2013 Authors' Addresses Rajiv Asati Cisco Systems, 7025 Kit Creek Rd, RTP, NC, 27709 Email: rajiva@cisco.com Dan Wing Cisco Systems, 821 Alder Drive, Milpitas, CA, 95035 Email: dwing@cisco.com Asati, et al. Expires July 2, 2013 [Page 11]