idnits 2.17.00 (12 Aug 2021) /tmp/idnits20119/draft-ietf-isis-wg-over-ip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 306 lines 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. ** There are 34 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 71: '...s recommended; IP fragmentation SHOULD...' RFC 2119 keyword, line 76: '... - IIHs MUST not exceed the size ...' RFC 2119 keyword, line 80: '... - SNPs MUST NOT be larger than t...' RFC 2119 keyword, line 83: '... - SNPs MUST be sent allowing IP ...' RFC 2119 keyword, line 85: '... - SNPs SHOULD NOT be larger than...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: - IIHs MUST not exceed the size of [InterfaceMT U - IP headersize] (1) and have the DF bit set. MTU size padding rules should be followed as described in ISO 10589. -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Cal90a' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'Cal90b' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'Hei93' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'ISO90' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'Kat92' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'MD90' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'Moy97' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'Pos81' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RP94' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'Wai90' is defined on line 317, but no explicit reference was found in the text -- 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: 7 errors (**), 0 flaws (~~), 15 warnings (==), 11 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, 3 Siara 4 Oct 5 1999 6 IS-IS over IPv4 7 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This draft describes an optional implementation technique within 31 IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing 32 within their clouds. IS-IS is an interior gateway routing protocol 33 developed originally by OSI and used with IP extensions as IGP. This 34 draft describes how to encapsulate IS-IS packets in IPv4 [Pos81 ] 35 format. Such an encapsulation has many advantages, one of those 36 being the possibility to run integrated IS-IS on anything that 37 understands IPv4, including avian carriers [Wai90 ]. Encapsulation of 38 IS-IS PDUs in IPv6 is outside the scope of this document. 40 1. Introduction 42 Encapsulation of IS-IS as defined in ISO 10589 [ISO90 , Cal90a , 43 Cal90b] uses directly over Link Layer protocols as opposed to IP 44 routing protocols [Moy97 ] that are encapsulated over IP directly. 46 Internet Draft IS-IS over IPv4 Oct 47 1999 49 By defining an encapsulation of IS-IS in IP, we save on special OSI 50 encapsulation on several media types. Such an encapsulation would 51 solve fragmentation problems of large LSPs and remove the necessity 52 for OSI PPP extensions [Kat92 ] when IS-IS is run over negotiated 53 PPP links. Additionally, on certain media, such as P2P ATM links, 54 no LLC/SNAP encapsulation is necessary to provide multi-protocol 55 routing, allowing for gains in efficiency. 57 2. Encapsulation of IS-IS and ISO 9542 packets over IP 59 IS-IS is encapsulated directly over the Internet Protocol's network 60 layer. IS-IS packets are therefore encapsulated by IP and local 61 data-link headers. Within this encapsulation, IS-IS packets are 62 propagated as usual, however without the appropriate link-layer 63 fields but starting at NLPI. 65 IS-IS does not normally provide a way to transmit packets larger 66 than MTU size. This proposal allows to use IP fragmentation when 67 transmitting such packets. If necessary, the length of IS-IS packets 68 over IP can be up to 65,535 bytes (including the IP header). The 69 IS-IS packet types that are likely to be large (LSPs, CSNPs, PSNPs) 70 can usually be split into several separate protocol packets, without 71 loss of functionality. This is recommended; IP fragmentation SHOULD 72 be avoided whenever possible since it can lead to different problems, 73 such as loss of fragments causing the retransmission of complete IP 74 packets. Following rules apply: 76 - IIHs MUST not exceed the size of [InterfaceMT U - IP headersize] 77 (1) and have the DF bit set. MTU size padding rules should be 78 followed as described in ISO 10589. 80 - SNPs MUST NOT be larger than the respective 81 originatingLSPBufferSize. 83 - SNPs MUST be sent allowing IP fragmentation (DF bit not set). 85 - SNPs SHOULD NOT be larger than the minimum of [InterfaceMT U - 86 IP headersize] and respective originatingLSPBufferSize. 88 - LSP fragments MAY BE built with a size up to the value of 89 corresponding originatingLSPBufferSize. 91 ___________________________________________ 92 1. not of maximum of Buffer and DataLinkSize used normally 94 Przygienda et al. Expires Mar 2000 [Page 95 2] 97 Internet Draft IS-IS over IPv4 Oct 98 1999 100 - LSP fragments MUST NOT be larger than the respective 101 originatingLSPBufferSize. 103 - LSPs MUST be sent allowing IP fragmentation (DF bit not set). 105 - LSP fragments SHOULD NOT exceed the size of the minimum of 106 dataLinkBlockSize and respective originatingLSPBufferSize. 108 This set of rules allows to configure a network with respective 109 originatingLSPBufferSize larger than some interfaces' MTUs. 110 In a mixed environment, care must be taken that respective 111 originatingLSPBufferSize does net exceed the MTU size of interfaces 112 without IP encapsulation. A default originatingLSPBufferSize of 1472 113 is recommended. 115 The other important features of IS-IS in IP's IP encapsulation are: 117 - IS-IS in IP has been assigned IP protocol number 124. IP 118 protocol number assignments are documented in [RP94 ]. 120 Historical note: For development purposes, IP Protocol number 121 9 (Private IGP protocol number) [RP94 ] has been used until an 122 official number was granted. 124 - Use of IP multicast. Some IS-IS in IP messages are multicast, 125 when sent over broadcast networks. Three distinct IP multicast 126 addresses are used. Packets sent to these multicast addresses 127 should never be forwarded; they are meant to travel a single hop 128 only. To ensure that these packets will not travel multiple 129 hops, their IP TTL must be set to 1. 131 IPAllL1ISs 133 OSI multicast value of this address was O1-80-C2-00-00-14. 134 This multicast address has been assigned the IP address 135 value 224.0.0.19 for IP encapsulated IS-IS. All routers 136 running L1 IS-IS in IP should be prepared to receive 137 packets sent to this address. Hello packets are always 138 sent to this destination. Also, certain IS-IS in IP 139 protocol packets are sent to this address during the 140 flooding procedure. 142 Przygienda et al. Expires Mar 2000 [Page 143 3] 145 Internet Draft IS-IS over IPv4 Oct 146 1999 148 IPAllL2ISs 150 OSI multicast value of this address was O1-80-C2-00-00-15. 151 This multicast address has been assigned the IP address 152 value 224.0.0.20 for IP encapsulated IS-IS. All routers 153 running L2 IS-IS in IP should be prepared to receive 154 packets sent to this address. Hello packets are always 155 sent to this destination. Also, certain IS-IS in IP 156 protocol packets are sent to this address during the 157 flooding procedure. 159 IPAllIntermediateSystems 161 OSI multicast value of this address was 09-00-2B-0O-00-05. 162 This multicast address has been assigned the IP address 163 value 224.0.0.21 for IP encapsulated IS-IS. All routers 164 running IS-IS in IP should be prepared to receive packets 165 sent to this address. ISO 9542 is using this address. 167 - All IS-IS in IP routing protocol packets are sent using the 168 normal service TOS value of binary 0000 defined in [Alm92 ]. 170 - Routing protocol packets are sent with IP precedence set to 171 Internetwork Control. IS-IS in IP protocol packets should be 172 given precedence over regular IP data traffic, in both sending 173 and receiving. Setting the IP precedence field in the IP header 174 to Internetwork Control [Pos81 ] may help to implement this 175 objective. 177 3. Internal Encapsulation 179 On point-to-point links no MAC addresses are used by IS-IS. Therefore 180 the Intradomain Routeing Protocol Discriminator or ISO 9542 Network 181 Layer Protocol Identifier starts directly after the IP header. 182 For P2P link running PPP, the Payload format will consist of PPP 183 header, followed by the IP header and the usual NLPID as indicated in 184 figure 1. 186 For P2P ATM links using VC muxing, the payload format MUST NOT 187 include the PPP header as indicated in figure 2. 189 In the case of broadcast media, MAC addresses are used for adjacency 190 identification. It is rather painful from the implementation 191 perspective to assume that an IS-IS must have access to MAC headers 193 Przygienda et al. Expires Mar 2000 [Page 194 4] 196 Internet Draft IS-IS over IPv4 Oct 197 1999 198 +------------+-----------+-----------+ 199 | PPP Header | IP Header | ISIS PDU | 200 +------------+-----------+-----------+ 202 Figure 1: Encapsulation of ISIS frames over PPP 204 +-------------+-----------+----------+ 205 | AAL5 Header | IP Header | ISIS PDU | 206 +-------------+-----------+----------+ 208 Figure 2: Encapsulation of ISIS frames over ATM 210 when receiving frames. However, based on the observation that 211 ethernets have at least one IP address assigned, MAC address 212 necessary for adjacency maintenance can be built algorithmically 213 using the source address of the IP packet received. To prevent 214 collisions with universally administered addresses, the addresses 215 are designated by having bit one in byte zero of the MAC set to 1 to 216 indicate locally administered address as specified by the according 217 IEEE standard. When receiving an IP encapsulated ISIS PDU, the 218 artificial MAC address is assumed to consist (in network order) of 219 4 bytes of source IP address aligned as least significant bytes, 220 ``locally administered'' bit being set and all remaining bits being 221 zero. Figure 3 visualizes such an address for a source IP address 222 128.127.128.1. 224 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 225 +--------+--------+--------+--------+--------+--------+ 226 |01000000|00000000|10000000|01111111|10000000|00000001| 227 +--------+--------+--------+--------+--------+--------+ 229 Figure 3: Artificial MAC for IP address 128.127.128.1 231 Przygienda et al. Expires Mar 2000 [Page 232 5] 234 Internet Draft IS-IS over IPv4 Oct 235 1999 237 When operating on an interface encapsulating IS-IS within IP, 238 encapsulated PDUs MUST be sent with a constant IP source address. 239 Any change of the IP address on the interface MUST be considered 240 equivalent to change of MAC address in ISO mode. In all places in 241 which MAC addresses are being used in ISO mode, source IP address 242 MUST be used to compute artificial MACs when sending and parsing 243 received PDUs. 245 Any PDU received on IP encapsulated broadcast interface and 246 containing MACs with either the ``locally administered'' bit not 247 being set or any of the remaining bits in the first two bytes being 248 set SHOULD be discarded. 250 4. Interoperability with Devices without IP Encapsulation 252 An interoperability solution for devices using IP encapsulation and 253 OSI encapsulation of ISIS frames would be only useful if it could 254 significantly ease the migration path in the existing networks. 255 Given the fact that graceful migration is not a paramount issue for 256 existing networks and any solution would invariably lead to the 257 problem of partitioning of broadcast media, such a solution is not 258 defined. 260 5. Acknowledgments 262 The encapsulation description part has been "borrowed" from a 263 well-known RFC [Moy97 ] with the author's consent. Tony Li, Dave 264 Katz, Christian Hopps, Mike Shand, Henk Smit, Rajesh Varadarajan, 265 Jeff Swinton, Stacy Smith and others provided constructive comments. 267 6. Security Consideration 269 ISIS security applies to the work presented. No specific security 270 issues with the proposed solutions are known. Things like IPSec may 271 influence the work in strange and unknown ways ;-) 272 References 274 [Alm92] P. Almquist. Type of Service in the Internet Protocol 275 Suite. INTERNET-RFC, Internet Engineering Task Force, July 276 1992. 277 Przygienda et al. Expires Mar 2000 [Page 278 6] 280 Internet Draft IS-IS over IPv4 Oct 281 1999 283 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 284 INTERNET-RFC, Internet Engineering Task Force, February 285 1990. 287 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 288 Environments. INTERNET-RFC, Internet Engineering Task 289 Force, December 1990. 291 [Hei93] J. Heinanen. Rfc 1483, Multiprotocol Encapsulation over ATM 292 Adaptation Layer 5. Internet Engineering Task Force, July 293 1993. 295 [ISO90] ISO. Information Technology - Telecommunications and 296 Information Exchange between Systems - Intermediate System 297 to Intermediate System Routing Exchange Protocol for 298 Use in Conjunction with the Protocol for Providing the 299 Connectionless-Mode Network Service. ISO, 1990. 301 [Kat92] D. Katz. Rfc 1377, The PPP OSI Network Layer Control 302 Protocol (OSINLCP). Internet Engineering Task Force, 303 November 1992. 305 [MD90] J. Mogul and S. Deering. Rfc 1191, Path MTU Discovery. 306 Internet Engineering Task Force, November 1990. 308 [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, 309 July 1997. 311 [Pos81] J. Postel. Rfc 791, rfc Internet Protocol. Internet 312 Engineering Task Force, September 1981. 314 [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. 315 Internet Engineering Task Force, October 1994. 317 [Wai90] D. Waitzman. Rfc 1149, standard for the Transmission of 318 IP Datagrams on Avian Carriers. Internet Engineering Task 319 Force, April 1990. 321 Authors' Addresses 323 Tony Przygienda 324 Siara Systems 326 Przygienda et al. Expires Mar 2000 [Page 327 7] 329 Internet Draft IS-IS over IPv4 Oct 330 1999 332 300 Ferguson Drive 333 Mountain View, CA 94043 334 prz@siara.com 336 Ajay Patel 337 Siara Systems 338 300 Ferguson Drive 339 Mountain View, CA 94043 340 ajayp@siara.com 342 Atul Bansal 343 FORE Systems, 344 1595 Spring Hill Rd 345 Vienna, VA 22181 346 bansal@fore.com 348 Przygienda et al. Expires Mar 2000 [Page 349 8]