This section describes the correct behavior when a PDU that contains a TLV that is specified as disallowed in the "TLV Codepoints Registry" is received.
] defines the behavior required when a PDU is received containing a TLV that is "not recognised". It states (see Sections 9.5 - 9.13):
Any codes in a received PDU that are not recognised shall be ignored.
This is the model to be followed when a TLV that is disallowed is received. Therefore, TLVs in a PDU (other than LSP purges) that are disallowed MUST
be ignored and MUST NOT
cause the PDU itself to be rejected by the receiving IS.
When purging LSPs, [ISO10589
] recommends (but does not require) the body of the LSP (i.e., all TLVs) be removed before generating the purge. LSP purges that have TLVs in the body are accepted, though any TLVs that are present are ignored.
When cryptographic authentication [RFC 5304
] was introduced, this looseness when processing received purges had to be addressed in order to prevent attackers from being able to initiate a purge without having access to the authentication key. Therefore, [RFC 5304
] imposed strict requirements on what TLVs were allowed in a purge (authentication only) and specified that:
ISes MUST NOT accept purges that contain TLVs other than the authentication TLV.
This behavior was extended by [RFC 6232
], which introduced the Purge Originator Identification (POI) TLV, and [RFC 6233
], which added the "Purge" column to the "TLV Codepoints Registry" to identify all the TLVs that are allowed in purges.
The behavior specified in [RFC 5304
] is not backwards compatible with the behavior defined by [ISO10589
]; therefore, it can only be safely enabled when all nodes support cryptographic authentication. Similarly, the extensions defined by [RFC 6232
] are not compatible with the behavior defined in [RFC 5304
]; therefore, they can only be safely enabled when all nodes support the extensions.
When new protocol behaviors are specified that are not backwards compatible, it is RECOMMENDED
that implementations provide controls for their enablement. This serves to prevent interoperability issues and allow for non-disruptive introduction of the new functionality into an existing network.
] introduced sub-TLVs, which are TLV tuples advertised within the body of a parent TLV. Registries associated with sub-TLVs are associated with the "TLV Codepoints Registry" and specify in which TLVs a given sub-TLV is allowed. Section 2
of RFC 5305
is updated by the following sentence:
As with TLVs, it is required that sub-TLVs that are disallowed MUST be ignored on receipt.
The existing sentence in Section 2
of RFC 5305
Unknown sub-TLVs are to be ignored and skipped upon receipt.
is replaced by:
Unknown sub-TLVs MUST be ignored and skipped upon receipt.
An error was introduced by [RFC 6232
] when specifying in which PDUs the POI TLV is allowed. Section 3
of RFC 6232
The POI TLV SHOULD be found in all purges and MUST NOT be found in LSPs with a non-zero Remaining Lifetime.
However, the IANA section of the same document states:
The additional values for this TLV should be IIH:n, LSP:y, SNP:n, and Purge:y.
The correct setting for "LSP" is "n". This document updates [RFC 6232
] by correcting that error.
This document also updates the previously quoted text from Section 3
of RFC 6232
The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non-zero Remaining Lifetime.