From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6119.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc6119.txt (limited to 'doc/rfc/rfc6119.txt') diff --git a/doc/rfc/rfc6119.txt b/doc/rfc/rfc6119.txt new file mode 100644 index 0000000..991b47a --- /dev/null +++ b/doc/rfc/rfc6119.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Harrison +Request for Comments: 6119 J. Berger +Category: Standards Track M. Bartlett +ISSN: 2070-1721 Metaswitch Networks + February 2011 + + + IPv6 Traffic Engineering in IS-IS + +Abstract + + This document specifies a method for exchanging IPv6 traffic + engineering information using the IS-IS routing protocol. This + information enables routers in an IS-IS network to calculate traffic- + engineered routes using IPv6 addresses. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6119. + +Copyright Notice + + Copyright (c) 2011 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. + + + + + + + +Harrison, et al. Standards Track [Page 1] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +1. Overview + + The IS-IS routing protocol is defined in [IS-IS]. Each router + generates a Link State PDU (LSP) that contains information describing + the router and the links from the router. The information in the LSP + is encoded in a variable length data structure consisting of a Type, + Length, and Value. Such a data structure is referred to as a TLV. + + [TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow + Traffic Engineering (TE) information to be disseminated by the IS-IS + protocol [IS-IS]. The addressing information passed in these TLVs is + IPv4 specific. + + [IPv6] describes how the IS-IS protocol can be used to carry out + Shortest Path First (SPF) routing for IPv6. It does this by defining + IPv6-specific TLVs that are analogous to the TLVs used by IS-IS for + carrying IPv4 addressing information. + + Multiprotocol Label Switching (MPLS) traffic engineering is very + successful, and, as the use of IPv6 grows, there is a need to be able + to support traffic engineering in IPv6 networks. + + This document defines the TLVs that allow traffic engineering + information (including Generalized-MPLS (GMPLS) TE information) to be + carried in IPv6 IS-IS networks. + +2. 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 [KEYWORDS]. + + + + + + + + +Harrison, et al. Standards Track [Page 2] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + +3. Summary of Operation + +3.1. Identifying IS-IS Links Using IPv6 Addresses + + Each IS-IS link has certain properties -- bandwidth, shared risk link + groups (SRLGs), switching capabilities, and so on. The IS-IS + extensions defined in [TE] and [GMPLS] describe how to associate + these traffic engineering parameters with IS-IS links. These TLVs + use IPv4 addresses to identify the link (or local/remote link + identifiers on unnumbered links). + + When IPv6 is used, a numbered link may be identified by IPv4 and/or + IPv6 interface addresses. The type of identifier used does not + affect the properties of the link; it still has the same bandwidth, + SRLGs, and switching capabilities. + + This document describes an approach for supporting IPv6 traffic + engineering by defining TLV extensions that allow TE links and nodes + to be identified by IPv6 addresses. + +3.1.1. IPv6 Address Types + + An IPv6 address can have global, unique-local, or link-local scope. + + - A global IPv6 address is valid within the scope of the Internet. + + - A unique-local IPv6 address is globally unique but is intended for + local communication. + + - A link-local IPv6 address is valid only within the scope of a + single link and may only be referenced on that link. + + Because the IPv6 traffic engineering TLVs present in LSPs are + propagated across networks, they MUST NOT use link-local addresses. + + IS-IS does not need to differentiate between global and unique-local + addresses. + +3.2. IP Addresses Used in Traffic Engineering TLVs + + This section lists the IP addresses used in the TLVs defined in [TE] + and [GMPLS] and gives an overview of the required IPv6 equivalents. + + + + + + + + + +Harrison, et al. Standards Track [Page 3] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + +3.2.1. TE Router ID TLV + + The TE Router ID TLV contains a stable IPv4 address that is routable, + regardless of the state of each interface. + + Similarly, for IPv6, it is useful to have a stable IPv6 address + identifying a TE node. The IPv6 TE Router ID TLV is defined in + Section 4.1. + +3.2.2. IPv4 Interface Address Sub-TLV + + This sub-TLV of the Extended IS Reachability TLV contains an IPv4 + address for the local end of a link. The equivalent IPv6 Interface + Address sub-TLV is defined in Section 4.2. + +3.2.3. IPv4 Neighbor Address Sub-TLV + + This sub-TLV of the Extended IS Reachability TLV is used for point- + to-point links and contains an IPv4 address for the neighbor's end of + a link. The equivalent IPv6 Neighbor Address sub-TLV is defined in + Section 4.3. + + A router constructs the IPv4 Neighbor Address sub-TLV using one of + the IPv4 addresses received in the IS-IS Hello (IIH) PDU from the + neighbor on the link. + + The IPv6 Neighbor Address sub-TLV contains a globally unique IPv6 + address for the interface from the peer (which can be either a global + or unique-local IPv6 address). The IPv6 Interface Address TLV + defined in [IPv6] only contains link-local addresses when used in the + IIH PDU. Hence, a neighbor's IP address from the IPv6 Interface + Address TLV cannot be used when constructing the IPv6 Neighbor + Address sub-TLV. Instead, we define an additional TLV, the IPv6 + Global Interface Address TLV in Section 4.5. The IPv6 Global + Interface Address TLV is included in IIH PDUs to provide the globally + unique IPv6 address that a neighbor router needs in order to + construct the IPv6 Neighbor Address sub-TLV. + +3.2.4. IPv4 SRLG TLV + + The SRLG TLV (type 138) defined in [GMPLS] contains the set of SRLGs + associated with a link. The SRLG TLV identifies the link using + either local/remote IPv4 addresses or, for point-to-point unnumbered + links, link-local/remote identifiers. The SRLG TLV includes a flags + field to indicate which type of identifier is used. + + + + + + +Harrison, et al. Standards Track [Page 4] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + + When only IPv6 is used, IPv4 addresses and link-local/remote + identifiers are not available to identify the link, but IPv6 + addresses can be used instead. + + There is no backward-compatible way to modify the SRLG TLV (type 138) + to identify the link by IPv6 addresses; therefore, we need a new TLV. + + The IPv6 SRLG TLV is defined in Section 4.4. + +4. IPv6 TE TLVs + +4.1. IPv6 TE Router ID TLV + + The IPv6 TE Router ID TLV is TLV type 140. + + The IPv6 TE Router ID TLV contains a 16-octet IPv6 address. A stable + global IPv6 address MUST be used, so that the router ID provides a + routable address, regardless of the state of a node's interfaces. + + If a router does not implement traffic engineering, it MAY include or + omit the IPv6 TE Router ID TLV. If a router implements traffic + engineering for IPv6, it MUST include this TLV in its LSP. This TLV + MUST NOT be included more than once in an LSP. + + An implementation receiving an IPv6 TE Router ID TLV MUST NOT + consider the router ID as a /128 reachable prefix in the standard SPF + calculation because this can lead to forwarding loops when + interacting with systems that do not support this TLV. + +4.2. IPv6 Interface Address Sub-TLV + + The IPv6 Interface Address sub-TLV of the Extended IS Reachability + TLV has sub-TLV type 12. It contains a 16-octet IPv6 address for the + interface described by the containing Extended IS Reachability TLV. + This sub-TLV can occur multiple times. + + Implementations MUST NOT inject a /128 prefix for the interface + address into their routing or forwarding table because this can lead + to forwarding loops when interacting with systems that do not support + this sub-TLV. + + If a router implements the basic TLV extensions described in [TE], it + MAY include or omit this sub-TLV. If a router implements IPv6 + traffic engineering, it MUST include this sub-TLV (except on an + unnumbered point-to-point link, in which case the Link-Local + Interface Identifiers sub-TLV is used instead). + + This sub-TLV MUST NOT contain an IPv6 link-local address. + + + +Harrison, et al. Standards Track [Page 5] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + +4.3. IPv6 Neighbor Address sub-TLV + + The IPv6 Neighbor Address sub-TLV of the Extended IS Reachability TLV + has sub-TLV type 13. It contains a 16-octet IPv6 address for a + neighboring router on the link described by the (main) TLV. This + sub-TLV can occur multiple times. + + Implementations MUST NOT inject a /128 prefix for the interface + address into their routing or forwarding table because this can lead + to forwarding loops when interacting with systems that do not support + this sub-TLV. + + If a router implements the basic TLV extensions described in [TE], it + MAY include or omit this sub-TLV. If a router implements IPv6 + traffic engineering, it MUST include this sub-TLV for point-to-point + links (except on an unnumbered point-to-point link, in which case the + Link-Local Interface Identifiers sub-TLV is used instead). + + This sub-TLV MUST NOT contain an IPv6 link-local address. + +4.4. IPv6 SRLG TLV + + The IPv6 SRLG TLV has type 139. The TLV carries the Shared Risk Link + Group information (see the "Shared Risk Link Group Information" + section of [GMPLS-ROUTING]). + + It contains a data structure consisting of the following: + + - 6 octets of System ID + - 1 octet of pseudonode number + - 1 octet flags + - 16 octets of IPv6 interface address + - (optional) 16 octets of IPv6 neighbor address + - (variable) list of SRLG values, where each element in the list has + 4 octets + + The following illustrates the encoding of the Value field of the IPv6 + SRLG TLV. + + + + + + + + + + + + + +Harrison, et al. Standards Track [Page 6] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | System ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | System ID (cont.) | Pseudonode num| Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 interface address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 interface address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 interface address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 interface address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (optional) IPv6 neighbor address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 neighbor address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 neighbor address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 neighbor address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Shared Risk Link Group Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ............ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Shared Risk Link Group Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The neighbor is identified by its System ID (6 octets), plus one + octet to indicate the pseudonode number if the neighbor is on a LAN + interface. + + The 1-octet flags field is interpreted as follows. + + Flags (1 octet) + + 0 1 2 3 4 5 6 7 + +--+--+--+--+--+--+--+--+ + | Reserved |NA| + +--+--+--+--+--+--+--+--+ + + NA - Neighbor Address included. + + The flags field currently contains one flag to indicate whether the + IPv6 neighbor address is included (the NA bit is set to 1) or not + included (the NA bit is set to 0). + + + +Harrison, et al. Standards Track [Page 7] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + + Other bits in the flags field are reserved for future use. Any bits + not understood by an implementation MUST be set to zero by the + sender. If a router receives an IPv6 SRLG TLV with non-zero values + for any bit that it does not understand, it MUST ignore the TLV (in + other words, it does not use the TLV locally but floods the TLV + unchanged to neighbors as normal). + + Note that this rule for processing the flags octet allows for future + extensibility of the IPv6 SRLG TLV. In particular, it allows + alternative means of identifying the corresponding link to be added + in the future. An implementation that does not understand such an + extension will ignore the TLV rather than attempt to interpret the + TLV incorrectly. + + The length of this TLV is 24 + 4 * (number of SRLG values) + 16 (if + the IPv6 neighbor address is included). + + To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP + from causing confusion of interpretation, the following rules are + applied. + + - The IPv6 SRLG TLV MAY occur more than once within the IS-IS + logical LSP. + + - There MUST NOT be more than one IPv6 SRLG TLV for a given link. + + - The IPv6 SRLG TLV (type 139) MUST NOT be used to describe the + SRLGs for a given link if it is possible to use the SRLG TLV (type + 138). + + - If both an SRLG TLV and an IPv6 SRLG are received describing the + SRLGs for the same link, the receiver MUST apply the SRLG TLV and + ignore the IPv6 SRLG TLV. + + In other words, if SRLGs are to be advertised for a link and if the + Extended IS Reachability TLV describing a link contains IPv4 + interface/neighbor address sub-TLVs or the link-local identifiers + sub-TLV, then the SRLGs MUST be advertised in the SRLG TLV (type + 138). + +4.5. IPv6 Global Interface Address TLV + + The IPv6 Global Interface Address TLV is TLV type 233. The TLV + structure is identical to that of the IPv6 Interface Address TLV + defined in [IPv6], but the semantics are different. In particular, + the TLV is included in IIH PDUs for those interfaces using IPv6 TE + extensions. The TLV contains global or unique-local IPv6 addresses + assigned to the interface that is sending the Hello. + + + +Harrison, et al. Standards Track [Page 8] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + + The IPv6 Global Interface Address TLV is not used in LSPs. + +5. Security Considerations + + This document raises no new security issues for IS-IS; for general + security considerations for IS-IS, see [ISIS-AUTH]. + +6. IPv4/IPv6 Migration + + The IS-IS extensions described in this document allow the routing of + GMPLS Label Switched Paths using IPv6 addressing through an IS-IS + network. There are no migration issues introduced by the addition of + this IPv6 TE routing information into an existing IPv4 GMPLS network. + Migration of Label Switched Paths from IPv4 to IPv6 is an issue for + GMPLS signaling and is outside the scope of this document. + +7. IANA Considerations + + This document defines the following new IS-IS TLV types that IANA has + reflected in the IS-IS TLV code-point registry: + + Type Description IIH LSP SNP + ---- ---------------------- --- --- --- + 139 IPv6 SRLG TLV n y n + 140 IPv6 TE Router ID n y n + 233 IPv6 Global Interface y n n + Address TLV + + This document also defines the following new sub-TLV types of top- + level TLV 22 that IANA has reflected in the Sub-TLVs for TLV 22, 141, + and 222 registry: + + Type Description 22 141 222 Length + ---- ----------- -- --- --- ------ + 12 IPv6 Interface Address y y y 16 + 13 IPv6 Neighbor Address y y y 16 + +8. Normative References + + [IS-IS] ISO, "Intermediate System to Intermediate System intra- + domain routeing information exchange protocol for use in + conjunction with the protocol for providing the + connectionless-mode network service (ISO 8473)", + International Standard 10589: 2002, Second Edition, 2002. + + [IPv6] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October + 2008. + + + + +Harrison, et al. Standards Track [Page 9] + +RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 + + + [TE] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, October 2008. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ISIS-AUTH] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, October 2008. + + [GMPLS] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 5307, October 2008. + + [GMPLS-ROUTING] + Kompella, K., Ed., and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi-Protocol Label + Switching (GMPLS)", RFC 4202, October 2005. + +Authors' Addresses + + Jon Harrison + Metaswitch Networks + 100 Church Street + Enfield + EN2 6BQ + U.K. + Phone: +44 20 8366 1177 + EMail: jon.harrison@metaswitch.com + + Jon Berger + Metaswitch Networks + 100 Church Street + Enfield + EN2 6BQ + U.K. + Phone: +44 20 8366 1177 + EMail: jon.berger@metaswitch.com + + Mike Bartlett + Metaswitch Networks + 100 Church Street + Enfield + EN2 6BQ + U.K. + Phone: +44 20 8366 1177 + EMail: mike.bartlett@metaswitch.com + + + + + +Harrison, et al. Standards Track [Page 10] + -- cgit v1.2.3