rfc8918xml2.original.xml   rfc8918.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<!-- used by XSLT processors --> docName="draft-ietf-lsr-isis-invalid-tlv-03" number="8918"
<!-- For a complete list and description of processing instructions (PIs), ipr="trust200902" updates="5305 6232" obsoletes="" submissionType="IETF"
please see http://xml.resource.org/authoring/README.html. --> category="std" consensus="true" xml:lang="en" tocInclude="true"
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds tocDepth="4" symRefs="true" sortRefs="true" version="3">
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) --> <!-- xml2rfc v2v3 conversion 2.47.0 -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-lsr-isis-invalid-tlv-03"
ipr="trust200902" updates="5305 6232">
<front> <front>
<title abbrev="draft-ietf-lsr-isis-invalid-tlv">Invalid TLV Handling in <title abbrev="Invalid TLV Handling in IS-IS">Invalid TLV Handling in
IS-IS</title> IS-IS</title>
<seriesInfo name="RFC" value="8918"/>
<author fullname="Les Ginsberg" initials="L." surname="Ginsberg"> <author fullname="Les Ginsberg" initials="L." surname="Ginsberg">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>ginsberg@cisco.com</email> <email>ginsberg@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Paul Wells" initials="P." surname="Wells"> <author fullname="Paul Wells" initials="P." surname="Wells">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>pauwells@cisco.com</email> <email>pauwells@cisco.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Tony Li" initials="T" surname="Li"> <author fullname="Tony Li" initials="T" surname="Li">
<organization>Arista Networks</organization> <organization>Arista Networks</organization>
<address> <address>
<postal> <postal>
<street>5453 Great America Parkway</street> <street>5453 Great America Parkway</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region>
<region>California</region>
<code>95054</code> <code>95054</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>tony.li@tony.li</email> <email>tony.li@tony.li</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Tony Przygienda" initials="T" surname="Przygienda"> <author fullname="Tony Przygienda" initials="T" surname="Przygienda">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1194 N. Matilda Ave</street> <street>1194 N. Matilda Ave</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region>
<region>California</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>prz@juniper.net</email> <email>prz@juniper.net</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Shraddha Hegde" initials="S" surname="Hegde"> <author fullname="Shraddha Hegde" initials="S" surname="Hegde">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Embassy Business Park</street> <street>Embassy Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>KA</region> <region>KA</region>
<code>560093</code> <code>560093</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>shraddha@juniper.net</email> <email>shraddha@juniper.net</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date year="2020" month="September"/>
<date year="2020"/>
<area>Routing</area> <area>Routing</area>
<workgroup>LSR Working Group</workgroup> <workgroup>LSR Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>TLV</keyword> <keyword>TLV</keyword>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<abstract> <abstract>
<t>Key to the extensibility of the Intermediate System to Intermediate <t>The key to the extensibility of the Intermediate System to Intermediate
System (IS-IS) protocol has been the handling of unsupported and/or System (IS-IS) protocol has been the handling of unsupported and/or
invalid Type/Length/Value (TLV) tuples. Although there are explicit invalid Type-Length-Value (TLV) tuples. Although there are explicit
statements in existing specifications, deployment experience has shown statements in existing specifications, deployment experience has shown
that there are inconsistencies in the behavior when a TLV which is that there are inconsistencies in the behavior when a TLV that is
disallowed in a particular Protocol Data Unit (PDU) is received.</t> disallowed in a particular Protocol Data Unit (PDU) is received.</t>
<t>This document discusses such cases and makes the correct behavior <t>This document discusses such cases and makes the correct behavior
explicit in order to ensure that interoperability is maximized.</t> explicit in order to ensure that interoperability is maximized.</t>
<t>This document updates RFCs 5305 and 6232.</t>
<t>This document updates RFC5305 and RFC6232.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The Intermediate System to Intermediate System (IS-IS) protocol <xref <t>The Intermediate System to Intermediate System (IS-IS) protocol <xref
target="ISO10589"/> utilizes Type/Length/Value (TLV) encoding for all target="ISO10589" format="default"/> utilizes Type-Length-Value (TLV)
content in the body of Protocol Data Units (PDUs). New extensions to the encoding for all content in the body of Protocol Data Units (PDUs). New
protocol are supported by defining new TLVs. In order to allow protocol extensions to the protocol are supported by defining new TLVs. In order
extensions to be deployed in a backwards compatible way an to allow protocol extensions to be deployed in a backwards compatible
implementation is required to ignore TLVs that it does not understand. way, an implementation is required to ignore TLVs that it does not
This behavior is also applied to sub-TLVs <xref target="RFC5305"/>, understand. This behavior is also applied to sub-TLVs <xref
which are contained within TLVs.</t> target="RFC5305" format="default"/>, which are contained within
TLVs.</t>
<t>Also essential to the correct operation of the protocol is having the <t>Also essential to the correct operation of the protocol is having the
validation of PDUs be independent from the validation of the TLVs validation of PDUs be independent from the validation of the TLVs
contained in the PDU. PDUs which are valid must be accepted <xref contained in the PDU. PDUs that are valid must be accepted <xref
target="ISO10589"/> even if an individual TLV contained within that PDU target="ISO10589" format="default"/> even if an individual TLV contained
is not understood or is invalid in some way (e.g., incorrect syntax, within that PDU is not understood or is invalid in some way (e.g.,
data value out of range, etc.).</t> incorrect syntax, data value out of range, etc.).</t>
<t>The set of TLVs (and sub-TLVs) that are allowed in each PDU type is
<t>The set of TLVs (and sub-TLVs) which are allowed in each PDU type is documented in the "TLV Codepoints Registry" established by <xref
documented in the TLV Codepoints Registry established by <xref target="RFC3563" format="default"/> and updated by <xref
target="RFC3563"/> and updated by <xref target="RFC6233"/> and <xref target="RFC6233" format="default"/> and <xref target="RFC7356"
target="RFC7356"/>.</t> format="default"/>.</t>
<t>This document is intended to clarify some aspects of existing <t>This document is intended to clarify some aspects of existing
specifications and thereby reduce the occurrence of non-conformant specifications and, thereby, reduce the occurrence of non-conformant
behavior seen in real world deployments. Although behaviors specified in behavior seen in real-world deployments. Although behaviors specified in
existing protocol specifications are not changed, the clarifications existing protocol specifications are not changed, the clarifications
contained in this document serve as updates to RFC 5305 (see Section contained in this document serve as updates to <xref target="RFC5305"/>
3.3) and RFC 6232 (see Section 3.4).</t> (see <xref target="app-sub-tlv" format="default"/>) and <xref
target="RFC6232" format="default"/> (see <xref
target="correct-poi"/>).</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section>
<section title="TLV Codepoints Registry"> <section numbered="true" toc="default">
<t><xref target="RFC3563"/> established the IANA-managed IS-IS TLV <name>TLV Codepoints Registry</name>
Codepoints Registry for recording assigned TLV code points <xref <t><xref target="RFC3563" format="default"/> established the
target="TLV_CODEPOINTS"/>. The initial contents of this registry were IANA-managed "IS-IS TLV Codepoints Registry" for recording assigned TLV
based on <xref target="RFC3359"/>.</t> codepoints <xref target="TLV_CODEPOINTS" format="default"/>. The
initial contents of this registry were based on <xref target="RFC3359"
format="default"/>.</t>
<t>The registry includes a set of columns indicating in which PDU types <t>The registry includes a set of columns indicating in which PDU types
a given TLV is allowed:</t> a given TLV is allowed:</t>
<dl newline="false" spacing="normal" indent="8">
<t>IIH - TLV is allowed in Intermediate System to Intermediate System <dt>IIH</dt>
Hello (IIH) PDUs (Point-to-point and LAN)</t> <dd>TLV is allowed in Intermediate System to Intermediate System
Hello (IIH) PDUs (Point-to-point and LAN)</dd>
<t>LSP - TLV is allowed in Link State PDUs (LSP)</t> <dt>LSP</dt>
<dd>TLV is allowed in Link State PDUs (LSPs)</dd>
<t>SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence <dt>SNP</dt>
Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP))</t> <dd>TLV is allowed in Sequence Number PDUs (SNPs) (Partial Sequence
Number PDUs (PSNPs) and Complete Sequence Number PDUs (CSNPs))</dd>
<t>Purge - TLV is allowed in LSP Purges <xref target="RFC6233"/></t> <dt>Purge</dt>
<dd>TLV is allowed in LSP Purges <xref target="RFC6233"
<t>If "Y" is entered in a column it means the TLV is allowed in the format="default"/></dd>
</dl>
<t>If "Y" is entered in a column, it means the TLV is allowed in the
corresponding PDU type.</t> corresponding PDU type.</t>
<t>If "N" is entered in a column, it means the TLV is not allowed in the
<t>If "N" is entered in a column it means the TLV is not allowed in the
corresponding PDU type.</t> corresponding PDU type.</t>
</section> </section>
<section anchor="TLV-Acceptance" numbered="true" toc="default">
<section anchor="TLV-Acceptance" title="TLV Acceptance in PDUs "> <name>TLV Acceptance in PDUs</name>
<t>This section describes the correct behavior when a PDU is received <t>This section describes the correct behavior when a PDU
which contains a TLV which is specified as disallowed in the TLV that contains a TLV that is specified as disallowed in the "TLV
Codepoints Registry.</t> Codepoints Registry" is received.</t>
<section numbered="true" toc="default">
<section title="Handling of Disallowed TLVs in Received PDUs other than LS <name>Handling of Disallowed TLVs in Received PDUs Other Than LSP
P Purges"> Purges</name>
<t><xref target="ISO10589"/> defines the behavior required when a PDU <t><xref target="ISO10589" format="default"/> defines the behavior
is received containing a TLV which is "not recognised". It states (see required when a PDU is received containing a TLV that is "not
Sections 9.5 - 9.13):</t> recognised". It states (see Sections 9.5 - 9.13):</t>
<blockquote>
<t><figure> Any codes in a received PDU that are not recognised shall be ignored.
<artwork><![CDATA[ "Any codes in a received PDU that are not </blockquote>
recognised shall be ignored."]]></artwork> <t>This is the model to be followed when a TLV that is disallowed is
</figure></t> received. Therefore, TLVs in a PDU (other than LSP purges) that are
disallowed <bcp14>MUST</bcp14> be ignored and <bcp14>MUST NOT</bcp14>
<t>This is the model to be followed when a TLV is received which is cause the PDU itself to be rejected by the receiving IS.</t>
disallowed. Therefore TLVs in a PDU (other than LSP purges) which are
disallowed MUST be ignored and MUST NOT cause the PDU itself to be
rejected by the receiving IS.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Special Handling of Disallowed TLVs in Received LSP Purge <name>Special Handling of Disallowed TLVs in Received LSP Purges</name>
s"> <t>When purging LSPs, <xref target="ISO10589" format="default"/>
<t>When purging LSPs, <xref target="ISO10589"/> recommends (but does recommends (but does not require) the body of the LSP (i.e., all TLVs)
not require) the body of the LSP (i.e., all TLVs) be removed before be removed before generating the purge. LSP purges that have TLVs in
generating the purge. LSP purges which have TLVs in the body are the body are accepted, though any TLVs that are present are
accepted though any TLVs which are present are ignored.</t> ignored.</t>
<t>When cryptographic authentication <xref target="RFC5304"
<t>When cryptographic authentication <xref target="RFC5304"/> was format="default"/> was introduced, this looseness when processing
introduced, this looseness when processing received purges had to be received purges had to be addressed in order to prevent attackers from
addressed in order to prevent attackers from being able to initiate a being able to initiate a purge without having access to the
purge without having access to the authentication key. <xref authentication key. Therefore, <xref target="RFC5304"
target="RFC5304"/> therefore imposed strict requirements on what TLVs format="default"/> imposed strict requirements on what TLVs were allowed
were allowed in a purge (authentication only) and specified that:</t> in a
purge (authentication only) and specified that:</t>
<t><figure> <blockquote>
<artwork><![CDATA[ "ISes MUST NOT accept purges that contain TLVs ISes <bcp14>MUST NOT</bcp14> accept purges that contain TLVs other than the
other than the authentication TLV".]]></artwork> authentication TLV.
</figure></t> </blockquote>
<t>This behavior was extended by <xref target="RFC6232"
<t>This behavior was extended by <xref target="RFC6232"/> which format="default"/>, which introduced the Purge Originator
introduced the Purge Originator Identification (POI) TLV and <xref Identification (POI) TLV, and <xref target="RFC6233" format="default"/>,
target="RFC6233"/> which added the "Purge" column to the TLV which added the "Purge" column to the "TLV Codepoints Registry" to
Codepoints registry to identify all the TLVs which are allowed in identify all the TLVs that are allowed in purges.</t>
purges.</t> <t>The behavior specified in <xref target="RFC5304" format="default"/>
is not backwards compatible with the behavior defined by <xref
<t>The behavior specified in <xref target="RFC5304"/> is not backwards target="ISO10589" format="default"/>; therefore, it can only be safely
compatible with the behavior defined by <xref target="ISO10589"/> and enabled when all nodes support cryptographic
therefore can only be safely enabled when all nodes support authentication. Similarly, the extensions defined by <xref
cryptographic authentication. Similarly, the extensions defined by target="RFC6232" format="default"/> are not compatible with the
<xref target="RFC6232"/> are not compatible with the behavior defined behavior defined in <xref target="RFC5304" format="default"/>;
in <xref target="RFC5304"/>, therefore can only be safely enabled when therefore, they can only be safely enabled when all nodes support the
all nodes support the extensions.</t> extensions.</t>
<t>When new protocol behaviors are specified that are not backwards <t>When new protocol behaviors are specified that are not backwards
compatible, it is RECOMMENDED that implementations provide controls compatible, it is <bcp14>RECOMMENDED</bcp14> that implementations
for their enablement. This serves to prevent interoperability issues provide controls for their enablement. This serves to prevent
and allow for non-disruptive introduction of the new functionality interoperability issues and allow for non-disruptive introduction of
into an existing network.</t> the new functionality into an existing network.</t>
</section> </section>
<section anchor="app-sub-tlv" numbered="true" toc="default">
<section title="Applicability to sub-TLVs"> <name>Applicability to Sub-TLVs</name>
<t><xref target="RFC5305"/> introduced sub-TLVs, which are TLV tuples <t><xref target="RFC5305" format="default"/> introduced sub-TLVs,
advertised within the body of a parent TLV. Registries associated with which are TLV tuples advertised within the body of a parent
sub-TLVs are associated with the TLV Codepoints Registry and specify TLV. Registries associated with sub-TLVs are associated with the "TLV
in which TLVs a given sub-TLV is allowed. Section 2 of <xref Codepoints Registry" and specify in which TLVs a given sub-TLV is
target="RFC5305"/> is updated by the following sentence:</t> allowed. <xref target="RFC5305" sectionFormat="of" section="2"/> is
updated by the following sentence:</t>
<t><figure> <blockquote>
<artwork><![CDATA[ "As with TLVs, it is required that sub-TLVs whi As with TLVs, it is required that sub-TLVs that are disallowed
ch <bcp14>MUST</bcp14> be ignored on receipt.
are disallowed MUST be ignored on receipt.".]]></artwork> </blockquote>
</figure></t> <t>The existing sentence in <xref target="RFC5305"
sectionFormat="of" section="2"/>:</t>
<t>The existing sentence in Section 2 of <xref target="RFC5305"/> <blockquote>
:</t> Unknown sub-TLVs are to be ignored and skipped upon receipt.
</blockquote>
<t><figure>
<artwork><![CDATA[ "Unknown sub-TLVs are to be ignored and skipped
upon
receipt."]]></artwork>
</figure></t>
<t>is replaced by:</t> <t>is replaced by:</t>
<blockquote>
<t><figure> Unknown sub-TLVs <bcp14>MUST</bcp14> be ignored and skipped upon receipt.
<artwork><![CDATA[ "Unknown sub-TLVs MUST be ignored and skipped u </blockquote>
pon
receipt."]]></artwork>
</figure></t>
</section> </section>
<section anchor="correct-poi" numbered="true" toc="default">
<section title="Correction to POI TLV Registry Entry"> <name>Correction to POI &quot;TLV Codepoints Registry&quot; Entry</name>
<t>An error was introduced by <xref target="RFC6232"/> when specifying <t>An error was introduced by <xref target="RFC6232"
in which PDUs the POI TLV is allowed. Section 3 of <xref format="default"/> when specifying in which PDUs the POI TLV is
target="RFC6232"/> stated:</t> allowed. <xref target="RFC6232" sectionFormat="of" section="3"/>
states:</t>
<t><figure> <blockquote>
<artwork><![CDATA[ "The POI TLV SHOULD be found in all purges and The POI TLV <bcp14>SHOULD</bcp14> be found in all purges and <bcp14>MUST
MUST NOT be found in LSPs with a non-zero NOT</bcp14> be found in LSPs with a non-zero Remaining Lifetime.
Remaining Lifetime."]]></artwork> </blockquote>
</figure></t> <t>However, the IANA section of the same document states:</t>
<blockquote>
<t>However, the IANA section of the same document stated:</t> The additional values for this TLV should be IIH:n, LSP:y, SNP:n, and
Purge:y.
<t><figure> </blockquote>
<artwork><![CDATA[ "The additional values for this TLV should be
IIH:n, LSP:y, SNP:n, and Purge:y."]]></artwork>
</figure></t>
<t>The correct setting for "LSP" is "n". This document updates <xref <t>The correct setting for "LSP" is "n". This document updates <xref
target="RFC6232"/> by correcting that error.</t> target="RFC6232" format="default"/> by correcting that error.</t>
<t>This document also updates the previously quoted text from <xref
<t>This document also updates the previously quoted text from Section target="RFC6232" sectionFormat="of" section="3"/> to be:</t>
3 of <xref target="RFC6232"/> to be:</t> <blockquote>
The POI TLV <bcp14>SHOULD</bcp14> be sent in all purges and <bcp14>MUST
<t><figure> NOT</bcp14> be sent in LSPs with a non-zero Remaining Lifetime.
<artwork><![CDATA[ "The POI TLV SHOULD be sent in all purges and </blockquote>
MUST NOT be sent in LSPs with a non-zero
Remaining Lifetime."]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="LSP_ACCEPTANCE" numbered="true" toc="default">
<section anchor="LSP_ACCEPTANCE" <name>TLV Validation and LSP Acceptance</name>
title="TLV Validation and LSP Acceptance ">
<t>The correct format of a TLV and its associated sub-TLVs, if <t>The correct format of a TLV and its associated sub-TLVs, if
applicable, are defined in the document(s) which introduce each applicable, is defined in the document(s) that introduces each
codepoint. The definition MUST include what action to take when the codepoint. The definition <bcp14>MUST</bcp14> include what action to
format/content of the TLV does not conform to the specification (e.g., take when the format/content of the TLV does not conform to the
"MUST be ignored on receipt"). When making use of the information specification (e.g., "<bcp14>MUST</bcp14> be ignored on receipt"). When
encoded in a given TLV (or sub-TLV) receiving nodes MUST verify that the making use of the information encoded in a given TLV (or sub-TLV),
TLV conforms to the standard definition. This includes cases where the receiving nodes <bcp14>MUST</bcp14> verify that the TLV conforms to the
length of a TLV/sub-TLV is incorrect and/or cases where the value field standard definition. This includes cases where the length of a
does not conform to the defined restrictions.</t> TLV/sub-TLV is incorrect and/or cases where the value field does not
conform to the defined restrictions.</t>
<t>However, the unit of flooding for the IS-IS Update process is an LSP. <t>However, the unit of flooding for the IS-IS Update process is an
The presence of a TLV (or sub-TLV) with content which does not conform LSP. The presence of a TLV (or sub-TLV) with content that does not
to the relevant specification MUST NOT cause the LSP itself to be conform to the relevant specification <bcp14>MUST NOT</bcp14> cause the
rejected. Failure to follow this requirement will result in inconsistent LSP itself to be rejected. Failure to follow this requirement will
LSP Databases on different nodes in the network which will compromise result in inconsistent LSP Databases on different nodes in the network
the correct operation of the protocol.</t> that will compromise the correct operation of the protocol.</t>
<t>LSP Acceptance rules are specified in <xref target="ISO10589"
<t>LSP Acceptance rules are specified in <xref target="ISO10589"/> . format="default"/>. Acceptance rules for LSP purges are extended by
Acceptance rules for LSP purges are extended by <xref target="RFC5304"/> <xref target="RFC5304" format="default"/> and <xref target="RFC5310"
<xref target="RFC5310"> and </xref> and are further extended by <xref format="default"/> and are further extended by <xref
target="RFC6233"/>.</t> target="RFC6233" format="default"/>.</t>
<t><xref target="ISO10589" format="default"/> also specifies the
behavior when an LSP is not accepted.
<t><xref target="ISO10589"/> also specifies the behavior when an LSP is This behavior is *not* altered by
not accepted. This behavior is NOT altered by extensions to the LSP extensions to the LSP Acceptance rules, i.e., regardless of the reason
Acceptance rules i.e., regardless of the reason for the rejection of an for the rejection of an LSP, the Update process on the receiving router
LSP the Update process on the receiving router takes the same takes the same action.</t>
action.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is requested to add this document as a reference for the TLV <t>IANA has added this document as a reference for the "TLV
Codepoints Registry.</t> Codepoints Registry".</t>
<t>IANA has also modified the entry for the Purge Originator
<t>IANA is also requested to modify the entry for the Purge Originator Identification TLV in the "TLV Codepoints Registry" to be IIH:n, LSP:n,
Identification TLV in the TLV Codepoints Registry to be:</t> SNP:n, and Purge:y.</t>
<t>The reference field of the Purge Originator Identification
<t>IIH:n, LSP:n, SNP:n, and Purge:y.</t> TLV has been updated to point to this document.</t>
<t>The reference field should be updated to point to this document.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>As this document makes no changes to the protocol there are no new <t>As this document makes no changes to the protocol, there are no new
security issues introduced.</t> security issues introduced.</t>
<t>The clarifications discussed in this document are intended to make it <t>The clarifications discussed in this document are intended to make it
less likely that implementations will incorrectly process received LSPs, less likely that implementations will incorrectly process received LSPs,
thereby also making it less likely that a bad actor could exploit a thereby also making it less likely that a bad actor could exploit a
faulty implementation.</t> faulty implementation.</t>
<t>Security concerns for IS-IS are discussed in <xref target="ISO10589"
<t>Security concerns for IS-IS are discussed in <xref format="default"/>, <xref target="RFC5304" format="default"/>, and <xref
target="ISO10589"/>, <xref target="RFC5304"/>, and <xref target="RFC5310" format="default"/>.</t>
target="RFC5310"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Alvaro Retana.</t>
<!---->
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<reference anchor="ISO10589"> <name>References</name>
<front> <references>
<title>Intermediate system to Intermediate system intra-domain <name>Normative References</name>
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473)</title>
<author> <reference anchor="ISO10589">
<organization abbrev="ISO">International Organization for <front>
<title>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)</title>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
<author>
<organization abbrev="ISO">International Organization for
Standardization</organization> Standardization</organization>
</author> </author>
<date month="November" year="2002"/>
<date month="Nov" year="2002"/> </front>
</front> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/> ence.RFC.2119.xml"/>
</reference> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3563.xml"/>
<?rfc include="reference.RFC.2119"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5304.xml"/>
<?rfc include="reference.RFC.3563"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5305.xml"/>
<?rfc include="reference.RFC.5304"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5310.xml"/>
<?rfc include="reference.RFC.5305"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6232.xml"/>
<?rfc include="reference.RFC.5310"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6233.xml"/>
<?rfc include="reference.RFC.6232"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<?rfc include="reference.RFC.6233"?>
<?rfc include="reference.RFC.8174"?>
<reference anchor="TLV_CODEPOINTS">
<front>
<title>IS-IS TLV Codepoints web page
(https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoi
nts.xhtml)</title>
<author>
<organization>IANA</organization>
</author>
<date/> <reference anchor="TLV_CODEPOINTS"
</front> target="https://www.iana.org/assignments/isis-tlv-codepoints/"
</reference> >
<front>
<title>IS-IS TLV Codepoints</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3359.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7356.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Alvaro
Retana"/>.</t>
<references title="Informative References"> </section>
<?rfc include="reference.RFC.3359"?>
<?rfc include="reference.RFC.7356"?>
<?rfc ?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 79 change blocks. 
374 lines changed or deleted 280 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/