One document matched: draft-lamparter-isis-reachability-critical-subtlvs-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="yes" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents, but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/sections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-lamparter-isis-reachability-critical-subtlvs-00"
ipr="trust200902">
<front>
<title abbrev="IS-IS Reachability with critical Sub-TLVs">
IS-IS Reachability with critical Sub-TLVs</title>
<author fullname="David Lamparter" initials="D." surname="Lamparter">
<organization>NetDEF</organization>
<address>
<postal>
<street></street>
<city>Leipzig</city>
<code>04103</code>
<region></region>
<country>Germany</country>
</postal>
<email>david@opensourcerouting.org</email>
</address>
</author>
<date/>
<area>Internet Engineering Task Force</area>
<workgroup>isis</workgroup>
<abstract>
<t>While previously existing TLVs for IP Reachability extensibly support
Sub-TLVs, these cannot be marked as critical. This is required for
extending router behaviour with additional qualifiers on routes, hence
this document introduces new Reachability TLVs that support critical
Sub-TLVs.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IS-IS is very extensible by design; Newly defined Sub-TLVs can be
added in many places. However, the behaviour for unknown Sub-TLVs is
always assumed to be "ignore", there is currently no way to prescribe
different behaviour. Therefore, a system that receives a Reachability
TLV with a Sub-TLV it doesn't recognise will silently process the
Reachability with a reduced set of specified information.</t>
<t>This is not desirable for situations where Sub-TLVs provide essential
information for the reachability, in particular if that information
restricts the usability of the reachability. At the time of writing,
usage by extensions of the following types is envisioned:</t>
<t>
<list style="symbols">
<t>further qualifications for the route target, e.g. restricted
source address or flowlabel. In this case the reachability
information is incomplete (and the route does not match) without
these critical fields.</t>
<t>mandatory encapsulation specifications, e.g. routing headers or
labels required for the egress router or systems outside the
domain. Here, ignorance of that information would render these
systems unable to apply correct forwarding decisions.</t>
</list>
</t>
<t>
Other future developments may find even more use cases for this TLV.
The functionality defined here could also have been used for <xref
target="RFC5120">M-ISIS</xref>
reachabilities in order to hide them from non-M-ISIS routers without
introducing a new TLV type.
</t>
<t>Therefore, this document creates a new Reachability TLV with a
critical Sub-TLV part, where the specified behavior on unrecognized
Sub-TLVs is to ignore the entire Reachability TLV, not just the
Sub-TLV.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Design considerations">
<t>This document specifies new Reachability TLVs for IPv4 and IPv6.
These new TLVs have two Sub-TLV blocks: one critical and one optional.
Sub-TLVs in the optional block behave exactly as Sub-TLVs in previous
Reachability TLVs (135, 235, 236, and 237.) This includes application
of the same TLV namespace, all TLVs defined for these four TLVs are
also applicable in the optional part of the new two TLVs.</t>
<t>The critical Sub-TLV block constitutes a separate namespace.
A system MUST keep these separated, and specifications MUST define
to which part exactly they apply. Expected combinations are:
<list style="symbols">
<t>135, 235, 236, 237, TBD1 and TBD2 optional</t>
<t>135, 235, TBD1 optional (IPv4)</t>
<t>236, 237, TBD2 optional (IPv6)</t>
<t>TBD1 and TBD2 critical</t>
<t>TBD1 critical (IPv4)</t>
<t>TBD2 critical (IPv6)</t>
</list>
Though no such use is foreseen at this point, a specification MAY
specify a TLV to be valid in either the optional or critical part.
This TLV may end up with different codepoints in each of the
namespaces.
</t>
<t>A system MUST NOT originate these new TLVs with an empty critical
part. Doing so would create an alternate encoding of the previous
TLVs, breaking interoperability. Systems SHOULD process a new TLV
with an empty critical block.</t>
<t>There is no need for non-MT variants of these TLVs. If a system does
not implement M-ISIS, it MUST ignore all TLVs with a MT ID other than
zero.</t>
</section>
<section title="SPF Functional specification">
<t>This document assumes that all transit routers need to support
processing of the feature associated with a respective critical
Sub-TLV. Hence, on calculating a path for a reachability with critical
Sub-TLV A, all intermediate systems that do not indicate support for
Sub-TLV A must be excluded.</t>
<t>The logical result from this is essentially that separate SPF trees
MUST be calculated for each set of critical Sub-TLVs.</t>
<t>Calculation of these extra trees can be optimized by sharing
intermediate calculation results as far as critical Sub-TLV support is
identical.</t>
<t>A system MUST NOT blindly use a "more Sub-TLVs supported" SPF
calculation result for calculating paths that require only a subset of
these Sub-TLVs. This would result in a disagreement on shortest path
with other routers, which correctly used a SPF tree for the specific
combination.</t>
<section title="Simplified SPF">
<t>TBD: It is possible to construct a variant of this that doesn't
implicitly work with multiple topologies, instead marking routes as
unreachable if they transit over routers that do not support the
critical TLVs. This may be useful for simpler implementations.</t>
</section>
</section>
<section title="TLV formats">
<section title="IP/IPv6 Reachability TLV">
<t>The encoding for TLVs TBD1 and TBD2 is modified from TLVs 235 and
237 by inserting a second length field for the critical Sub-TLV part
before the existing length field for the optional Sub-TLV part. The
critical Sub-TLV part follows after the length field, then the
optional part.</t>
<figure><preamble>This results in the following TLV structure:</preamble>
<artwork>
(2/4 bytes TLV header)
2 octets of MT ID (12 bits, top 4 bits reserved)
-- multiple (n >= 1) occurences of the following:
4 octets of metric information
1 octet of control information, consisting of
1 bit of up/down information
1 bit indicating the presence of optional sub-TLVs
6 bits of prefix length
0-4/0-16 octets of IPv4/IPv6 prefix
4-n optional octets of sub-TLVs, if present consisting of
1/2 octets of length of critical sub-TLVs
2-n octets of critical sub-TLVs,
-- depending on presence of optional sub-TLVs indication:
0-2 octets of length of optional sub-TLVs
0-n octets of optional sub-TLVs,
where each sub-TLV (critical or optional) is a sequence of
1/2 octets of sub-type
1/2 octets of length of the value field of the sub-TLV
0-n octets of value
</artwork>
</figure>
<t>Unlike MT Reachability TLVs, this TLV MUST NOT be ignored if the MT
ID is zero. Instead, the information applies to the "standard"
topology.</t>
<t>The size of offset and length fields depends on the PDU in which the
TLV is found, as per <xref target="RFC7356"/>.</t>
<t>The critical sub-TLV part MUST NOT be empty. Reachability TLVs
without a critical Sub-TLV field MUST be used instead in this
case.</t>
<t>As in TLVs 235 and 237, the optional sub-TLV length and data fields
are only present if the "presence of optional sub-TLVs" bit is one.</t>
</section>
<section title="Reachability Critical Sub-TLVs Supported TLV">
<t></t>
<figure><preamble>Supported Critical Information Sub-TLV format</preamble>
<artwork>
0 1 LSB
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+ + + + + + + + +
| Type = TBD3 | : (1 / 2 bytes)
+-+-+-+-+-+-+-+-+ + + + + + + + +
| Length | : (1 / 2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Applicable TLV length |0| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Applicable TLV numbers | (n * 2 bytes)
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (multiple of this block allowed)
| Sub-TLV combination length |C| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV numbers | (n * 2 bytes)
: :
</artwork>
</figure>
<t>Applicable TLV length and numbers specify which (parent) TLVs this
information applies to. Both fields are always in 2-octet units
each, which means the length is even. Thus, the LSB of the length
field MUST be set to 0 on TLV origination. Systems SHOULD ignore the
entire TLV if the applicable TLV length field is not even. The same
applies if the applicable TLV length is zero, systems SHOULD ignore
the entire TLV.</t>
<t>Sub-TLV combination length and numbers specify supported Sub-TLVs
for the TLVs with applicable TLV numbers listed before. As with
Applicable TLVs, these are units of 2 octets each.</t>
<t>The LSB of the combination length is redefined to be the
"Combinatorial" bit. Any mixture (present or not present) of
Sub-TLVs listed with C=1, plus any Sub-TLVs present in at most one
list with C=0 are understood to be supported by the router. A
combination of Sub-TLVs present in two distinct lists with C=0 MUST
NOT be assumed to be in a router's supported set.</t>
<t>The block of Sub-TLV combination length and numbers MAY occur
multiple times, as MAY the entire TLV. The information MUST be
merged.</t>
<t>Systems MUST process known TLVs even if unknown TLVs are present.
The latter MUST be ignored.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="IS-IS TLV Codepoints">
<t>This document requests the allocation of two codepoints from the
IS-IS TLV Codepoints registry. Suggested values are 238 for TBD1 and
239 for TBD2.</t>
<figure><preamble>Top-level codepoints</preamble>
<artwork>
Value Name IIH LSP SNP Purge
TBD1 MT IPv4 Reach with Critical Sub-TLVs n y n n
TBD2 MT IPv6 Reach with Critical Sub-TLVs n y n n
</artwork>
</figure>
<t>A codepoint from the Sub-TLVs for TLV 144 registry is also
requested:</t>
<figure><preamble>TLV 144 Sub-TLV codepoints</preamble>
<artwork>
Value Name
TBD3 Reachability Critical Sub-TLVs Supported
</artwork>
</figure>
</section>
<section title="TLVs 135, 235, 236, 237 Sub-TLV Registry">
<t>The registry for Sub-TLVs below TLVs 135, 235, 236, and 237 is
requested to be renamed to "Sub-TLVs for TLVs 135, 235, 236, 237,
TBD1 (optional) and TBD2 (optional)". Two new columns are added
to the table: "TBD1 (optional)" and "TBD2 (optional)". The value
for preexisting entries is copied from 235 to TBD1 and from 237 to
TBD2. This document is added as reference.</t>
</section>
<section title="TLVs TBD1, TBD2 critical Sub-TLV Registry">
<t>This document requests creation of a new registry named "Sub-TLVs
for TLVs TBD1 (critical), and TBD2 (critical)". Procedures and
experts are inherited from the registry in the previous paragraph.
The registry's table is initially empty and has a total of two
applicability columns titled "TBD1 (critical)" and "TBD2
(critical)". The starting value for allocations is 1.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The mechanism outlined in this document can be used to perform memory
and processor resource exhaustion attacks against routers. By
introducing reachabilities with different sets of critical Sub-TLVs
present, participating routers are forced to calculate different SPF
trees.</t>
<t>As a countermeasure, routers SHOULD:</t>
<t>
<list style="symbols">
<t>only calculate SPF trees for critical TLV combinations they
support</t>
<t>conflate SPF trees where logically correct, i.e. where routers'
lists of critical TLV combinations overlap</t>
</list>
</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>No privacy considerations apply to this document, as it only specifies
routing control plane information.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is largely the result of discussions with Fred Baker.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">October 2014</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="IS-IS">
<front>
<!-- [IS-IS] ISO/IEC 10589:2002, Second Edition, "", 2002. -->
<title>Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the Protocol
for Providing the Connectionless-mode Network Service (ISO
8473)</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
</reference>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5120"?>
<?rfc include="reference.RFC.7356"?>
</references>
<!--
<references title="Informative References">
</references>
-->
<!-- appendix: correctness? -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:37 |