idnits 2.17.1 draft-ietf-isis-auto-encap-01.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 191: '...tic encapsulation/unencapsulation MUST...' RFC 2119 keyword, line 193: '...ber 0. This TLV MUST be included in b...' RFC 2119 keyword, line 208: '... type equal to 1 MUST contain three by...' RFC 2119 keyword, line 225: '...capsulation-mode SHALL be 47 (decimal)...' RFC 2119 keyword, line 229: '...capsulation-mode SHALL be 41 (decimal)...' (55 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 940 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 1056 looks like a reference -- Missing reference section? '12' on line 824 looks like a reference -- Missing reference section? '2' on line 802 looks like a reference -- Missing reference section? '3' on line 804 looks like a reference -- Missing reference section? '4' on line 806 looks like a reference -- Missing reference section? '5' on line 808 looks like a reference -- Missing reference section? '6' on line 810 looks like a reference -- Missing reference section? '7' on line 812 looks like a reference -- Missing reference section? '8' on line 814 looks like a reference -- Missing reference section? '10' on line 819 looks like a reference -- Missing reference section? '11' on line 822 looks like a reference -- Missing reference section? '9' on line 817 looks like a reference Summary: 9 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 Category: Informational 3 Expires: January 2003 5 IS-IS Automatic Encapsulation 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 The IETF is advised of potential intellectual property rights in 14 regard to some or all of the specification contained in this 15 document. For more information consult the online list for notices 16 and/or updates. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. Note that 20 other groups may also distribute working documents as Internet 21 Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a 27 "working draft" or "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This memo provides information for the Internet community. This memo 36 does not specify an Internet standard of any kind. 38 Distribution of this draft is unlimited. 40 Christian Expires January 2003 1 41 IS-IS Automatic Encapsulation 43 Abstract 45 RFC 1195 [1] documents a dual routing protocol that can be used to 46 route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS- 47 IS can now also be used to route IPv6 [12]. 49 RFC 1195 [1] places certain topological restrictions on networks 50 that are routed using Integrated IS-IS, specifically that every 51 Intermediate System in a level-1 area must be able to forward all 52 network layer protocols that are present in that area, and that 53 every level-2 Intermediate System must be able to forward all 54 network layer protocols present in the routing domain. 56 The mechanism described in this document enables an Intermediate 57 System or a group of Intermediate Systems that do not support a 58 particular network layer protocol to be used in a level-1 area or 59 level-2 subdomain where that network layer protocol is present. 61 Specifically the mechanism provides automatic encapsulation and 62 unencapsulation so that a packet or PDU may pass through an 63 Intermediate System that would not normally be able to forward that 64 type of packet. 66 1.Introduction 68 RFC 1195 [1] documents a dual routing protocol that can be used to 69 route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS-IS 70 can now also be used to route IPv6 [12]. 72 RFC 1195 [1] also foresaw the possibility of an automatic 73 encapsulation feature. Automatic encapsulation is stated as for 74 "for further study" in section 3.8. The automatic encapsulation 75 scheme detailed here may be considered a continuation of section 3.8 76 of RFC 1195 [1]. 78 Integrated IS-IS ISs (Intermediate Systems) can calculate routes to 79 CLNS, IPv4 and IPv6 destinations using a single SPF calculation. 80 This is achieved by treating OSI End System, IPv4 and IPv6 addresses 81 in a similar way, but it does rely on an assumption which forces 82 topological restrictions onto the network. 84 Integrated IS-IS views a level-1 area or level-2 subdomain as a 85 collection of connected ISs, without considering which ISs can 86 actually forward which network-layer protocols. It simply assumes 87 that all ISs that it can see, can forward all packet types. For 88 Integrated IS-IS to be able to pick different routes for different 89 network-layer protocols would imply a separate SPF calculation for 90 each network layer protocol. It would then arguably no longer be an 91 integrated routing protocol. 93 Specifically page 26 of RFC 1195 [1] states:- 95 Christian Expires January 2003 2 96 IS-IS Automatic Encapsulation 98 "The Dijkstra computation does not take into consideration whether 99 a router is IP-only, OSI-only, or dual. The topological 100 restrictions specified in section 1.4 ensure that IP packets will 101 only be sent via IP-capable routers, and OSI packets will only be 102 sent via OSI-capable routers." 104 It is important that all ISs in a network calculate routes in such 105 a way that they all arrive at the same shortest path. If some ISs 106 calculate a different shortest path to others then routing loops 107 and blackholes can occur. Therefore in a multiprotocol environment 108 having ISs that consider forwarding capabilities when calculating 109 the shortest path, mixed with ISs that do not could result in 110 routing loops and packet loss. 112 Consequently, RFC 1195 states that if both IPv4 and CLNP are to be 113 forwarded anywhere in a level-1 area or level-2 subdomain, then, all 114 of the ISs in that level-1 area or level-2 subdomain must be capable 115 of forwarding both IPv4 and CLNP. The same logic applies if it is 116 required to have both IPv4 and IPv6 present in a level-1 area or 117 level-2 subdomain. 119 This topological rule can already be broken with extreme care. If it 120 can be guaranteed that a certain part of an IS-IS network will never 121 receive a certain type of packet, then that network layer protocol 122 need not be supported. 124 However, failure to observe these topological restrictions can 125 result in blackholes forming, and packet loss. Consider the 126 following (illegal) example:- 128 +--------+ +-------+ +--------+ 129 | IS A | | IS B | | IS C | 130 IPv6 host#1--+ v4/v6 +--+ v4 IS +--+ v4/v6 +--IPv6 host#2 131 | | | | | | 132 +--------+ +-------+ +--------+ 134 IS A will find the shortest path to IPv6 host#2 as being through IS 135 B. If host#1 then sends an IPv6 packet to the host#2, then the dual 136 IS will forward it to the IS B, which will not be able to forward 137 the packet. IS B will discard the packet instead, resulting in 138 packet loss. 140 This document describes a mechanism that can be used to overcome 141 this topological restriction. The mechanism detects that a packet is 142 about to be send to an IS that does not support that network layer 143 protocol, and automatically encapsulates the packet into a form that 144 then can be forwarded. Essentially the mechanism can take an 145 existing IS, or collection of ISs, that support forwarding of IPv4 146 for example, and, by automatic encapsulation of IPv6 inside IPv4, 147 can enable IPv6 traffic to also cross these IPv4 ISs, making that 148 part of the network behave as if it is dual. 150 Christian Expires January 2003 3 151 IS-IS Automatic Encapsulation 153 2.The automatic encapsulation mechanism. 155 2.1. Introduction. 157 Consider the following example:- 159 +--------+ +-------+ +--------+ 160 IPv4 host--+ IS A | | IS B | | IS C +--IPv4 host 161 | v4/v6 +--+ v4 IS +--+ v4/v6 | 162 IPv6 host--+ | | | | +--IPv6 host 163 +--------+ +-------+ +--------+ 165 Forwarding of IPv4 traffic from one host to the other is not a 166 problem in this network. However IPv6 traffic cannot be forwarded by 167 IS B without being encapsulated inside an IPv4 packet. 169 IS A and IS C actually have most of the information that they need 170 in order to automatically perform this encapsulation. 172 1. IS A can detect that IS B cannot forward an IPv6 packet, because 173 RFC 1195 [1] already requires IS B to include a "protocols 174 supported" TLV in Hello packets. Absence of the TLV indicates 175 that an IS that can forward only CLNP. 177 2. IS A receives LSPs (Link State PDUs) from IS C. This is because 178 IS-IS LSPs are neither IPv4 nor IPv6 packets. IS-IS is a 179 network-layer protocol in its own right, and is used in common 180 by all ISs whether they forward CLNP, IPv4 or IPv6 packets. 182 By adding an extra TLV to the LSPs that IS C transmits, containing 183 the encapsulation/unencapsulation capability of C, this information 184 will be flooded throughout the level-1 area or level-2 subdomain. 185 IS A is now able to encapsulate IPv6 traffic inside IPv4 packets, 186 and send them to IS C, on the understanding that IS C will 187 unencapsulate the IPv6 traffic and forward it onwards. 189 2.2. Encapsulation Capability Field. 191 Any IS that supports automatic encapsulation/unencapsulation MUST 192 include an "Encapsulation Capability" TLV in LSPs that have LSP 193 number 0. This TLV MUST be included in both level-1 LSPs and level- 194 2 LSPs. 196 The structure of the TLV is as follows:- 198 Code: 16 (decimal) 199 Length: The length of the value 200 Value: The value shall contain Sub-TLVs of the form:- 201 Sub-TLV Type 202 Sub-TLV Length: The length of the sub-TLV value 203 Sub-TLV Value: Variable number of bytes 205 Christian Expires January 2003 4 206 IS-IS Automatic Encapsulation 208 Sub-TLVs with sub-TLV type equal to 1 MUST contain three byte 209 encapsulation modes with the following structure:- 211 Sub-TLV type: 1 212 Sub-TLV length: Three times the number of encapsulation modes 213 Sub-TLV value: Encapsulation-mode#1 214 Inner-Protocol#1 215 Outer-Protocol#1 216 Encapsulation-mode#2 217 Inner-Protocol#2 218 Outer-Protocol#2 219 . 220 . 221 Encapsulation-mode#n 222 Inner-Protocol#n 223 Outer-Protocol#n 225 Encapsulation-mode SHALL be 47 (decimal) to describe a 226 GRE encapsulation as defined in RFCs 1701[2], 1702[3], 227 2784[4] and 3147[5]. 229 Encapsulation-mode SHALL be 41 (decimal) to describe 230 IPv6 in IP encapsulation as defined in RFC 1933 and in 231 RFC 2893[6]. 233 Encapsulation-mode SHALL be 4 (decimal) to describe IPv4 234 in IP encapsulation as (sort of) defined in RFC 2003[7]. 236 Inner-Protocol SHALL be the NLPID of a packet that the 237 IS is capable of sending or receiving in an encapsulated 238 form. 240 Outer-Protocol SHALL be the NLPID of a packet that the 241 IS is capable of using to transport the Inner-Protocol 242 in encapsulated form. 244 NLPIDs SHALL be those as specified in ISO/TR 9577[8]. 246 These encapsulation modes are chosen simply as they are the IP 247 protocol numbers for these encapsulation mechanisms. 249 Future capabilities, such as non-NLPID definitions, may be provided 250 using the same TLV number by using an alternative sub-TLV number. 252 Note that ITU-T G.7712 [10] mandates that GRE shall be used for all 253 combinations of CLNS, IPv4 and IPv6 over CLNS, IPv4 or IPv6. 254 Therefore if interoperability is required with SONET / SDH DCC 255 channels then GRE will have to be supported. RFC 3147 [5] also 256 describes IP encapsulation over CLNS using GRE. This is stated for 257 information purposes only and is not a requirement of this document. 259 By way of an example, a dual IPv4/IPv6 IS that supports automatic 260 encapsulation of IPv6 over IPv4, and automatic encapsulation of IPv4 262 Christian Expires January 2003 5 263 IS-IS Automatic Encapsulation 265 over IPv6, using only GRE would therefore transmit the TLV with the 266 following contents:- 268 Dec (Hex) 269 16 (0x10): The TLV number 270 8 (0x08): The length of the value 271 1 (0x01): Sub-TLV type 1 272 6 (0x06): Length of the value of the sub-TLV 273 47 (0x2F): Indicating that the next two bytes are a GRE mode 274 204 (0xCC): Inner-protocol of IPv4 275 142 (0x8E): Outer-protocol of IPv6 276 47 (0x2F): Indicating that the next two bytes are a GRE mode 277 142 (0x8E): Inner protocol of IPv6 278 204 (0xCC): Outer protocol of IPv4 280 An IS that includes an encapsulation mode in its "encapsulation 281 capability" TLV MUST be capable of both transmitting and receiving 282 that encapsulation mode, as specified in sections 2.3 and 2.4. 284 2.3. Transmission of automatically encapsulated packets 286 Shortest paths SHALL be calculated in the normal way, as per RFC 287 1195 [1]. 289 Before forwarding a packet to a next hop, an IS MUST check that the 290 next hop can forward that type of packet. The IS MUST check this by 291 referring to the "protocol supported" TLV in IS-IS Hello PDUs. 292 Absence of a "Protocols Supported" TLV in Hello PDUs indicates that 293 the next hop can forward only CLNP packets. 295 If an IS finds that the next hop does support the type of packet 296 that it is attempting to forward, then it MUST simply forward the 297 packet to that adjacency as normal, without encapsulating it. 299 If an IS finds that the next hop does not support the type of packet 300 that it is attempting to forward, then it MUST search along the 301 shortest path from itself to the destination, and MUST inspect the 302 "encapsulation capability" TLV of LSP 0 of each IS until it finds an 303 IS that it is able to send the packet to in an encapsulated form. 305 The IS MUST search within each "encapsulation capability" TLV until 306 it finds an encapsulation mode that meets the following three 307 criteria:- 309 1.The encapsulation-mode MUST be one that this IS supports. 310 2.The inner-protocol MUST be equal to the NLPID of the packet that 311 this IS is attempting to forward. 312 3.The outer-protocol MUST be equal to one of the NLPIDs that the 313 next hop lists in the "protocols supported" TLV of IS-IS Hello 314 PDUs, or equal to the NLPID for CLNS/CLNP if no "protocols 315 supported" TLV is present in IS-IS Hello PDUs from the next hop. 317 When inspecting an "encapsulation capability" TLV, then, an IS MUST 319 Christian Expires January 2003 6 320 IS-IS Automatic Encapsulation 322 ignore any encapsulation modes that it does not understand, but 323 instead jump forward to inspect the next encapsulation mode, until 324 it finds a suitable mode or until it reaches the end of the TLV. 326 When inspecting an "encapsulation capability" TLV, then, an IS MUST 327 ignore any sub-TLVs that it does not understand, but instead jump 328 forward to inspect the next sub-TLV, until it finds a suitable mode 329 or until it reaches the end of the TLV. 331 The IS MUST encapsulate the packet inside another and send it to the 332 first IS along the shortest path to the destination that meets the 333 criteria, using the encapsulation mode that resulted in it meeting 334 the above criteria. See 2.3.1. for an explanation. 336 It is suggested that this search is pre-calculated and performed for 337 every destination that cannot be forwarded natively every time the 338 SPF (Dijkstra) algorithm is run, and that the results are included 339 in each forwarding table, with a marker indicating that for that 340 particular destination that the packet should be encapsulated using 341 a certain encapsulation mode (if more than one is supported) and 342 with a certain destination address, which will be a destination 343 address expressed in the format used by the outer-protocol that is 344 going to be used. For this a modified SPF algorithm is provided in 345 Annex A. 347 The destination address of the resultant encapsulation packet MUST 348 be equal to the identity of the IS that sent the TLV that was the 349 first along the shortest path that met the above criteria. 351 The source address of the resultant encapsulation packet MUST be 352 equal to the identity of the IS that is performing the 353 encapsulation. 355 If the outer protocol is IPv4 then the "Don't Fragment" bit MUST NOT 356 be set. If the outer protocol is CLNP then the "Segmentation 357 Permitted" flag MUST be set. This will protect against packet loss 358 due to the new packet being longer than the MTU size of the link 359 over which it is to be transmitted, and will prevent unwanted 360 interactions with path MTU discovery [11]. 362 2.3.1. Reasoning for sending to first capable IS 364 Section 2.3 indicates that a packet that cannot be forwarded 365 natively should be encapsulated and sent to the first IS along the 366 shortest path that advertises itself as being capable of 367 unencapsulating it. In fact, the packet could be encapsulated and 368 sent to any IS along the shortest path that advertises itself as 369 being capable of unencapsulating it, and the packet would arrive at 370 its destination. 372 The most reasonable choices would appear to be either the first, or 373 the last IS unencapsulation capable IS, each choice has advantages 374 and disadvantages. 376 Christian Expires January 2003 7 377 IS-IS Automatic Encapsulation 379 Choosing the first may result in a packet being encapsulated and 380 unencapsulated several times on its way to its destination, as it 381 crosses multiple "subnetworks" that do not support forwarding of 382 that type of packet. When the packet is being forwarded by a part of 383 the network that can forward it natively, it is in its original 384 form. 386 Choosing the last may result in encapsulation within encapsulation 387 within encapsulation, as for example an IPv6 packet will become an 388 IPv4 packet and remain so till the last IS that can unencapsulate. 389 This IPv4 packet may in turn need to traverse an IPv6-only 390 "subnetwork" and be encapsulated again. If the last IS capable of 391 unencapsulation advertises itself as being capable of IPv6/IPv4 and 392 IPv4/IPv6, then it will loaded with unencapsulating all of the 393 layers of encapsulation in one go. 395 Although the argument is probably a religious one, unencapsulating a 396 packet as soon as possible, and avoiding encapsulation within 397 encapsulation (and the long packets that may result) would appear to 398 be the lesser of the two evils. The load of fragmentation and 399 reassembly must also be considered if multiple layers of 400 encapsulation results in an MTU size being blown. Also it is 401 probably better for a packet to exist in the network in its native 402 form whenever possible, making the network easier to debug, and 403 reducing the impact of encapsulation to the smallest part of the 404 network possible. 406 However, any IS MUST be able to unencapsulate any packet that 407 arrives at it with its destination address, and with an 408 encapsulation mode that it advertised in its "encapsulation 409 capability" TLV. This opens the possibility for more intelligent 410 algorithms to be developed that choose an IS capable of 411 unencapsulating, other than the first. 413 2.4. Receipt of automatically encapsulated packets 415 An IS that supports automatic encapsulation / unencapsulation MUST 416 inspect any received packet that has a destination address equal to 417 itself to see if it is an encapsulation of a type that it 418 transmitted in its "encapsulation capability" TLV. 420 If the IS finds that such a received packet is an encapsulation 421 packet then it SHOULD discard the inner packet if it is of a type 422 that it did not list as an "inner-protocol" in an encapsulation mode 423 in its "encapsulation capability" TLV. 425 Upon discarding such a packet it is suggested that the IS reports or 426 logs an error report. 428 An IS that also supports manually configured tunnels will need to 429 check that a packet has not arrived over a manual tunnel in the 430 normal way before discarding it. 432 Christian Expires January 2003 8 433 IS-IS Automatic Encapsulation 435 Otherwise the received packet MUST be unencapsulated and re- 436 received. Note that encapsulation within encapsulation is a 437 possibility, particularly for ISs that support three or more network 438 layer protocols. 440 2.5. Interaction with Path MTU Discovery (PMTU), RFC 1191 [11]. 442 Although packets become encapsulated, no tunnel "interface" or 443 circuit as such really exists. Therefore there will be no MTU limit 444 for the inner-protocol. It is suggested that packets of any size 445 are accepted, then encapsulated, and that the encapsulated outer- 446 protocol packet is fragmented/segmented if necessary in order to be 447 forwarded over the real interface. For this reason in the new 448 outer-protocol packet the Don't Fragment MUST NOT be set (for IPv4), 449 or Segmentation Permitted flag MUST be set (for CLNP). 451 One consequence of this is that a link, if packets traverse it in 452 an encapsulated form, becomes invisible to Path MTU Discovery. 454 However this is the safest option as it guarantees that packets will 455 never be discarded due to MTU issues. Because the inner-protocol is 456 different to the outer-protocol, if the outer-protocol where to be 457 discarded for any reason then the reason is not likely to be known 458 to the originator of the inner-protocol packet. Path MTU discovery 459 does rely on knowing the reason for discard of packets, and so the 460 safest option is to make the outer-protocol and encapsulation 461 process invisible to it. 463 An additional option is to reject packets for encapsulation that are 464 bigger than a certain size, and to report back to the originator a 465 suitable error message. If this approach is chosen then the packet 466 MUST be rejected before encapsulation, and a suitable error message 467 MUST be returned to the originator using the correct mechanism for 468 that network layer protocol. Such a process would be prior to and 469 independent of automatic encapsulation, and does not alter the 470 requirement that the outer-protocol packets are never discarded, but 471 fragmented/segmented instead. 473 3.Allowable and non-allowable topologies 475 This mechanism effectively enables an IS or group of ISs to act as 476 if they support one or more network layer protocols that they 477 actually do not. Automatic encapsulation is the process that 478 enables this to be possible, but care must be taken to ensure that 479 incompatible packets are not leaked into such a "subnetwork" without 480 going through an automatic encapsulation capable IS. 482 Thus, at the all of the boundaries to the "subnetwork", there MUST 483 be installed an IS that supports automatic encapsulation. At points 484 where the inner "subnetwork" meet the outer general network without 485 an automatic encapsulation IS between the two, any adjacency MUST be 486 disabled. 488 Christian Expires January 2003 9 489 IS-IS Automatic Encapsulation 491 In order to partially automate this the ITU-T mandated in G.7712[10] 492 that any Integrated IS-IS capable SDH NE must not consider itself a 493 neighbour to any other IS unless the other IS supports at least one 494 network layer protocol in common with it. This effectively makes it 495 impossible to accidentally have an adjacency between an OSI-only and 496 an IP-only SDH NE, or between an IPv4-only and an IPv6-only SDH NE. 498 This cannot be retrospectively applied to RFC 1195[1] compliant ISs, 499 however it is recommended that all Integrated IS-IS ISs include this 500 safeguard whenever possible. In the absence of this behaviour it is 501 the responsibility of the network manager to manually insure that no 502 such adjacencies are formed. Certain Integrated IS-IS 503 implementations also check for correct subnetting of a neighbour 504 before accepting an adjacency; usefully this should also prevent an 505 IPv4-only IS from forming an adjacency with an OSI-only or an 506 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 one 623 pseudonode which MUST declare adjacencies with all IPv4-capable 624 ISs on the LAN, with all-IPv6 capable ISs on the LAN, and with 625 the dual automatic encapsulating IS. 627 The first three scenarios will always forward traffic correctly in 628 on a LAN and will result in packets being encapsulated before being 629 forwarded across incompatible ISs. 631 The fourth scenario relies on other ISs on the LAN conforming to 632 ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section 633 C.1.4 step 0 clause 8. ISs that do not will drop packets 634 rather than send traffic to a dual IS for automatic encapsulation, 635 if the dual IS is the DIS, and if non-compatible ISs on the same LAN 636 are on the shortest path. This is because the psuedonode declares 637 itself to be between two ISs that are actually incompatible and 638 therefore should not share an adjacency. The SPF algorithm in one 639 IS on the LAN may find other ISs on the LAN to be the shortest path 640 to certain destinations, through the pseudonode, but then cannot 641 actually forward traffic to them as there is no adjacency. This 642 can result in packets being dropped rather than being encapsulated 643 in order to traverse incompatible ISs on the LAN. 645 ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section 646 C.1.4 step 0 clause 8 causes an IS to forward traffic to the DIS in 647 this scenario, which in this case is an automatic encapsulation IS. 648 Thus if all ISs on the LAN that have a lower priority than the 649 automatic encapsulation IS are conformant with this clause then 650 packets are forwarded and encapsulated properly. 652 Network administrators need to ensure that ISs that do not conform 653 with ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section 654 C.1.4 step 0 clause 8 have a higher priority than any automatic 655 encapsulation ISs on the same LAN if it is a mixed protocol LAN. 657 Christian Expires January 2003 12 658 IS-IS Automatic Encapsulation 660 4.2. LSP update process 662 ISO/IEC 10589 [2] states in section 7.3.15.1 that an LSP received 663 that does not come from a valid adjacency must be discarded. A 664 strict single protocol implementation will therefore reject LSPs 665 that are transmitted onto a LAN interface by an IS that it has 666 rejected an adjacency with due to no network-layer protocol in 667 common (or by manual configuration or no subnet in common). 669 Thus if an IPv4-only IS transmits an LSP onto a LAN then an IPv6- 670 only IS can receive such an LSP only from a dual automatic 671 encapsulating IS. Normally a dual IS will only forward such an LSP 672 during periodic LSP database synchronisation. 674 Dual automatic encapsulating ISs are therefore required to have 675 modified LSP flooding behaviour so that OSI-only, IPv4-only or IPv6- 676 only ISs do not need to wait for the next LSP database 677 synchronisation event. 679 Dual automatic encapsulating ISs MUST check incoming LSPs that 680 arrive on LAN interfaces to see if they come from a neighbour that 681 supports all of the network layer protocols that the dual automatic 682 encapsulating IS does. This MUST be achieved by inspection of the 683 "protocols supported" TLV in Hello packets received from that 684 neighbour. 686 If the LSP is received from a neighbour that does support all of the 687 network layer protocols that the dual or multilingual IS supports, 688 then the dual automatic encapsulating IS SHALL behave as per ISO/IEC 689 10589 and unset the SRM flag for that LSP on that LAN interface if 690 it already has the LSP, or shall flood it out of all other 691 interfaces if it does not already have the LSP. 693 If the LSP is received from a neighbour that does not support all of 694 the network layer protocols that the dual automatic encapsulating IS 695 supports, and, if it does not already have the LSP then the dual 696 automatic encapsulating IS SHALL set the SRM flag for that LSP on 697 the LAN interface over which the LSP was received, in addition to 698 all other interfaces, resulting in the dual automatic encapsulating 699 IS re-transmitting the LSP onto the LAN. 701 In this way if an LSP is transmitted onto the LAN by an IPv4-only 702 IS, then one of the dual automatic encapsulating ISs will re- 703 transmit the LSP, so that it may be received on a valid adjacency by 704 IPv6-only ISs on the LAN and vice versa. 706 Christian Expires January 2003 13 707 IS-IS Automatic Encapsulation 709 4.3. Redirects 711 If a dual automatic encapsulating IS originates an ICMP redirect 712 request, the request MUST not redirect IPv4 packets from an IPv4 713 capable IS to a non-IPv4 capable IS, or redirect IPv6 packets from 714 an IPv6 capable IS to a non-IPv6 capable IS. Likewise if a dual 715 automatic encapsulating router originates ISO/IEC 9542[5] Redirect 716 PDUs, the redirect MUST not redirect CLNS packets from an OSI 717 capable IS to a non-OSI capable IS. 719 5.Level-1, level-2 ISs 721 Although this mechanism allows "subnetworks" to exist in a level-1 722 area or level-2 subdomain that do not support all of the network 723 layer protocols present in the area or subdomain, packets must still 724 be able to get in and out of an area and onto the level-2 subdomain. 726 It is therefore recommended that all ISs that support both level-1 727 and level-2 can forward all network layer protocols that exist in 728 the area. 730 However this may not be possible, if for example an existing network 731 is using this mechanism to upgrade parts of an area to support a new 732 network layer protocol, but a level-1, level-2 IS cannot be 733 upgraded. 735 In this case another IS that does support the new network layer 736 protocol must become the gateway for that protocol. This can be 737 achieved by configuration either of a default route, or a collection 738 of static routes that cover all possible "out of area" destinations. 740 Note that RFC 1195 [1] forbids default routes in level-1 LSPs 741 (however this does not reduce its usefulness as a solution). 743 This gateway IS must then tunnel all "out of area" packets of the 744 new network layer protocol across the incompatible level-1,level-2 745 IS to another IS somewhere in the level-2 subdomain or other routing 746 protocol. 748 Multiple gateways may be configured for redundancy, in this case a 749 gateway SHOULD gate advertisement of a default route on the validity 750 of the tunnel that it is using to send "out of area" packets across. 751 i.e. the IS SHOULD somehow detect that the other end of the tunnel 752 is alive and contactable, and if it is not, it SHOULD stop 753 advertising a default route into the area. This can be achieved by 754 running some other routing protocol such as RIP or OSPF across the 755 tunnel, or another instance of IS-IS, for example. 757 Christian Expires January 2003 14 758 IS-IS Automatic Encapsulation 760 6.Security Considerations 762 6.1 Injection of IP and CLNP packets into the network 764 An IS that employs automatic encapsulation is required to 765 unencapsulate any incoming packet that is of a an advertised 766 encapsulation mode, and forward the contents. 768 Consequently packets may potentially be injected at such an IS 769 in an encapsulated form that maybe would normally be filtered 770 at the edge of a routing domain, but which are now an 771 encapsulation packet. 773 Such a risk is not unique to automatic encapsulation, but is 774 present in manually configured tunnels too, such as RFC 2784 [4] 775 GRE tunnels. 777 Encapsulated packets should never arrive from any source other 778 than another IS in the same level-1 area or level-2 subdomain, 779 and this MAY then be used as the basis of a security filter. 781 In any case such a mechanism will allow an attacker only to 782 inject packets into a network; it does not supply a return path. 784 6.2 Injection of other packets into the network 786 Section 2.4 states that incoming packets SHOULD be discarded if 787 they are not of an inner-protocol type that the IS advertised as 788 being able to unencapsulate. 790 This clause is an important security feature as it prevents 791 false routing packets and consequent false routes from being 792 injected into the network. 794 Christian Expires January 2003 15 795 IS-IS Automatic Encapsulation 797 7.References 799 [1] RFC 1195 800 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. 802 [2] RFC 1701 Generic Routing Encapsulation (GRE). 804 [3] RFC 1702 Generic Routing Encapsulation over IPv4 networks. 806 [4] RFC 2784 Generic Routing Encapsulation (GRE). 808 [5] RFC 3147 Generic Routing Encapsulation over CLNS Networks. 810 [6] RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers. 812 [7] RFC 2003 IP Encapsulation within IP. 814 [8] ISO 9577 and ITU-T X.263 Information Technology - Protocol 815 Identification In The Network Layer. 817 [9] http://www.iana.org/assignments/ethernet-numbers. 819 [10] ITU-T Recommendation G.7712 v1.2 Architecture and 820 Specification of Data Communication Network. 822 [11] RFC 1191 Path MTU discovery. 824 [12] draft-ietf-isis-ipv6-02.txt Routing IPv6 with IS-IS 826 8.Acknowledgements 828 Jonathan Sadler, Mike Shand and Les Ginsberg have made various 829 suggestions that have improved the automatic encapsulation scheme 830 way beyond what was originally presented. 832 9.Author's Address 834 Philip Christian 835 Essex, 836 UK 837 Email: philip.christian@deathsdoor.com 839 Christian Expires January 2003 16 840 IS-IS Automatic Encapsulation 842 10.Copyright Notice 844 Copyright (C) The Internet Society 2001. All Rights Reserved. 846 This document and translations of it may be copied and furnished to 847 others, and derivative works that comment on or otherwise explain it 848 or assist in its implementation may be prepared, copied, published 849 and distributed, in whole or in part, without restriction of any 850 kind, provided that the above copyright notice and this paragraph 851 are included on all such copies and derivative works. However, this 852 document itself may not be modified in any way, such as by removing 853 the copyright notice or references to the Internet Society or other 854 Internet organisations, except as needed for the purpose of 855 developing Internet standards in which case the procedures for 856 copyrights defined in the Internet Standards process must be 857 followed, or as required to translate it into languages other than 858 English. 860 The limited permissions granted above are perpetual and will not be 861 revoked by the Internet Society or its successors or assigns. 863 This document and the information contained herein is provided on an 864 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 865 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 866 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 867 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 868 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Christian Expires January 2003 17 871 IS-IS Automatic Encapsulation 873 Annex A 874 Updates to Dijkstra's Algorithm 876 The following Annex contains the full Dijkstra's algorithm including 877 extensions to support automatic tunnelling. It is based on the 878 algorithm as specified in RFC 1195 [1]. The algorithm describes the 879 behaviour of a dual protocol IS capable of supporting network-layer 880 protocols A and B. A and B represent any pair of network-layer 881 protocols such as CLNP, IPv4 or IPv6. 883 A1. Changes to the Database 885 The PATHS and TENTS database should be updated to contain an 886 extension to the {Adj(N)}, element of the triple. The adjacency N 887 element will contain two corresponding Dual Protocol Support 888 (ABDP(N)-BADP(N)) entries which will represent the System ID of the 889 first Dual router on the path from S to N capable of de- 890 encapsulating A over B tunnelled packets (ABDP(N)) and the System ID 891 of the first dual router on that path from S to N capable of de- 892 encapsulating B over A tunnelled packets (BADP(N). If no *DP(N) 893 router exists on the PATH then this value will be set to zero. If 894 multiple Adj(N) entries exist in either the TENTS or the PATHS 895 database then each adjacency will have corresponding *DP(N) entries. 896 Thus each triple will take the format 897 898 If the value of ABDP(N) is set to 0 then this means that no dual 899 router exists on the path to the destination capable of de- 900 encapsulating and encapsulating A over B packets. 901 If the value of BADP(N) is set to 0 then this means that no dual 902 router exists on the path to the destination capable of de- 903 encapsulating and encapsulating B over A packets. 905 A2. Changes to the Algorithm 907 The SPF algorithm specified in section C.2.3 of [1] is amended to 908 appear as follows: 910 Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to 911 [internalmetric=0, externalmetric=0]. 913 (tentlength is the pathlength of elements in TENT that we are 914 examining.) 916 1) Add to PATHS, where W is a special value 917 indicating traffic to SELF is passed up to internal processes 918 (rather than forwarded). 920 2) Now pre-load TENT with the local adjacency database (Each entry 921 made to TENT must be marked as being either an End System or a 922 router to enable the check at the end of Step 2 to be made 923 correctly - Note that each local IP reachability entry is 924 included as an adjacency, and is marked as being an End System). 926 Christian Expires January 2003 18 927 IS-IS Automatic Encapsulation 929 For each adjacency Adj(N) (including level 1 OSI Manual 930 Adjacencies, or level 2 OSI enabled reachable addresses, and IP 931 reachability entries) on enabled circuits, to system N of SELF in 932 state "Up" compute: 934 d(N) = cost of the parent circuit of the adjacency (N), 935 obtained from metric.k , where k = one of {default metric, 936 delay metric, monetary metric, error metric} 938 Adj(N)-ABDP(N)-BADP(N) = the adjacency number of the 939 adjacency to N ,the SID of the next-hop router along the path 940 to the neighbour capable of de-encapsulating A over B packets 941 and the SID of the next-hop router along the path to the 942 neighbour capable of de-encapsulating B over A packets . In 943 this case i.e. during initialisation both DP values will be 944 set to 0 946 3) If a triple is in TENT, then: 948 If x = d(N), then {Adj(M)-ABDP(N)-BADP(N)} <--- {Adj(M)- 949 ABDP(M)-BADP(M)} U {Adj(N)-ABDP(N)-BADP(N)}. 951 4) If N is a router or an OSI End System entry, and there are now 952 more adjacencies in {Adj(M)} than maximumPathSplits, then remove 953 excess adjacencies as described in Clause 7.2.7 of [1]. If N is 954 an IP Reachability Entry, then excess adjacencies may be removed 955 as desired. This will not effect the correctness of routing, but 956 may eliminate the determinism for IP routes (i.e., IP packets 957 still follow optimal routes within an area, but where multiple 958 equally good routes exist, will not necessarily follow precisely 959 the route that any one particular router would have anticipated). 961 5) If x < d(N), do nothing. 963 6) If x > d(N), remove from TENT and 964 add the triple . 966 7) If no triple is in TENT, then 967 add to TENT. 969 8) Now add systems to which the local router does not have 970 adjacencies, but which are mentioned in neighbouring pseudonode 971 LSPs. The adjacency for such systems is set to that of the 972 designated router. 973 Note that this does not include IP reachability entries from 974 neighbouring pseudonode LSPs. In particular, the pseudonode LSPs 975 do not include IP reachability entries. 977 9) For all broadcast circuits in state "On", find the pseudonode LSP 978 for that circuit (specifically, the LSP with number zero and with 979 the first 7 octets of LSPID equal to LnCircuitID for that 980 circuit, where n is 1 (for level 1 routing) or 2 (level 2 981 routing)). If it is present, for all the neighbours N reported in 983 Christian Expires January 2003 19 984 IS-IS Automatic Encapsulation 986 all the LSPs of this pseudonode which do not exist in TENT add an 987 entry to TENT, where: 989 d(N) = metric.k of the circuit. 990 Adj(N) = the adjacency number of the adjacency to the DR. 992 10) Go to Step 2. 994 Step 1: Examine the zeroeth link state PDU of P, the system just 995 placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID 996 as P, and LSP number zero). 998 1) If this LSP is present and the "Infinite Hippity Cost" bit is 999 clear, then for each Adj(*)-ABDP(*)-BADP(*) pair in the PATHS 1000 database for P:- 1002 If this is not a pseudonode LSP and if ABDP(*) is equal to 1003 zero then check the unencapsulation capability field of the 1004 LSP, if it supports A over B then set the ABDP(P) value for 1005 this adjacency to be the system ID of P. 1007 If this is not a pseudonode LSP and if BADP(*) is equal to 1008 zero then check the unencapsulation capability field of the 1009 LSP, if it supports B over A then set the BADP(P)value for 1010 this adjacency to be the system ID of P. 1012 2) If this LSP is present, and the "Infinite Hippity Cost" bit is 1013 clear, then for each LSP of P (i.e., all LSPs with the same first 1014 7 octets of LSPID and P, irrespective of the value of LSP number) 1015 compute: 1017 dist(P,N) = d(P) + metric.k(P,N) 1019 for each neighbour N (both End System and router) of the system 1020 P. If the "Infinite Hippity Cost" bit is set, only consider the 1021 End System neighbours of the system P. 1022 Note that the End Systems neighbours of the system P includes IP 1023 reachable address entries included in the LSPs from system P. 1024 Here, d(P) is the second element of the triple 1026 1028 and metric.k(P,N) is the cost of the link from P to N as reported 1029 in P's link state PDU. 1031 3) If dist(P,N) > MaxPathMetric, then do nothing. 1033 4) If is in PATHS, then do 1034 nothing. 1036 Note: d(N) must be less than dist(P,N), or else N would not 1037 have been put into PATHS. An additional sanity check may be 1038 done here to ensure that d(N) is in fact less than dist(P,N) 1040 Christian Expires January 2003 20 1041 IS-IS Automatic Encapsulation 1043 6) If a triple is in TENT, then: 1045 a) If x = dist(P,N), then {Adj(N), ABDP(N)-BADP(N)} <-- {Adj(N) - 1046 ABDP(N)-BADP(N)} U {Adj(P) -ABDP(P)-BADP(N)}. 1048 Note that even if the value of Adj(N) is equal to the value 1049 Adj(P) but the corresponding values of either ABDP(P) or 1050 BADP(P) and ABDP(N) or BADP(N) are different then this should 1051 be treated as a different adjacency and will represent a 1052 different path to the destination. 1054 b) If N is a router or an OSI end system, and there are now more 1055 adjacencies in {Adj(N)} than maximumPath Splits, then remove 1056 excess adjacencies, as described in clause 7.2.7 of [1]. For IP 1057 Reachability Entries, excess adjacencies may be removed as 1058 desired. This will not effect the correctness of routing, but 1059 may eliminate the determinism for IP routes (i.e., IP packets 1060 will still follow optimal routes within an area, but where 1061 multiple equally good routes exist, will not necessarily follow 1062 precisely the route that any one particular router would have 1063 anticipated). 1065 c) if x < dist(P,N), do nothing. 1067 d) if x > dist(P,N), remove from 1068 TENT, and add 1069 1071 7) if no triple is in TENT, then add 1072 to TENT. 1074 Step 2: If TENT is empty, stop. Else: 1076 1) Find the element , with minimal x 1077 as follows: 1079 a) If an element <*,tentlength,*> remains in TENT in the list for 1080 tentlength, choose that element. If there are more than one 1081 elements in the list for tentlength, choose one of the elements 1082 (if any) for a system which is a pseudonode in preference to 1083 one for a non-pseudonode. If there are no more elements in the 1084 list for tentlength, increment tentlength and repeat Step 2. 1086 b) Remove from TENT. 1088 c) Add to PATHS. 1090 d) If this is the Level 2 Decision Process running, and the system 1091 just added to PATHS listed itself as Partition Designated Level 1092 2 Intermediate system, then additionally add 1093 to PATHS, where AREA.P is the Network 1095 Christian Expires January 2003 21 1096 IS-IS Automatic Encapsulation 1098 Entity Title of the other end of the Virtual Link, obtained by 1099 taking the first AREA listed in P's LSP and appending P's ID. 1101 e) If the system just added to PATHS was an end system, go to step 1102 2. Else go to Step 1. 1104 NOTE - In the level 2 context, the "End Systems" are the set of 1105 Reachable Address Prefixes (for OSI), the set of Area Addresses with 1106 zero cost (again, for OSI), plus the set of IP reachability entries 1107 (including both internal and external). 1109 Christian Expires January 2003 22