Internet DRAFT - draft-baker-ipv6-isis-automatic-prefix

draft-baker-ipv6-isis-automatic-prefix







Network Working Group                                         F.J. Baker
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                       February 19, 2013
Expires: August 23, 2013


                  Automated prefix allocation in IS-IS
               draft-baker-ipv6-isis-automatic-prefix-00

Abstract

   This note describes a TLV and associated mechanisms for the
   allocation of /64 prefixes from a less specific prefix.

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 August 23, 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




Baker                   Expires August 23, 2013                 [Page 1]

Internet-Draft        Automated Prefix Management          February 2013


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Autoconfiguration TLV Advertisement . . . . . . . . . . .   3
     2.2.  Subnet prefix allocation and announcement . . . . . . . .   3
     2.3.  Autoconfiguration TLV Withdrawal  . . . . . . . . . . . .   4
     2.4.  Renumbering using autoconfiguration . . . . . . . . . . .   4
   3.  IPv6 Autoconfiguration TLV  . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This note recommends an approach to the automated allocation of /64
   prefixes within a network.  This not something that will be done in a
   heavily-managed network, but may be appropriate in networks with
   light management, such as residential and SOHO networks.

1.1.  Requirements Language

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

2.  Theory of Operation

   The premise is that some party allocates a prefix to a network, such
   as a PA /48 or /56.  The obvious way is using DHCP-PD [RFC3633],
   although that is not actually required.

   IS-IS [ISO.10589.1992] represents those destinations as a type-
   length-value field that identifies an address.  For CLNS, it was
   designed to the ISO NSAP; by various extensions, it also handles IPv4
   and IPv6 prefixes and their counterparts for other protocols.  In
   this model, we add a TLV to advertise the delegated prefix, with the
   expectation that routers in the network (including pseudo-nodes) will
   allocate more specific prefixes from that prefix.







Baker                   Expires August 23, 2013                 [Page 2]

Internet-Draft        Automated Prefix Management          February 2013


   In short, some specified system in the network, potentially a
   configuration management system or the CPE router facing an upstream
   network, is configured with an autoconfiguration prefix, and manages
   the use of that prefix in the network.

2.1.  Autoconfiguration TLV Advertisement

   Upon recognizing that it has been configured with a prefix and that
   the network management policy is for autoconfiguration, the system in
   question advertises the autoconfiguration prefix described in
   Section 3 within the intended area or network.

2.2.  Subnet prefix allocation and announcement

   Each router advertising a Reachability TLV [RFC5308], including a
   pseudonode on a LAN, when it receives the Autoconfiguration TLV
   Advertisement, calculates and announces a more specific prefix from
   the advertised autoconfiguration prefix in a Reachability TLV.  This
   prefix is chosen at random, but may not collide with any prefix
   currently advertised within the network and therefore in the LSP
   database.

   There are obvious caveats here: if the autoconfiguration prefix is
   too long and as a result there are more LANs than there are prefixes
   to allocate to them, the procedure breaks down badly, and if there
   are just exactly enough, it may take time to converge.  Hence, from
   an operational perspective, the autoconfiguration prefix should have
   enough /64 more specific prefixes, and from an implementation
   perspective, the randomization function must be sufficiently robust,
   that independent choices are unlikely to collide.

   In the event of collision, which is likely to happen from time to
   time, it is up to the nodes advertising the prefix in question to
   detect and resolve the situation.  Upon receiving an LSP containing
   its "own" prefix advertised by another router, each router waits
   CollisionDetect (10) seconds, to give the network ample opportunity
   to detect the issue.  It then waits an additional random interval
   between zero and CollisionDetect seconds, to randomize the recovery
   process and maximize the chance that replacement prefixes do not
   collide.  It then allocates a new prefix following the procedure
   described in this section, and re-announces its LSP, removing (and
   therefore withdrawing) the offending reachability TLV, and instead
   announcing the new one.








Baker                   Expires August 23, 2013                 [Page 3]

Internet-Draft        Automated Prefix Management          February 2013


   Subsequent procedures, such as the advertisement of Router
   Advertisement using the allocated prefix or DHCPv6 allocation of
   addresses, may start CollisionDetect seconds after the LSP has been
   announced if no collision has been detected.  At this point, routers
   MAY store their /64s in non-volatile storage.

2.3.  Autoconfiguration TLV Withdrawal

   When the prefix advertised in the Autoconfiguration TLV expires or is
   withdrawn, the Autoconfiguration TLV is withdrawn from the network.
   Upon detection of the withdrawal, each router in the network MUST
   withdraw any addresses or prefixes dependent on it.  If those
   prefixes are stored in non-volatile storage, they MUST also be
   removed.

2.4.  Renumbering using autoconfiguration

   [RFC4192] describes the process of renumbering in some detail.  The
   discussion here is somewhat simplistic; refer to that for a more
   detailed discussion.

   In short, "renumbering" a network is a special case of "numbering" a
   network.  If there is one prefix in use in a network and it is
   withdrawn, the network will experience an outage.  Hence, it is
   generally advisable to ensure that there are at least two prefixes in
   use in a network when one of them is removed.  This might be
   accomplished by simply using multiple prefixes in the network; it
   might also be accomplished by deploying a second autoconfiguration
   prefix minutes or hours before the "old" one is removed.  During that
   time, DNS and DHCP databases need to be updated as described in
   [RFC4192] to reflect the new prefix.

   If an outage is acceptable, it is also possible to renumber using the
   same prefix.  For this, the administration withdraws the prefix as
   described in Section 2.3 and waits until the process is complete.
   There are two obvious ways to determine completion:

   o  Wait long enough that it is highly unlikely to have not completed,
      which might be the number of routers in the network diameter times
      the LSP update retransmission interval, or

   o  Wait until the managing router's LSP database contains no
      Reachability TLVs that depend on the prefix.

   At this point, any systems that are only using that prefix are now
   unreachable using global addressing.





Baker                   Expires August 23, 2013                 [Page 4]

Internet-Draft        Automated Prefix Management          February 2013


   At this point, the managing system may re-advertise the prefix as
   described in Section 2.1, and the routers in the network will re-
   allocate prefixes as described in Section 2.3.

3.  IPv6 Autoconfiguration TLV

   The structure of the Autoconfiguration TLV is 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 = IANA  |    Length     |U|X|   Reserve |  Prefix Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Prefix ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      * - if present
      U - up/down bit
      X - external original bit


                      Figure 1: Autoconfiguration TLV

   As is described in [RFC5305]: "The up/down bit SHALL be set to 0 when
   a prefix is first injected into IS-IS.  If a prefix is advertised
   from a higher level to a lower level (e.g.  level 2 to level 1), the
   bit SHALL be set to 1, indicating that the prefix has traveled down
   the hierarchy.  Prefixes that have the up/down bit set to 1 may only
   be advertised down the hierarchy, i.e., to lower levels".

   If the prefix was distributed into IS-IS from another routing
   protocol, the external bit SHALL be set to 1.  This information is
   useful when distributing prefixes from IS-IS to other protocols.

   The prefix is "packed" in the data structure.  That is, only the
   required number of octets of prefix are present.  This number can be
   computed from the prefix length octet as follows:

      prefix octets = integer of ((prefix length + 7) / 8)

4.  IANA Considerations

   This section will request an identifying value for the TLV defined.
   This is deferred to the -01 version of the draft.

5.  Security Considerations

   To be considered.



Baker                   Expires August 23, 2013                 [Page 5]

Internet-Draft        Automated Prefix Management          February 2013


6.  Privacy Considerations

   To be considered.

7.  Acknowledgements

8.  Change Log

   Initial Version:  February 2013

9.  References

9.1.  Normative References

   [ISO.10589.1992]
              International Organization for Standardization,
              "Intermediate system to intermediate system intra-domain-
              routing routine information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473)", ISO
              Standard 10589, 1992.

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

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
              2008.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

9.2.  Informative References

   [I-D.baker-fun-routing-class]
              Baker, F., "Routing a Traffic Class", draft-baker-fun-
              routing-class-00 (work in progress), July 2011.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.




Baker                   Expires August 23, 2013                 [Page 6]

Internet-Draft        Automated Prefix Management          February 2013


   [RFC1247]  Moy, J., "OSPF Version 2", RFC 1247, July 1991.

   [RFC1349]  Almquist, P., "Type of Service in the Internet Protocol
              Suite", RFC 1349, July 1992.

   [RFC2460]  Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
              6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

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

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com



















Baker                   Expires August 23, 2013                 [Page 7]