Internet Engineering Task Force P. Christian, INTERNET-DRAFT Christian Tena LTD, Category: Informational September 2002 Expires: March 2003 IS-IS Automatic Encapsulation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. The IETF is advised of potential intellectual property rights in regard to some or all of the specification contained in this document. For more information consult the online list for notices and/or updates. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited. Christian Expires March 2003 1 Internet Draft September 2002 IS-IS Automatic Encapsulation Abstract RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS- IS can now also be used to route IPv6 [12]. RFC 1195 [1] places certain topological restrictions on networks that are routed using Integrated IS-IS, specifically that every Intermediate System in a level-1 area must be able to forward all network layer protocols that are present in that area, and that every level-2 Intermediate System must be able to forward all network layer protocols present in the routing domain. The mechanism described in this document enables an Intermediate System or a group of Intermediate Systems that do not support a particular network layer protocol to be used in a level-1 area or level-2 subdomain where that network layer protocol is present. Specifically the mechanism provides automatic encapsulation and unencapsulation so that a packet or PDU may pass through an Intermediate System that would not normally be able to forward that type of packet. 1.History The automatic encapsulation mechanism was originally presented to Study Group 15 of the ITU-T as part of a push by the ITU-T to migrate SONET / SDH DCN networks from CLNP to IP. The scheme was presented as an "autotunnelling scheme" that used the existing IS-IS routing protocol that was present in all standards compliant SONET or SDH multiplexers, so that IP traffic could be passed through existing CLNP capable multiplexers without needing to upgrade them. In May 2002 the ITU-T Draft Recommendation G.7712 version 1.1 and 1.2 were liaised to the IETF IS-IS Working Group. The liaison statement and these version of G.7712 may be viewed from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport /COMMUNICATIONS/isis/index.html The automatic encapsulation mechanism was then documented as an IETF document in draft-ietf-isis-proprietary-tlv-00.txt. This document included a modified PseudoNode election process that was intended to improve interoperability and ease topologic restrictions compared with G.7712. The modification turned out to be impossible to implement, as it would have required an automatically encapsulating IS to create two or more pseudonodes in certain circumstances (one for each supported network-layer protocol). Multiple pseudonodes would have required multiple IDs in LAN Hello PDUs, which is not possible. Christian Expires March 2003 2 Internet Draft September 2002 IS-IS Automatic Encapsulation draft-ietf-isis-proprietary-tlv-01.txt therefore reverted the pseudonode election process back to that used in G.7712. This version converges further towards G.7712 as it only documents GRE encapsulation. G.7712 requires SONET / SDH multiplexers to support GRE for encapsulation of CLNP, IPv4 or IPv6 PDUs. This modification is designed to improve interoperability between vendors. Shortest paths are calculated by ISs in the domain without considering whether a complete path for any particular network-layer protocol exists or not, nor whether encapsulation and unencapsulation is available or not. Thus if some automatically encapsulating ISs support only GRE encapsulation, whilst others support only some other encapsulation, then dynamic tunnels cannot be built between the two. The result is paths that cannot forward traffic which causes blackholes, or very complex topological restrictions to avoid them. Given that GRE is the only standardised encapsulation mechanism that supports CLNP (see RFC 2784[4] and RC 3147[5]) it makes sense to use it here. As a result implementations that conform to this draft are guaranteed to interwork with others (by virtue of a common encapsulation) and with ITU-T G.7712 implementations (by virture of using GRE). 2.Introduction RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS-IS can now also be used to route IPv6 [12]. RFC 1195 [1] also foresaw the possibility of an automatic encapsulation feature. Automatic encapsulation is stated as for "for further study" in section 3.8. The automatic encapsulation scheme detailed here may be considered a continuation of section 3.8 of RFC 1195 [1]. Integrated IS-IS ISs (Intermediate Systems) can calculate routes to CLNS, IPv4 and IPv6 destinations using a single SPF calculation. This is achieved by treating OSI End System, IPv4 and IPv6 addresses in a similar way, but it does rely on an assumption which forces topological restrictions onto the network. Integrated IS-IS views a level-1 area or level-2 subdomain as a collection of connected ISs, without considering which ISs can actually forward which network-layer protocols. It simply assumes that all ISs that it can see, can forward all packet types. For Integrated IS-IS to be able to pick different routes for different network-layer protocols would imply a separate SPF calculation for each network layer protocol. It would then arguably no longer be an integrated routing protocol. Christian Expires March 2003 3 Internet Draft September 2002 IS-IS Automatic Encapsulation Specifically page 26 of RFC 1195 [1] states:- "The Dijkstra computation does not take into consideration whether a router is IP-only, OSI-only, or dual. The topological restrictions specified in section 1.4 ensure that IP packets will only be sent via IP-capable routers, and OSI packets will only be sent via OSI-capable routers." It is important that all ISs in a network calculate routes in such a way that they all arrive at the same shortest path. If some ISs calculate a different shortest path to others then routing loops and blackholes can occur. Therefore in a multiprotocol environment having ISs that consider forwarding capabilities when calculating the shortest path, mixed with ISs that do not could result in routing loops and packet loss. Consequently, RFC 1195 states that if both IPv4 and CLNP are to be forwarded anywhere in a level-1 area or level-2 subdomain, then, all of the ISs in that level-1 area or level-2 subdomain must be capable of forwarding both IPv4 and CLNP. The same logic applies if it is required to have both IPv4 and IPv6 present in a level-1 area or level-2 subdomain. This topological rule can already be broken with extreme care. If it can be guaranteed that a certain part of an IS-IS network will never receive a certain type of packet, then that network layer protocol need not be supported. However, failure to observe these topological restrictions can result in blackholes forming, and packet loss. Consider the following (illegal) example:- +--------+ +-------+ +--------+ IPv6 host#1--+ IS A +--+ IS B +--+ IS C +--IPv6 host#2 | v4/v6 | | v4 IS | | v4/v6 | +--------+ +-------+ +--------+ IS A will find the shortest path to IPv6 host#2 as being through IS B. If host#1 then sends an IPv6 packet to the host#2, then the dual IS will forward it to the IS B, which will not be able to forward the packet. IS B will discard the packet instead, resulting in packet loss and a blackhole. This document describes a mechanism that can be used to overcome this topological restriction. The mechanism detects that a packet is about to be send to an IS that does not support that network-layer protocol, and automatically encapsulates the packet into a form that then can be forwarded. Essentially the mechanism can take an existing IS, or collection of ISs, that support forwarding of IPv4 for example, and, by automatic encapsulation of IPv6 inside IPv4, can enable IPv6 traffic to also cross these IPv4 ISs, making that part of the network behave as if it is dual. Christian Expires March 2003 4 Internet Draft September 2002 IS-IS Automatic Encapsulation 3.The automatic encapsulation mechanism. 3.1. Introduction. Consider the following example:- +--------+ +-------+ +--------+ IPv4 host--+ IS A | | IS B | | IS C +--IPv4 host | v4/v6 +--+ v4 IS +--+ v4/v6 | IPv6 host--+ | | | | +--IPv6 host +--------+ +-------+ +--------+ Forwarding of IPv4 traffic from one host to the other is not a problem in this network. However IPv6 traffic cannot be forwarded by IS B without being encapsulated inside an IPv4 packet. IS A and IS C actually have most of the information that they need in order to automatically perform this encapsulation. 1. IS A can detect that IS B cannot forward an IPv6 packet, because RFC 1195 [1] already requires IS B to include a "protocols supported" TLV in Hello packets. Absence of the TLV indicates that an IS that can forward only CLNP. 2. IS A receives LSPs (Link State PDUs) from IS C. This is because IS-IS LSPs are neither IPv4 nor IPv6 packets. IS-IS is a network-layer protocol in its own right, and is used in common by all ISs whether they forward CLNP, IPv4 or IPv6 packets. By adding an extra TLV to the LSPs that IS C transmits, containing the encapsulation/unencapsulation capability of C, this information will be flooded throughout the level-1 area or level-2 subdomain. IS A is now able to encapsulate IPv6 traffic inside IPv4 packets, and send them to IS C, on the understanding that IS C will unencapsulate the IPv6 traffic and forward it onwards. 3.2. Encapsulation Capability Field. Any IS that supports automatic encapsulation/unencapsulation MUST include an "Encapsulation Capability" TLV in LSPs that have LSP number 0. This TLV MUST be included in both level-1 LSPs and level- 2 LSPs. The structure of the TLV is as follows:- Code: 16 (decimal) Length: The length of the value Value: The value shall contain Sub-TLVs of the form:- Sub-TLV Type Sub-TLV Length: The length of the sub-TLV value Sub-TLV Value: Variable number of bytes Christian Expires March 2003 5 Internet Draft September 2002 IS-IS Automatic Encapsulation Sub-TLVs with sub-TLV type equal to 1 MUST contain three byte encapsulation modes with the following structure:- Sub-TLV type: 1 Sub-TLV length: Three times the number of encapsulation modes Sub-TLV value: Encapsulation-mode#1 Inner-Protocol#1 Outer-Protocol#1 Encapsulation-mode#2 Inner-Protocol#2 Outer-Protocol#2 . . Encapsulation-mode#n Inner-Protocol#n Outer-Protocol#n Encapsulation-mode SHALL be 47 (decimal) to describe a GRE encapsulation as defined in RFCs 1701[2], 1702[3], 2784[4] and 3147[5]. Inner-Protocol SHALL be the NLPID of a packet that the IS is capable of sending or receiving in an encapsulated form. Outer-Protocol SHALL be the NLPID of a packet that the IS is capable of using to transport the Inner-Protocol in encapsulated form. NLPIDs SHALL be those as specified in ISO/TR 9577[8]. 47 is chosen simply as it is the IP protocol number for GRE encapsulation. Note that ITU-T G.7712 [10] mandates that GRE shall be used for all combinations of CLNS, IPv4 and IPv6 over CLNS, IPv4 or IPv6. Therefore if interoperability is required with SONET / SDH DCC channels then GRE will have to be supported. RFC 3147 [5] also describes IP encapsulation over CLNS using GRE. Future capabilities, such as non-NLPID definitions, may be provided using the same TLV number by using an alternative sub-TLV number. Christian Expires March 2003 6 Internet Draft September 2002 IS-IS Automatic Encapsulation By way of an example, a dual IPv4/IPv6 IS that supports automatic encapsulation of IPv6 over IPv4, and automatic encapsulation of IPv4 over IPv6, using GRE would therefore transmit the TLV with the following contents:- Dec (Hex) 16 (0x10): The TLV number 8 (0x08): The length of the value 1 (0x01): Sub-TLV type 1 6 (0x06): Length of the value of the sub-TLV 47 (0x2F): Indicating that the next two bytes are a GRE mode 204 (0xCC): Inner-protocol of IPv4 142 (0x8E): Outer-protocol of IPv6 47 (0x2F): Indicating that the next two bytes are a GRE mode 142 (0x8E): Inner protocol of IPv6 204 (0xCC): Outer protocol of IPv4 An IS that includes an encapsulation mode in its "encapsulation capability" TLV MUST be capable of both transmitting and receiving that encapsulation mode, as specified in sections 3.3 and 3.4. 3.3. Transmission of automatically encapsulated packets Shortest paths SHALL be calculated in the normal way, as per RFC 1195 [1]. Before forwarding a packet to a next hop, an IS MUST check that the next hop can forward that type of packet. The IS MUST check this by referring to the "protocol supported" TLV in IS-IS Hello PDUs. Absence of a "Protocols Supported" TLV in Hello PDUs indicates that the next hop can forward only CLNP packets. If an IS finds that the next hop does support the type of packet that it is attempting to forward, then it MUST simply forward the packet to that adjacency as normal, without encapsulating it. If an IS finds that the next hop does not support the type of packet that it is attempting to forward, then it MUST search along the shortest path from itself to the destination, and MUST inspect the "encapsulation capability" TLV of LSP 0 of each IS until it finds an IS that it is able to send the packet to in an encapsulated form. Christian Expires March 2003 7 Internet Draft September 2002 IS-IS Automatic Encapsulation The IS MUST search within each "encapsulation capability" TLV until it finds an encapsulation mode that meets the following three conditions:- 1.The encapsulation-mode MUST be one that this IS supports. 2.The inner-protocol MUST be equal to the NLPID of the packet that this IS is attempting to forward. 3.The outer-protocol MUST be equal to one of the NLPIDs that the next hop lists in the "protocols supported" TLV of IS-IS Hello PDUs, or equal to the NLPID for CLNS/CLNP if no "protocols supported" TLV is present in IS-IS Hello PDUs from the next hop. When inspecting an "encapsulation capability" TLV, then, an IS MUST ignore any encapsulation modes that it does not understand, but instead jump forward to inspect the next encapsulation mode, until it finds a suitable mode or until it reaches the end of the TLV. When inspecting an "encapsulation capability" TLV, then, an IS MUST ignore any sub-TLVs that it does not understand, but instead jump forward to inspect the next sub-TLV, until it finds a suitable mode or until it reaches the end of the TLV. The IS MUST encapsulate the packet inside another and send it to the first IS along the shortest path to the destination that meets the criteria, using the encapsulation mode that resulted in it meeting the above criteria. See 2.3.1. for an explanation. It is suggested that this search is pre-calculated and performed for every destination that cannot be forwarded natively every time the SPF (Dijkstra) algorithm is run, and that the results are included in each forwarding table, with a marker indicating that for that particular destination that the packet should be encapsulated using a certain encapsulation mode (if more than one is supported) and with a certain destination address, which will be a destination address expressed in the format used by the outer-protocol that is going to be used. For this a modified SPF algorithm is provided in Annex A. The destination address of the resultant encapsulation packet MUST be equal to the identity of the IS that sent the TLV that was the first along the shortest path that met the above criteria. The source address of the resultant encapsulation packet MUST be equal to the identity of the IS that is performing the encapsulation. If the outer protocol is IPv4 then the "Don't Fragment" bit MUST NOT be set. If the outer protocol is CLNP then the "Segmentation Permitted" flag MUST be set. This will protect against packet loss due to the new packet being longer than the MTU size of the link over which it is to be transmitted, and will prevent unwanted interactions with path MTU discovery [11]. Christian Expires March 2003 8 Internet Draft September 2002 IS-IS Automatic Encapsulation 3.3.1. Reasoning for sending to first capable IS Section 3.3 indicates that a packet that cannot be forwarded natively should be encapsulated and sent to the first IS along the shortest path that advertises itself as being capable of unencapsulating it. In fact, the packet could be encapsulated and sent to any IS along the shortest path that advertises itself as being capable of unencapsulating it, and the packet would arrive at its destination. The most reasonable choices would appear to be either the first, or the last IS unencapsulation capable IS, each choice has advantages and disadvantages. Choosing the first may result in a packet being encapsulated and unencapsulated several times on its way to its destination, as it crosses multiple "subnetworks" that do not support forwarding of that type of packet. When the packet is being forwarded by a part of the network that can forward it natively, it is in its original form. Choosing the last may result in encapsulation within encapsulation within encapsulation, as for example an IPv6 packet will become an IPv4 packet and remain so till the last IS that can unencapsulate. This IPv4 packet may in turn need to traverse an IPv6-only "subnetwork" and be encapsulated again. If the last IS capable of unencapsulation advertises itself as being capable of IPv6/IPv4 and IPv4/IPv6, then it will loaded with unencapsulating all of the layers of encapsulation in one go. Although the argument is probably a religious one, unencapsulating a packet as soon as possible, and avoiding encapsulation within encapsulation (and the long packets that may result) would appear to be the lesser of the two evils. The load of fragmentation and reassembly must also be considered if multiple layers of encapsulation results in an MTU size being blown. Also it is probably better for a packet to exist in the network in its native form whenever possible, making the network easier to debug, and reducing the impact of encapsulation to the smallest part of the network possible. However, any IS MUST be able to unencapsulate any packet that arrives at it with its destination address, and with an encapsulation mode that it advertised in its "encapsulation capability" TLV. This opens the possibility for more intelligent algorithms to be developed that choose an IS capable of unencapsulating, other than the first. Christian Expires March 2003 9 Internet Draft September 2002 IS-IS Automatic Encapsulation 3.4. Receipt of automatically encapsulated packets An IS that supports automatic encapsulation / unencapsulation MUST inspect any received packet that has a destination address equal to itself to see if it is an encapsulation of a type that it transmitted in its "encapsulation capability" TLV. If the IS finds that such a received packet is an encapsulation packet then it SHOULD discard the inner packet if it is of a type that it did not list as an "inner-protocol" in an encapsulation mode in its "encapsulation capability" TLV. Upon discarding such a packet it is suggested that the IS reports or logs an error report. An IS that also supports manually configured tunnels will need to check that a packet has not arrived over a manual tunnel in the normal way before discarding it. Otherwise the received packet MUST be unencapsulated and re- received. Note that encapsulation within encapsulation is a possibility, particularly for ISs that support three or more network layer protocols. 3.5. Interaction with Path MTU Discovery (PMTU), RFC 1191 [11]. Although packets become encapsulated, no tunnel "interface" or circuit as such really exists. Therefore there will be no MTU limit for the inner-protocol. It is suggested that packets of any size are accepted, then encapsulated, and that the encapsulated outer- protocol packet is fragmented/segmented if necessary in order to be forwarded over the real interface. For this reason in the new outer-protocol packet the Don't Fragment MUST NOT be set (for IPv4), or Segmentation Permitted flag MUST be set (for CLNP). One consequence of this is that a link, if packets traverse it in an encapsulated form, becomes invisible to Path MTU Discovery. However this is the safest option as it guarantees that packets will never be discarded due to MTU issues. Because the inner-protocol is different to the outer-protocol, if the outer-protocol where to be discarded for any reason then the reason is not likely to be known to the originator of the inner-protocol packet. Path MTU discovery does rely on knowing the reason for discard of packets, and so the safest option is to make the outer-protocol and encapsulation process invisible to it. Christian Expires March 2003 10 Internet Draft September 2002 IS-IS Automatic Encapsulation An additional option is to reject packets for encapsulation that are bigger than a certain size, and to report back to the originator a suitable error message. If this approach is chosen then the packet MUST be rejected before encapsulation, and a suitable error message MUST be returned to the originator using the correct mechanism for that network layer protocol. Such a process would be prior to and independent of automatic encapsulation, and does not alter the requirement that the outer-protocol packets are never discarded, but fragmented/segmented instead. 4.Allowable and non-allowable topologies This mechanism effectively enables an IS or group of ISs to act as if they support one or more network layer protocols that they actually do not. Automatic encapsulation is the process that enables this to be possible, but care must be taken to ensure that incompatible packets are not leaked into such a "subnetwork" without going through an automatic encapsulation capable IS. Thus, at the all of the boundaries to the "subnetwork", there MUST be installed an IS that supports automatic encapsulation. At points where the inner "subnetwork" meet the outer general network without an automatic encapsulation IS between the two, any adjacency MUST be disabled. In order to partially automate this the ITU-T mandated in G.7712[10] that any Integrated IS-IS capable SDH NE must not consider itself a neighbour to any other IS unless the other IS supports at least one network layer protocol in common with it. This effectively makes it impossible to accidentally have an adjacency between an OSI-only and an IP-only SDH NE, or between an IPv4-only and an IPv6-only SDH NE. This cannot be retrospectively applied to RFC 1195[1] compliant ISs, however it is recommended that all Integrated IS-IS ISs include this safeguard whenever possible. In the absence of this behaviour it is the responsibility of the network manager to manually insure that no such adjacencies are formed. Certain Integrated IS-IS implementations also check for correct subnetting of a neighbour before accepting an adjacency; usefully this should also prevent an IPv4-only IS from forming an adjacency with an OSI-only or an IPv6-only IS. Christian Expires March 2003 11 Internet Draft September 2002 IS-IS Automatic Encapsulation In general the existing RFC 1195[1] topological restrictions still apply inside a "subnetwork" that is bounded by automatically encapsulating ISs, and outside of the automatically encapsulating ISs too. For example:- 1. Within a "subnetwork" that can forward only IPv4, only IPv4 can be forwarded. A dual IPv4/IPv6 IS MAY be installed inside this "subnetwork", but, it MUST NOT forward any IPv6 packets. No IPv6 hosts (including hosts internal to an IPv4/IPv6 IS) may be present in the "subnetwork". 2. Outside of the "subnetwork", i.e. on the other side of an automatic encapsulation capable IS, if both IPv4 and IPv6 packets are present in a native form, then all ISs must be capable of forwarding both IPv4 and IPv6. IPv6-only .......... IPv4 host-+------+ +------+ .+------+. +------+ +------+-IPv4 host | IS G |--| IS H |--| IS I |--| IS J |--| IS K | IPv6 host-+------+ +---+--+ .+--+---+. +--+---+ +------+-IPv6 host | ....X..... | | X | .......|........X.........|....... . +---+--+ +--+---+ +--+---+ . . | IS A |--| IS B |--| IS C | . . +--+---+ +------+ +---+--+ . . | | .IPv4-only . +--+---+ +------+ +---+--+ . . | IS D |--| IS E |--| IS F | . . +---+--+ +------+ +--+---+ . .......|..................|....... | | +------+ +---+--+ +--+---+ +------+ IPv6 host-+ IS L |--| IS M | | IS N |--| IS O +-IPv6 host +------+ +------+ +------+ +------+ ISs A, B, C, D, E and F are an IPv4-only "subnetwork"; therefore ISs H, J, M and N must be capable of automatically encapsulating IPv6 over IPv4. IS I is an IPv6-only "subnetwork", therefore ISs H and J must be capable of automatically encapsulating IPv4 over IPv6. ISs I and B support no network layer protocol in common and must therefore not form an adjacency. ISs G and K must forward IPv4 and IPv6 traffic and must therefore both be dual. ISs L and O need to forward only IPv6 and therefore may be either IPv6 only or dual. Christian Expires March 2003 12 Internet Draft September 2002 IS-IS Automatic Encapsulation 5.LAN interfaces As stated in section 4, ISs must not have adjacencies if they are able to forward packets that the neighbour does not support, unless they can automatically encapsulate. Consequently an IPv4-only and an IPv6-only IS may exist in the same area and on the same LAN, but will have no adjacency with each other. If there is a dual IS on the LAN that does support automatic encapsulation, then both the IPv4 and the IPv6 IS will have an adjacency with it. 5.1. PseudoNode election process ISs can choose a Designated IS (DIS) only from valid adjacencies, therefore an IPv4-only IS cannot elect an IPv6-only IS as DIS, and vice versa. In this case there are effectively two separate "sub-LANs" on the physical LAN. The IPv4-only ISs form one "sub-LAN" and elect a DIS, whilst the IPv6-only ISs form a second "sub-LAN" and a second DIS. Clearly a dual automatically encapsulating IS needs to be capable of connecting to both "sub-LANs", and so MUST participate in both pseudonode election processes. In this case a dual IS that does not support automatic encapsulation MUST NOT have adjacencies both with IPv4-only and with IPv6-only ISs, as this would form a leak between the two "subnetworks" and may cause packet loss. Therefore such a dual IS simply cannot appear on such a LAN, and a modified pseudonode election process does not apply to it. The following scenarios must be considered:- 1.The dual automatic encapsulating IS might win neither election process, in which case it is not DIS. 2.The dual automatic encapsulating IS might be elected DIS by the IPv4 ISs on the LAN, but not the IPv6 ISs; in this case it MUST create a pseudonode, and the pseudonode MUST declare adjacencies with all IPv4-capable ISs on the LAN (the IPv4-only ISs and the dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies with any IPv6-only ISs. 3.The dual automatic encapsulating IS might be elected DIS by the IPv6 ISs on the LAN, but not the IPv4 ISs; in this case it MUST create a pseudonode, and the pseudonode MUST declare adjacencies with all IPv6-capable ISs on the LAN (the IPv6-only ISs and the dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies with any IPv4-only ISs. Christian Expires March 2003 13 Internet Draft September 2002 IS-IS Automatic Encapsulation 4.The dual automatic encapsulating IS might be elected DIS both by the IPv4 ISs and by the IPv6 ISs; in this case it MUST create one pseudonode which MUST declare adjacencies with all IPv4-capable ISs on the LAN, with all-IPv6 capable ISs on the LAN, and with the dual automatic encapsulating IS. The first three scenarios will always forward traffic correctly in on a LAN and will result in packets being encapsulated before being forwarded across incompatible ISs. The fourth scenario relies on other ISs on the LAN conforming to ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section C.1.4 step 0 clause 8. ISs that do not will drop packets rather than send traffic to a dual IS for automatic encapsulation, if the dual IS is the DIS, and if non-compatible ISs on the same LAN are on the shortest path. This is because the psuedonode declares itself to be between two ISs that are actually incompatible and therefore should not share an adjacency. The SPF algorithm in one IS on the LAN may find other ISs on the LAN to be the shortest path to certain destinations, through the pseudonode, but then cannot actually forward traffic to them as there is no adjacency. This can result in packets being dropped rather than being encapsulated in order to traverse incompatible ISs on the LAN. ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section C.1.4 step 0 clause 8 causes an IS to forward traffic to the DIS in this scenario, which in this case is an automatic encapsulation IS. Thus if all ISs on the LAN that have a lower priority than the automatic encapsulation IS are conformant with this clause then packets are forwarded and encapsulated properly. Network administrators need to ensure that ISs that do not conform with ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section C.1.4 step 0 clause 8 have a higher priority than any automatic encapsulation ISs on the same LAN if it is a mixed protocol LAN. 5.2. LSP update process ISO/IEC 10589 [2] states in section 7.3.15.1 that an LSP received that does not come from a valid adjacency must be discarded. A strict single protocol implementation will therefore reject LSPs that are transmitted onto a LAN interface by an IS that it has rejected an adjacency with due to no network-layer protocol in common (or by manual configuration or no subnet in common). Thus if an IPv4-only IS transmits an LSP onto a LAN then an IPv6- only IS can receive such an LSP only from a dual automatic encapsulating IS. Normally a dual IS will only forward such an LSP during periodic LSP database synchronisation. Christian Expires March 2003 14 Internet Draft September 2002 IS-IS Automatic Encapsulation Dual automatic encapsulating ISs are therefore required to have modified LSP flooding behaviour so that OSI-only, IPv4-only or IPv6- only ISs do not need to wait for the next LSP database synchronisation event. Dual automatic encapsulating ISs MUST check incoming LSPs that arrive on LAN interfaces to see if they come from a neighbour that supports all of the network layer protocols that the dual automatic encapsulating IS does. This MUST be achieved by inspection of the "protocols supported" TLV in Hello packets received from that neighbour. If the LSP is received from a neighbour that does support all of the network layer protocols that the dual or multilingual IS supports, then the dual automatic encapsulating IS SHALL behave as per ISO/IEC 10589 and unset the SRM flag for that LSP on that LAN interface if it already has the LSP, or shall flood it out of all other interfaces if it does not already have the LSP. If the LSP is received from a neighbour that does not support all of the network layer protocols that the dual automatic encapsulating IS supports, and, if it does not already have the LSP then the dual automatic encapsulating IS SHALL set the SRM flag for that LSP on the LAN interface over which the LSP was received, in addition to all other interfaces, resulting in the dual automatic encapsulating IS re-transmitting the LSP onto the LAN. In this way if an LSP is transmitted onto the LAN by an IPv4-only IS, then one of the dual automatic encapsulating ISs will re- transmit the LSP, so that it may be received on a valid adjacency by IPv6-only ISs on the LAN and vice versa. 5.3. Redirects 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. 6.Level-1, level-2 ISs Although this mechanism allows "subnetworks" to exist in a level-1 area or level-2 subdomain that do not support all of the network layer protocols present in the area or subdomain, packets must still be able to get in and out of an area and onto the level-2 subdomain. Christian Expires March 2003 15 Internet Draft September 2002 IS-IS Automatic Encapsulation It is therefore recommended that all ISs that support both level-1 and level-2 can forward all network layer protocols that exist in the area. However this may not be possible, if for example an existing network is using this mechanism to upgrade parts of an area to support a new network layer protocol, but a level-1, level-2 IS cannot be upgraded. In this case another IS that does support the new network layer protocol must become the gateway for that protocol. This can be achieved by configuration either of a default route, or a collection of static routes that cover all possible "out of area" destinations. Note that RFC 1195 [1] forbids default routes in level-1 LSPs (however this does not reduce its usefulness as a solution). This gateway IS must then tunnel all "out of area" packets of the new network layer protocol across the incompatible level-1,level-2 IS to another IS somewhere in the level-2 subdomain or other routing protocol. Multiple gateways may be configured for redundancy, in this case a gateway SHOULD gate advertisement of a default route on the validity of the tunnel that it is using to send "out of area" packets across. i.e. the IS SHOULD somehow detect that the other end of the tunnel is alive and contactable, and if it is not, it SHOULD stop advertising a default route into the area. This can be achieved by running some other routing protocol such as RIP or OSPF across the tunnel, or another instance of IS-IS, for example. 7.Security Considerations 7.1 Injection of IP and CLNP packets into the network An IS that employs automatic encapsulation is required to unencapsulate any incoming packet that is of a an advertised encapsulation mode, and forward the contents. Consequently packets may potentially be injected at such an IS in an encapsulated form that maybe would normally be filtered at the edge of a routing domain, but which are now an encapsulation packet. Such a risk is not unique to automatic encapsulation, but is present in manually configured tunnels too, such as RFC 2784 [4] GRE tunnels. Encapsulated packets should never arrive from any source other than another IS in the same level-1 area or level-2 subdomain, and this MAY then be used as the basis of a security filter. Christian Expires March 2003 16 Internet Draft September 2002 IS-IS Automatic Encapsulation In any case such a mechanism will allow an attacker only to inject packets into a network; it does not supply a return path. 7.2 Injection of other packets into the network Section 3.4 states that incoming packets SHOULD be discarded if they are not of an inner-protocol type that the IS advertised as being able to unencapsulate. This clause is an important security feature as it prevents false routing packets and consequent false routes from being injected into the network. 8.References [1] RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. [2] RFC 1701 Generic Routing Encapsulation (GRE). [3] RFC 1702 Generic Routing Encapsulation over IPv4 networks. [4] RFC 2784 Generic Routing Encapsulation (GRE). [5] RFC 3147 Generic Routing Encapsulation over CLNS Networks. [6] RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers. [7] RFC 2003 IP Encapsulation within IP. [8] ISO 9577 and ITU-T X.263 Information Technology - Protocol Identification In The Network Layer. [9] http://www.iana.org/assignments/ethernet-numbers. [10] ITU-T Recommendation G.7712 v1.2 Architecture and Specification of Data Communication Network. [11] RFC 1191 Path MTU discovery. [12] draft-ietf-isis-ipv6-02.txt Routing IPv6 with IS-IS 9.Acknowledgements Jonathan Sadler, Mike Shand and Les Ginsberg have made various suggestions that have improved the automatic encapsulation scheme way beyond what was originally presented. Christian Expires March 2003 17 Internet Draft September 2002 IS-IS Automatic Encapsulation 10.Author's Address Philip Christian, Christian Tena LTD, Essex, UK Email: philip.christian@christiantena.co.uk 11.Copyright Notice Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Christian Expires March 2003 18 Internet Draft September 2002 IS-IS Automatic Encapsulation Annex A Updates to Dijkstra's Algorithm The following Annex contains the full Dijkstra's algorithm including extensions to support automatic tunnelling. It is based on the algorithm as specified in RFC 1195 [1]. The algorithm describes the behaviour of a dual protocol IS capable of supporting network-layer protocols A and B. A and B represent any pair of network-layer protocols such as CLNP, IPv4 or IPv6. A1. Changes to the Database The PATHS and TENTS database should be updated to contain an extension to the {Adj(N)}, element of the triple. The adjacency N element will contain two corresponding Dual Protocol Support (ABDP(N)-BADP(N)) entries which will represent the System ID of the first Dual router on the path from S to N capable of de- encapsulating A over B tunnelled packets (ABDP(N)) and the System ID of the first dual router on that path from S to N capable of de- encapsulating B over A tunnelled packets (BADP(N). If no *DP(N) router exists on the PATH then this value will be set to zero. If multiple Adj(N) entries exist in either the TENTS or the PATHS database then each adjacency will have corresponding *DP(N) entries. Thus each triple will take the format If the value of ABDP(N) is set to 0 then this means that no dual router exists on the path to the destination capable of de- encapsulating and encapsulating A over B packets. If the value of BADP(N) is set to 0 then this means that no dual router exists on the path to the destination capable of de- encapsulating and encapsulating B over A packets. A2. Changes to the Algorithm The SPF algorithm specified in section C.2.3 of [1] is amended to appear as follows: Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to [internalmetric=0, externalmetric=0]. (tentlength is the pathlength of elements in TENT that we are examining.) 1) Add to PATHS, where W is a special value indicating traffic to SELF is passed up to internal processes (rather than forwarded). 2) Now pre-load TENT with the local adjacency database (Each entry made to TENT must be marked as being either an End System or a router to enable the check at the end of Step 2 to be made correctly - Note that each local IP reachability entry is included as an adjacency, and is marked as being an End System). Christian Expires March 2003 19 Internet Draft September 2002 IS-IS Automatic Encapsulation For each adjacency Adj(N) (including level 1 OSI Manual Adjacencies, or level 2 OSI enabled reachable addresses, and IP reachability entries) on enabled circuits, to system N of SELF in state "Up" compute: d(N) = cost of the parent circuit of the adjacency (N), obtained from metric.k , where k = one of {default metric, delay metric, monetary metric, error metric} Adj(N)-ABDP(N)-BADP(N) = the adjacency number of the adjacency to N ,the SID of the next-hop router along the path to the neighbour capable of de-encapsulating A over B packets and the SID of the next-hop router along the path to the neighbour capable of de-encapsulating B over A packets . In this case i.e. during initialisation both DP values will be set to 0 3) If a triple is in TENT, then: If x = d(N), then {Adj(M)-ABDP(N)-BADP(N)} <--- {Adj(M)- ABDP(M)-BADP(M)} U {Adj(N)-ABDP(N)-BADP(N)}. 4) If N is a router or an OSI End System entry, and there are now more adjacencies in {Adj(M)} than maximumPathSplits, then remove excess adjacencies as described in Clause 7.2.7 of [1]. If N is an IP Reachability Entry, then excess adjacencies may be removed as desired. This will not effect the correctness of routing, but may eliminate the determinism for IP routes (i.e., IP packets still follow optimal routes within an area, but where multiple equally good routes exist, will not necessarily follow precisely the route that any one particular router would have anticipated). 5) If x < d(N), do nothing. 6) If x > d(N), remove from TENT and add the triple . 7) If no triple is in TENT, then add to TENT. 8) Now add systems to which the local router does not have adjacencies, but which are mentioned in neighbouring pseudonode LSPs. The adjacency for such systems is set to that of the designated router. Note that this does not include IP reachability entries from neighbouring pseudonode LSPs. In particular, the pseudonode LSPs do not include IP reachability entries. 9) For all broadcast circuits in state "On", find the pseudonode LSP for that circuit (specifically, the LSP with number zero and with the first 7 octets of LSPID equal to LnCircuitID for that circuit, where n is 1 (for level 1 routing) or 2 (level 2 Christian Expires March 2003 20 Internet Draft September 2002 IS-IS Automatic Encapsulation routing)). If it is present, for all the neighbours N reported in all the LSPs of this pseudonode which do not exist in TENT add an entry to TENT, where: d(N) = metric.k of the circuit. Adj(N) = the adjacency number of the adjacency to the DR. 10) Go to Step 2. Step 1: Examine the zeroeth link state PDU of P, the system just placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID as P, and LSP number zero). 1) If this LSP is present and the "Infinite Hippity Cost" bit is clear, then for each Adj(*)-ABDP(*)-BADP(*) pair in the PATHS database for P:- If this is not a pseudonode LSP and if ABDP(*) is equal to zero then check the unencapsulation capability field of the LSP, if it supports A over B then set the ABDP(P) value for this adjacency to be the system ID of P. If this is not a pseudonode LSP and if BADP(*) is equal to zero then check the unencapsulation capability field of the LSP, if it supports B over A then set the BADP(P)value for this adjacency to be the system ID of P. 2) If this LSP is present, and the "Infinite Hippity Cost" bit is clear, then for each LSP of P (i.e., all LSPs with the same first 7 octets of LSPID and P, irrespective of the value of LSP number) compute: dist(P,N) = d(P) + metric.k(P,N) for each neighbour N (both End System and router) of the system P. If the "Infinite Hippity Cost" bit is set, only consider the End System neighbours of the system P. Note that the End Systems neighbours of the system P includes IP reachable address entries included in the LSPs from system P. Here, d(P) is the second element of the triple and metric.k(P,N) is the cost of the link from P to N as reported in P's link state PDU. 3) If dist(P,N) > MaxPathMetric, then do nothing. 4) If is in PATHS, then do nothing. Note: d(N) must be less than dist(P,N), or else N would not Christian Expires March 2003 21 Internet Draft September 2002 IS-IS Automatic Encapsulation have been put into PATHS. An additional sanity check may be done here to ensure that d(N) is in fact less than dist(P,N) 6) If a triple is in TENT, then: a) If x = dist(P,N), then {Adj(N), ABDP(N)-BADP(N)} <-- {Adj(N) - ABDP(N)-BADP(N)} U {Adj(P) -ABDP(P)-BADP(N)}. Note that even if the value of Adj(N) is equal to the value Adj(P) but the corresponding values of either ABDP(P) or BADP(P) and ABDP(N) or BADP(N) are different then this should be treated as a different adjacency and will represent a different path to the destination. b) If N is a router or an OSI end system, and there are now more adjacencies in {Adj(N)} than maximumPath Splits, then remove excess adjacencies, as described in clause 7.2.7 of [1]. For IP Reachability Entries, excess adjacencies may be removed as desired. This will not effect the correctness of routing, but may eliminate the determinism for IP routes (i.e., IP packets will still follow optimal routes within an area, but where multiple equally good routes exist, will not necessarily follow precisely the route that any one particular router would have anticipated). c) if x < dist(P,N), do nothing. d) if x > dist(P,N), remove from TENT, and add 7) if no triple is in TENT, then add to TENT. Step 2: If TENT is empty, stop. Else: 1) Find the element , with minimal x as follows: a) If an element <*,tentlength,*> remains in TENT in the list for tentlength, choose that element. If there are more than one elements in the list for tentlength, choose one of the elements (if any) for a system which is a pseudonode in preference to one for a non-pseudonode. If there are no more elements in the list for tentlength, increment tentlength and repeat Step 2. b) Remove from TENT. c) Add to PATHS. Christian Expires March 2003 22 Internet Draft September 2002 IS-IS Automatic Encapsulation d) If this is the Level 2 Decision Process running, and the system just added to PATHS listed itself as Partition Designated Level 2 Intermediate system, then additionally add to PATHS, where AREA.P is the Network Entity Title of the other end of the Virtual Link, obtained by taking the first AREA listed in P's LSP and appending P's ID. e) If the system just added to PATHS was an end system, go to step 2. Else go to Step 1. NOTE - In the level 2 context, the "End Systems" are the set of Reachable Address Prefixes (for OSI), the set of Area Addresses with zero cost (again, for OSI), plus the set of IP reachability entries (including both internal and external). Christian Expires March 2003 23