Internet DRAFT - draft-asati-dhc-ipv6-autoconfig-address-tracking
draft-asati-dhc-ipv6-autoconfig-address-tracking
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]