IS-IS Capabilities: IS-IS Extensions for Advertising Router Information
A way for IS-IS routers to tell each other what they can do.
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <https://www.rfc-editor.org/info/rfc7981>.
@misc{rfc7981,
series = {Request for Comments},
number = 7981,
howpublished = {RFC 7981},
publisher = {RFC Editor},
doi = {10.17487/RFC7981},
url = {https://www.rfc-editor.org/info/rfc7981},
author = {L. Ginsberg and S. Previdi and M. Chen},
title = {{IS-IS Extensions for Advertising Router Information}},
pagetotal = 10,
year = 2016,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7981 S. Previdi
Obsoletes: 4971 Cisco Systems
Category: Standards Track M. Chen
ISSN: 2070-1721 Huawei Technologies Co., Ltd
October 2016
IS-IS Extensions for Advertising Router Information
Abstract
This document defines a new optional Intermediate System to
Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
sub-TLVs, which allows a router to announce its capabilities within
an IS-IS level or the entire routing domain. This document obsoletes
RFC 4971.
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 7841.
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/rfc7981.
Copyright Notice
Copyright (c) 2016 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
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the IS-IS Router
CAPABILITY TLV ..................................................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Appendix A. Changes to RFC 4971 ...................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
1. Introduction
There are several situations where it is useful for the IS-IS
[ISO10589] [RFC1195] routers to learn the capabilities of the other
routers of their IS-IS level, area, or routing domain. For the sake
of illustration, three examples related to MPLS Traffic Engineering
(TE) are described here:
1. Mesh-group: The setting up of a mesh of TE Label Switched Paths
(LSPs) [RFC5305] requires some significant configuration effort.
[RFC4972] proposes an auto-discovery mechanism whereby every
Label Switching Router (LSR) of a mesh advertises its mesh-group
membership by means of IS-IS extensions.
2. Point-to-Multipoint TE LSP (RFC4875): A specific sub-TLV
[RFC5073] allows an LSR to advertise its Point-to-Multipoint
capabilities ([RFC4875] and [RFC4461]).
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or
the IPv6 Traffic Engineering Router IDs.
The use of IS-IS for Path Computation Element (PCE) discovery may
also be considered and will be discussed in the PCE WG.
The capabilities mentioned above require the specification of new
sub-TLVs carried within the IS-IS Router CAPABILITY TLV defined in
this document.
Note that the examples above are provided for the sake of
illustration. This document proposes a generic capability
advertising mechanism that is not limited to MPLS Traffic
Engineering.
This document defines a new optional IS-IS TLV named CAPABILITY,
formed of multiple sub-TLVs, which allows a router to announce its
capabilities within an IS-IS level or the entire routing domain. The
applications mentioned above require the specification of new sub-
TLVs carried within the IS-IS Router CAPABILITY TLV defined in this
document.
Definition of these sub-TLVs is outside the scope of this document.
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 RFC 2119 [RFC2119].
2. IS-IS Router CAPABILITY TLV
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
1 octet that specifies the number of bytes in the value field, and a
variable length value field that starts with 4 octets of Router ID,
indicating the source of the TLV, followed by 1 octet of flags.
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are
formatted as described in [RFC5305].
TYPE: 242
LENGTH: from 5 to 255
VALUE:
Router ID (4 octets)
Flags (1 octet)
Set of optional sub-TLVs (0-250 octets)
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
Currently, two bit flags are defined.
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV
MUST be flooded across the entire routing domain. If the S bit is
not set(0), the TLV MUST NOT be leaked between levels. This bit MUST
NOT be altered during the TLV leaking.
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from
Level 2 (L2) to Level 1 (L1), the D bit MUST be set. Otherwise, this
bit MUST be clear. IS-IS Router CAPABILITY TLVs with the D bit set
MUST NOT be leaked from Level 1 to Level 2. This is to prevent TLV
looping.
The IS-IS Router CAPABILITY TLV is OPTIONAL. As specified in
Section 3, more than one IS-IS Router CAPABILITY TLV from the same
source MAY be present.
This document does not specify how an application may use the IS-IS
Router CAPABILITY TLV, and such specification is outside the scope of
this document.
3. Elements of Procedure
The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV [RFC5305]. If no Traffic
Engineering Router ID is assigned, the Router ID SHOULD be identical
to an IP Interface Address [RFC1195] advertised by the originating
IS. If the originating node does not support IPv4, then the reserved
value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE
Router ID sub-TLV [RFC5316] MUST be present in the TLV. IS-IS Router
CAPABILITY TLVs that have a Router ID of 0.0.0.0 and do NOT have the
IPv6 TE Router ID sub-TLV present MUST NOT be used.
When advertising capabilities with different flooding scopes, a
router MUST originate a minimum of two IS-IS Router CAPABILITY TLVs,
each TLV carrying the set of sub-TLVs with the same flooding scope.
For instance, if a router advertises two sets of capabilities, C1 and
C2, with an area/level scope and routing domain scope respectively,
C1 and C2 being specified by their respective sub-TLV(s), the router
will originate two IS-IS Router CAPABILITY TLVs:
o One IS-IS Router CAPABILITY TLV with the S flag cleared, carrying
the sub-TLV(s) relative to C1. This IS-IS Router CAPABILITY TLV
will not be leaked into another level.
o One IS-IS Router CAPABILITY TLV with the S flag set, carrying the
sub-TLV(s) relative to C2. This IS-IS Router CAPABILITY TLV will
be leaked into other IS-IS levels. When the TLV is leaked from
Level 2 to Level 1, the D bit will be set in the Level 1 LSP
advertisement.
In order to prevent the use of stale IS-IS Router CAPABILITY TLVs, a
system MUST NOT use an IS-IS Router CAPABILITY TLV present in an LSP
of a system that is not currently reachable via Level x paths, where
"x" is the level (1 or 2) in which the sending system advertised the
TLV. This requirement applies regardless of whether or not the
sending system is the originator of the IS-IS Router CAPABILITY TLV.
When an IS-IS Router CAPABILITY TLV is not used, either due to a lack
of reachability to the originating router or due to an unusable
Router ID, note that leaking the IS-IS Router CAPABILITY TLV is one
of the uses that is prohibited under these conditions.
Example: If Level 1 router A generates an IS-IS Router CAPABILITY
TLV and floods it to two L1/L2 routers, S and T, they will flood
it into the Level 2 domain. Now suppose the Level 1 area
partitions, such that A and S are in one partition and T is in
another. IP routing will still continue to work, but if A now
issues a revised version of the CAP TLV, or decides to stop
advertising it, S will follow suit, but without the above
prohibition, T will continue to advertise the old version until
the LSP times out.
Routers in other areas have to choose whether to trust T's copy of
A's IS-IS Router CAPABILITY TLV or S's copy of A's IS-IS Router
CAPABILITY TLV, and they have no reliable way to choose. By
making sure that T stops leaking A's information, the possibility
that other routers will use stale information from A is
eliminated.
In IS-IS, the atomic unit of the update process is a TLV -- or more
precisely, in the case of TLVs that allow multiple entries to appear
in the value field (e.g., IS-neighbors), the atomic unit is an entry
in the value field of a TLV. If an update to an entry in a TLV is
advertised in an LSP fragment different from the LSP fragment
associated with the old advertisement, the possibility exists that
other systems can temporarily have either 0 copies of a particular
advertisement or 2 copies of a particular advertisement, depending on
the order in which new copies of the LSP fragment that had the old
advertisement and the fragment that has the new advertisement arrive
at other systems.
Wherever possible, an implementation SHOULD advertise the update to
an IS-IS Router CAPABILITY TLV in the same LSP fragment as the
advertisement that it replaces. Where this is not possible, the two
affected LSP fragments should be flooded as an atomic action.
Systems that receive an update to an existing IS-IS Router CAPABILITY
TLV can minimize the potential disruption associated with the update
by employing a holddown time prior to processing the update so as to
allow for the receipt of multiple LSP fragments associated with the
same update prior to beginning processing.
Where a receiving system has two copies of an IS-IS Router CAPABILITY
TLV from the same system that have conflicting information for a
given sub-TLV, the procedure used to choose which copy shall be used
is undefined.
4. Interoperability with Routers Not Supporting the IS-IS Router
CAPABILITY TLV
Routers that do not support the IS-IS Router CAPABILITY TLV MUST
silently ignore the TLV(s) and continue processing other TLVs in the
same LSP. Routers that do not support specific sub-TLVs carried
within an IS-IS Router CAPABILITY TLV MUST silently ignore the
unsupported sub-TLVs and continue processing those sub-TLVs that are
supported in the IS-IS Router CAPABILITY TLV. How partial support
may impact the operation of the capabilities advertised within the
IS-IS Router CAPABILITY TLV is outside the scope of this document.
In order for IS-IS Router CAPABILITY TLVs with domain-wide scope
originated by L1 routers to be flooded across the entire domain, at
least one L1/L2 router in every area of the domain MUST support the
Router CAPABILITY TLV.
If leaking of the IS-IS Router CAPABILITY TLV is required, the entire
CAPABILITY TLV MUST be leaked into another level without change
(except for changes to the TLV flags as noted in Section 2) even
though it may contain some sub-TLVs that are unsupported by the
router doing the leaking.
5. Security Considerations
Any new security issues raised by the procedures in this document
depend upon the opportunity for LSPs to be snooped and modified, the
ease/difficulty of which has not been altered. As the LSPs may now
contain additional information regarding router capabilities, this
new information would also become available to an attacker.
Specifications based on this mechanism need to describe the security
considerations around the disclosure and modification of their
information. Note that an integrity mechanism, such as the ones
defined in [RFC5304] or [RFC5310], should be applied if there is high
risk resulting from modification of capability information.
6. IANA Considerations
IANA originally assigned a TLV codepoint for the IS-IS Router
CAPABILITY TLV (242) as described in RFC 4971. IANA has updated this
entry in the "TLV Codepoints Registry" to refer to this document.
7. References
7.1. Normative References
[ISO10589] International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- 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)", ISO/IEC 10589:2002, Second Edition,
November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic Engineering
Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <http://www.rfc-editor.org/info/rfc5316>.
7.2. Informative References
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
<http://www.rfc-editor.org/info/rfc4461>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>.
[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
Previdi, S., Psenak, P., and P. Mabbey, "Routing
Extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007,
<http://www.rfc-editor.org/info/rfc4972>.
Appendix A. Changes to RFC 4971
This document makes the following changes to RFC 4971.
RFC 4971 only allowed a 32-bit Router ID in the fixed header of TLV
242. This is problematic in an IPv6-only deployment where an IPv4
address may not be available. This document specifies:
1. The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV (134) if available.
2. If no Traffic Engineering Router ID is assigned, the Router ID
SHOULD be identical to an IP Interface Address [RFC1195]
advertised by the originating IS.
3. If the originating node does not support IPv4, then the reserved
value 0.0.0.0 MUST be used in the Router ID field, and the IPv6
TE Router ID sub-TLV [RFC5316] MUST be present in the TLV.
In addition, some clarifying editorial changes have been made.
Acknowledgements
The authors of RFC 4971 thanked Jean-Louis Le Roux, Paul Mabey,
Andrew Partan, and Adrian Farrel for their useful comments.
The authors of this document would like to thank Kris Michielsen for
calling attention to the problem associated with an IPv6-only router.
Authors' Addresses
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
United States of America
Email: ginsberg@cisco.com
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
Email: sprevidi@cisco.com
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District
Beijing 100085
China
Email: mach.chen@huawei.com
ISO Plain Language
On this page
§1Why Routers Need to Announce Capabilities
There are several situations where it is useful for IS-IS routers to learn the capabilities of the other routers of their IS-IS level, area or routing domain. Three examples related to MPLS Traffic Engineering illustrate this. First, a mesh group: setting up a mesh of traffic engineering label switched paths requires significant configuration effort, and RFC 4972 proposes an auto-discovery mechanism in which every label switching router of a mesh advertises its mesh-group membership by means of IS-IS extensions. Second, point-to-multipoint traffic engineering label switched paths: a specific sub-TLV allows a label switching router to advertise its point-to-multipoint capabilities. Third, inter-area traffic engineering, which needs the advertisement of the IPv4 and or the IPv6 traffic engineering Router IDs.
The use of IS-IS for Path Computation Element discovery may also be considered and is discussed in the PCE working group.
The capabilities mentioned above require the specification of new sub-TLVs carried within the IS-IS Router CAPABILITY TLV defined in this document. The examples are given for the sake of illustration: the document proposes a generic capability advertising mechanism that is not limited to MPLS traffic engineering.
This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. Definition of the sub-TLVs themselves is outside the scope of this document, as is the specification of how an application may use the TLV.
Some jobs need the routers in a network to know what each other can do. Setting up a mesh of traffic engineering paths, for example, needs every router to say which group it belongs to. This document gives them a general place to say so, so that each kind of information can be defined separately.
§2The IS-IS Router CAPABILITY TLV
The IS-IS Router CAPABILITY TLV is composed of one octet for the type, one octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, followed by one octet of flags. A set of optional sub-TLVs may follow the flag field, formatted as described in RFC 5305. The type is 242, the length runs from 5 to 255, and the optional sub-TLVs occupy 0 to 250 octets.
Two bit flags are defined. The S bit, with value 0x01, decides the reach of the record: if it is set, the TLV MUST be flooded across the entire routing domain, and if it is not set, the TLV MUST NOT be leaked between levels. The bit MUST NOT be altered during the leaking. The D bit, with value 0x02, is set when the TLV is leaked from Level 2 to Level 1, and must be clear otherwise. TLVs with the D bit set MUST NOT be leaked from Level 1 to Level 2, which is what prevents the record from looping.
The TLV is OPTIONAL, and more than one IS-IS Router CAPABILITY TLV from the same source MAY be present.
IANA originally assigned the codepoint 242 to the IS-IS Router CAPABILITY TLV as described in RFC 4971, and has updated the entry in the TLV Codepoints Registry to refer to this document.
The record is small: a four octet identifier for the router that sent it, one octet of flags, and then whatever pieces of information other specifications define. Two of the flag bits matter: one says whether the record should travel across the whole routing domain, and the other records that it has already been copied down a level, so that it is not copied back up and forth forever.
TYPE: 242
LENGTH: from 5 to 255
VALUE:
Router ID (4 octets)
Flags (1 octet)
Set of optional sub-TLVs (0-250 octets)
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+- 242TLV type — The codepoint for the IS-IS Router CAPABILITY TLV, assigned in RFC 4971 and now referring to RFC 7981.
- 0x01S bit — If set, the TLV MUST be flooded across the entire routing domain. If not set, it MUST NOT be leaked between levels, and the bit MUST NOT be altered during leaking.
- 0x02D bit — Set when the TLV is leaked from Level 2 to Level 1, and clear otherwise. A TLV with the D bit set MUST NOT be leaked from Level 1 to Level 2, to prevent looping.
§3Elements of Procedure
The Router ID SHOULD be identical to the value advertised in the traffic engineering Router ID TLV of RFC 5305. If no traffic engineering Router ID is assigned, it SHOULD be identical to an IP interface address advertised by the originating IS-IS router. If the originating node does not support IPv4, the reserved value 0.0.0.0 MUST be used in the Router ID field and the IPv6 traffic engineering Router ID sub-TLV MUST be present. TLVs that have a Router ID of 0.0.0.0 and do not have the IPv6 traffic engineering Router ID sub-TLV present MUST NOT be used. These rules are the change this document makes to RFC 4971, which only allowed a 32-bit Router ID in the fixed header, a problem in an IPv6-only deployment where an IPv4 address may not be available.
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two IS-IS Router CAPABILITY TLVs, each carrying the set of sub-TLVs with the same flooding scope. So a router advertising two sets of capabilities, C1 with an area or level scope and C2 with a routing domain scope, originates one TLV with the S flag cleared carrying the sub-TLVs for C1, which will not be leaked into another level, and one TLV with the S flag set carrying the sub-TLVs for C2, which will be leaked into other IS-IS levels. When that second TLV is leaked from Level 2 to Level 1, the D bit is set in the Level 1 LSP advertisement.
To prevent the use of stale TLVs, a system MUST NOT use an IS-IS Router CAPABILITY TLV present in an LSP of a system that is not currently reachable via Level x paths, where x is the level in which the sending system advertised the TLV. This applies whether or not the sending system is the originator of the TLV. When the TLV is not used, whether because of a lack of reachability or an unusable Router ID, leaking it is one of the uses prohibited under these conditions. The example in the document: if a Level 1 router A generates the TLV and floods it to two routers, S and T, they will flood it into the Level 2 domain. If the Level 1 area then partitions so that A and S are in one partition and T in another, IP routing will still work, but if A issues a revised TLV or stops advertising it, S will follow suit while T keeps advertising the old version until the LSP times out. Routers in other areas have to choose between T's copy and S's copy of A's TLV and have no reliable way to choose, so making sure that T stops leaking A's information removes the possibility that other routers use stale information.
In IS-IS, the atomic unit of the update process is a TLV, or, for TLVs that allow multiple entries in the value field, an entry in that field. If an update to an entry is advertised in a different LSP fragment from the advertisement it replaces, other systems can temporarily hold either zero copies or two copies of an advertisement, depending on the order in which the fragments arrive. Wherever possible, an implementation SHOULD advertise the update in the same LSP fragment as the advertisement it replaces, and where that is not possible the two affected fragments should be flooded as an atomic action. A receiving system can minimize disruption by employing a holddown time before processing the update, so that several fragments of the same update can arrive first. Where a receiving system has two copies from the same system with conflicting information for a given sub-TLV, the procedure for choosing which copy to use is undefined.
Two rules matter in practice. A router that has both a local and a domain-wide set of capabilities sends two records, one for each scope, because a record cannot be both. And a router must stop using a capability record from a neighbour it can no longer reach, so that a partitioned area does not leave stale information circulating in the rest of the domain.
| Aspect | Area or level scope | Routing domain scope |
|---|---|---|
| S flag | Cleared | Set |
| Leaking | Not leaked into another level | Leaked into other IS-IS levels |
| D bit when leaked from Level 2 to Level 1 | Not applicable | Set in the Level 1 LSP advertisement |
| Sub-TLVs carried | The ones belonging to that scope | The ones belonging to that scope |
§4Routers That Do Not Support the TLV
Routers that do not support the IS-IS Router CAPABILITY TLV MUST silently ignore the TLVs and continue processing the other TLVs in the same LSP. Routers that do not support specific sub-TLVs carried within it MUST silently ignore the unsupported sub-TLVs and continue processing those that are supported. How partial support affects the operation of the capabilities advertised is outside the scope of this document.
For the Router CAPABILITY TLVs with domain-wide scope, originated by Level 1 routers, to be flooded across the entire domain, at least one Level 1 to Level 2 router in every area of the domain MUST support the TLV.
If leaking of the TLV is required, the entire CAPABILITY TLV MUST be leaked into another level without change, except for the changes to the flags described earlier, even if it contains sub-TLVs that the router doing the leaking does not support.
A router that has never heard of this record simply skips it and carries on with the rest of the link state advertisement. That is what makes it safe to deploy: older routers ignore what they do not understand, and a router that copies the record into another level copies all of it, even the parts it cannot read.
- Unsupported TLVSilently ignore it and continue processing the other TLVs in the same LSP.
- Unsupported sub-TLVSilently ignore the unsupported sub-TLVs and carry on with the ones that are supported.
- LeakingThe entire CAPABILITY TLV must be leaked into another level without change, even if it holds sub-TLVs the leaking router does not support.
- Domain-wide floodingAt least one L1/L2 router in every area of the domain must support the TLV.
§5Security Considerations
Any new security issues raised by the procedures in this document depend on the opportunity for link state advertisements to be snooped and modified, whose ease or difficulty has not been altered. As the LSPs may now contain additional information regarding router capabilities, that new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information.
An integrity mechanism, such as the ones defined in RFC 5304 or RFC 5310, should be applied if there is high risk resulting from modification of capability information.
Everything the protocol sends is visible to anyone who can watch the routing protocol, and that includes the new capability information. Where it would matter, for instance if the information guided traffic that an attacker could redirect, the existing IS-IS authentication mechanisms should be used to protect it.
§6The Codepoint and the Changes from RFC 4971
IANA originally assigned a TLV codepoint for the IS-IS Router CAPABILITY TLV, 242, as described in RFC 4971, and has updated that entry in the TLV Codepoints Registry to refer to this document.
RFC 4971 only allowed a 32-bit Router ID in the fixed header of TLV 242. That is problematic in an IPv6-only deployment, where an IPv4 address may not be available. This document therefore specifies that the Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV, 134, if one is available; that if no traffic engineering Router ID is assigned, the Router ID SHOULD be identical to an IP interface address advertised by the originating IS-IS router; and that if the originating node does not support IPv4, the reserved value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE Router ID sub-TLV MUST be present in the TLV. In addition, some clarifying editorial changes have been made.
The only real change from the earlier version is how the router's own identifier is filled in, so that a network that has no IPv4 addresses at all can still use the record. The rest is wording.