idnits 2.17.1 draft-baker-ipv6-isis-automatic-prefix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2013) is 4083 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2328' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-fun-routing-class' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC1247' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 290, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1247 (Obsoleted by RFC 1583) -- Obsolete informational reference (is this intentional?): RFC 1349 (Obsoleted by RFC 2474) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F.J. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track February 19, 2013 5 Expires: August 23, 2013 7 Automated prefix allocation in IS-IS 8 draft-baker-ipv6-isis-automatic-prefix-00 10 Abstract 12 This note describes a TLV and associated mechanisms for the 13 allocation of /64 prefixes from a less specific prefix. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 23, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 50 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. Autoconfiguration TLV Advertisement . . . . . . . . . . . 3 52 2.2. Subnet prefix allocation and announcement . . . . . . . . 3 53 2.3. Autoconfiguration TLV Withdrawal . . . . . . . . . . . . 4 54 2.4. Renumbering using autoconfiguration . . . . . . . . . . . 4 55 3. IPv6 Autoconfiguration TLV . . . . . . . . . . . . . . . . . 5 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This note recommends an approach to the automated allocation of /64 69 prefixes within a network. This not something that will be done in a 70 heavily-managed network, but may be appropriate in networks with 71 light management, such as residential and SOHO networks. 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Theory of Operation 81 The premise is that some party allocates a prefix to a network, such 82 as a PA /48 or /56. The obvious way is using DHCP-PD [RFC3633], 83 although that is not actually required. 85 IS-IS [ISO.10589.1992] represents those destinations as a type- 86 length-value field that identifies an address. For CLNS, it was 87 designed to the ISO NSAP; by various extensions, it also handles IPv4 88 and IPv6 prefixes and their counterparts for other protocols. In 89 this model, we add a TLV to advertise the delegated prefix, with the 90 expectation that routers in the network (including pseudo-nodes) will 91 allocate more specific prefixes from that prefix. 93 In short, some specified system in the network, potentially a 94 configuration management system or the CPE router facing an upstream 95 network, is configured with an autoconfiguration prefix, and manages 96 the use of that prefix in the network. 98 2.1. Autoconfiguration TLV Advertisement 100 Upon recognizing that it has been configured with a prefix and that 101 the network management policy is for autoconfiguration, the system in 102 question advertises the autoconfiguration prefix described in 103 Section 3 within the intended area or network. 105 2.2. Subnet prefix allocation and announcement 107 Each router advertising a Reachability TLV [RFC5308], including a 108 pseudonode on a LAN, when it receives the Autoconfiguration TLV 109 Advertisement, calculates and announces a more specific prefix from 110 the advertised autoconfiguration prefix in a Reachability TLV. This 111 prefix is chosen at random, but may not collide with any prefix 112 currently advertised within the network and therefore in the LSP 113 database. 115 There are obvious caveats here: if the autoconfiguration prefix is 116 too long and as a result there are more LANs than there are prefixes 117 to allocate to them, the procedure breaks down badly, and if there 118 are just exactly enough, it may take time to converge. Hence, from 119 an operational perspective, the autoconfiguration prefix should have 120 enough /64 more specific prefixes, and from an implementation 121 perspective, the randomization function must be sufficiently robust, 122 that independent choices are unlikely to collide. 124 In the event of collision, which is likely to happen from time to 125 time, it is up to the nodes advertising the prefix in question to 126 detect and resolve the situation. Upon receiving an LSP containing 127 its "own" prefix advertised by another router, each router waits 128 CollisionDetect (10) seconds, to give the network ample opportunity 129 to detect the issue. It then waits an additional random interval 130 between zero and CollisionDetect seconds, to randomize the recovery 131 process and maximize the chance that replacement prefixes do not 132 collide. It then allocates a new prefix following the procedure 133 described in this section, and re-announces its LSP, removing (and 134 therefore withdrawing) the offending reachability TLV, and instead 135 announcing the new one. 137 Subsequent procedures, such as the advertisement of Router 138 Advertisement using the allocated prefix or DHCPv6 allocation of 139 addresses, may start CollisionDetect seconds after the LSP has been 140 announced if no collision has been detected. At this point, routers 141 MAY store their /64s in non-volatile storage. 143 2.3. Autoconfiguration TLV Withdrawal 145 When the prefix advertised in the Autoconfiguration TLV expires or is 146 withdrawn, the Autoconfiguration TLV is withdrawn from the network. 147 Upon detection of the withdrawal, each router in the network MUST 148 withdraw any addresses or prefixes dependent on it. If those 149 prefixes are stored in non-volatile storage, they MUST also be 150 removed. 152 2.4. Renumbering using autoconfiguration 154 [RFC4192] describes the process of renumbering in some detail. The 155 discussion here is somewhat simplistic; refer to that for a more 156 detailed discussion. 158 In short, "renumbering" a network is a special case of "numbering" a 159 network. If there is one prefix in use in a network and it is 160 withdrawn, the network will experience an outage. Hence, it is 161 generally advisable to ensure that there are at least two prefixes in 162 use in a network when one of them is removed. This might be 163 accomplished by simply using multiple prefixes in the network; it 164 might also be accomplished by deploying a second autoconfiguration 165 prefix minutes or hours before the "old" one is removed. During that 166 time, DNS and DHCP databases need to be updated as described in 167 [RFC4192] to reflect the new prefix. 169 If an outage is acceptable, it is also possible to renumber using the 170 same prefix. For this, the administration withdraws the prefix as 171 described in Section 2.3 and waits until the process is complete. 172 There are two obvious ways to determine completion: 174 o Wait long enough that it is highly unlikely to have not completed, 175 which might be the number of routers in the network diameter times 176 the LSP update retransmission interval, or 178 o Wait until the managing router's LSP database contains no 179 Reachability TLVs that depend on the prefix. 181 At this point, any systems that are only using that prefix are now 182 unreachable using global addressing. 184 At this point, the managing system may re-advertise the prefix as 185 described in Section 2.1, and the routers in the network will re- 186 allocate prefixes as described in Section 2.3. 188 3. IPv6 Autoconfiguration TLV 190 The structure of the Autoconfiguration TLV is as follows: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type = IANA | Length |U|X| Reserve | Prefix Len | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Prefix ... 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 * - if present 200 U - up/down bit 201 X - external original bit 203 Figure 1: Autoconfiguration TLV 205 As is described in [RFC5305]: "The up/down bit SHALL be set to 0 when 206 a prefix is first injected into IS-IS. If a prefix is advertised 207 from a higher level to a lower level (e.g. level 2 to level 1), the 208 bit SHALL be set to 1, indicating that the prefix has traveled down 209 the hierarchy. Prefixes that have the up/down bit set to 1 may only 210 be advertised down the hierarchy, i.e., to lower levels". 212 If the prefix was distributed into IS-IS from another routing 213 protocol, the external bit SHALL be set to 1. This information is 214 useful when distributing prefixes from IS-IS to other protocols. 216 The prefix is "packed" in the data structure. That is, only the 217 required number of octets of prefix are present. This number can be 218 computed from the prefix length octet as follows: 220 prefix octets = integer of ((prefix length + 7) / 8) 222 4. IANA Considerations 224 This section will request an identifying value for the TLV defined. 225 This is deferred to the -01 version of the draft. 227 5. Security Considerations 229 To be considered. 231 6. Privacy Considerations 233 To be considered. 235 7. Acknowledgements 237 8. Change Log 239 Initial Version: February 2013 241 9. References 243 9.1. Normative References 245 [ISO.10589.1992] 246 International Organization for Standardization, 247 "Intermediate system to intermediate system intra-domain- 248 routing routine information exchange protocol for use in 249 conjunction with the protocol for providing the 250 connectionless-mode Network Service (ISO 8473)", ISO 251 Standard 10589, 1992. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 258 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 259 Engineering", RFC 5305, October 2008. 261 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 262 2008. 264 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 265 for IPv6", RFC 5340, July 2008. 267 9.2. Informative References 269 [I-D.baker-fun-routing-class] 270 Baker, F., "Routing a Traffic Class", draft-baker-fun- 271 routing-class-00 (work in progress), July 2011. 273 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 274 1981. 276 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 277 dual environments", RFC 1195, December 1990. 279 [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. 281 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 282 Suite", RFC 1349, July 1992. 284 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 285 6 (IPv6) Specification", RFC 2460, December 1998. 287 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 288 "Assured Forwarding PHB Group", RFC 2597, June 1999. 290 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 291 Defeating Denial of Service Attacks which employ IP Source 292 Address Spoofing", BCP 38, RFC 2827, May 2000. 294 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 295 Host Configuration Protocol (DHCP) version 6", RFC 3633, 296 December 2003. 298 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 299 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 300 September 2005. 302 Author's Address 304 Fred Baker 305 Cisco Systems 306 Santa Barbara, California 93117 307 USA 309 Email: fred@cisco.com