idnits 2.17.1 draft-ietf-isis-rfc3373bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 469. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2008) is 5826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NetLink' -- Obsolete informational reference (is this intentional?): RFC 3373 (Obsoleted by RFC 5303) -- Obsolete informational reference (is this intentional?): RFC 3567 (Obsoleted by RFC 5304) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS Working Group Dave Katz 3 INTERNET-DRAFT Juniper Networks 4 Obsoletes RFC 3373 Rajesh Saluja 5 Intended status: Proposed Standard Tenet Technologies 6 Donald Eastlake 3rd 7 Motorola Laboratories 8 Expires: October 2008 April 2008 10 Three-Way Handshake for 11 Intermediate System to Intermediate System (IS-IS) 12 Point-to-Point Adjacencies 13 15 Status of This Document 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 This document is intended to become a Proposed Standard. 23 Distribution of this document is unlimited. Comments should be sent 24 to the ISIS Working Group . 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Abstract 44 The IS-IS routing protocol (Intermediate System to Intermediate 45 System, ISO 10589) requires reliable protocols at the link layer for 46 point-to-point links. As a result, it does not use a three-way 47 handshake when establishing adjacencies on point-to- point media. 48 This paper defines a backward-compatible extension to the protocol 49 that provides for a three-way handshake. It is fully interoperable 50 with systems that do not support the extension. 52 Additionally, the extension allows the robust operation of more than 53 256 point-to-point links on a single router. 55 This extension has been implemented by multiple router vendors; this 56 paper is provided to the Internet community in order to allow 57 interoperable implementations to be built by other vendors. 59 Table of Contents 61 Status of This Document....................................1 63 Abstract...................................................2 65 Table of Contents..........................................3 67 1. Introduction............................................4 68 1.1 Terminology............................................4 70 2. Overview of Extensions..................................5 71 2.1 Handshaking............................................5 72 2.2 More Than 256 Interfaces...............................6 74 3. Details.................................................7 75 3.1 Syntax.................................................7 76 3.2 Elements of Procedure..................................8 78 4. IANA Considerations....................................11 79 5. Security Considerations................................11 80 6. Changes from RFC 3373 and Acknowledgements.............11 82 7. Normative References...................................12 83 8. Informative References.................................12 85 Disclaimer................................................13 86 Additional IPR Provisions.................................13 88 Author's Address..........................................14 89 Expiration and File Name..................................14 91 1. Introduction 93 The IS-IS protocol [ISIS] assumes certain requirements stated in ISO 94 10589 (section 6.7.2) for the operation of IS-IS over point-to-point 95 links and hence provides only a two-way handshake when establishing 96 adjacencies on point-to-point links. The protocol does not operate 97 correctly if these subnetwork requirements for point-to-point links 98 are not met. The basic mechanism defined in the standard is that 99 each side declares the other side to be reachable if a Hello packet 100 is heard from it. Once this occurs, each side then sends a Complete 101 Sequence Number PDU (CSNP) to trigger database synchronization. 103 Three failure modes are known. First, if the link goes down and then 104 comes back up, or one of the systems restarts, and the CSNP packet is 105 lost, and the network has a cut set of one through the link, the link 106 state databases on either side of the link will not synchronize for a 107 full LSP refresh period (up to eighteen hours). 109 A second, more serious failure, is that if the link fails in only one 110 direction, the failure will only be detected by one of the systems. 111 Normally only one of the two systems will announce the adjacency in 112 its link state packets, and the SPF algorithm will thus ignore the 113 link. However, if there are two parallel links between systems and 114 one of them fails in one direction, SPF will still calculate paths 115 between the two systems, and the system that does not notice the 116 failure will attempt to pass traffic down the failed link (in the 117 direction that does not work). 119 The third issue is that on some physical layers, the 120 interconnectivity between endpoints can change without causing a 121 link-layer-down condition. In this case, a system may receive 122 packets that are actually destined for a different system (or a 123 different link on the same system). The receiving system may end up 124 thinking that it has an adjacency with the remote system when in fact 125 the remote system is adjacent with a third system. 127 The solution proposed here ensures correct operation of the protocol 128 over unreliable point-to-point links. As part of the solution to the 129 three-way handshaking issue, a method is defined to remove the 130 limitation of 255 point-to-point interfaces imposed by IS-IS [ISIS]. 131 This method is more robust than the ad hoc methods currently in use. 133 1.1 Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 2. Overview of Extensions 141 This section provides a general overview of the three-way handshaking 142 provided and how more than 256 interfaces are handled. 144 2.1 Handshaking 146 The intent is to provide a three-way handshake for point-to-point 147 adjacency establishment in a backward compatible fashion. This is 148 done by providing an optional mechanism that allows each system to 149 report its adjacency three-way state thus allowing a system to only 150 declare an adjacency to be up if it knows that the other system is 151 receiving its IS-IS Hello (IIH) packets. 153 The adjacency three-way state can be one of the following types: 155 Down 156 This is the initial point-to-point adjacency three-way state. The 157 system has not received any IIH packet containing the three-way 158 handshake option on this point-to-point circuit. 160 Initializing 161 The system has received IIH packet containing the three-way 162 handshake option from a neighbor but does not know whether the 163 neighbor is receiving its IIH packet. 165 Up 166 The system knows that the neighbor is receiving its IIH packets. 168 The adjacency three-way state that is reported by this mechanism is 169 not equal or equivalent to the adjacency state that is described in 170 ISO 10589 [ISIS]. If this mechanism is supported then an adjacency 171 may have two states, its state as defined in ISO 10589 [ISIS], and 172 its three-way state. For example according to ISO 10589 receipt of 173 an ISH will cause an adjacency to go to Initializing state; however 174 receipt of an ISH will have no effect on the three-way state of an 175 adjacency, which remains firmly Down until it receives an IIH from a 176 neighbor that contains the three-way handshaking option. 178 In addition, the neighbor's system ID and (newly-defined) extended 179 circuit ID are reported in order to detect the case where the same 180 stream is being received by multiple systems (only one of which can 181 talk back). 183 The mechanism is quite similar to the one defined in the Netware Link 184 Services Protocol (NLSP) [NetLink], a variant of IS-IS used for 185 routing IPX traffic. The difference between this mechanism and the 186 one used in NLSP is the location where the information is carried 187 (NLSP uses two of the reserved bits in the IIH header, whereas this 188 solution adds a separate option to the IIH), and the presence of the 189 neighbor's system ID and circuit ID. In theory, using the reserved 190 header bits should be backward compatible, since systems are supposed 191 to ignore them. However, it was felt that this was risky, as the use 192 of untested mechanisms such as this have led to problems in the past 193 in other protocols. New option codes, on the other hand, have been 194 demonstrated to work properly, as the deployment of Integrated IS-IS 195 for IP [RFC1195] has done exactly this. 197 The new mechanism only comes into play when the remote system 198 includes the new option in its IIH packet; if the option is not 199 present, it is assumed that the system does not support the new 200 mechanism, and so the old procedures are used. 202 2.2 More Than 256 Interfaces 204 The IS-IS specification has an implicit limit of 256 interfaces, as 205 constrained by the eight bit Circuit ID field carried in various 206 packets. Moderately clever implementers have realized that the only 207 true constraint is that of 256 LAN interfaces, and for that matter 208 only 256 LAN interfaces for which a system is the Designated IS. 209 This is because the only place that the circuit ID is advertised in 210 LSPs is in the pseudonode LSP ID. 212 Implementers have treated the point-to-point Circuit ID number space 213 as being independent from that of the LAN interfaces, since these 214 Circuit IDs appear only in IIH PDUs and are only used for detection 215 of a change in identity at the other end of a link. More than 256 216 point-to-point interfaces have been supported by sending the same 217 circuit ID on multiple interfaces. This reduces the robustness of 218 the ID change detection algorithm, since it would then be possible to 219 switch links between interfaces on a system without detecting the 220 change. 222 Since the Circuit ID is an integral part of the new handshaking 223 mechanism, a backward compatible mechanism for expanding the circuit 224 ID number space is included in this specification. 226 3. Details 228 The detailed syntax and procedures for this IS-IS option are given 229 below. 231 3.1 Syntax 233 A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is 234 defined: 236 x Type - 0xF0 (decimal 240) 237 x Length - total length of the value field (1 to 17 octets) 238 x Value - 239 No. of Octets 240 +-----------------------------------+ 241 | Adjacency Three-Way State | 1 242 +-----------------------------------+ 243 | Extended Local Circuit ID | 4 244 +-----------------------------------+ 245 | Neighbor System ID | ID Length 246 +-----------------------------------+ 247 | Neighbor Extended Local Circuit ID| 4 248 +-----------------------------------+ 250 Adjacency Three-Way State 251 The adjacency three-way state of the point-to-point adjacency. The 252 following values are defined: 254 0 - Up 255 1 - Initializing 256 2 - Down 258 Extended Local Circuit ID 259 Unique ID assigned to this circuit when it is created by this 260 Intermediate system. 262 Neighbor System ID 263 System ID of neighbor Intermediate system if known. The length of 264 this field is equal to "ID Length" of IIH PDU described in section 265 "Point-to-point IS to IS hello PDU" (section 9.7 of [ISIS]). 267 Neighbor Extended Local Circuit ID 268 Extended Local Circuit ID of the other end of the point-to-point 269 adjacency if known. 271 Any system that supports this mechanism SHALL include this option in 272 its Point-to-Point IIH packets. 274 Any system that does not understand this option SHALL ignore it, and 275 (of course) SHALL NOT include it in its own IIH packets. 277 Any system that supports this mechanism MUST include Adjacency 278 Three-Way State field in this option. The other fields in this 279 option SHOULD be included as explained below in section 2.2. 281 Any system that is able to process this option SHALL follow the 282 procedures below. 284 3.2 Elements of Procedure 286 The new handshake procedure is added to the IS-IS point-to-point IIH 287 state machine after the PDU acceptance tests have been performed. 289 Although the extended circuit ID is only used in the context of the 290 three-way handshake, it is worth noting that it effectively protects 291 against the unlikely event where a link is moved to another interface 292 on a system that has the same local circuit ID, as the received PDUs 293 will be ignored (via the checks defined below) and the existing 294 adjacency will fail. 296 Add a clause e) to the end of section "Receiving ISH PDUs by an 297 intermediate system" (section 8.2.2 of [ISIS]): 299 Set the state to be reported in the Adjacency Three-Way State 300 field of the Point-to-Point Three-Way Adjacency option to Down. 302 Add a clause e) to the end of section "Sending point-to-point IIH 303 PDUs" (section 8.2.3 of [ISIS]): 305 The IS SHALL include the Point-to-Point Three-Way Adjacency option 306 in the transmitted Point-to-Point IIH PDU. The current three-way 307 state of the adjacency with its neighbor on the link (as defined 308 in new section 8.2.4.1.1 introduced later in the document) SHALL 309 be reported in the Adjacency Three-Way State field. If no 310 adjacency exists, the state SHALL be reported as Down. 312 The Extended Local Circuit ID field SHALL contain a value assigned 313 by this IS when the circuit is created. This value SHALL be 314 unique among all the circuits of this Intermediate System. The 315 value is not necessarily related to that carried in the Local 316 Circuit ID field of the IIH PDU. 318 If the system ID and Extended Local Circuit ID of the neighboring 319 system are known (in adjacency three-way state Initializing or 320 Up), the neighbor's system ID SHALL be reported in the Neighbor 321 System ID field, and the neighbor's Extended Local Circuit ID 322 SHALL be reported in the Neighbor Extended Local Circuit ID field. 324 Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to 325 section "IIH PDU Processing" (section 8.2.4.2 of [ISIS]): 327 A received Point-to-Point IIH PDU may or may not contain the 328 Point-to-Point Three-Way Adjacency option. If it does not, the 329 link is assumed to be functional in both directions, and the 330 procedures described in section 8.2.4.2 are followed. 332 If the option is present and contains invalid Adjacency Three-Way 333 State, the PDU SHALL be discarded and no further action is taken. 335 If the option with a valid Adjacency Three-Way State is present, 336 the Neighbor System ID and Neighbor Extended Local Circuit ID 337 fields, if present, SHALL be examined. If they are present, and 338 the Neighbor System ID contained therein does not match the local 339 system's ID, or the Neighbor Extended Local Circuit ID does not 340 match the local system's extended circuit ID, the PDU SHALL be 341 discarded and no further action is taken. 343 If the Neighbor System ID and Neighbor Extended Local Circuit ID 344 fields match those of the local system, or are not present, the 345 procedures described in section 8.2.4.2 are followed with 346 following changes: 348 a) In section 8.2.4.2 a and b, the action "Up" from state tables 349 5, 6, 7 and 8 may create a new adjacency but the three-way 350 state of the adjacency SHALL be Down. 352 b) If the action taken from section 8.2.4.2 a or b is "Up" or 353 "Accept", the IS SHALL perform the action indicated by the 354 new adjacency three-way state table below, based on the 355 current adjacency three-way state and the received Adjacency 356 Three-Way State value from the option. (Note that the 357 procedure works properly if neither field is ever included. 358 This provides backward compatibility to an earlier version of 359 this option.) 360 Received Adjacency Three-Way State 361 Down Initializing Up 362 ------------------------------------------------- 363 Down | Initialize Up Down 364 | 365 adj Initializing | Initialize Up Up 366 three | 367 -way Up | Initialize Accept Accept 368 state | 369 | 371 Adjacency Three-Way State Table 373 If the new action is "Down", an adjacencyStateChange(Down) 374 event is generated with the reason "Neighbor restarted" and the 375 adjacency SHALL be deleted. 377 If the new action is "Initialize", no event is generated and 378 the adjacency three-way state SHALL be set to "Initializing". 380 If the new action is "Up", an adjacencyStateChange(Up) event is 381 generated. 383 c) Skip section 8.2.4.2 c and d. 385 d) If the new action is "Initialize", "Up" or "Accept", follow 386 section 8.2.4.2 e. 388 4. IANA Considerations 390 This document specifies IS-IS Option 240 (0xF0) which has already 391 been allocated. See [RFC3359]. 393 5. Security Considerations 395 This document raises no new security issues for IS-IS. IS-IS security 396 may be used to secure the IS-IS messages discussed here. See 397 [RFC3567]. 399 6. Changes from RFC 3373 and Acknowledgements 401 This document is a minor edit of [RFC3373] with the intent of 402 advancing it from Informational to Standards Track. It also updates 403 the ISP 10589 reference to refer to the current "2002" version. 404 Thanks to Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, 405 Les Ginsberg and Philip Christian for their contributions to the 406 document. 408 7. Normative References 410 [ISIS] "Intermediate system to Intermediate system routeing information 411 exchange protocol for use in conjunction with the Protocol for 412 providing the Connectionless-mode Network Service (ISO 8473)", ISO, 413 ISO/IEC 10589:2002. 415 [NetLink] "Netware Link Services Protocol Specification, Version 1.0", 416 Novell, Inc., February 1994. 418 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 419 environments", RFC 1195, December 1990. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 8. Informative References 426 [RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for Intermediate 427 System to Intermediate System (IS-IS) Point-to-Point Adjacencies", 428 RFC 3373, September 2002. 430 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 431 Codepoints in Intermediate System to Intermediate System", RFC 3359, 432 August 2002. 434 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate 435 System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. 437 Disclaimer 439 This document and the information contained herein are provided on an 440 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 441 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 442 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 443 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 444 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 445 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 447 Additional IPR Provisions 449 The IETF takes no position regarding the validity or scope of any 450 Intellectual Property Rights or other rights that might be claimed to 451 pertain to the implementation or use of the technology described in 452 this document or the extent to which any license under such rights 453 might or might not be available; nor does it represent that it has 454 made any independent effort to identify any such rights. Information 455 on the procedures with respect to rights in RFC documents can be 456 found in BCP 78 and BCP 79. 458 Copies of IPR disclosures made to the IETF Secretariat and any 459 assurances of licenses to be made available, or the result of an 460 attempt made to obtain a general license or permission for the use of 461 such proprietary rights by implementers or users of this 462 specification can be obtained from the IETF on-line IPR repository at 463 http://www.ietf.org/ipr. 465 The IETF invites any interested party to bring to its attention any 466 copyrights, patents or patent applications, or other proprietary 467 rights that may cover technology that may be required to implement 468 this standard. Please address the information to the IETF at ietf- 469 ipr@ietf.org. 471 Copyright (C) The IETF Trust 2008. This document is subject to the 472 rights, licenses and restrictions contained in BCP 78, and except as 473 set forth therein, the authors retain all their rights. 475 Author's Address 477 Dave Katz 478 Juniper Networks 479 1194 N. Mathilda Ave. 480 Sunnyvale, CA 94089 482 Phone: +1-408-745-2073 483 EMail: dkatz@juniper.net 485 Rajesh Saluja 486 Tenet Technologies 487 30/31, 100 Feet Road, Madiwala 488 Bangalore - 560 068 INDIA 490 Phone: +91 80 552 2215 491 EMail: rajesh.saluja@tenetindia.com 493 Donald E. Eastlake 3rd 494 Motorola Laboratories 495 111 Locke Drive 496 Marlborough, MA 01752 498 Phone: +1-508-786-7554 499 EMail: Donald.Eastlake@motorola.com 501 Expiration and File Name 503 This draft expires in July 2008. 505 Its file name is .