idnits 2.17.00 (12 Aug 2021) /tmp/idnits29946/draft-ietf-isis-wg-over-ip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Pos81], Cal90b], [ISO90,Cal90a,, [Wai90]), 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 61: '...s recommended; IP fragmentation SHOULD...' RFC 2119 keyword, line 65: '... - IIHs MUST have the size of [Int...' RFC 2119 keyword, line 66: '... set. IIH's TTL MUST be set to 1 to p...' RFC 2119 keyword, line 69: '...lated interfaces MUST NOT be larger th...' RFC 2119 keyword, line 73: '...- LSP fragments MAY BE built with a s...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 Jan 1998) is 8887 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Hei93' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'MD90' is defined on line 239, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Alm92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hei93' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kat92' -- Possible downref: Non-RFC (?) normative reference: ref. 'MD90' ** Obsolete normative reference: RFC 2178 (ref. 'Moy97') (Obsoleted by RFC 2328) -- Possible downref: Non-RFC (?) normative reference: ref. 'Pos81' -- Possible downref: Non-RFC (?) normative reference: ref. 'RP94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Wai90' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Bansal, T. Przygienda, A. Patel 2 INTERNET DRAFT Fore, Bell Labs/Lucent 3 20 Jan 1998 5 IS-IS over IPv4 6 8 Status of This Memo 9 This document is an Internet Draft, and can be found as 10 draft-ietf-isis-wg-over-ip-02.txt in any standard internet drafts 11 repository. Internet Drafts are working documents of the Internet 12 Engineering Task Force (IETF), its Areas, and its Working Groups. 13 Note that other groups may also distribute working documents as 14 Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material, or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 Abstract 26 This draft describes an optional implementation technique within 27 IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing 28 within their clouds. IS-IS is an interior gateway routing protocol 29 developed originally by OSI and used with IP extensions as IGP. This 30 draft describes how to encapsulate IS-IS packets in IPv4 [Pos81] 31 format. Such an encapsulation has many advantages, one of those 32 being the possibility to run integrated IS-IS on anything that 33 understands IPv4, including avian carriers [Wai90]. 35 1. Introduction 36 Encapsulation of IS-IS as defined in ISO 10589 [ISO90, Cal90a, 37 Cal90b] uses directly over Link Layer protocols as opposed to IP 38 routing protocols [Moy97] that are encapsulated over IP directly. 40 By defining an encapsulation of IS-IS in IP, we save on special OSI 41 encapsulation on several media types. Such an encapsulation would 42 solve fragmentation problems of large LSPs and remove the necessity 43 for OSI PPP extensions [Kat92] when IS-IS is run over negotiated 44 PPP links. Additionally, on certain media, such as P2P ATM links, 45 no LLC/SNAP encapsulation is necessary to provide multi-protocol 46 routing, allowing for gains in efficiency. 48 2. Encapsulation of IS-IS and ISO 9542 packets over IP 49 IS-IS is encapsulated directly over the Internet Protocol's network 50 layer. IS-IS packets are therefore encapsulated by IP and local 51 data-link headers. Within this encapsulation, IS-IS packets are 52 propagated as usual, however without the appropriate link-layer 53 fields but starting at NLPI. 55 IS-IS does not normally provide a way to transmit packets larger 56 than MTU size. This proposal allows to use IP fragmentation when 57 transmitting such packets. If necessary, the length of IS-IS packets 58 over IP can be up to 65,535 bytes (including the IP header). The 59 IS-IS packet types that are likely to be large (LSPs, CSNPs, PSNPs) 60 can usually be split into several separate protocol packets, without 61 loss of functionality. This is recommended; IP fragmentation SHOULD 62 be avoided whenever possible since it can lead to different problems, 63 such as loss of fragments causing the retransmission of complete IP 64 packets. Following rules apply: 65 - IIHs MUST have the size of [InterfaceMTU - IP headersize] (1) 66 and have the DF bit set. IIH's TTL MUST be set to 1 to prevent 67 them from traveling multiple hops. 69 - SNPs on IP encapsulated interfaces MUST NOT be larger than 70 the minimum of [InterfaceMTU - IP headersize] and respective 71 originatingLSPBufferSize. 73 - LSP fragments MAY BE built with a size up to the value of 74 corresponding originatingLSPBufferSize. 76 - LSP fragments MUST NOT be larger than the respective 77 originatingLSPBufferSize. 79 ___________________________________________ 80 1. not of maximum of Buffer and DataLinkSize used normally 81 - LSPs MUST be sent allowing IP fragmentation (DF bit not set). 83 - LSP fragments SHOULD NOT exceed the size of the minimum of 84 dataLinkBlockSize and respective originatingLSPBufferSize. 86 This set of rules allows to configure a network with respective 87 originatingLSPBufferSize larger than some interfaces' MTUs. 88 In a mixed environment, care must be taken that respective 89 originatingLSPBufferSize does net exceed the MTU size of interfaces 90 without IP encapsulation. 91 The other important features of IS-IS in IP's IP encapsulation are: 93 - Use of IP multicast. Some IS-IS in IP messages are multicast, 94 when sent over broadcast networks. Three distinct IP multicast 95 addresses are used. Packets sent to these multicast addresses 96 should never be forwarded; they are meant to travel a single hop 97 only. To ensure that these packets will not travel multiple 98 hops, their IP TTL must be set to 1. 100 IPAllL1ISs 102 OSI multicast value of this address was O1-80-C2-00-00-14. 103 This multicast address has been assigned the IP address 104 value 224.0.0.? for IP encapsulated IS-IS. All routers 105 running L1 IS-IS in IP should be prepared to receive 106 packets sent to this address. Hello packets are always 107 sent to this destination. Also, certain IS-IS in IP 108 protocol packets are sent to this address during the 109 flooding procedure. 111 IPAllL2ISs 113 OSI multicast value of this address was O1-80-C2-00-00-15. 114 This multicast address has been assigned the IP address 115 value 224.0.0.? for IP encapsulated IS-IS. All routers 116 running L2 IS-IS in IP should be prepared to receive 117 packets sent to this address. Hello packets are always 118 sent to this destination. Also, certain IS-IS in IP 119 protocol packets are sent to this address during the 120 flooding procedure. 122 IPAllIntermediateSystems 124 OSI multicast value of this address was 09-00-2B-0O-00-05. 125 This multicast address has been assigned the IP address 126 value 224.0.0.? for IP encapsulated IS-IS. All routers 127 running IS-IS in IP should be prepared to receive packets 128 sent to this address. ISO 9542 is using this address. 130 - IS-IS in IP is IP protocol number ??. This number has been 131 requested with the Network Information Center. IP protocol 132 number assignments are documented in [RP94]. 134 Note: For development purposes, IP Protocol number 9 (Private 135 IGP protocol number) [RP94] will be used until an official number 136 is granted. 138 - All IS-IS in IP routing protocol packets are sent using the 139 normal service TOS value of binary 0000 defined in [Alm92]. 141 - Routing protocol packets are sent with IP precedence set to 142 Internetwork Control. IS-IS in IP protocol packets should be 143 given precedence over regular IP data traffic, in both sending 144 and receiving. Setting the IP precedence field in the IP 145 header to Internetwork Control [Pos81] may help implement this 146 objective. 148 3. Internal Encapsulation 149 On point-to-point links no MAC addresses are used by IS-IS. Therefore 150 the Intradomain Routeing Protocol Discriminator or ISO 9542 Network 151 Layer Protocol Identifier starts directly after the IP header. For 152 P2P link running PPP, the Payload format will consist of PPP header, 153 followed by the IP header and NLPID as indicated in figure 1. 155 +------------+-----------+----------------+ 156 | PPP Header | IP Header | NLPID|ISIS PDU | 157 +------------+-----------+----------------+ 159 Figure 1: Encapsulation of ISIS frames over PPP 161 For P2P ATM links using VC muxing, the payload format must not 162 include the PPP header as indicated in figure 2. 164 +-------------+-----------+-----------------+ 165 | AAL5 Header | IP Header | NLPID|ISIS PDU | 166 +-------------+-----------+-----------------+ 168 Figure 2: Encapsulation of ISIS frames over ATM 170 In the case of broadcast media, MAC addresses are used for adjacency 171 identification. It is rather painful from the implementation 172 perspective to assume that an IS-IS must have access to MAC headers 173 when receiving frames. On the other hand, introducing an artificial 174 `bridging' encapsulation header preceding the Intradomain Routeing 175 Protocol Discriminator within the routed frame was perceived as 176 a very bulky solution. As yet another approach, based on the 177 observation that ethernets always have at least one IP address, 178 MAC address necessary for adjacency maintenance could be built 179 algorithmically using the source address of the IP packet received. 180 However, this would necessitate e.g. the allocation of a 2-byte 181 prefix within the 802.2/3 MAC space. Given the difficulties 182 surrounding each of these solutions, no special encapsulation is 183 defined for the ethernet case and the protocol implementation is 184 either required to received the complete frame, including layer 2 185 encapsulation or obtain the appropriate MAC address from the source 186 IP address using an interface to the lower layers of the IP stack. 188 4. Interoperability with Devices without IP Encapsulation 190 An interoperability solution for devices using IP encapsulation and 191 OSI encapsulation of ISIS frames would be only useful if it could 192 significantly ease the migration path in the existing networks. 193 Given the fact that graceful migration is not a paramount issue for 194 existing networks and any solution would invariable lead to the 195 problem of partitioning of broadcast media, such a solution is not 196 defined. 198 5. Acknowledgments 200 The encapsulation description part has been "borrowed" from a 201 well-known RFC [Moy97] with the author's consent. Tony Li, Mike 202 Shand, Henk Smit, Rajesh Varadarajan, Jeff Swinton, Stacy Smith gave 203 many constructive comments. 205 6. Security Consideration 207 ISIS security applies to the work presented. No specific security 208 issues with the proposed solutions are known. Things like IPSec may 209 influence the work in strange and unknown ways ;-) 211 References 213 [Alm92] P. Almquist. Type of Service in the Internet Protocol 214 Suite. INTERNET-RFC, Internet Engineering Task Force, July 215 1992. 217 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 218 INTERNET-RFC, Internet Engineering Task Force, February 219 1990. 221 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 222 Environments. INTERNET-RFC, Internet Engineering Task 223 Force, December 1990. 225 [Hei93] J. Heinanen. Rfc 1483, Multiprotocol Encapsulation over ATM 226 Adaptation Layer 5. Internet Engineering Task Force, July 227 1993. 229 [ISO90] ISO. Information Technology - Telecommunications and 230 Information Exchange between Systems - Intermediate System 231 to Intermediate System Routing Exchange Protocol for 232 Use in Conjunction with the Protocol for Providing the 233 Connectionless-Mode Network Service. ISO, 1990. 235 [Kat92] D. Katz. Rfc 1377, The PPP OSI Network Layer Control 236 Protocol (OSINLCP). Internet Engineering Task Force, 237 November 1992. 239 [MD90] J. Mogul and S. Deering. Rfc 1191, Path MTU Discovery. 240 Internet Engineering Task Force, November 1990. 242 [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, 243 July 1997. 245 [Pos81] J. Postel. Rfc 791, rfc Internet Protocol. Internet 246 Engineering Task Force, September 1981. 248 [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. 249 Internet Engineering Task Force, October 1994. 251 [Wai90] D. Waitzman. Rfc 1149, standard for the Transmission of 252 IP Datagrams on Avian Carriers. Internet Engineering Task 253 Force, April 1990. 255 Authors' Addresses 257 Tony Przygienda 258 Bell Labs, Lucent Technologies 259 101 Crawfords Corner Road 260 Holmdel, NJ 07733-3030 261 prz@dnrc.bell-labs.com 263 Ajay Patel 264 Bell Labs, Lucent Technologies 265 101 Crawfords Corner Road 266 Holmdel, NJ 07733-3030 267 ajayp@dnrc.bell-labs.com 269 Atul Bansal 270 FORE Systems, 271 1595 Spring Hill Rd 272 Vienna, VA 22181 273 bansal@fore.com