idnits 2.17.1 draft-ietf-isis-auto-encap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([12], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '...tic encapsulation/unencapsulation MUST...' RFC 2119 keyword, line 194: '...ber 0. This TLV MUST be included in b...' RFC 2119 keyword, line 209: '... type equal to 1 MUST contain three by...' RFC 2119 keyword, line 226: '...capsulation-mode SHALL be 47 (decimal)...' RFC 2119 keyword, line 230: '...capsulation-mode SHALL be 41 (decimal)...' (60 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 948 has weird spacing: '... to the neigh...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a dual automatic encapsulating IS originates an ICMP redirect request, the request MUST not redirect IPv4 packets from an IPv4 capable IS to a non-IPv4 capable IS, or redirect IPv6 packets from an IPv6 capable IS to a non-IPv6 capable IS. Likewise if a dual automatic encapsulating router originates ISO/IEC 9542[5] Redirect PDUs, the redirect MUST not redirect CLNS packets from an OSI capable IS to a non-OSI capable IS. -- 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 (July 2002) is 7954 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 1064 looks like a reference -- Missing reference section? '12' on line 831 looks like a reference -- Missing reference section? '2' on line 809 looks like a reference -- Missing reference section? '3' on line 811 looks like a reference -- Missing reference section? '4' on line 813 looks like a reference -- Missing reference section? '5' on line 815 looks like a reference -- Missing reference section? '6' on line 817 looks like a reference -- Missing reference section? '7' on line 819 looks like a reference -- Missing reference section? '8' on line 821 looks like a reference -- Missing reference section? '10' on line 826 looks like a reference -- Missing reference section? '11' on line 829 looks like a reference -- Missing reference section? '9' on line 824 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Christian, 2 INTERNET-DRAFT Nortel Networks 3 Category: Informational July 2002 4 Expires: January 2003 6 IS-IS Automatic Encapsulation 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 The IETF is advised of potential intellectual property rights in 15 regard to some or all of the specification contained in this 16 document. For more information consult the online list for notices 17 and/or updates. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that 21 other groups may also distribute working documents as Internet 22 Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a 28 "working draft" or "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This memo provides information for the Internet community. This memo 37 does not specify an Internet standard of any kind. 39 Distribution of this draft is unlimited. 41 Christian Expires January 2003 1 42 IS-IS Automatic Encapsulation 44 Abstract 46 RFC 1195 [1] documents a dual routing protocol that can be used to 47 route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS- 48 IS can now also be used to route IPv6 [12]. 50 RFC 1195 [1] places certain topological restrictions on networks 51 that are routed using Integrated IS-IS, specifically that every 52 Intermediate System in a level-1 area must be able to forward all 53 network layer protocols that are present in that area, and that 54 every level-2 Intermediate System must be able to forward all 55 network layer protocols present in the routing domain. 57 The mechanism described in this document enables an Intermediate 58 System or a group of Intermediate Systems that do not support a 59 particular network layer protocol to be used in a level-1 area or 60 level-2 subdomain where that network layer protocol is present. 62 Specifically the mechanism provides automatic encapsulation and 63 unencapsulation so that a packet or PDU may pass through an 64 Intermediate System that would not normally be able to forward that 65 type of packet. 67 1.Introduction 69 RFC 1195 [1] documents a dual routing protocol that can be used to 70 route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS-IS 71 can now also be used to route IPv6 [12]. 73 RFC 1195 [1] also foresaw the possibility of an automatic 74 encapsulation feature. Automatic encapsulation is stated as for 75 "for further study" in section 3.8. The automatic encapsulation 76 scheme detailed here may be considered a continuation of section 3.8 77 of RFC 1195 [1]. 79 Integrated IS-IS ISs (Intermediate Systems) can calculate routes to 80 CLNS, IPv4 and IPv6 destinations using a single SPF calculation. 81 This is achieved by treating OSI End System, IPv4 and IPv6 addresses 82 in a similar way, but it does rely on an assumption which forces 83 topological restrictions onto the network. 85 Integrated IS-IS views a level-1 area or level-2 subdomain as a 86 collection of connected ISs, without considering which ISs can 87 actually forward which network-layer protocols. It simply assumes 88 that all ISs that it can see, can forward all packet types. For 89 Integrated IS-IS to be able to pick different routes for different 90 network-layer protocols would imply a separate SPF calculation for 91 each network layer protocol. It would then arguably no longer be an 92 integrated routing protocol. 94 Specifically page 26 of RFC 1195 [1] states:- 96 Christian Expires January 2003 2 97 IS-IS Automatic Encapsulation 99 "The Dijkstra computation does not take into consideration whether 100 a router is IP-only, OSI-only, or dual. The topological 101 restrictions specified in section 1.4 ensure that IP packets will 102 only be sent via IP-capable routers, and OSI packets will only be 103 sent via OSI-capable routers." 105 It is important that all ISs in a network calculate routes in such 106 a way that they all arrive at the same shortest path. If some ISs 107 calculate a different shortest path to others then routing loops 108 and blackholes can occur. Therefore in a multiprotocol environment 109 having ISs that consider forwarding capabilities when calculating 110 the shortest path, mixed with ISs that do not could result in 111 routing loops and packet loss. 113 Consequently, RFC 1195 states that if both IPv4 and CLNP are to be 114 forwarded anywhere in a level-1 area or level-2 subdomain, then, all 115 of the ISs in that level-1 area or level-2 subdomain must be capable 116 of forwarding both IPv4 and CLNP. The same logic applies if it is 117 required to have both IPv4 and IPv6 present in a level-1 area or 118 level-2 subdomain. 120 This topological rule can already be broken with extreme care. If it 121 can be guaranteed that a certain part of an IS-IS network will never 122 receive a certain type of packet, then that network layer protocol 123 need not be supported. 125 However, failure to observe these topological restrictions can 126 result in blackholes forming, and packet loss. Consider the 127 following (illegal) example:- 129 +--------+ +-------+ +--------+ 130 | IS A | | IS B | | IS C | 131 IPv6 host#1--+ v4/v6 +--+ v4 IS +--+ v4/v6 +--IPv6 host#2 132 | | | | | | 133 +--------+ +-------+ +--------+ 135 IS A will find the shortest path to IPv6 host#2 as being through IS 136 B. If host#1 then sends an IPv6 packet to the host#2, then the dual 137 IS will forward it to the IS B, which will not be able to forward 138 the packet. IS B will discard the packet instead, resulting in 139 packet loss. 141 This document describes a mechanism that can be used to overcome 142 this topological restriction. The mechanism detects that a packet is 143 about to be send to an IS that does not support that network layer 144 protocol, and automatically encapsulates the packet into a form that 145 then can be forwarded. Essentially the mechanism can take an 146 existing IS, or collection of ISs, that support forwarding of IPv4 147 for example, and, by automatic encapsulation of IPv6 inside IPv4, 148 can enable IPv6 traffic to also cross these IPv4 ISs, making that 149 part of the network behave as if it is dual. 151 Christian Expires January 2003 3 152 IS-IS Automatic Encapsulation 154 2.The automatic encapsulation mechanism. 156 2.1. Introduction. 158 Consider the following example:- 160 +--------+ +-------+ +--------+ 161 IPv4 host--+ IS A | | IS B | | IS C +--IPv4 host 162 | v4/v6 +--+ v4 IS +--+ v4/v6 | 163 IPv6 host--+ | | | | +--IPv6 host 164 +--------+ +-------+ +--------+ 166 Forwarding of IPv4 traffic from one host to the other is not a 167 problem in this network. However IPv6 traffic cannot be forwarded by 168 IS B without being encapsulated inside an IPv4 packet. 170 IS A and IS C actually have most of the information that they need 171 in order to automatically perform this encapsulation. 173 1. IS A can detect that IS B cannot forward an IPv6 packet, because 174 RFC 1195 [1] already requires IS B to include a "protocols 175 supported" TLV in Hello packets. Absence of the TLV indicates 176 that an IS that can forward only CLNP. 178 2. IS A receives LSPs (Link State PDUs) from IS C. This is because 179 IS-IS LSPs are neither IPv4 nor IPv6 packets. IS-IS is a 180 network-layer protocol in its own right, and is used in common 181 by all ISs whether they forward CLNP, IPv4 or IPv6 packets. 183 By adding an extra TLV to the LSPs that IS C transmits, containing 184 the encapsulation/unencapsulation capability of C, this information 185 will be flooded throughout the level-1 area or level-2 subdomain. 186 IS A is now able to encapsulate IPv6 traffic inside IPv4 packets, 187 and send them to IS C, on the understanding that IS C will 188 unencapsulate the IPv6 traffic and forward it onwards. 190 2.2. Encapsulation Capability Field. 192 Any IS that supports automatic encapsulation/unencapsulation MUST 193 include an "Encapsulation Capability" TLV in LSPs that have LSP 194 number 0. This TLV MUST be included in both level-1 LSPs and level- 195 2 LSPs. 197 The structure of the TLV is as follows:- 199 Code: 16 (decimal) 200 Length: The length of the value 201 Value: The value shall contain Sub-TLVs of the form:- 202 Sub-TLV Type 203 Sub-TLV Length: The length of the sub-TLV value 204 Sub-TLV Value: Variable number of bytes 206 Christian Expires January 2003 4 207 IS-IS Automatic Encapsulation 209 Sub-TLVs with sub-TLV type equal to 1 MUST contain three byte 210 encapsulation modes with the following structure:- 212 Sub-TLV type: 1 213 Sub-TLV length: Three times the number of encapsulation modes 214 Sub-TLV value: Encapsulation-mode#1 215 Inner-Protocol#1 216 Outer-Protocol#1 217 Encapsulation-mode#2 218 Inner-Protocol#2 219 Outer-Protocol#2 220 . 221 . 222 Encapsulation-mode#n 223 Inner-Protocol#n 224 Outer-Protocol#n 226 Encapsulation-mode SHALL be 47 (decimal) to describe a 227 GRE encapsulation as defined in RFCs 1701[2], 1702[3], 228 2784[4] and 3147[5]. 230 Encapsulation-mode SHALL be 41 (decimal) to describe 231 IPv6 in IP encapsulation as defined in RFC 1933 and in 232 RFC 2893[6]. 234 Encapsulation-mode SHALL be 4 (decimal) to describe IPv4 235 in IP encapsulation as (sort of) defined in RFC 2003[7]. 237 Inner-Protocol SHALL be the NLPID of a packet that the 238 IS is capable of sending or receiving in an encapsulated 239 form. 241 Outer-Protocol SHALL be the NLPID of a packet that the 242 IS is capable of using to transport the Inner-Protocol 243 in encapsulated form. 245 NLPIDs SHALL be those as specified in ISO/TR 9577[8]. 247 These encapsulation modes are chosen simply as they are the IP 248 protocol numbers for these encapsulation mechanisms. 250 Future capabilities, such as non-NLPID definitions, may be provided 251 using the same TLV number by using an alternative sub-TLV number. 253 Note that ITU-T G.7712 [10] mandates that GRE shall be used for all 254 combinations of CLNS, IPv4 and IPv6 over CLNS, IPv4 or IPv6. 255 Therefore if interoperability is required with SONET / SDH DCC 256 channels then GRE will have to be supported. RFC 3147 [5] also 257 describes IP encapsulation over CLNS using GRE. This is stated for 258 information purposes only and is not a requirement of this document. 260 By way of an example, a dual IPv4/IPv6 IS that supports automatic 261 encapsulation of IPv6 over IPv4, and automatic encapsulation of IPv4 263 Christian Expires January 2003 5 264 IS-IS Automatic Encapsulation 266 over IPv6, using only GRE would therefore transmit the TLV with the 267 following contents:- 269 Dec (Hex) 270 16 (0x10): The TLV number 271 8 (0x08): The length of the value 272 1 (0x01): Sub-TLV type 1 273 6 (0x06): Length of the value of the sub-TLV 274 47 (0x2F): Indicating that the next two bytes are a GRE mode 275 204 (0xCC): Inner-protocol of IPv4 276 142 (0x8E): Outer-protocol of IPv6 277 47 (0x2F): Indicating that the next two bytes are a GRE mode 278 142 (0x8E): Inner protocol of IPv6 279 204 (0xCC): Outer protocol of IPv4 281 An IS that includes an encapsulation mode in its "encapsulation 282 capability" TLV MUST be capable of both transmitting and receiving 283 that encapsulation mode, as specified in sections 2.3 and 2.4. 285 2.3. Transmission of automatically encapsulated packets 287 Shortest paths SHALL be calculated in the normal way, as per RFC 288 1195 [1]. 290 Before forwarding a packet to a next hop, an IS MUST check that the 291 next hop can forward that type of packet. The IS MUST check this by 292 referring to the "protocol supported" TLV in IS-IS Hello PDUs. 293 Absence of a "Protocols Supported" TLV in Hello PDUs indicates that 294 the next hop can forward only CLNP packets. 296 If an IS finds that the next hop does support the type of packet 297 that it is attempting to forward, then it MUST simply forward the 298 packet to that adjacency as normal, without encapsulating it. 300 If an IS finds that the next hop does not support the type of packet 301 that it is attempting to forward, then it MUST search along the 302 shortest path from itself to the destination, and MUST inspect the 303 "encapsulation capability" TLV of LSP 0 of each IS until it finds an 304 IS that it is able to send the packet to in an encapsulated form. 306 The IS MUST search within each "encapsulation capability" TLV until 307 it finds an encapsulation mode that meets the following three 308 criteria:- 310 1.The encapsulation-mode MUST be one that this IS supports. 311 2.The inner-protocol MUST be equal to the NLPID of the packet that 312 this IS is attempting to forward. 313 3.The outer-protocol MUST be equal to one of the NLPIDs that the 314 next hop lists in the "protocols supported" TLV of IS-IS Hello 315 PDUs, or equal to the NLPID for CLNS/CLNP if no "protocols 316 supported" TLV is present in IS-IS Hello PDUs from the next hop. 318 When inspecting an "encapsulation capability" TLV, then, an IS MUST 320 Christian Expires January 2003 6 321 IS-IS Automatic Encapsulation 323 ignore any encapsulation modes that it does not understand, but 324 instead jump forward to inspect the next encapsulation mode, until 325 it finds a suitable mode or until it reaches the end of the TLV. 327 When inspecting an "encapsulation capability" TLV, then, an IS MUST 328 ignore any sub-TLVs that it does not understand, but instead jump 329 forward to inspect the next sub-TLV, until it finds a suitable mode 330 or until it reaches the end of the TLV. 332 The IS MUST encapsulate the packet inside another and send it to the 333 first IS along the shortest path to the destination that meets the 334 criteria, using the encapsulation mode that resulted in it meeting 335 the above criteria. See 2.3.1. for an explanation. 337 It is suggested that this search is pre-calculated and performed for 338 every destination that cannot be forwarded natively every time the 339 SPF (Dijkstra) algorithm is run, and that the results are included 340 in each forwarding table, with a marker indicating that for that 341 particular destination that the packet should be encapsulated using 342 a certain encapsulation mode (if more than one is supported) and 343 with a certain destination address, which will be a destination 344 address expressed in the format used by the outer-protocol that is 345 going to be used. For this a modified SPF algorithm is provided in 346 Annex A. 348 The destination address of the resultant encapsulation packet MUST 349 be equal to the identity of the IS that sent the TLV that was the 350 first along the shortest path that met the above criteria. 352 The source address of the resultant encapsulation packet MUST be 353 equal to the identity of the IS that is performing the 354 encapsulation. 356 If the outer protocol is IPv4 then the "Don't Fragment" bit MUST NOT 357 be set. If the outer protocol is CLNP then the "Segmentation 358 Permitted" flag MUST be set. This will protect against packet loss 359 due to the new packet being longer than the MTU size of the link 360 over which it is to be transmitted, and will prevent unwanted 361 interactions with path MTU discovery [11]. 363 2.3.1. Reasoning for sending to first capable IS 365 Section 2.3 indicates that a packet that cannot be forwarded 366 natively should be encapsulated and sent to the first IS along the 367 shortest path that advertises itself as being capable of 368 unencapsulating it. In fact, the packet could be encapsulated and 369 sent to any IS along the shortest path that advertises itself as 370 being capable of unencapsulating it, and the packet would arrive at 371 its destination. 373 The most reasonable choices would appear to be either the first, or 374 the last IS unencapsulation capable IS, each choice has advantages 375 and disadvantages. 377 Christian Expires January 2003 7 378 IS-IS Automatic Encapsulation 380 Choosing the first may result in a packet being encapsulated and 381 unencapsulated several times on its way to its destination, as it 382 crosses multiple "subnetworks" that do not support forwarding of 383 that type of packet. When the packet is being forwarded by a part of 384 the network that can forward it natively, it is in its original 385 form. 387 Choosing the last may result in encapsulation within encapsulation 388 within encapsulation, as for example an IPv6 packet will become an 389 IPv4 packet and remain so till the last IS that can unencapsulate. 390 This IPv4 packet may in turn need to traverse an IPv6-only 391 "subnetwork" and be encapsulated again. If the last IS capable of 392 unencapsulation advertises itself as being capable of IPv6/IPv4 and 393 IPv4/IPv6, then it will loaded with unencapsulating all of the 394 layers of encapsulation in one go. 396 Although the argument is probably a religious one, unencapsulating a 397 packet as soon as possible, and avoiding encapsulation within 398 encapsulation (and the long packets that may result) would appear to 399 be the lesser of the two evils. The load of fragmentation and 400 reassembly must also be considered if multiple layers of 401 encapsulation results in an MTU size being blown. Also it is 402 probably better for a packet to exist in the network in its native 403 form whenever possible, making the network easier to debug, and 404 reducing the impact of encapsulation to the smallest part of the 405 network possible. 407 However, any IS MUST be able to unencapsulate any packet that 408 arrives at it with its destination address, and with an 409 encapsulation mode that it advertised in its "encapsulation 410 capability" TLV. This opens the possibility for more intelligent 411 algorithms to be developed that choose an IS capable of 412 unencapsulating, other than the first. 414 2.4. Receipt of automatically encapsulated packets 416 An IS that supports automatic encapsulation / unencapsulation MUST 417 inspect any received packet that has a destination address equal to 418 itself to see if it is an encapsulation of a type that it 419 transmitted in its "encapsulation capability" TLV. 421 If the IS finds that such a received packet is an encapsulation 422 packet then it SHOULD discard the inner packet if it is of a type 423 that it did not list as an "inner-protocol" in an encapsulation mode 424 in its "encapsulation capability" TLV. 426 Upon discarding such a packet it is suggested that the IS reports or 427 logs an error report. 429 An IS that also supports manually configured tunnels will need to 430 check that a packet has not arrived over a manual tunnel in the 431 normal way before discarding it. 433 Christian Expires January 2003 8 434 IS-IS Automatic Encapsulation 436 Otherwise the received packet MUST be unencapsulated and re- 437 received. Note that encapsulation within encapsulation is a 438 possibility, particularly for ISs that support three or more network 439 layer protocols. 441 2.5. Interaction with Path MTU Discovery (PMTU), RFC 1191 [11]. 443 Although packets become encapsulated, no tunnel "interface" or 444 circuit as such really exists. Therefore there will be no MTU limit 445 for the inner-protocol. It is suggested that packets of any size 446 are accepted, then encapsulated, and that the encapsulated outer- 447 protocol packet is fragmented/segmented if necessary in order to be 448 forwarded over the real interface. For this reason in the new 449 outer-protocol packet the Don't Fragment MUST NOT be set (for IPv4), 450 or Segmentation Permitted flag MUST be set (for CLNP). 452 One consequence of this is that a link, if packets traverse it in 453 an encapsulated form, becomes invisible to Path MTU Discovery. 455 However this is the safest option as it guarantees that packets will 456 never be discarded due to MTU issues. Because the inner-protocol is 457 different to the outer-protocol, if the outer-protocol where to be 458 discarded for any reason then the reason is not likely to be known 459 to the originator of the inner-protocol packet. Path MTU discovery 460 does rely on knowing the reason for discard of packets, and so the 461 safest option is to make the outer-protocol and encapsulation 462 process invisible to it. 464 An additional option is to reject packets for encapsulation that are 465 bigger than a certain size, and to report back to the originator a 466 suitable error message. If this approach is chosen then the packet 467 MUST be rejected before encapsulation, and a suitable error message 468 MUST be returned to the originator using the correct mechanism for 469 that network layer protocol. Such a process would be prior to and 470 independent of automatic encapsulation, and does not alter the 471 requirement that the outer-protocol packets are never discarded, but 472 fragmented/segmented instead. 474 3.Allowable and non-allowable topologies 476 This mechanism effectively enables an IS or group of ISs to act as 477 if they support one or more network layer protocols that they 478 actually do not. Automatic encapsulation is the process that 479 enables this to be possible, but care must be taken to ensure that 480 incompatible packets are not leaked into such a "subnetwork" without 481 going through an automatic encapsulation capable IS. 483 Thus, at the all of the boundaries to the "subnetwork", there MUST 484 be installed an IS that supports automatic encapsulation. At points 485 where the inner "subnetwork" meet the outer general network without 486 an automatic encapsulation IS between the two, any adjacency MUST be 487 disabled. 489 Christian Expires January 2003 9 490 IS-IS Automatic Encapsulation 492 In order to partially automate this the ITU-T mandated in G.7712[10] 493 that any Integrated IS-IS capable SDH NE must not consider itself a 494 neighbour to any other IS unless the other IS supports at least one 495 network layer protocol in common with it. This effectively makes it 496 impossible to accidentally have an adjacency between an OSI-only and 497 an IP-only SDH NE, or between an IPv4-only and an IPv6-only SDH NE. 499 This cannot be retrospectively applied to RFC 1195[1] compliant ISs, 500 however it is recommended that all Integrated IS-IS ISs include this 501 safeguard whenever possible. In the absence of this behaviour it is 502 the responsibility of the network manager to manually insure that no 503 such adjacencies are formed. Certain Integrated IS-IS 504 implementations also check for correct subnetting of a neighbour 505 before accepting an adjacency; usefully this should also prevent an 506 IPv4-only IS from forming an adjacency with an IPv6-only IS. 508 In general the existing RFC 1195[1] topological restrictions still 509 apply inside a "subnetwork" that is bounded by automatically 510 encapsulating ISs, and outside of the automatically encapsulating 511 ISs too. For example:- 513 1. Within a "subnetwork" that can forward only IPv4, only IPv4 can 514 be forwarded. A dual IPv4/IPv6 IS MAY be installed inside this 515 "subnetwork", but, it MUST NOT forward any IPv6 packets. No IPv6 516 hosts (including hosts internal to an IPv4/IPv6 IS) may be 517 present in the "subnetwork". 519 2. Outside of the "subnetwork", i.e. on the other side of an 520 automatic encapsulation capable IS, if both IPv4 and IPv6 packets 521 are present in a native form, then all ISs must be capable of 522 forwarding both IPv4 and IPv6. 524 IPv6-only 525 .......... 526 IPv4 host-+------+ +------+ .+------+. +------+ +------+-IPv4 host 527 | IS G |--| IS H |--| IS I |--| IS J |--| IS K | 528 IPv6 host-+------+ +---+--+ .+--+---+. +--+---+ +------+-IPv6 host 529 | ....X..... | 530 | X | 531 .......|........X.........|....... 532 . +---+--+ +--+---+ +--+---+ . 533 . | IS A |--| IS B |--| IS C | . 534 . +--+---+ +------+ +---+--+ . 535 . | | .IPv4-only 536 . +--+---+ +------+ +---+--+ . 537 . | IS D |--| IS E |--| IS F | . 538 . +---+--+ +------+ +--+---+ . 539 .......|..................|....... 540 | | 541 +------+ +---+--+ +--+---+ +------+ 542 IPv6 host-+ IS L |--| IS M | | IS N |--| IS O +-IPv6 host 543 +------+ +------+ +------+ +------+ 545 Christian Expires January 2003 10 546 IS-IS Automatic Encapsulation 548 ISs A, B, C, D, E and F are an IPv4-only "subnetwork"; therefore ISs 549 H, J, M and N must be capable of automatically encapsulating IPv6 550 over IPv4. 552 IS I is an IPv6-only "subnetwork", therefore ISs H and J must be 553 capable of automatically encapsulating IPv4 over IPv6. 555 ISs I and B support no network layer protocol in common and must 556 therefore not form an adjacency. 558 ISs G and K must forward IPv4 and IPv6 traffic and must therefore 559 both be dual. 561 ISs L and O need to forward only IPv6 and therefore may be either 562 IPv6 only or dual. 564 4.LAN interfaces 566 As stated in section 3, ISs must not have adjacencies if they are 567 able to forward packets that the neighbour does not support, unless 568 they can automatically encapsulate. 570 Consequently an IPv4-only and an IPv6-only IS may exist in the same 571 area and on the same LAN, but will have no adjacency with each 572 other. 574 If there is a dual IS on the LAN that does support automatic 575 encapsulation, then both the IPv4 and the IPv6 IS will have an 576 adjacency with it. 578 4.1. PseudoNode election process 580 ISs can choose a Designated IS (DIS) only from valid adjacencies, 581 therefore an IPv4-only IS cannot elect an IPv6-only IS as DIS, and 582 vice versa. 584 In this case there are effectively two separate "sub-LANs" on the 585 physical LAN. The IPv4-only ISs form one "sub-LAN" and elect a DIS, 586 whilst the IPv6-only ISs form a second "sub-LAN" and a second DIS. 588 Clearly a dual automatically encapsulating IS needs to be capable of 589 connecting to both "sub-LANs", and so MUST participate in both 590 pseudonode election processes. 592 In this case a dual IS that does not support automatic 593 encapsulation MUST NOT have adjacencies both with IPv4-only and with 594 IPv6-only ISs, as this would form a leak between the two 595 "subnetworks" and may cause packet loss. Therefore such a dual IS 596 simply cannot appear on such a LAN, and a modified pseudonode 597 election process does not apply to it. 599 The following scenarios must be considered:- 601 Christian Expires January 2003 11 602 IS-IS Automatic Encapsulation 604 1.The dual automatic encapsulating IS might win neither election 605 process, in which case it is not DIS. 607 2.The dual automatic encapsulating IS might be elected DIS by the 608 IPv4 ISs on the LAN, but not the IPv6 ISs; in this case it MUST 609 create a pseudonode, and the pseudonode MUST declare adjacencies 610 with all IPv4-capable ISs on the LAN (the IPv4-only ISs and the 611 dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies 612 with any IPv6-only ISs. 614 3.The dual automatic encapsulating IS might be elected DIS by the 615 IPv6 ISs on the LAN, but not the IPv4 ISs; in this case it MUST 616 create a pseudonode, and the pseudonode MUST declare adjacencies 617 with all IPv6-capable ISs on the LAN (the IPv6-only ISs and the 618 dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies 619 with any IPv4-only ISs. 621 4.The dual automatic encapsulating IS might be elected DIS both by 622 the IPv4 ISs and by the IPv6 ISs; in this case it MUST create two 623 separate pseudonodes. One of the pseudonodes MUST declare 624 adjacencies with all IPv4-capable ISs on the LAN, and the other 625 pseudonode must declare adjacencies with all-IPv6 capable ISs on 626 the LAN. Both pseudonodes MUST declare an adjacency with the 627 dual automatic encapsulating IS, and with any other dual ISs on 628 the LAN. 630 Note that in the fourth scenario the behaviour described here is 631 different to that described in ITU-T G.7712 v1.2 [10]. In that 632 document if the dual automatic encapsulating IS might is elected DIS 633 both by the IPv4 ISs and the IPv6 ISs; then it creates a single 634 pseudonode and that pseudonode declares adjacencies with all ISs on 635 the LAN. This behaviour has been proven to cause interoperability 636 problems with existing implementations that do not conform with 637 ISO/IEC 10589 section C.2.5 item "h" or as per RFC 1195 [1] section 638 C.1.4 step 0 clause 8. Such implementations will drop packets 639 rather than send traffic to a dual IS for automatic encapsulation, 640 if the dual IS is the DIS, and if non-compatible ISs on the same LAN 641 are on the shortest path. Having two separate pseudonodes avoids 642 this situation as a non-compatible IS will never be the next hop. 643 At this time the author is planning contributions into the ITU-T to 644 modify G.7712 to include the safer behaviour described here. 646 There are scenarios where two separate psuedonode elections are not 647 necessary. As an optimisation an automatic encapsulation IS MAY 648 detect such a condition and MAY have a single pseudonode election if 649 such a condition exists. Specifically if an automatic encapsulation 650 IS detects disjoint on the LAN, then the automatic encapsulation IS 651 MUST participate in a pseudonode election process separately for 652 each network-layer protocol that it supports as described above. 653 However if an automatic encapsulation IS detects that there is no 655 Christian Expires January 2003 12 656 IS-IS Automatic Encapsulation 658 disjoint on the LAN, then the IS MAY revert to ISO 10589 [2] 659 behaviour and participate in a single pseudonode election. 661 If an IPv4-only and an IPv6-only IS appear on the same LAN then 662 there is disjoint on the LAN. If only IPv4 capable ISs (IPv4-only 663 and dual) appear on the LAN then there is no disjoint. If only IPv6 664 capable ISs (IPv6-only and dual) appear on the LAN then there is no 665 disjoint. 667 4.2. LSP update process 669 ISO/IEC 10589 [2] states in section 7.3.15.1 that an LSP received 670 that does not come from a valid adjacency must be discarded. A 671 strict single protocol implementation will therefore reject LSPs 672 that are transmitted onto a LAN interface by an IS that it has 673 rejected an adjacency with due to no network-layer protocol in 674 common (or by manual configuration or no subnet in common). 676 Thus if an IPv4-only IS transmits an LSP onto a LAN then an IPv6- 677 only IS can receive such an LSP only from a dual automatic 678 encapsulating IS. Normally a dual IS will only forward such an LSP 679 during periodic LSP database synchronisation. 681 Dual automatic encapsulating ISs are therefore required to have 682 modified LSP flooding behaviour so that OSI-only, IPv4-only or IPv6- 683 only ISs do not need to wait for the next LSP database 684 synchronisation event. 686 Dual automatic encapsulating ISs MUST check incoming LSPs that 687 arrive on LAN interfaces to see if they come from a neighbour that 688 supports all of the network layer protocols that the dual automatic 689 encapsulating IS does. This MUST be achieved by inspection of the 690 "protocols supported" TLV in Hello packets received from that 691 neighbour. 693 If the LSP is received from a neighbour that does support all of the 694 network layer protocols that the dual or multilingual IS supports, 695 then the dual automatic encapsulating IS SHALL behave as per ISO/IEC 696 10589 and unset the SRM flag for that LSP on that LAN interface if 697 it already has the LSP, or shall flood it out of all other 698 interfaces if it does not already have the LSP. 700 If the LSP is received from a neighbour that does not support all of 701 the network layer protocols that the dual automatic encapsulating IS 702 supports, and, if it does not already have the LSP then the dual 703 automatic encapsulating IS SHALL set the SRM flag for that LSP on 704 the LAN interface over which the LSP was received, in addition to 705 all other interfaces, resulting in the dual automatic encapsulating 706 IS re-transmitting the LSP onto the LAN. 708 Christian Expires January 2003 13 709 IS-IS Automatic Encapsulation 711 In this way if an LSP is transmitted onto the LAN by an IPv4-only 712 IS, then one of the dual automatic encapsulating ISs will re- 713 transmit the LSP, so that it may be received on a valid adjacency by 714 IPv6-only ISs on the LAN and vice versa. 716 4.3. Redirects 718 If a dual automatic encapsulating IS originates an ICMP redirect 719 request, the request MUST not redirect IPv4 packets from an IPv4 720 capable IS to a non-IPv4 capable IS, or redirect IPv6 packets from 721 an IPv6 capable IS to a non-IPv6 capable IS. Likewise if a dual 722 automatic encapsulating router originates ISO/IEC 9542[5] Redirect 723 PDUs, the redirect MUST not redirect CLNS packets from an OSI 724 capable IS to a non-OSI capable IS. 726 5.Level-1, level-2 ISs 728 Although this mechanism allows "subnetworks" to exist in a level-1 729 area or level-2 subdomain that do not support all of the network 730 layer protocols present in the area or subdomain, packets must still 731 be able to get in and out of an area and onto the level-2 subdomain. 733 It is therefore recommended that all ISs that support both level-1 734 and level-2 can forward all network layer protocols that exist in 735 the area. 737 However this may not be possible, if for example an existing network 738 is using this mechanism to upgrade parts of an area to support a new 739 network layer protocol, but a level-1, level-2 IS cannot be 740 upgraded. 742 In this case another IS that does support the new network layer 743 protocol must become the gateway for that protocol. This can be 744 achieved by configuration either of a default route, or a collection 745 of static routes that cover all possible "out of area" destinations. 747 Note that RFC 1195 [1] forbids default routes in level-1 LSPs 748 (however this does not reduce its usefulness as a solution). 750 This gateway IS must then tunnel all "out of area" packets of the 751 new network layer protocol across the incompatible level-1,level-2 752 IS to another IS somewhere in the level-2 subdomain or other routing 753 protocol. 755 Multiple gateways may be configured for redundancy, in this case a 756 gateway SHOULD gate advertisement of a default route on the validity 757 of the tunnel that it is using to send "out of area" packets across. 758 i.e. the IS SHOULD somehow detect that the other end of the tunnel 759 is alive and contactable, and if it is not, it SHOULD stop 760 advertising a default route into the area. This can be achieved by 761 running some other routing protocol such as RIP or OSPF across the 762 tunnel, or another instance of IS-IS, for example. 764 Christian Expires January 2003 14 765 IS-IS Automatic Encapsulation 767 6.Security Considerations 769 6.1 Injection of IP and CLNP packets into the network 771 An IS that employs automatic encapsulation is required to 772 unencapsulate any incoming packet that is of a an advertised 773 encapsulation mode, and forward the contents. 775 Consequently packets may potentially be injected at such an IS 776 in an encapsulated form that maybe would normally be filtered 777 at the edge of a routing domain, but which are now an 778 encapsulation packet. 780 Such a risk is not unique to automatic encapsulation, but is 781 present in manually configured tunnels too, such as RFC 2784 [4] 782 GRE tunnels. 784 Encapsulated packets should never arrive from any source other 785 than another IS in the same level-1 area or level-2 subdomain, 786 and this MAY then be used as the basis of a security filter. 788 In any case such a mechanism will allow an attacker only to 789 inject packets into a network; it does not supply a return path. 791 6.2 Injection of other packets into the network 793 Section 2.4 states that incoming packets SHOULD be discarded if 794 they are not of an inner-protocol type that the IS advertised as 795 being able to unencapsulate. 797 This clause is an important security feature as it prevents 798 false routing packets and consequent false routes from being 799 injected into the network. 801 Christian Expires January 2003 15 802 IS-IS Automatic Encapsulation 804 7.References 806 [1] RFC 1195 807 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. 809 [2] RFC 1701 Generic Routing Encapsulation (GRE). 811 [3] RFC 1702 Generic Routing Encapsulation over IPv4 networks. 813 [4] RFC 2784 Generic Routing Encapsulation (GRE). 815 [5] RFC 3147 Generic Routing Encapsulation over CLNS Networks. 817 [6] RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers. 819 [7] RFC 2003 IP Encapsulation within IP. 821 [8] ISO 9577 and ITU-T X.263 Information Technology - Protocol 822 Identification In The Network Layer. 824 [9] http://www.iana.org/assignments/ethernet-numbers. 826 [10] ITU-T Recommendation G.7712 v1.2 Architecture and 827 Specification of Data Communication Network. 829 [11] RFC 1191 Path MTU discovery. 831 [12] draft-ietf-isis-ipv6-02.txt Routing IPv6 with IS-IS 833 8.Acknowledgements 835 Jonathan Sadler, Mike Shand and Les Ginsberg have made various 836 suggestions that have improved the automatic encapsulation scheme 837 way beyond what was originally presented. 839 9.Author's Address 841 Philip Christian 842 Nortel Networks Harlow Laboratories 843 London Road, Harlow, 844 Essex, CM17 9NA UK 845 Email: christi@nortelnetworks.com 847 Christian Expires January 2003 16 848 IS-IS Automatic Encapsulation 850 10.Copyright Notice 852 Copyright (C) The Internet Society 2001. All Rights Reserved. 854 This document and translations of it may be copied and furnished to 855 others, and derivative works that comment on or otherwise explain it 856 or assist in its implementation may be prepared, copied, published 857 and distributed, in whole or in part, without restriction of any 858 kind, provided that the above copyright notice and this paragraph 859 are included on all such copies and derivative works. However, this 860 document itself may not be modified in any way, such as by removing 861 the copyright notice or references to the Internet Society or other 862 Internet organisations, except as needed for the purpose of 863 developing Internet standards in which case the procedures for 864 copyrights defined in the Internet Standards process must be 865 followed, or as required to translate it into languages other than 866 English. 868 The limited permissions granted above are perpetual and will not be 869 revoked by the Internet Society or its successors or assigns. 871 This document and the information contained herein is provided on an 872 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 873 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 874 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 875 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 876 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 878 Christian Expires January 2003 17 879 IS-IS Automatic Encapsulation 881 Annex A 882 Updates to Dijkstra's Algorithm 884 The following Annex contains the full Dijkstra's algorithm including 885 extensions to support automatic tunnelling. It is based on the 886 algorithm as specified in RFC 1195 [1]. The algorithm describes the 887 behaviour of a dual protocol IS capable of supporting network-layer 888 protocols A and B. A and B represent any pair of network-layer 889 protocols such as CLNP, IPv4 or IPv6. 891 A1. Changes to the Database 893 The PATHS and TENTS database should be updated to contain an 894 extension to the {Adj(N)}, element of the triple. The adjacency N 895 element will contain two corresponding Dual Protocol Support 896 (ABDP(N)-BADP(N)) entries which will represent the System ID of the 897 first Dual router on the path from S to N capable of de- 898 encapsulating A over B tunnelled packets (ABDP(N)) and the System ID 899 of the first dual router on that path from S to N capable of de- 900 encapsulating B over A tunnelled packets (BADP(N). If no *DP(N) 901 router exists on the PATH then this value will be set to zero. If 902 multiple Adj(N) entries exist in either the TENTS or the PATHS 903 database then each adjacency will have corresponding *DP(N) entries. 904 Thus each triple will take the format 905 906 If the value of ABDP(N) is set to 0 then this means that no dual 907 router exists on the path to the destination capable of de- 908 encapsulating and encapsulating A over B packets. 909 If the value of BADP(N) is set to 0 then this means that no dual 910 router exists on the path to the destination capable of de- 911 encapsulating and encapsulating B over A packets. 913 A2. Changes to the Algorithm 915 The SPF algorithm specified in section C.2.3 of [1] is amended to 916 appear as follows: 918 Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to 919 [internalmetric=0, externalmetric=0]. 921 (tentlength is the pathlength of elements in TENT that we are 922 examining.) 924 1) Add to PATHS, where W is a special value 925 indicating traffic to SELF is passed up to internal processes 926 (rather than forwarded). 928 2) Now pre-load TENT with the local adjacency database (Each entry 929 made to TENT must be marked as being either an End System or a 930 router to enable the check at the end of Step 2 to be made 931 correctly - Note that each local IP reachability entry is 932 included as an adjacency, and is marked as being an End System). 934 Christian Expires January 2003 18 935 IS-IS Automatic Encapsulation 937 For each adjacency Adj(N) (including level 1 OSI Manual 938 Adjacencies, or level 2 OSI enabled reachable addresses, and IP 939 reachability entries) on enabled circuits, to system N of SELF in 940 state "Up" compute: 942 d(N) = cost of the parent circuit of the adjacency (N), 943 obtained from metric.k , where k = one of {default metric, 944 delay metric, monetary metric, error metric} 946 Adj(N)-ABDP(N)-BADP(N) = the adjacency number of the 947 adjacency to N ,the SID of the next-hop router along the path 948 to the neighbour capable of de-encapsulating A over B packets 949 and the SID of the next-hop router along the path to the 950 neighbour capable of de-encapsulating B over A packets . In 951 this case i.e. during initialisation both DP values will be 952 set to 0 954 3) If a triple is in TENT, then: 956 If x = d(N), then {Adj(M)-ABDP(N)-BADP(N)} <--- {Adj(M)- 957 ABDP(M)-BADP(M)} U {Adj(N)-ABDP(N)-BADP(N)}. 959 4) If N is a router or an OSI End System entry, and there are now 960 more adjacencies in {Adj(M)} than maximumPathSplits, then remove 961 excess adjacencies as described in Clause 7.2.7 of [1]. If N is 962 an IP Reachability Entry, then excess adjacencies may be removed 963 as desired. This will not effect the correctness of routing, but 964 may eliminate the determinism for IP routes (i.e., IP packets 965 still follow optimal routes within an area, but where multiple 966 equally good routes exist, will not necessarily follow precisely 967 the route that any one particular router would have anticipated). 969 5) If x < d(N), do nothing. 971 6) If x > d(N), remove from TENT and 972 add the triple . 974 7) If no triple is in TENT, then 975 add to TENT. 977 8) Now add systems to which the local router does not have 978 adjacencies, but which are mentioned in neighbouring pseudonode 979 LSPs. The adjacency for such systems is set to that of the 980 designated router. 981 Note that this does not include IP reachability entries from 982 neighbouring pseudonode LSPs. In particular, the pseudonode LSPs 983 do not include IP reachability entries. 985 9) For all broadcast circuits in state "On", find the pseudonode LSP 986 for that circuit (specifically, the LSP with number zero and with 987 the first 7 octets of LSPID equal to LnCircuitID for that 988 circuit, where n is 1 (for level 1 routing) or 2 (level 2 989 routing)). If it is present, for all the neighbours N reported in 991 Christian Expires January 2003 19 992 IS-IS Automatic Encapsulation 994 all the LSPs of this pseudonode which do not exist in TENT add an 995 entry to TENT, where: 997 d(N) = metric.k of the circuit. 998 Adj(N) = the adjacency number of the adjacency to the DR. 1000 10) Go to Step 2. 1002 Step 1: Examine the zeroeth link state PDU of P, the system just 1003 placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID 1004 as P, and LSP number zero). 1006 1) If this LSP is present and the "Infinite Hippity Cost" bit is 1007 clear, then for each Adj(*)-ABDP(*)-BADP(*) pair in the PATHS 1008 database for P:- 1010 If this is not a pseudonode LSP and if ABDP(*) is equal to 1011 zero then check the unencapsulation capability field of the 1012 LSP, if it supports A over B then set the ABDP(P) value for 1013 this adjacency to be the system ID of P. 1015 If this is not a pseudonode LSP and if BADP(*) is equal to 1016 zero then check the unencapsulation capability field of the 1017 LSP, if it supports B over A then set the BADP(P)value for 1018 this adjacency to be the system ID of P. 1020 2) If this LSP is present, and the "Infinite Hippity Cost" bit is 1021 clear, then for each LSP of P (i.e., all LSPs with the same first 1022 7 octets of LSPID and P, irrespective of the value of LSP number) 1023 compute: 1025 dist(P,N) = d(P) + metric.k(P,N) 1027 for each neighbour N (both End System and router) of the system 1028 P. If the "Infinite Hippity Cost" bit is set, only consider the 1029 End System neighbours of the system P. 1030 Note that the End Systems neighbours of the system P includes IP 1031 reachable address entries included in the LSPs from system P. 1032 Here, d(P) is the second element of the triple 1034 1036 and metric.k(P,N) is the cost of the link from P to N as reported 1037 in P's link state PDU. 1039 3) If dist(P,N) > MaxPathMetric, then do nothing. 1041 4) If is in PATHS, then do 1042 nothing. 1044 Note: d(N) must be less than dist(P,N), or else N would not 1045 have been put into PATHS. An additional sanity check may be 1046 done here to ensure that d(N) is in fact less than dist(P,N) 1048 Christian Expires January 2003 20 1049 IS-IS Automatic Encapsulation 1051 6) If a triple is in TENT, then: 1053 a) If x = dist(P,N), then {Adj(N), ABDP(N)-BADP(N)} <-- {Adj(N) - 1054 ABDP(N)-BADP(N)} U {Adj(P) -ABDP(P)-BADP(N)}. 1056 Note that even if the value of Adj(N) is equal to the value 1057 Adj(P) but the corresponding values of either ABDP(P) or 1058 BADP(P) and ABDP(N) or BADP(N) are different then this should 1059 be treated as a different adjacency and will represent a 1060 different path to the destination. 1062 b) If N is a router or an OSI end system, and there are now more 1063 adjacencies in {Adj(N)} than maximumPath Splits, then remove 1064 excess adjacencies, as described in clause 7.2.7 of [1]. For IP 1065 Reachability Entries, excess adjacencies may be removed as 1066 desired. This will not effect the correctness of routing, but 1067 may eliminate the determinism for IP routes (i.e., IP packets 1068 will still follow optimal routes within an area, but where 1069 multiple equally good routes exist, will not necessarily follow 1070 precisely the route that any one particular router would have 1071 anticipated). 1073 c) if x < dist(P,N), do nothing. 1075 d) if x > dist(P,N), remove from 1076 TENT, and add 1077 1079 7) if no triple is in TENT, then add 1080 to TENT. 1082 Step 2: If TENT is empty, stop. Else: 1084 1) Find the element , with minimal x 1085 as follows: 1087 a) If an element <*,tentlength,*> remains in TENT in the list for 1088 tentlength, choose that element. If there are more than one 1089 elements in the list for tentlength, choose one of the elements 1090 (if any) for a system which is a pseudonode in preference to 1091 one for a non-pseudonode. If there are no more elements in the 1092 list for tentlength, increment tentlength and repeat Step 2. 1094 b) Remove from TENT. 1096 c) Add to PATHS. 1098 d) If this is the Level 2 Decision Process running, and the system 1099 just added to PATHS listed itself as Partition Designated Level 1100 2 Intermediate system, then additionally add 1101 to PATHS, where AREA.P is the Network 1103 Christian Expires January 2003 21 1104 IS-IS Automatic Encapsulation 1106 Entity Title of the other end of the Virtual Link, obtained by 1107 taking the first AREA listed in P's LSP and appending P's ID. 1109 e) If the system just added to PATHS was an end system, go to step 1110 2. Else go to Step 1. 1112 NOTE - In the level 2 context, the "End Systems" are the set of 1113 Reachable Address Prefixes (for OSI), the set of Area Addresses with 1114 zero cost (again, for OSI), plus the set of IP reachability entries 1115 (including both internal and external). 1117 Christian Expires January 2003 22