IS-IS IPv6 TE: IPv6 Traffic Engineering in IS-IS
New IS-IS TLVs that let routers plan traffic-engineered paths using IPv6 addresses.
Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <https://www.rfc-editor.org/info/rfc6119>.
@misc{rfc6119,
series = {Request for Comments},
number = 6119,
howpublished = {RFC 6119},
publisher = {RFC Editor},
doi = {10.17487/RFC6119},
url = {https://www.rfc-editor.org/info/rfc6119},
author = {J. Harrison and J. Berger and M. Bartlett},
title = {{IPv6 Traffic Engineering in IS-IS}},
pagetotal = 10,
year = 2011,
month = feb,
} RFC text
Contents
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.
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].
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.
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.
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.
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.
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).
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.
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.
[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
ISO Plain Language
On this page
§1Overview
The IS-IS routing protocol is defined in the ISO standard for the Intermediate System to Intermediate System intra-domain routing information exchange protocol. Each router generates a Link State PDU containing information describing the router and the links from the router. The information in the PDU is encoded in a variable length data structure consisting of a Type, a Length and a Value, and such a data structure is referred to as a TLV.
The traffic engineering extensions of RFC 5305 and the GMPLS extensions of RFC 5307 define a number of TLVs and sub-TLVs that allow traffic engineering information to be disseminated by IS-IS. The addressing information passed in those TLVs is IPv4 specific. RFC 5308 describes how IS-IS can be used to carry out Shortest Path First routing for IPv6, by defining IPv6-specific TLVs analogous to those used for IPv4 addressing.
MPLS traffic engineering is very successful, and as the use of IPv6 grows there is a need to support traffic engineering in IPv6 networks. This document defines the TLVs that allow traffic engineering information, including Generalized MPLS traffic engineering information, to be carried in IPv6 IS-IS networks.
The extensions allow the routing of GMPLS Label Switched Paths using IPv6 addressing through an IS-IS network. There are no migration issues introduced by adding this IPv6 traffic engineering information to an existing IPv4 GMPLS network. Migrating Label Switched Paths themselves from IPv4 to IPv6 is an issue for GMPLS signalling and is outside the scope of this document.
Every IS-IS router advertises a list of its links, and other routers use that list to work out paths. The traffic engineering part of that list names links and routers with IPv4 addresses. This RFC adds matching fields that use IPv6 addresses.
§3.1Identifying IS-IS Links with IPv6 Addresses
Each IS-IS link has certain properties: bandwidth, shared risk link groups, switching capabilities, and so on. The IS-IS extensions of RFC 5305 and RFC 5307 describe how to associate these traffic engineering parameters with IS-IS links, and those TLVs use IPv4 addresses to identify the link, or the local and remote link identifiers on unnumbered links.
When IPv6 is used, a numbered link may be identified by IPv4 and by or IPv6 interface addresses. The type of identifier used does not affect the properties of the link, which still has the same bandwidth, shared risk link groups and switching capabilities.
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.
An IPv6 address can be valid everywhere, valid only inside one organisation, or valid only on one cable. The ones that travel between routers have to be the first kind, or at least the second, because a link-local address means nothing on the next hop.
§3.2The Addresses the Existing TLVs Use
The RFC reviews the IP addresses used in the TLVs defined in RFC 5305 and RFC 5307, and gives an overview of the IPv6 equivalents it needs.
The TE Router ID TLV contains a stable IPv4 address that is routable, regardless of the state of each interface. For IPv6 it is useful to have a stable IPv6 address identifying a traffic engineering node, and the IPv6 TE Router ID TLV provides one.
The IPv4 Interface Address sub-TLV of the Extended IS Reachability TLV contains an IPv4 address for the local end of a link.
The IPv4 Neighbor Address 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. A router constructs it using one of the IPv4 addresses received in the IS-IS Hello PDU from the neighbor on the link.
The IPv6 Neighbor Address sub-TLV holds a globally unique IPv6 address for the interface of the peer, which can be either a global or a unique-local address. The IPv6 Interface Address TLV of RFC 5308 only contains link-local addresses when used in the Hello PDU, so a neighbor's address from that TLV cannot be used when constructing the IPv6 Neighbor Address sub-TLV. Instead the RFC defines an additional TLV, the IPv6 Global Interface Address TLV, which is included in Hello PDUs to provide the globally unique IPv6 address that a neighbor router needs in order to construct the IPv6 Neighbor Address sub-TLV.
The SRLG TLV, type 138, defined in RFC 5307 contains the set of shared risk link groups associated with a link. It identifies the link using either local and remote IPv4 addresses or, for point-to-point unnumbered links, link-local and remote identifiers, and it includes a flags field to indicate which type of identifier is used. When only IPv6 is used, IPv4 addresses and link-local 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 of type 138 to identify the link by IPv6 addresses, so a new TLV is needed.
Four existing pieces of information name links and routers with IPv4 addresses: the router identifier, the local interface address, the neighbour's address and the shared risk groups. Each needs an IPv6 counterpart, and one of them, the shared risk group TLV, cannot simply be extended.
| Existing IPv4 construct | IPv6 counterpart |
|---|---|
| TE Router ID TLV | IPv6 TE Router ID TLV, type 140 |
| IPv4 Interface Address sub-TLV | IPv6 Interface Address sub-TLV, type 12 |
| IPv4 Neighbor Address sub-TLV | IPv6 Neighbor Address sub-TLV, type 13 |
| SRLG TLV, type 138 THIS RFC | IPv6 SRLG TLV, type 139 |
| IPv6 Interface Address TLV in Hello PDUs THIS RFC | IPv6 Global Interface Address TLV, type 233 |
§4.1The IPv6 Router ID and Address Sub-TLVs
The IPv6 TE Router ID TLV is TLV type 140. It 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 TLV. If a router implements traffic engineering for IPv6 it must include this TLV in its LSP, and it 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 that can lead to forwarding loops when interacting with systems that do not support this 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, and it can occur multiple times. Implementations must not inject a /128 prefix for the interface address into their routing or forwarding table, because that can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions of RFC 5305 it may include or omit this sub-TLV. If it implements IPv6 traffic engineering it must include it, except on an unnumbered point-to-point link, where the Link-Local Interface Identifiers sub-TLV is used instead. It must not contain an IPv6 link-local address.
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, and it can occur multiple times. The same rule about not injecting a /128 prefix applies, and the same rules govern when it must be included: a router implementing IPv6 traffic engineering must include it for point-to-point links, except on an unnumbered point-to-point link where the Link-Local Interface Identifiers sub-TLV is used instead. It must not contain an IPv6 link-local address.
The router identifier names the router itself with a 16-byte address that does not change with its interfaces. The two sub-TLVs name the two ends of a link. None of them may carry a link-local address, and none of them may be turned into a host route, because an older router that does not know them would then black-hole traffic.
§4.4The IPv6 SRLG TLV
The IPv6 SRLG TLV has type 139 and carries the Shared Risk Link Group information defined in RFC 4202. Its value is a data structure consisting of 6 octets of System ID, 1 octet of pseudonode number, 1 octet of flags, 16 octets of IPv6 interface address, an optional 16 octets of IPv6 neighbor address, and a variable list of SRLG values where each element in the list has 4 octets.
The neighbor is identified by its System ID of 6 octets plus one octet to indicate the pseudonode number if the neighbor is on a LAN interface. The 1-octet flags field has one flag defined: the NA bit, set to 1 when the IPv6 neighbor address is included and to 0 when it is not. Other bits in the flags field are reserved for future use. Any bit not understood by an implementation must be set to zero by the sender, and if a router receives an IPv6 SRLG TLV with non-zero values for any bit it does not understand, it must ignore the TLV, that is, not use it locally but flood it unchanged to its neighbours as normal. That rule is what allows alternative ways of identifying the link to be added later: an implementation that does not understand such an extension ignores the TLV rather than misinterpret it.
The length of the TLV is 24 plus 4 times the number of SRLG values, plus 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, four rules apply. 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 of type 139 must not be used to describe the shared risk link groups for a given link if it is possible to use the SRLG TLV of type 138. If both an SRLG TLV and an IPv6 SRLG TLV are received describing the shared risk link groups for the same link, the receiver must apply the SRLG TLV and ignore the IPv6 SRLG TLV. In other words, if shared risk link groups are to be advertised for a link and the Extended IS Reachability TLV describing that link contains IPv4 interface or neighbor address sub-TLVs, or the link-local identifiers sub-TLV, then the groups must be advertised in the SRLG TLV of type 138.
The shared risk group TLV says which sets of links tend to fail together, so that a path can avoid depending on two links that share a fate. This one names the link with IPv6 addresses. It carries an optional neighbour address, and it can be extended later by adding flag bits, because a router that sees an unknown flag just passes the TLV on without using it.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
SYSTEM-ID | System ID | 6 bytes | The system ID of the node the link belongs to. | |
PSEUDONODE-NUMBER | Pseudonode num | 1 byte | The pseudonode number, used when the neighbor is on a LAN interface. | |
FLAGS | Flags | 1 byte | One flag is defined: NA, set to 1 when the IPv6 neighbor address is included. Other bits are reserved and must be set to zero if not understood. | |
INTERFACE-ADDRESS | IPv6 interface address | 16 bytes | The IPv6 address of the local end of the link. | |
NEIGHBOR-ADDRESS | IPv6 neighbor address | 16 bytes | Optional. The IPv6 address of the far end of the link, present when the NA flag is set. | |
SRLG-VALUE | SRLG value | 4 bytes | One shared risk link group value. The list is variable, with 4 octets per element. |
§4.5The IPv6 Global Interface Address TLV
The IPv6 Global Interface Address TLV is TLV type 233. Its structure is identical to that of the IPv6 Interface Address TLV defined in RFC 5308, but the semantics differ. The TLV is included in Hello PDUs for those interfaces that use the IPv6 traffic engineering extensions, and it contains the global or unique-local IPv6 addresses assigned to the interface that is sending the Hello. It is not used in LSPs.
This is the piece that makes the neighbour sub-TLV possible. A router next door needs a globally unique address for the far end of the link, and the IPv6 Interface Address TLV only carries link-local addresses in Hello PDUs, so a separate TLV is needed to carry the usable address.
Neighbouring routers exchange Hello packets. This new field lets a router put its routable IPv6 address in that Hello, so the other end can name it in the shared risk group information it later advertises.
§7IANA Considerations
The document defines three new IS-IS TLV types, which IANA has reflected in the IS-IS TLV code point registry.
- Type 139, IPv6 SRLG TLV, is carried in LSPs.
- Type 140, IPv6 TE Router ID, is carried in LSPs.
- Type 233, IPv6 Global Interface Address TLV, is carried in Hello PDUs.
It also defines two new sub-TLV types of top-level TLV 22, which IANA has reflected in the Sub-TLVs for TLV 22, 141 and 222 registry. Sub-TLV type 12 is the IPv6 Interface Address and sub-TLV type 13 is the IPv6 Neighbor Address. Both are valid in TLV 22, TLV 141 and TLV 222, and both are 16 octets long.
IANA keeps the list of IS-IS TLV numbers and where each one may appear. Three new numbers and two new sub-numbers are added here.
- 139IPv6 SRLG TLV — Carried in LSPs. Names the link with IPv6 addresses and lists the shared risk link groups.
- 140IPv6 TE Router ID — Carried in LSPs. Holds a 16-octet IPv6 address identifying the traffic engineering node.
- 233IPv6 Global Interface Address TLV — Carried in Hello PDUs. Holds the global or unique-local addresses of the sending interface.
- 12IPv6 Interface Address sub-TLV — A sub-TLV of TLV 22, 141 and 222. Holds the 16-octet IPv6 address of the local end of a link.
- 13IPv6 Neighbor Address sub-TLV — A sub-TLV of TLV 22, 141 and 222. Holds the 16-octet IPv6 address of the far end of a link.
§5Security Considerations
This document raises no new security issues for IS-IS. For the general security considerations for IS-IS, see RFC 5304, IS-IS Cryptographic Authentication.
Nothing new. The usual IS-IS authentication guidance applies, and these TLVs are covered by it in the same way as the existing ones.