idnits 2.17.1 draft-ietf-isis-ipv6-te-08.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 2010) is 4954 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Harrison 2 INTERNET-DRAFT J. Berger 3 Expires March 2011 M. Bartlett 4 Intended status: Proposed Standard Metaswitch Networks 5 September 30, 2010 7 IPv6 Traffic Engineering in IS-IS 8 10 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 30, 2011. 32 Abstract 34 This document specifies a method for exchanging IPv6 Traffic 35 Engineering information using the IS-IS routing protocol. 36 This information enables routers in an IS-IS network to calculate 37 traffic engineered routes using IPv6 addresses. 39 1. Overview 41 The IS-IS routing protocol is defined in [IS-IS]. Each router 42 generates a Link State Protocol Data Unit (LSP) that contains 43 information describing the router and the links from the router. 44 The information in the LSP is encoded in a variable length data 45 structure consisting of a Type, Length and Value. Such a data 46 structure is referred to as a TLV. 48 [TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow 49 Traffic Engineering (TE) information to be disseminated by the IS-IS 50 protocol [IS-IS]. The addressing information passed in these TLVs is 51 IPv4 specific. 53 [IPv6] describes how the IS-IS protocol can be used to carry out 54 Shortest Path First (SPF) routing for IPv6. It does this by defining 55 IPv6 specific TLVs that are analogous to the TLVs used by IS-IS for 56 carrying IPv4 addressing information. 58 Multi-Protocol Label Switching (MPLS) Traffic Engineering is very 59 successful and, as the use of IPv6 grows, there is a need to be able 60 to support Traffic Engineering in IPv6 networks. 62 This document defines the TLVs that allow Traffic Engineering 63 information (including Generalized-MPLS (GMPLS) TE information) to be 64 carried in IPv6 IS-IS networks. 66 2. Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [KEYWORDS]. 72 3. Summary of operation 74 3.1 Identifying IS-IS links using IPv6 addresses 76 Each IS-IS link has certain properties - bandwidth, shared risk 77 link groups (SRLGs), switching capabilities and so on. The IS-IS 78 extensions defined in [TE] and [GMPLS] describe how to associate 79 these traffic engineering parameters with IS-IS links. These TLVs 80 use IPv4 addresses to identify the link (or local/remote link 81 identifiers on unnumbered links). 83 When IPv6 is used, a numbered link may be identified by IPv4 and/or 84 IPv6 interface addresses. The type of identifier used does not 85 affect the properties of the link - it still has the same bandwidth, 86 SRLGs, switching capabilities. 88 This document describes an approach for supporting IPv6 traffic 89 engineering, by defining TLV extensions that allow TE links and nodes 90 to be identified by IPv6 addresses. 92 3.1.1 IPv6 address types 94 An IPv6 address can have global, unique-local or link-local scope. 96 - A link-local IPv6 address is valid only within the scope of a 97 single link, and may only be referenced on that link. 99 - A unique-local IPv6 address is globally unique, but is intended 100 for local communication. 102 - A global IPv6 address is valid within the scope of the Internet. 104 Because the IPv6 traffic engineering TLVs present in LSPs are 105 propagated across networks, they MUST NOT use link-local addresses. 107 IS-IS does not need to differentiate between global and unique-local 108 addresses. 110 3.2 IP addresses used in Traffic Engineering TLVs 112 This section lists the IP addresses used in the TLVs defined in 113 [TE] and [GMPLS], and gives an overview of the required IPv6 114 equivalents. 116 3.2.1 TE Router ID TLV 118 The TE Router ID TLV contains a stable IPv4 address that is routable, 119 regardless of the state of each interface. 121 Similarly, for IPv6, it is useful to have a stable IPv6 address 122 identifying a TE node. The IPv6 TE Router ID TLV is defined in 123 section 4.1. 125 3.2.2 IPv4 Interface Address sub-TLV 127 This sub-TLV of the Extended IS Reachability TLV contains an 128 IPv4 address for the local end of a link. The equivalent IPv6 129 Interface Address sub-TLV is defined in section 4.2. 131 3.2.3 IPv4 Neighbor Address sub-TLV 133 This sub-TLV of the Extended IS Reachability TLV is used for 134 point-to-point links, and contains an IPv4 address for the neighbor's 135 end of a link. The equivalent IPv6 Neighbor Address sub-TLV is 136 defined in section 4.3. 138 A router constructs the IPv4 TLV Neighbor Address TLV using one of 139 the IPv4 addresses received in the IS-IS Hello (IIH) PDU from the 140 neighbor on the link. 142 The IPv6 Neighbor Address sub-TLV contains a globally unique IPv6 143 address for the interface from the peer (which can be either a global 144 or unique-local IPv6 address). The IPv6 Interface Address TLV 145 defined in [IPv6] only contains link-local addresses when used in the 146 IIH PDU. Hence a neighbor's IP address from the the 147 IPv6 Interface Address TLV cannot be used when constructing the 148 IPv6 Neighbor Address sub-TLV. Instead, we define an additional 149 TLV, the IPv6 Global Interface Address TLV in section 4.5. The IPv6 150 Global Interface Address TLV is included in IIH PDUs to provide the 151 globally unique IPv6 address that a neighbor router needs in order to 152 construct the IPv6 Neighbor Address sub-TLV. 154 3.2.4 IPv4 SRLG TLV 156 The SRLG TLV (type 138) defined in [GMPLS] contains the set of SRLGs 157 associated with a link. The SRLG TLV identifies the link using 158 either local/remote IPv4 addresses or, (for point-to-point unnumbered 159 links), link local/remote identifiers. The SRLG TLV includes a flags 160 field to indicate which type of identifier is used. 162 When only IPv6 is used, IPv4 addresses and link local/remote 163 identifiers are not available to identify the link, but IPv6 164 addresses can be used instead. 166 There is no back-compatible way to modify the SRLG TLV (type 138) 167 to identify the link by IPv6 addresses, and therefore we need a new 168 TLV. 170 The IPv6 SRLG TLV is defined in section 4.4. 172 4. IPv6 TE TLVs 174 4.1 IPv6 TE Router ID TLV 176 The IPv6 Traffic Engineering Router ID TLV is TLV type 140. 178 The IPv6 TE Router ID TLV contains a 16-octet IPv6 address. A 179 stable global IPv6 address MUST be used, so that the router ID 180 provides a routable address, regardless of the state of a node's 181 interfaces. 183 If a router does not implement traffic engineering, it MAY include or 184 omit the IPv6 Traffic Engineering Router ID TLV. If a router 185 implements traffic engineering for IPv6, it MUST include this TLV in 186 its LSP. This TLV MUST NOT be included more than once in an LSP. 188 An implementation receiving an IPv6 TE Router ID TLV MUST NOT 189 consider the router ID as a /128 reachable prefix in the standard 190 SPF calculation, because this can lead to forwarding loops when 191 interacting with systems that do not support this TLV. 193 4.2 IPv6 Interface Address sub-TLV 195 The IPv6 Interface Address sub-TLV of the Extended IS Reachability 196 TLV has sub-TLV type 12. It contains a 16-octet IPv6 address for the 197 interface described by the containing Extended IS Reachability TLV. 198 This sub-TLV can occur multiple times. 200 Implementations MUST NOT inject a /128 prefix for the interface 201 address into their routing or forwarding table, because this can lead 202 to forwarding loops when interacting with systems that do not support 203 this sub-TLV. 205 If a router implements the basic TLV extensions described in [TE], it 206 MAY include or omit this sub-TLV. If a router implements IPv6 207 traffic engineering, it MUST include this sub-TLV (except on an 208 unnumbered point-to-point link, in which case the Link Local 209 Interface Identifiers sub-TLV is used instead). 211 This sub-TLV MUST NOT contain an IPv6 link-local address. 213 4.3 IPv6 Neighbor Address sub-TLV 215 The IPv6 Neighbor Address sub-TLV of the Extended IS Reachability TLV 216 has sub-TLV type 13. It contains a 16-octet IPv6 address for a 217 neighboring router on the link described by the (main) TLV. This 218 sub-TLV can occur multiple times. 220 Implementations MUST NOT inject a /128 prefix for the interface 221 address into their routing or forwarding table, because this can lead 222 to forwarding loops when interacting with systems that do not support 223 this sub-TLV. 225 If a router implements the basic TLV extensions described in [TE], it 226 MAY include or omit this sub-TLV. If a router implements IPv6 227 traffic engineering, it MUST include this sub-TLV for point-to-point 228 links (except on an unnumbered point-to-point link, in which case the 229 Link Local Interface Identifiers sub-TLV is used instead). 231 This sub-TLV MUST NOT contain an IPv6 link-local address. 233 4.4 IPv6 SRLG TLV 235 The IPv6 SRLG TLV has type 139. The TLV carries the Shared Risk Link 236 Group information (see Section "Shared Risk Link Group Information" 237 of [GMPLS-ROUTING]). 239 It contains a data structure consisting of: 241 - 6 octets of System ID 242 - 1 octet of Pseudonode Number 243 - 1 octet flags 244 - 16 octets of IPv6 interface address 245 - (optional) 16 octets of IPv6 neighbor address 246 - (variable) list of SRLG values, where each element in the list 247 has 4 octets. 249 The following illustrates the encoding of the Value field of the 250 IPv6 SRLG TLV. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | System ID | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | System ID (cont.) | Pseudonode num| Flags | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | IPv6 interface address | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | IPv6 interface address (continued) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | IPv6 interface address (continued) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | IPv6 interface address (continued) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | (optional) IPv6 neighbor address | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | IPv6 neighbor address (continued) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | IPv6 neighbor address (continued) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | IPv6 neighbor address (continued) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Shared Risk Link Group Value | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | ............ | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Shared Risk Link Group Value | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 The neighbor is identified by its System Id (6-octets), plus one 283 octet to indicate the pseudonode number if the neighbor is on a 284 LAN interface. 286 The 1-octet flags field is interpreted as follows. 288 Flags (1 octet) 290 0 1 2 3 4 5 6 7 291 +--+--+--+--+--+--+--+--+ 292 | Reserved |NA| 293 +--+--+--+--+--+--+--+--+ 295 NA - Neighbor Address included. 297 The flags field currently contains one flag to indicate whether the 298 IPv6 neighbor address is included (the NA bit is set to 1), or not 299 included (the NA bit is set to 0). 301 Other bits in the flags field are reserved for future use. Any 302 bits not understood by an implementation MUST be set to zero by 303 the sender. If a router receives an IPv6 SRLG TLV with non-zero 304 values for any bit that it does not understand, it MUST ignore the 305 TLV (in other words, it does not use the TLV locally, but floods the 306 TLV unchanged to neighbors as normal). 308 Note that this rule for processing the flags octet allows for future 309 extensibility of the IPv6 SRLG TLV. In particular, it allows 310 alternative means of identifying the corresponding link to be added 311 in the future. An implementation that does not understand such an 312 extension will ignore the TLV, rather than attempting to interpret 313 the TLV incorrectly. 315 The length of this TLV is 24 + 4 * (number of SRLG values) + 16 (if 316 the IPv6 neighbor address is included). 318 To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP 319 from causing confusion of interpretation, the following rules are 320 applied. 322 - The IPv6 SRLG TLV MAY occur more than once within the IS-IS 323 logical LSP. 325 - There MUST NOT be more than one IPv6 SRLG TLV for a given link. 327 - The IPv6 SRLG TLV (type 139) MUST NOT be used to describe the 328 SRLGs for a given link if it is possible to use the SRLG TLV 329 (type 138). 331 - If both an SRLG TLV and an IPv6 SRLG are received describing the 332 SRLGs for the same link, the receiver MUST apply the SRLG TLV 333 and ignore the IPv6 SRLG TLV. 335 In other words, if SRLGs are to be advertised for a link, and if 336 the Extended IS Reachability TLV describing a link contains IPv4 337 interface/neighbor address sub-TLVs or the link local identifiers 338 sub-TLV, then the SRLGs MUST be advertised in the SRLG TLV 339 (type 138). 341 4.5 IPv6 Global Interface Address TLV 343 The IPv6 Global Interface Address TLV is TLV type 233. The TLV 344 structure is identical to that of the IPv6 Interface Address TLV 345 defined in [IPv6], but the semantics are different. In particular, 346 the TLV is included in IIH PDUs for those interfaces using IPv6 TE 347 extensions. The TLV contains global or unique-local IPv6 addresses 348 assigned to the interface that is sending the Hello. 350 The IPv6 Global Interface Address TLV is not used in LSPs. 352 5. Security Considerations 354 This document raises no new security issues for IS-IS; for general 355 security considerations for IS-IS see [ISIS-AUTH]. 357 6. IPv4/IPv6 Migration 359 The IS-IS extensions described in this document allow the routing of 360 GMPLS Label Switched Paths using IPv6 addressing through an IS-IS 361 network. There are no migration issues introduced by the addition of 362 this IPv6 TE routing information into an existing IPv4 GMPLS network. 363 Migration of Label Switched Paths from IPv4 to IPv6 is an issue for 364 GMPLS signaling and is outside the scope of this document. 366 7. IANA Considerations 368 This document defines the following new IS-IS TLV types that need to 369 be reflected in the IS-IS TLV code-point registry: 371 Type Description IIH LSP SNP 372 ---- ---------------------- --- --- --- 373 139 IPv6 SRLG TLV n y n 374 140 IPv6 TE Router ID n y n 375 233 IPv6 Global Interface y n n 376 Address TLV 378 This document also defines the following new sub-TLV types of 379 top-level TLV 22 that need to be reflected in the IS-IS sub-TLV 380 registry for TLV 22: 382 Type Description Length 383 ---- ------------------------------ -------- 384 12 IPv6 Interface Address 16 385 13 IPv6 Neighbor Address 16 387 8. References 389 8.1 Normative References 391 [IS-IS] ISO, "Intermediate System to Intermediate System intra- 392 domain routeing information exchange protocol for use in 393 conjunction with the protocol for providing the 394 connectionless-mode network service (ISO 8473)", 395 International Standard 10589: 2002, Second Edition, 2002. 397 [IPv6] C. Hopps, "Routing IPv6 with IS-IS", RFC 5308, 398 October 2008. 400 [TE] H. Smit and T. Li, "IS-IS extensions for Traffic 401 Engineering", RFC 5305, October 2008. 403 [KEYWORDS] 404 S. Bradner, "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [ISIS-AUTH] 408 T. Li and R. Atkinson, "IS-IS Cryptographic 409 Authentication", RFC 5304, October 2008. 411 [GMPLS] K.Kompella and Y.Rekhter, "IS-IS Extensions in Support of 412 Generalized Multi-Protocol Label Switching", RFC 5307, 413 October 2008. 415 [GMPLS-ROUTING] 416 K.Kompella and Y.Rekhter, "Routing Extensions in Support of 417 Generalized Multi-Protocol Label Switching (GMPLS)", 418 RFC 4202, October 2005. 420 9. Authors' Addresses 422 Jon Harrison 423 Metaswitch Networks 424 100 Church Street 425 Enfield 426 EN2 6BQ 427 U.K. 428 Phone: +44 20 8366 1177 429 Email: jon.harrison@metaswitch.com 431 Jon Berger 432 Metaswitch Networks 433 100 Church Street 434 Enfield 435 EN2 6BQ 436 U.K. 437 Phone: +44 20 8366 1177 438 Email: jon.berger@metaswitch.com 440 Mike Bartlett 441 Metaswitch Networks 442 100 Church Street 443 Enfield 444 EN2 6BQ 445 U.K. 446 Phone: +44 20 8366 1177 447 Email: mike.bartlett@metaswitch.com 449 10. Full Copyright Statement 451 Copyright (c) 2010 IETF Trust and the persons identified as the 452 document authors. All rights reserved. 454 This document is subject to BCP 78 and the IETF Trust's Legal 455 Provisions Relating to IETF Documents 456 (http://trustee.ietf.org/license-info) in effect on the date of 457 publication of this document. Please review these documents 458 carefully, as they describe your rights and restrictions with respect 459 to this document. Code Components extracted from this document must 460 include Simplified BSD License text as described in Section 4.e of 461 the Trust Legal Provisions and are provided without warranty as 462 described in the Simplified BSD License. 464 ALL IETF Documents and the information contained herein are provided 465 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 466 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 467 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 468 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 469 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 470 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 471 FOR A PARTICULAR PURPOSE. 473 Intellectual Property 475 This document may contain material from IETF Documents or IETF 476 Contributions published or made publicly available before November 477 10, 2008. The person(s) controlling the copyright in some of this 478 material may not have granted the IETF Trust the right to allow 479 modifications of such material outside the IETF Standards Process. 480 Without obtaining an adequate license from the person(s) 481 controlling the copyright in such materials, this document may not 482 be modified outside the IETF Standards Process, and derivative 483 works of it may not be created outside the IETF Standards Process, 484 except to format it for publication as an RFC or to translate it 485 into languages other than English.