AN Use Case BOF                                            S. Jiang, Ed.
Internet-Draft                              Huawei Technologies Co., Ltd
Intended status: Informational                              B. Carpenter
Expires: October 30, 2014                              Univ. of Auckland
                                                                  Q. Sun
                                                           China Telecom
                                                          April 28, 2014


       Autonomic Networking Use Case for Auto Address Management
                  draft-jiang-auto-addr-management-00

Abstract

   This document describes a use case for autonomic address management
   in large-scale networks.  It is one of a series of use cases intended
   to illustrate requirements for autonomic networking.

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 October 30, 2014.

Copyright Notice

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




Jiang, et al.           Expires October 30, 2014                [Page 1]


Internet-Draft        Auto Addr Management Use case           April 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Intended User and Administrator Experience  . . . . . . . . .   3
   4.  Analysis of Parameters and Information Involved . . . . . . .   3
     4.1.  Parameters each device can decide for itself  . . . . . .   4
     4.2.  Information needed from policy intent . . . . . . . . . .   5
   5.  Interaction with other devices  . . . . . . . . . . . . . . .   5
     5.1.  Information needed from other devices . . . . . . . . . .   5
     5.2.  Monitoring, diagnostics and reporting . . . . . . . . . .   6
   6.  Comparison with current solutions . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. Change log [RFC Editor: Please remove]  . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   This document is one of a set of use cases being developed to clarify
   the requirements for discovery and negotiation protocols for
   autonomic networking (AN).  The background to AN is described in
   [I-D.irtf-nmrg-autonomic-network-definitions] and
   [I-D.irtf-nmrg-an-gap-analysis].  A problem statement and outline
   requirements for the negotiation protocol are given in
   [I-D.jiang-config-negotiation-ps].

   This document is dedicated to how to make IP address management in
   large-scale networks as autonomic as possible, including operator
   (ISP) networks and large enterprise networks.  Although this document
   is targeting pure IPv6 networks, autonomically sharing public IPv4
   addresses among the Address Family Transition Routers (AFTRs)
   [RFC6333] or NAT64 [RFC6146] devices is also discussed.

   Note in draft: This version is preliminary.  In particular, opinions
   may vary about how concrete vs how abstract a use case should be.

2.  Problem Statement

   The autonomic networking use case considered here is autonomic IP
   address management in large-scale networks.





Jiang, et al.           Expires October 30, 2014                [Page 2]


Internet-Draft        Auto Addr Management Use case           April 2014


   Although DHCPv6 Prefix Delegation [RFC3633] has supported automated
   delegation of IPv6 prefixes, the prefix management is still largely
   depending on human planning.  In other words, there is no basic
   information or policies to support autonomic decisions on the prefix
   length that each router should request or be delegated, according to
   its role in the network.  Roles could be locally defined or could be
   generic (edge router, interior router, etc.).  Furthermore, the
   current IPv6 prefix management by humans is rigid and static after
   initial planning.

   Additionally, the management of public IPv4 addresses on AFTRs or
   NAT64 devices is similarly rigid and static.  The utilisation rate of
   addresses depends on the initial plan.  Efficient utilisation of
   public IPv4 addresses is the most important requirement since they
   are a limited resource during the IPv4 exhaustion period.

   The problem to be solved by AN is how to dynamically and
   autonomically manage IPv6 address space and public IPv4 addresses on
   AFTRs or NAT64 devices in large-scale networks, so that IP addresses
   can be used efficiently.  The AN approach discussed in this document
   is based on the assumption that there was a generic dicovery and
   negotiation protocol that enables direct negotiation between
   intelligent IP routers.  [I-D.jiang-config-negotiation-protocol] is
   one of the attempts at such a protocol.

3.  Intended User and Administrator Experience

   The intended experience is, for the administrator(s) of a large-scale
   network, that the management of IPv6 address space can be run with
   minimum efforts, for both the network and network device initiation
   stage and during running time.  In the most ideal scenario, the
   administrator(s) only have to configure a single IPv6 prefix for the
   whole network and the initial prefix length for each device role.

   Where applicable, another intended experience is dynamically and
   autonomically sharing public IPv4 addresses on AFTRs or NAT64 devices
   without human intervention.  The administrator only has to configure
   the total available IPv4 address range.

   The actual address usage needs to be logged for the potential offline
   management operations including audit and security incident tracing.

4.  Analysis of Parameters and Information Involved

   For specific purposes of address management, a few parameters are
   involved on each device (some of them can be pre-configured before
   they are connected).  They include:




Jiang, et al.           Expires October 30, 2014                [Page 3]


Internet-Draft        Auto Addr Management Use case           April 2014


   o  Identity of this device.  It can be verified by the certification
      authority (CA) that is maintained by the network administrator(s).

   o  Identity of a trust anchor which is certification authority (CA)
      that is maintained by the network administrator(s).

   o  Role of this device.

   o  An IPv6 prefix length for this device.

   o  An IPv6 prefix that is assigned to this device and its downstream
      devices.

   o  A public IPv4 address pool if the device acts as an AFTR or NAT64
      device.

   A few parameters are involved in the network as a whole.  They are:

   o  Identity of a trust anchor which is a certification authority (CA)
      that is maintained by the network administrator(s).

   o  Total IPv6 address space.  It is one (or several) IPv6 prefix(es).

   o  A public IPv4 address pool if the network provides IPv4 over IPv6
      access or IPv4/IPv6 transition services.

   o  The initial prefix length for each device role.

4.1.  Parameters each device can decide for itself

   This section identifies those of the above parameters that do not
   need external information in order for the devices concerned to set
   them to a reasonable value after bootstrap or after a network
   disruption.  There are few of these:

   o  Role of this device, this includes whether this device acts as an
      AFTR or NAT64 device.

   o  Default IPv6 prefix length for this device.

   o  Identity of this device.

   The device may be shipped from the manufacture with pre-configured
   role and default prefix length.







Jiang, et al.           Expires October 30, 2014                [Page 4]


Internet-Draft        Auto Addr Management Use case           April 2014


4.2.  Information needed from policy intent

   This section identifies those parameters that need external
   information about policy intent in order for the devices concerned to
   set them to a non-default value.

   o  Non-default value for the IPv6 prefix length for this device.
      This needs to be decided based on the role of this device.

   o  The initial prefix length for each device role.

   o  Identity of a trust anchor.

   o  Whether to allow the device request more address space.

   o  Whether to allow the device to request or share public IPv4
      address.

   o  The policy when to request more address space, for example, the
      address usage reaches a certain limit or percentage.

5.  Interaction with other devices

5.1.  Information needed from other devices

   This section identifies those of the above parameters that need
   external information from neighbor devices (including the upstream
   devices).  In many cases, two-way dialogue with neighbor devices is
   needed to set or optimise them.

   o  Identity of a trust anchor.

   o  The device will need to discover their neighbors, particularly,
      the upstream device, from which it can acquire IPv6 address space.

   o  The initial prefix length for each device role, particularly for
      its own downstream devices.

   o  The default value of the IPv6 prefix length may be overridden by a
      non-default value.

   o  The device will need to request and acquire IPv6 prefix that is
      assigned to this device and its downstream devices.

   o  The device may respond to prefix delegation request from its
      downstream devices.





Jiang, et al.           Expires October 30, 2014                [Page 5]


Internet-Draft        Auto Addr Management Use case           April 2014


   o  The device may require to be assigned more IPv6 address space, if
      it used up its assigned IPv6 address space.

   o  An AFTR or NAT64 device will need to request and acquire an
      initial public IPv4 address pool.

   o  An AFTR or NAT64 device will need to discover its neighbors, from
      which it may acquire spare public IPv4 addresses.

   o  An AFTR or NAT64 device may acquire spare public IPv4 addresses
      with their associated available period.

5.2.  Monitoring, diagnostics and reporting

   This section discusses what role devices should play in monitoring,
   fault diagnosis, and reporting.

   o  The actual address assignments need to be logged for the potential
      offline management operations.

   o  In general, the usage situation of address space should be
      reported to the network administrators, in an abstract way, for
      example, statistics or visualized report.

   o  A forecast of address exhaustion should be reported.

6.  Comparison with current solutions

   This section briefly compares the above use case with current
   solutions.  Currently, the address management is still largely
   depending on human planning.  It is rigid and static after initial
   planning.  The address requests will fail if the configured address
   space is used up.

   Some functions, for autonomic and dynamic address management, may be
   achievable by extending the existing protocols, for example,
   extending DHCPv6-PD to request IPv6 address according to the device
   role.  However, defining uniform device roles may not be a practical
   task.  Some functions are not suitable to be achieved by any existing
   protocols, such as dynamically negotiating the sharing of public IPv4
   addresses.

   However, using a generic autonomic discovery and negotiation protocol
   instead of specific solutions has the advantage that additional
   parameters can be included in the autonomic solution without creating
   new mechanisms.  This is the principal argument for a generic
   approach.




Jiang, et al.           Expires October 30, 2014                [Page 6]


Internet-Draft        Auto Addr Management Use case           April 2014


7.  Security Considerations

   Relevant security issues are discussed in
   [I-D.irtf-nmrg-autonomic-network-definitions],
   [I-D.jiang-config-negotiation-ps].  The security mechanism in this
   document is established on a Public Key Infrastructure (PKI) system
   [RFC3647] that is maintained by the network administrator(s).

8.  IANA Considerations

   This document requests no action by IANA.

9.  Acknowledgements

   Valuable comments were received from Michael Behringer and Chongfeng
   Xie.

   This document was produced using the xml2rfc tool [RFC2629].

10.  Change log [RFC Editor: Please remove]

   draft-jiang-auto-addr-management-00: original version, 2014-04-28.

11.  References

   [I-D.irtf-nmrg-an-gap-analysis]
              Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis
              for Autonomic Networking", draft-irtf-nmrg-an-gap-
              analysis-00 (work in progress), April 2014.

   [I-D.irtf-nmrg-autonomic-network-definitions]
              Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking - Definitions and Design Goals", draft-irtf-
              nmrg-autonomic-network-definitions-00 (work in progress),
              December 2013.

   [I-D.jiang-config-negotiation-protocol]
              Jiang, S., Carpenter, B., Liu, B., and Y. Yin,
              "Configuration Negotiation Protocol for Network Devices",
              draft-jiang-config-negotiation-protocol-01 (work in
              progress), April 2014.

   [I-D.jiang-config-negotiation-ps]
              Jiang, S., Yin, Y., and B. Carpenter, "Network
              Configuration Negotiation Problem Statement and
              Requirements", draft-jiang-config-negotiation-ps-02 (work
              in progress), January 2014.



Jiang, et al.           Expires October 30, 2014                [Page 7]


Internet-Draft        Auto Addr Management Use case           April 2014


   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

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

   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
              Wu, "Internet X.509 Public Key Infrastructure Certificate
              Policy and Certification Practices Framework", RFC 3647,
              November 2003.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

Authors' Addresses

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

   Email: jiangsheng@huawei.com


   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com


   Qiong
   China Telecom
   No.118, Xizhimennei Street
   Beijing  100035
   P. R. China

   Email: sunqiong@ctbri.com.cn



Jiang, et al.           Expires October 30, 2014                [Page 8]