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]