From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3373.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc3373.txt (limited to 'doc/rfc/rfc3373.txt') diff --git a/doc/rfc/rfc3373.txt b/doc/rfc/rfc3373.txt new file mode 100644 index 0000000..ce7530c --- /dev/null +++ b/doc/rfc/rfc3373.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group D. Katz +Request for Comments: 3373 Juniper Networks, Inc. +Category: Informational R. Saluja + Tenet Technologies + September 2002 + + + Three-Way Handshake for + Intermediate System to Intermediate System (IS-IS) + Point-to-Point Adjacencies + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The IS-IS routing protocol (ISO 10589) requires reliable protocols at + the link layer for point-to-point links. As a result, it does not + use a three-way handshake when establishing adjacencies on point-to- + point media. This paper defines a backward-compatible extension to + the protocol that provides for a three-way handshake. It is fully + interoperable with systems that do not support the extension. + + Additionally, the extension allows the robust operation of more than + 256 point-to-point links on a single router. + + This extension has been implemented by multiple router vendors; this + paper is provided as information to the Internet community in order + to allow interoperable implementations to be built by other vendors. + +1. Terms + + 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 BCP 14, RFC 2119. + +2. Introduction + + The IS-IS protocol [1] assumes certain requirements stated in ISO + 10589 (section 6.7.2) for the operation of IS-IS over point-to-point + links and hence provides only a two-way handshake when establishing + + + +Katz & Saluja Informational [Page 1] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + + adjacencies on point-to-point links. The protocol does not operate + correctly if these subnetwork requirements for point-to-point links + are not met. The basic mechanism defined in the standard is that + each side declares the other side to be reachable if a Hello packet + is heard from it. Once this occurs, each side then sends a Complete + Sequence Number PDU (CSNP) to trigger database synchronization. + + Three failure modes are known. First, if the link goes down and then + comes back up, or one of the systems restarts, and the CSNP packet is + lost, and the network has a cut set of one through the link, the link + state databases on either side of the link will not synchronize for a + full LSP refresh period (up to eighteen hours). + + A second, more serious failure, is that if the link fails in only one + direction, the failure will only be detected by one of the systems. + Normally only one of the two systems will announce the adjacency in + its link state packets, and the SPF algorithm will thus ignore the + link. However, if there are two parallel links between systems and + one of them fails in one direction, SPF will still calculate paths + between the two systems, and the system that does not notice the + failure will attempt to pass traffic down the failed link (in the + direction that does not work). + + The third issue is that on some physical layers, the + interconnectivity between endpoints can change without causing a + link-layer-down condition. In this case, a system may receive + packets that are actually destined for a different system (or a + different link on the same system). The receiving system may end up + thinking that it has an adjacency with the remote system when in fact + the remote system is adjacent with a third system. + + The solution proposed here ensures correct operation of the protocol + over unreliable point-to-point links. As part of the solution to the + three-way handshaking issue, a method is defined to remove the + limitation of 255 point-to-point interfaces imposed by IS-IS [1]. + This method is more robust than the ad hoc methods currently in use. + +3. Overview of Extensions + +3.1 Handshaking + + The intent is to provide a three-way handshake for point-to-point + adjacency establishment in a backward compatible fashion. This is + done by providing an optional mechanism that allows each system to + report its adjacency three-way state; this allows a system to only + declare an adjacency to be up if it knows that the other system is + receiving its IS-IS Hello (IIH) packets. + + + + +Katz & Saluja Informational [Page 2] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + + The adjacency three-way state can be one of the following types: + + Down + This is the initial point-to-point adjacency three-way state. The + system has not received any IIH packet containing the three-way + handshake option on this point-to-point circuit. + + Initializing + The system has received IIH packet containing the three-way + handshake option from a neighbor but does not know whether the + neighbor is receiving its IIH packet. + + Up + The system knows that the neighbor is receiving its IIH packets. + + The adjacency three-way state that is reported by this mechanism is + not equal or equivalent to the adjacency state that is described in + ISO 10589 [1]. If this mechanism is supported then an adjacency may + have two states, its state as defined in ISO 10589 [1], and its + three-way state. For example according to ISO 10589 [1] receipt of + an ISH will cause an adjacency to go to Initializing state; however + receipt of an ISH will have no effect on the three-way state of an + adjacency, which remains firmly Down until it receives an IIH from a + neighbor that contains the three-way handshaking option. + + In addition, the neighbor's system ID and (newly-defined) extended + circuit ID are reported in order to detect the case where the same + stream is being received by multiple systems (only one of which can + talk back). + + The mechanism is quite similar to the one defined in the Netware Link + Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX + traffic. The difference between this mechanism and the one used in + NLSP is the location where the information is carried (NLSP uses two + of the reserved bits in the IIH header, whereas this solution adds a + separate option to the IIH), and the presence of the neighbor's + system ID and circuit ID. In theory, using the reserved header bits + should be backward compatible, since systems are supposed to ignore + them. However, it was felt that this was risky, as the use of + untested mechanisms such as this have led to problems in the past in + other protocols. New option codes, on the other hand, have been + demonstrated to work properly, as the deployment of Integrated IS-IS + for IP [3] has done exactly this. + + The new mechanism only comes into play when the remote system + includes the new option in its IIH packet; if the option is not + present, it is assumed that the system does not support the new + mechanism, and so the old procedures are used. + + + +Katz & Saluja Informational [Page 3] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + +3.2 More Than 256 Interfaces + + The IS-IS specification has an implicit limit of 256 interfaces, as + constrained by the eight bit Circuit ID field carried in various + packets. Moderately clever implementors have realized that the only + true constraint is that of 256 LAN interfaces, and for that matter + only 256 LAN interfaces for which a system is the Designated IS. + This is because the only place that the circuit ID is advertised in + LSPs is in the pseudonode LSP ID. + + Implementors have treated the point-to-point Circuit ID number space + as being independent from that of the LAN interfaces, since these + Circuit IDs appear only in IIH PDUs and are only used for detection + of a change in identity at the other end of a link. More than 256 + point-to-point interfaces have been supported by sending the same + circuit ID on multiple interfaces. This reduces the robustness of + the ID change detection algorithm, since it would then be possible to + switch links between interfaces on a system without detecting the + change. + + Since the Circuit ID is an integral part of the new handshaking + mechanism, a backward compatible mechanism for expanding the circuit + ID number space is included in this specification. + +4. Details + +4.1 Syntax + + A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is + defined: + + x Type - 0xF0 (decimal 240) + x Length - total length of the value field (1 to 17 octets) + x Value - + No. of Octets + +-----------------------------------+ + | Adjacency Three-Way State | 1 + +-----------------------------------+ + | Extended Local Circuit ID | 4 + +-----------------------------------+ + | Neighbor System ID | ID Length + +-----------------------------------+ + | Neighbor Extended Local Circuit ID| 4 + +-----------------------------------+ + + + + + + + +Katz & Saluja Informational [Page 4] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + + Adjacency Three-Way State + The adjacency three-way state of the point-to-point adjacency. The + following values are defined: + + 0 - Up + 1 - Initializing + 2 - Down + + Extended Local Circuit ID + Unique ID assigned to this circuit when it is created by this + Intermediate system. + + Neighbor System ID + System ID of neighbor Intermediate system if known. The length of + this field is equal to "ID Length" of IIH PDU described in section + "Point-to-point IS to IS hello PDU" (section 9.7 of [1]). + + Neighbor Extended Local Circuit ID + Extended Local Circuit ID of the other end of the point-to-point + adjacency if known. + + Any system that supports this mechanism SHALL include this option in + its Point-to-Point IIH packets. + + Any system that does not understand this option SHALL ignore it, and + (of course) SHALL NOT include it in its own IIH packets. + + Any system that supports this mechanism MUST include Adjacency + Three-Way State field in this option. The other fields in this + option SHOULD be included as explained below in section 3.2. + + Any system that is able to process this option SHALL follow the + procedures below. + +4.2 Elements of Procedure + + The new handshake procedure is added to the IS-IS point-to-point IIH + state machine after the PDU acceptance tests have been performed. + + Although the extended circuit ID is only used in the context of the + three-way handshake, it is worth noting that it effectively protects + against the unlikely event where a link is moved to another interface + on a system that has the same local circuit ID, as the received PDUs + will be ignored (via the checks defined below) and the existing + adjacency will fail. + + + + + + +Katz & Saluja Informational [Page 5] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + + Add a clause e) to the end of section "Receiving ISH PDUs by an + intermediate system" (section 8.2.2 of [1]): + + Set the state to be reported in the Adjacency Three-Way State + field of the Point-to-Point Three-Way Adjacency option to Down. + + Add a clause e) to the end of section "Sending point-to-point IIH + PDUs" (section 8.2.3 of [1]): + + The IS SHALL include the Point-to-Point Three-Way Adjacency option + in the transmitted Point-to-Point IIH PDU. The current three-way + state of the adjacency with its neighbor on the link (as defined + in new section 8.2.4.1.1 introduced later in the document) SHALL + be reported in the Adjacency Three-Way State field. If no + adjacency exists, the state SHALL be reported as Down. + + The Extended Local Circuit ID field SHALL contain a value assigned + by this IS when the circuit is created. This value SHALL be + unique among all the circuits of this Intermediate System. The + value is not necessarily related to that carried in the Local + Circuit ID field of the IIH PDU. + + If the system ID and Extended Local Circuit ID of the neighboring + system are known (in adjacency three-way state Initializing or + Up), the neighbor's system ID SHALL be reported in the Neighbor + System ID field, and the neighbor's Extended Local Circuit ID + SHALL be reported in the Neighbor Extended Local Circuit ID field. + + Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to + section "IIH PDU Processing" (section 8.2.4.2 of [1]): + + A received Point-to-Point IIH PDU may or may not contain the + Point-to-Point Three-Way Adjacency option. If it does not, the + link is assumed to be functional in both directions, and the + procedures described in section 8.2.4.2 are followed. + + If the option is present and contains invalid Adjacency Three-Way + State, the PDU SHALL be discarded and no further action is taken. + + If the option with a valid Adjacency Three-Way State is present, + the Neighbor System ID and Neighbor Extended Local Circuit ID + fields, if present, SHALL be examined. If they are present, and + the Neighbor System ID contained therein does not match the local + system's ID, or the Neighbor Extended Local Circuit ID does not + match the local system's extended circuit ID, the PDU SHALL be + discarded and no further action is taken. + + + + + +Katz & Saluja Informational [Page 6] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + + If the Neighbor System ID and Neighbor Extended Local Circuit ID + fields match those of the local system, or are not present, the + procedures described in section 8.2.4.2 are followed with + following changes: + + a) In section 8.2.4.2 a and b, the action "Up" from state tables + 5, 6, 7 and 8 may create a new adjacency but the three-way + state of the adjacency SHALL be Down. + + b) If the action taken from section 8.2.4.2 a or b is "Up" or + "Accept", the IS SHALL perform the action indicated by the + new adjacency three-way state table below, based on the + current adjacency three-way state and the received Adjacency + Three-Way State value from the option. (Note that the + procedure works properly if neither field is ever included. + This provides backward compatibility to an earlier version of + this option.) + + Received Adjacency Three-Way State + Down Initializing Up + ------------------------------------------------- + Down | Initialize Up Down + | + adj Initializing | Initialize Up Up + three | + -way Up | Initialize Accept Accept + state | + | + + Adjacency Three-Way State Table + + + If the new action is "Down", an adjacencyStateChange(Down) + event is generated with the reason "Neighbor restarted" and the + adjacency SHALL be deleted. + + If the new action is "Initialize", no event is generated and + the adjacency three-way state SHALL be set to "Initializing". + + If the new action is "Up", an adjacencyStateChange(Up) + event is generated. + + c) Skip section 8.2.4.2 c and d. + + d) If the new action is "Initialize", "Up" or "Accept", follow + section 8.2.4.2 e. + + + + + +Katz & Saluja Informational [Page 7] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + +5. Security Considerations + + This document raises no new security issues for IS-IS. + +6. References + + [1] ISO, "Intermediate system to Intermediate system routeing + information exchange protocol for use in conjunction with the + Protocol for providing the Connectionless-mode Network Service + (ISO 8473)", ISO/IEC 10589:1992. + + [2] "Netware Link Services Protocol Specification, Version 1.0", + Novell, Inc., February 1994. + + [3] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, + December 1990. + +7. Acknowledgements + + The authors would like to thank Tony Li, Henk Smit, Naiming Shen, + Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their + contributions to this document. + +8. Authors' Addresses + + Dave Katz + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + + Phone: (408) 745-2073 + EMail: dkatz@juniper.net + + + Rajesh Saluja + Tenet Technologies + 30/31, 100 Feet Road, Madiwala + Bangalore - 560 068 INDIA + + Phone: +91 80 552 2215 + EMail: rajesh.saluja@tenetindia.com + + + + + + + + + + +Katz & Saluja Informational [Page 8] + +RFC 3373 Three-Way Handshake for IS-IS September 2002 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Katz & Saluja Informational [Page 9] + -- cgit v1.2.3