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]