6man
DHC Working Group                                               S. Jiang
Internet-Draft                              Huawei Technologies Co., Ltd
Intended status: Standards Track                                 G. Chen
Expires: April 25, August 29, 2013                                    China Mobile
                                                             S. Krishnan
                                                                Ericsson
                                                        October 22, 2012
                                                       February 25, 2013

      A Generic IPv6 Addresses Registration Solution Using DHCPv6
                  draft-ietf-dhc-addr-registration-01
                  draft-ietf-dhc-addr-registration-02

Abstract

   In networks that are centrally managed, self-generated addresses
   cause traceability issues due to their decentralized nature.  To
   minimize the issues due to lack of traceability, these self-generated
   addresses can be registered with the network for allowing centralized
   address administration.  This document defines a generic address
   registration solution using DHCPv6, using a new ND option and a new
   DHCPv6 option in order to communicate the use of self-generated
   addresses.  A new Addr-registration-request message type is defined
   for initiate the address registration request, among with two new
   Status codes to indicate registration errors on the server side.

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 April 25, August 29, 2013.

Copyright Notice

   Copyright (c) 2012 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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Overview of Generic Address Registration Solution . . . . . . . 3
   4.  Propagating the Address Registration Solicitation . . . . . . . 4
     4.1.  ND Address Registration Solicitation Option . . . . . . . . 5
     4.2.  DHCPv6 Address Registration Solicitation Option . . . . .  6 . 5
   5.  DHCPv6 Addr-registration-request Message  . . . . . . . . . . . 6
   6.  DHCPv6 Address Registration Procedure . . . . . . . . . . . .  7
     5.1. . 6
     6.1.  DHCPv6 Address Registration Request . . . . . . . . . . .  7
     5.2. . 6
     6.2.  DHCPv6 Address Registration Acknowledge . . . . . . . . .  8
   6. . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  8
   7. . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  8
   8. . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  9
   9. 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1. 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2. 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 10 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 10 9

1.  Introduction

   In several common network scenarios, IPv6 addresses are self-
   generated by the end-hosts using some information propogated to them
   by the network (i.e. the network prefix).  Examples of self-generated
   addresses include those created using IPv6 Stateless Address
   Configuration [RFC4862] , temporary addresses [RFC4941] and
   Cryptographically Generated Addresses (CGA) [RFC3972] etc.  These
   addresses are potentially incompatible with networks with a centrally
   managed address architecture such as DHCPv6 [RFC3315] as they lack
   traceability and stability.

   Many operators of enterprise networks and similarly tightly
   administered networks have expressed the desire to be at least aware
   of the hosts' self-generated addresses when migrating to IPv6.

   One potential way to provide network administrators with most of
   their needs while retaining compatibility with normal stateless
   configuration would be to register the self-generated addresses with
   the systems in place to centrally administer the addresses.  The host
   may be required to perform this registration in some scenarios since
   only registered IPv6 edge
   router that observes hosts' addresses may be granted access to through the network
   resources . Neighbor Discovery
   protocol is the most suitable devices to register these addresses.

   This document introduces a new IPv6 Neighbor Discovery option and a
   new DHCPv6 option to propagate the address registration information
   from the hosts solicite edge routers to the network. register addresses.
   The DHCPv6 protocol is used to perform the address registration
   procedure while the address registration server role may be performed
   by a DHCPv6 server or a stand-alone server. server, which is also considered
   as a DHCPv6 server from the DHCPv6 protocol perspective.  A new Addr-
   registration-request DHCPv6 message type is defined to initiate the
   address registration request, and two new Status codes is defined to
   indicate registration errors on the server side.

2.  Terminology

   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 [RFC2119].

3.  Overview of Generic Address Registration Solution

   In the generic address registration solution, the network management
   system solicits hosts the edge routers to register their self-generated addresses, by sending
   solicitation messages from either local upstream router (step 1a in Figure
   1) or DHCPv6 server (step 1b in Figure 1).

   After receiving such solicitations, a host an edge router implementing this
   specification and using a self-generated address SHOULD send an
   address registration request Addr-registration-request message to the
   address registration server (step 2 in Figure 1). 1, defined in Section 5
   of this document).  The address registration server may be acted by a
   DHCPv6 server.  By received the address registration request, the
   address registration server records the requested address in the
   address registration database, which MAY be used by other network
   functions, such as DNS or ACL, etc.  The address registration server
   should also assign lifetimes for the requested address.  An acknowledgement is MAY be sent
   back to the host with the assigned lifetimes edge router (step 3 in Figure 1).

       +--------+                 +------------+
       +----+   +-----------+   +---------------+
       |  Host  |                 |Local   +---------------+
       |Host|   |Edge router|   |Upstream Router|   |Addr-Reg Server|
       +--------+                 +------------+
       +----+   +-----------+   +---------------+   +---------------+
         |    ND     |                   |                  |
         |<--------->|                   |                  |
                     |                   |                  |
                     |Addr Register Solicitation(1a)| Solicitation(1a)        |
          |<-----------------------------|
                     |<------------------|                  |
                     |                                      |
                     |   Addr Register Solicitation(1b)     |
          |<------------------------------------------------|
                     |<-------------------------------------|
                     |                                      |
          |Send self-generation addr registration request(2)|
          |------------------------------------------------>|
                     |       Addr-registration-request(2)   |
                     |------------------------------------->|
                     |                                      |Register
                     | Reply acknowledgment with assigned lifetimes(3)  Acknowledgment addr registration(3) |address
          |<------------------------------------------------|
                     |<-------------------------------------|

                 Figure 1: Address Registration Procedure

   By received the acknowledgement, the host can continue use the
   registered address.  It SHOULD use the assigned preferred and valid
   lifetime for the correspondeding address.

4.  Propagating the Address Registration Solicitation

   In order to request notify the hosts with self-generated addresses to
   register their addresses and edge routers the availabilityof the appointed address
   registration
   server, service, new solicitation options are defined. needed.  There is
   more than one mechanism by which configuration parameters could be
   pushed to the end hosts. edge routers.  The address registration solicitation
   option can be carried in Router Advertisement (RA) message, which is
   broadcasted by local upstream routers.  In the DHCPv6 managed network, it
   can also be carried in DHCPv6 messages.  This document defines a new
   ND option and one a new DHCPv6 option that
   convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 of
   [RFC1035] to be used as the destination of for this purpose.  Since the
   address registration
   messages.  In order process is through the standard DHCPv6 client/
   server communication - send packets to make use of ff02::1:2, the
   All_DHCP_Relay_Agents_and_Servers multicast address, these options, this document
   assumes that appropriate name resolution mechanisms (see Section
   6.1.1 of [RFC1123] are available on
   solicitation options do not contain the host. IP address of address
   registration server.

   After receving a message containing an address registration
   solicitation option, a host an edge router implementing this specification
   SHOULD register its self-generated addresses, if any, addresses to the announced
   address registration server.  The solicitation options MAY include
   the IPv6 address(es) of address registration server.

   In principle, hosts need to receive a prefix from either RA message
   [RFC4861] or DHCPv6 message [I-D.ietf-dhc-host-gen-id] so that they
   can generate an IPv6 address by themselves.  The Address Registration
   Solicitation options are expected to be propagated along with prefix
   assignment information.

4.1.  ND Address Registration Solicitation Option

   The ND Address Registration Solicitation Option allows routers an upstream
   router to propagate the solicitation for hosts edge routers to register their self-generated
   address.  This option also carries the fully qualified domain name of
   the address registration server.  This option SHOULD be propagated
   together with the Prefix Information Option, Section 4.6.2,
   [RFC4861].
   addresses.  The format of the ND Address Registration Solicitation
   Option is described as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |  Pad Length   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                          Domain Name                          .
       .                   (Address Registration Server)               .                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                            Padding                            .
       .                                                               .
       |                           Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Fields:

       Type         TBA1

       Length       The length of the option in       1 (in units of 8 octets,
                      including the Type and Length fields. The value 0
                      is invalid. The receiver MUST discard a message
                      that contains this value.

         Pad Length   The number of padding octets beyond the end of the
                      Domain Name field but within the length specified
                      by the Length field. themselves
                    are included).

       Reserved     Padding bits. It is for For future use also. The value MUST
                    be initialized to zero by the sender, and MUST be
                    ignored by the receiver.

         Domain Name  Fully qualified domain name of the announced
                      address registration server. The domain name is
                      encoded as specified in Section 8 of [RFC3315].

         Padding      A variable-length field making the option length a
                      multiple of 8, containing as many octets as
                      specified in the Pad Length field. Padding octets
                      MUST be set to zero by senders and ignored by
                      receivers.

                ND Address Registration Solicitation Option

4.2.  DHCPv6 Address Registration Solicitation Option

   The DHCPv6 Address Registration Solicitation Option allows a DHCPv6
   server to propagate the solicitation for hosts edge routers to register their
   self-generated address.  This option also carries a domain name of
   the appointed address registration server.
   addresses.  This option SHOULD MAY be propagated together with DHCPv6 Prefix Information
   Delegation Option, Section 5,
   [I-D.ietf-dhc-host-gen-id]. [RFC3633].  The format of the DHCPv6 Address
   Registration Solicitation Option is described as follows:

        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_ADDR_REG_SOLICITATION |       option-len              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                          Domain Name                          .
      .                   (Address Registration Server)               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         option-code   OPTION_ADDR_REG_SOLICITATION (TBA2).

         option-len    0, Length of this option in octets (not including
                       option-code and option-len).

          Domain Name

               DHCPv6 Addr Registration Solicitation Option

5.  DHCPv6 Addr-registration-request Message

   A fully qualified domain name DHCPv6 client (the edge router) sends an Addr-registration-request
   message to a server to request addresses to be registered.  The
   format of the appointed
                        address registration server. The domain name Addr-registration-request message is encoded described as specified in
   follows, compliant with Section 6 in [RFC3315]:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 of
                        [RFC3315].

5. 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; (TBA3).

      transaction-id       The transaction ID for this message exchange.

      options              Options carried in this message.

                 DHCPv6 Addr-Registration-Request message

   This Addr-registration-request message MUST NOT contain server-
   identifier option and SHOULD only contain IA_NA option(s) and Client
   Identifier option.

   Clients MUST discard any received Addr-registration-request messages.
   Servers MUST discard any Addr-Registration-Request messages that do
   not include a Client Identifier option or that do include a Server
   Identifier option.

6.  DHCPv6 Address Registration Procedure

   The DHCPv6 protocol is reused as the address registration protocol
   while a DHCPv6 server can play the role of an address registration
   server.  The IA_NA DHCPv6 option [RFC3315] is reused in order to
   fulfill the address registration interactions.

5.1.

6.1.  DHCPv6 Address Registration Request

   The host with one or more self-generated addresses edge router sends a DHCPv6
   Request Addr-registration-request message to
   the address registration server received to ff02::1:2, the
   All_DHCP_Relay_Agents_and_Servers multicast address.

   The edge router MUST include a Client Identifier option in the
   address registration solicitation option. Addr-
   registration-request message to identify itself to the server.  The
   DHCPv6 Request Addr-registration-request message SHOULD contain at least one
   IA_NA option.  The IA_NA option SHOULD contain at least one IA
   Address option.  The
   host SHOULD set the T1 and T2 fields in any IA_NA options, and the
   preferred-lifetime and valid-lifetime fields in the IA Address
   options to 0.

   After receiving this address registration request, Addr-Registration-Request message, the address
   registration server MUST register the requested address address(es) in its
   address registration database, which may further be used by other
   network functions, such as DNS, network access control lists, etc.  The
   address registration server SHOULD also assign the lifetimes for
   these registered addresses.

   The centrally managed address database contains both self-generated
   addresses and the DHCPv6 assigned addresses.  They MAY be marked and
   treated differently in
   If the database.

5.2. DHCPv6 Address Registration Acknowledge

   The server does not support address registration server then sends function,
   a Reply message as the
   response to registration requests.  The DHCPv6 Reply message SHOULD
   contain at least one IA_NA option.  The IA_NA with includes a Status Code option SHOULD contain
   at least one IA Address option.  The server SHOULD set with the T1 and T2
   fields in any IA_NA options, and value the preferred-lifetime and valid-
   lifetime fields in
   RegistrationNotSupported (TBA4) MAY be sent back to the IA initiated
   client.

6.2.  DHCPv6 Address options following the rules defined
   in Section 22 of [RFC3315]. Registration Acknowledge

   After receiving the acknowledgement from the server, all the host can use addresses have been processed, the registered address registration
   server MAY send a Reply message as the response to access registration
   requests.  The server generates a Reply message and includes a Status
   Code option with value Success, a Server Identifier option with the network.  It SHOULD use
   server's DUID, and a Client Identifier option with the
   values client's DUID.
   For each IA in the preferred and valid lifetime fields of the received Release message to determine for which the preferred and valid lifetimes of server does no
   register, the
   address.

   Please note that server adds an IA option using the host MAY continue to use expired address, such
   as Upper-Layer Identifiers (ULID) IAID from the Addr-
   registration-request message, and includes a Status Code option with
   the value RegistrationDenied (TBA5) in Shim6 protocol [RFC5533], etc.
   but the network could potentially refuse IA option.  No other
   options are included in the network access from such
   addresses.

6. IA option.

7.  Security Considerations

   An attacker may use a faked address registration request option to
   indicate hosts reports their address to a malicious server and
   collect the user information.  An attacker may also register large number of fake addresses with the
   network in order to overwhelm the address registration server.  In either case, these  These
   attacks may be prevented generic DHCPv6 protection by using Secure Neighbor Discovery [RFC3971] if the RA
   Address Registration Request Option is used, and the AUTH
   option [RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] if the DHCPv6
   Address Registration Request Option is used.

7. [I-D.ietf-dhc-secure-dhcpv6].

8.  IANA Considerations

   This document defines a new IPv6 Neighbor Discovery option, the
   Address Registration Solicitation Option (TBA1) described in Section
   4.1, that requires an allocation out of the registry defined at

   http://www.iana.org/assignments/icmpv6-parameters

   This document defines a new DHCPv6 option, the
   OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that
   requires an allocation out of the registry defined at
   http://www.iana.org/assignments/dhcpv6-parameters/

8.

   This document defines a new DHCPv6 message, the Addr-registration-
   request message (TBA3) described in Section 5, that requires an
   allocation out of the registry defined at

   http://www.iana.org/assignments/dhcpv6-parameters/

   This document defines two new DHCPv6 Status code, the
   RegistrationNotSupported (TBA4) and RegistrationDenied (TBA5)
   described in Section 6, that requires an allocation out of the
   registry defined at

   http://www.iana.org/assignments/dhcpv6-parameters/

9.  Acknowledgements

   The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz Volz,
   Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten
   Carlsen, Mark Smith and other members of dhc and v6ops working group groups
   for their valuable comments.

9.

10.  References

9.1.

10.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

9.2.

10.2.  Informative References

   [I-D.ietf-dhc-host-gen-id]
              Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment in
              DHCPv6", draft-ietf-dhc-host-gen-id-04 (work in progress),
              August 2012.

   [I-D.ietf-dhc-secure-dhcpv6]
              Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
              draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
              September 2012.

Authors' Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing 100095
   P.R. China

   Email: jiangsheng@huawei.com

   Gang Chen
   China Mobile
   53A, Xibianmennei Ave., Xuanwu District, Beijing
   P.R. China

   Phone: 86-13910710674
   Email: phdgang@gmail.com

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com