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

      A Generic IPv6 Addresses Registration Solution Using DHCPv6
                draft-ietf-dhc-addr-registration-00.txt
                  draft-ietf-dhc-addr-registration-01

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.

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 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 November 8, 2012. April 25, 2013.

Copyright Notice

   Copyright (c) 2012 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.

Abstract

   In the IPv6 address allocation scenarios, host self-generated
   addresses are notionally conflicted with the network managed address
   architecture. These addresses need to be registered in the networking
   management plate for the purposes of central address administration.
   This document introduces a generic address registration solution
   using DHCPv6, and defines one new ND option and one new DHCPv6 option
   in order to propagate the solicitations of registering self-generated
   addresses. The registration procedure reuses the existing IA_NA in
   the DHCPv6 protocol.

Table of Contents

   1.  Introduction & Requirements .................................. . . . . . . . . . . . . . . . . . . . . . . . . .  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 ......... 7  . . . . .  6
   5.  DHCPv6 Address Registration Procedure ........................  . . . . . . . . . . . .  7
     5.1.  DHCPv6 Address Registration Request .....................  . . . . . . . . . . .  7
     5.2.  DHCPv6 Address Registration Acknowledge .................  . . . . . . . . .  8
   6.  Security Considerations ......................................  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations .......................................... 9  . . . . . . . . . . . . . . . . . . . . .  8
   8. Acknowledgments ..............................................  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References ................................................... . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References .................................... . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References ................................. . . . . . . . . . . . . . . . . . . 10
   Author's
   Authors' Addresses ............................................. . . . . . . . . . . . . . . . . . . . . . . . . 10

1.  Introduction & Requirements

   In the IPv6 address allocation several common network scenarios, there IPv6 addresses are many host self-
   generated addresses, such as by the end-hosts using some information propogated to them
   by the network (i.e. the network prefix).  Examples of self-generated
   addresses in include those created using IPv6 Stateless Address
   Configuration [RFC4862, RFC4941] scenario [RFC4862] , temporary addresses [RFC4941] and
   Cryptographically Generated Addresses (CGA, [RFC3972]), and (CGA) [RFC3972] etc.  These
   addresses are
   notionally conflicted potentially incompatible with the network networks with a centrally
   managed address architecture, architecture such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6,
   [RFC3315]) managed network or network with Access Control List. 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 moving migrating to IPv6. Furthermore, they may want
   to stop the usage of some hosts' addresses for various reasons.

   A useful

   One potential way to give provide network administrators with most of what they want,
   their needs while at the same time retaining compatibility with normal stateless
   configuration would be: if be to register the self-generated IPv6 addresses are
   used, they may need to be registered with
   the systems in place to centrally administer the networking management
   plate. addresses.  The host
   may be required to perform this registration in some scenarios since
   only registered IPv6 addresses may be granted access to the network
   resources in
   some scenarios.

   In order to fulfill the abovementioned practice, this .

   This document introduces a new IPv6 Neighbor Discovery (ND) option and a
   new DHCPv6 option to propagate the address registration solicitation information
   from
   network management the hosts to hosts. the network.  The DHCPv6 protocol is suitable used to
   perform the address registration procedure while the address
   registration server role may play be performed by a DHCPv6 server or a
   stand-alone server. The
   existing IA_NA in the DHCPv6 protocol is reused for the registration
   procedure.

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

3.  Overview of Generic Address Registration Solution

   By current default, the hosts with self-generated addresses do not
   register their addresses to any network devices. However, this may
   result that the network may reject the access request from these
   devices if the address registration is requested.

   As showed in below Figure 1, in

   In the generic address registration solution, proposed by this document, the network management plate
   firstly propagates the solicitations of registering
   system solicits hosts to register their self-generated addresses, by
   sending solicitation messages from either local router (step 1a in
   Figure 1) or DHCPv6 server (step 1b in Figure 1).

   By received

   After receiving such solicitations, a host implementing this
   specification and using the a self-generated address SHOULD send an
   address registration request message to the address registration
   server (step 2 in Figure 1).  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 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 sent back to the host with the assigned lifetimes
   (step 3 in Figure 1).

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

                 Figure 1: address registration procedure 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 corresponded correspondeding address.

4.  Propagating the Address Registration Solicitation

   In order to indicate or force request the hosts with self-generated addresses to
   register their addresses and the appointed address registration
   server, new solicitation options need to be are defined.

   There are is more than one mechanism in by which configuration parameters
   could be pushed to the end hosts.  The address registration
   solicitation option can be carried in Router Advertisement (RA)
   message, which is broadcasted by local routers.  In the DHCPv6
   managed network, it can also be carried in DHCPv6 messages.

   More precisely it

   This document defines one a new ND option and one new DHCPv6 option that
   convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 of [RFC1035])
   [RFC1035] to be used as the destination of the address registration(s). registration
   messages.  In order to make use of these options, this document
   assumes that appropriate name resolution
   means mechanisms (see Section
   6.1.1 of [RFC1123]) [RFC1123] are available on the host
   client. The use of the FQDN may benefit for load-balancing purposes.

   By receiving the host.

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

   In principle, hosts must 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 could are expected to be propagated together along with prefix
   assignment information.

4.1.  ND Address Registration Solicitation Option

   The ND Address Registration Solicitation Option allows routers to
   propagate the solicitation for hosts to register their self-generated
   address.  This option also carries a the fully qualified domain name of
   the appointed address registration server.  This option SHOULD be propagated
   together with ND the Prefix Information Option, Section 4.6.2,
   [RFC4861].
   That is also applied to the case of Neighbor Discovery Proxies
   [RFC4389].  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                            .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Fields:

         Type      (TBA1)         TBA1

         Length       The length of the option 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.

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

         Domain Name A fully  Fully qualified domain name of the appointed announced
                      address registration server. The domain name is
                      encoded as specified in Section 8 of [RFC3315]. Any
                  possible future updates to Section 8 of the Section
                  8 of [RFC3315] also apply to this option.

         Padding:

         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.

4.2.  DHCPv6 Address Registration Solicitation Option

   The DHCPv6 Address Registration Solicitation Option allows DHCPv6
   server to propagate the solicitation for hosts to register their
   self-generated address.  This option also carries a domain name of
   the appointed address registration server.  This option SHOULD be
   propagated together with DHCPv6 Prefix Information Option, Section 5,
   [I-D.ietf-dhc-host-gen-id].  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_ADDR_REG_SOLICITATION |       option-len              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                          Domain Name                          .
      .                   (Address Registration Server)               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          option-code   OPTION_Addr_Reg_Solicitation   OPTION_ADDR_REG_SOLICITATION (TBA2).

          option-len    Length of this option in octets (option-code (not including
                        option-code and
                  option-len are not included). option-len).

          Domain Name   A fully qualified domain name of the appointed
                        address registration server. The domain name
                        is encoded as specified in Section 8 of
                        [RFC3315]. Any
                  possible future updates to Section 8 of the Section
                  8 of [RFC3315] also apply to this option.

5.  DHCPv6 Address Registration Procedure

   The current DHCPv6 protocol is reused as the address registration protocol
   while a DHCPv6 serve plays as server can play the role of an address registration
   server.
   Identity Association for Non-temporary Addresses (IA_NA)  The IA_NA DHCPv6 option [RFC3315] is reused in order to
   fulfill the address registration interactions.

5.1.  DHCPv6 Address Registration Request

   The host with one or more self-generated address(es) addresses sends a DHCPv6
   Request message to the appointed address registration server, which may be a
   DHCPv6 server. server received in the
   address registration solicitation option.

   The DHCPv6 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.

   By received,

   After receiving this address registration request, the address
   registration server MUST register the requested address in its
   address database, which MAY may further be used by other network
   functions, such as DNS or ACL, 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 the self-generated
   addresses and the DHCPv6 assigned addresses.  They MAY be marked different and
   treated differently in the database.

5.2.  DHCPv6 Address Registration Acknowledge

   The address registration server then sends a Reply message as the
   response to registration requests.  The DHCPv6 Reply message SHOULD
   contain at least one IA_NA option.  The IA_NA option SHOULD contain
   at least one IA Address option.  The server SHOULD set the T1 and T2
   fields in any IA_NA options, and the preferred-lifetime and valid-lifetime valid-
   lifetime fields in the IA Address options following the rules defined
   in Section 22 in of [RFC3315].

   By received

   After receiving the acknowledgement from the server, the host can use
   the registered address to access the network.  It SHOULD use the
   values in the preferred and valid lifetime fields for of the received
   message to determine the preferred and valid lifetimes of the
   address.

   Note:

   Please note that the host MAY continue to use expired address, such
   as Locators
   as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.; etc.
   but the network MAY could potentially refuse the network access from such
   addresses.

6.  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. Or, an  An attacker may also register a faked
   address large
   number of fake addresses with the network in order to spoof overwhelm the networking management plate.
   address registration server.  In either cases, case, these attacks may be
   prevented by using Secure Neighbor Discovery
   (SEND, [RFC3971]) [RFC3971] if the RA
   Address Registration Request Option is used,
   or and the AUTH option
   [RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] if the DHCPv6
   Address Registration Request Option is used.

7.  IANA Considerations

   This document defines a new IPv6 Neighbor Discovery [RFC4861] option,
   which MUST be assigned Option Type values within the option numbering
   space for Neighbor Discovery Option Type:

       The
   Address Registration Solicitation Option (TBA1), (TBA1) described in Section 4.1.
   4.1, that requires an allocation out of the registry defined at

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

   This document defines one a new DHCPv6 [RFC3315] option, which MUST be
   assigned Option Type values within the option numbering space for
   DHCPv6 options:

       The OPTION_Addr_Reg_Solicitation (TBA2),
   OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2; 4.2, that
   requires an allocation out of the registry defined at

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

8. Acknowledgments  Acknowledgements

   The authors would like to thank Ralph Dorm, Droms, Ted Lemon, Bernie Volz
   and other member members of DHC WG dhc working group for their valuable comments.

9.  References

9.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] S.  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC2119, BCP 14, RFC 2119, March 1997.

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

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

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

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

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

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

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

9.2.  Informative References

   [RFC4389] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery
             Proxies (ND Proxy)", RFC4389, April 2006.

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

   [I-D.ietf-dhc-host-gen-id]
             S.
              Jiang, F. S., Xia, F., and B. Sarikaya, "Prefix Assignment in
              DHCPv6", draft-ietf-dhc-host-gen-id 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),
             November, 2011.

Author's
              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