idnits 2.17.1 draft-ietf-isis-wg-over-ip-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 expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 63: '...s recommended; IP fragmentation SHOULD...' RFC 2119 keyword, line 67: '... - IIHs MUST not exceed the size o...' RFC 2119 keyword, line 71: '... - SNPs MUST NOT be larger than th...' RFC 2119 keyword, line 73: '... - SNPs MUST be sent allowing IP f...' RFC 2119 keyword, line 75: '... - 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: IS-IS does not normally provide a way to transmit packets larger than MTU size. This proposal allows to use IP fragmentation when transmitting such packets. If necessary, the length of IS-IS packets over IP can be up to 65,535 bytes (including the IP header). The IS-IS packet types that are likely to be large (LSPs, CSNPs, PSNPs) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation SHOULD be avoided whenever possible since it can lead to different problems, such as loss of fragments causing the retransmission of complete IP packets. Following rules apply: - IIHs MUST not exceed the size of [InterfaceMTU - 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.) -- The document date (May 1998) is 9472 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) -- 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. 'ISO90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kat92' ** 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: 9 errors (**), 0 flaws (~~), 4 warnings (==), 10 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 May 1998 5 IS-IS over IPv4 6 8 Status of This Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note 14 that other groups may also distribute working documents as 15 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at 18 any time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 27 This draft describes an optional implementation technique within 28 IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing 29 within their clouds. IS-IS is an interior gateway routing protocol 30 developed originally by OSI and used with IP extensions as IGP. This 31 draft describes how to encapsulate IS-IS packets in IPv4 [Pos81] 32 format. Such an encapsulation has many advantages, one of those 33 being the possibility to run integrated IS-IS on anything that 34 understands IPv4, including avian carriers [Wai90]. Encapsulation of 35 IS-IS PDUs in IPv6 is outside the scope of this document. 37 1. Introduction 38 Encapsulation of IS-IS as defined in ISO 10589 [ISO90, Cal90a, 39 Cal90b] uses directly over Link Layer protocols as opposed to IP 40 routing protocols [Moy97] that are encapsulated over IP directly. 42 By defining an encapsulation of IS-IS in IP, we save on special OSI 43 encapsulation on several media types. Such an encapsulation would 44 solve fragmentation problems of large LSPs and remove the necessity 45 for OSI PPP extensions [Kat92] when IS-IS is run over negotiated 46 PPP links. Additionally, on certain media, such as P2P ATM links, 47 no LLC/SNAP encapsulation is necessary to provide multi-protocol 48 routing, allowing for gains in efficiency. 50 2. Encapsulation of IS-IS and ISO 9542 packets over IP 51 IS-IS is encapsulated directly over the Internet Protocol's network 52 layer. IS-IS packets are therefore encapsulated by IP and local 53 data-link headers. Within this encapsulation, IS-IS packets are 54 propagated as usual, however without the appropriate link-layer 55 fields but starting at NLPI. 57 IS-IS does not normally provide a way to transmit packets larger 58 than MTU size. This proposal allows to use IP fragmentation when 59 transmitting such packets. If necessary, the length of IS-IS packets 60 over IP can be up to 65,535 bytes (including the IP header). The 61 IS-IS packet types that are likely to be large (LSPs, CSNPs, PSNPs) 62 can usually be split into several separate protocol packets, without 63 loss of functionality. This is recommended; IP fragmentation SHOULD 64 be avoided whenever possible since it can lead to different problems, 65 such as loss of fragments causing the retransmission of complete IP 66 packets. Following rules apply: 67 - IIHs MUST not exceed the size of [InterfaceMTU - IP headersize] 68 (1) and have the DF bit set. MTU size padding rules should be 69 followed as described in ISO 10589. 71 - SNPs MUST NOT be larger than the respective originatingLSPBufferSize. 73 - SNPs MUST be sent allowing IP fragmentation (DF bit not set). 75 - SNPs SHOULD NOT be larger than the minimum of [InterfaceMTU - 76 IPheadersize] and respective originatingLSPBufferSize. 78 - LSP fragments MAY BE built with a size up to the value of 79 corresponding originatingLSPBufferSize. 81 ___________________________________________ 82 1. not of maximum of Buffer and DataLinkSize used normally 83 - LSP fragments MUST NOT be larger than the respective 84 originatingLSPBufferSize. 86 - LSPs MUST be sent allowing IP fragmentation (DF bit not set). 88 - LSP fragments SHOULD NOT exceed the size of the minimum of 89 dataLinkBlockSize and respective originatingLSPBufferSize. 91 This set of rules allows to configure a network with respective 92 originatingLSPBufferSize larger than some interfaces' MTUs. 93 In a mixed environment, care must be taken that respective 94 originatingLSPBufferSize does net exceed the MTU size of interfaces 95 without IP encapsulation. 96 The other important features of IS-IS in IP's IP encapsulation are: 98 - Use of IP multicast. Some IS-IS in IP messages are multicast, 99 when sent over broadcast networks. Three distinct IP multicast 100 addresses are used. Packets sent to these multicast addresses 101 should never be forwarded; they are meant to travel a single hop 102 only. To ensure that these packets will not travel multiple 103 hops, their IP TTL must be set to 1. 105 IPAllL1ISs 107 OSI multicast value of this address was O1-80-C2-00-00-14. 108 This multicast address has been assigned the IP address 109 value 224.0.0.? for IP encapsulated IS-IS. All routers 110 running L1 IS-IS in IP should be prepared to receive 111 packets sent to this address. Hello packets are always 112 sent to this destination. Also, certain IS-IS in IP 113 protocol packets are sent to this address during the 114 flooding procedure. 116 IPAllL2ISs 118 OSI multicast value of this address was O1-80-C2-00-00-15. 119 This multicast address has been assigned the IP address 120 value 224.0.0.? for IP encapsulated IS-IS. All routers 121 running L2 IS-IS in IP should be prepared to receive 122 packets sent to this address. Hello packets are always 123 sent to this destination. Also, certain IS-IS in IP 124 protocol packets are sent to this address during the 125 flooding procedure. 127 IPAllIntermediateSystems 129 OSI multicast value of this address was 09-00-2B-0O-00-05. 130 This multicast address has been assigned the IP address 131 value 224.0.0.? for IP encapsulated IS-IS. All routers 132 running IS-IS in IP should be prepared to receive packets 133 sent to this address. ISO 9542 is using this address. 135 - IS-IS in IP is IP protocol number ??. This number has been 136 requested with the Network Information Center. IP protocol 137 number assignments are documented in [RP94]. 139 Note: For development purposes, IP Protocol number 9 (Private 140 IGP protocol number) [RP94] will be used until an official number 141 is granted. 143 - All IS-IS in IP routing protocol packets are sent using the 144 normal service TOS value of binary 0000 defined in [Alm92]. 146 - Routing protocol packets are sent with IP precedence set to 147 Internetwork Control. IS-IS in IP protocol packets should be 148 given precedence over regular IP data traffic, in both sending 149 and receiving. Setting the IP precedence field in the IP 150 header to Internetwork Control [Pos81] may help implement this 151 objective. 153 3. Internal Encapsulation 154 On point-to-point links no MAC addresses are used by IS-IS. Therefore 155 the Intradomain Routeing Protocol Discriminator or ISO 9542 Network 156 Layer Protocol Identifier starts directly after the IP header. For 157 P2P link running PPP, the Payload format will consist of PPP header, 158 followed by the IP header and NLPID as indicated in figure 1. 160 +------------+-----------+----------------+ 161 | PPP Header | IP Header | NLPID|ISIS PDU | 162 +------------+-----------+----------------+ 164 Figure 1: Encapsulation of ISIS frames over PPP 166 For P2P ATM links using VC muxing, the payload format must not 167 include the PPP header as indicated in figure 2. 169 +-------------+-----------+-----------------+ 170 | AAL5 Header | IP Header | NLPID|ISIS PDU | 171 +-------------+-----------+-----------------+ 173 Figure 2: Encapsulation of ISIS frames over ATM 175 In the case of broadcast media, MAC addresses are used for adjacency 176 identification. It is rather painful from the implementation 177 perspective to assume that an IS-IS must have access to MAC headers 178 when receiving frames. However, based on the observation that 179 ethernets have at least one IP address assigned, MAC address 180 necessary for adjacency maintenance can be built algorithmically 181 using the source address of the IP packet received. To prevent 182 collisions with universally administered addresses, the addresses 183 are designated by having bit one in byte zero of the MAC set to 1 to 184 indicate locally administered address as specified by the according 185 IEEE standard. When receiving an IP encapsulated ISIS PDU, the 186 artificial MAC address is assumed to consist (in network order) of 187 4 bytes of source IP address aligned as least significant bytes, 188 ``locally administered'' bit being set and all remaining bits being 189 zero. Figure 3 visualizes such an address for a source IP address 190 128.127.128.1. 192 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 193 +--------+--------+--------+--------+--------+--------+ 194 |01000000|00000000|10000000|01111111|10000000|00000001| 195 +--------+--------+--------+--------+--------+--------+ 197 Figure 3: Artificial MAC for IP address 128.127.128.1 199 When operating on an interface encapsulating IS-IS within IP, 200 encapsulated PDUs MUST be sent with a constant IP source address. 201 Any change of the IP address on the interface MUST be considered 202 equivalent to change of MAC address in ISO mode. In all places in 203 which MAC addresses are being used in ISO mode, source IP address 204 MUST be used to compute artificial MACs when sending and parsing 205 received PDUs. 207 Any PDU received on IP encapsulated broadcast interface and 208 containing MACs with either the ``locally administered'' bit not 209 being set or any of the remaining bits in the first two bytes being 210 set SHOULD be discarded. Any configuration in which an interface 211 uses a MAC that would be equivalent to such an algorithmic MAC being 212 generated on another interface within the same system SHOULD be 213 considered a misconfiguration. 215 4. Interoperability with Devices without IP Encapsulation 217 An interoperability solution for devices using IP encapsulation and 218 OSI encapsulation of ISIS frames would be only useful if it could 219 significantly ease the migration path in the existing networks. 220 Given the fact that graceful migration is not a paramount issue for 221 existing networks and any solution would invariable lead to the 222 problem of partitioning of broadcast media, such a solution is not 223 defined. 225 5. Acknowledgments 227 The encapsulation description part has been "borrowed" from a 228 well-known RFC [Moy97] with the author's consent. Tony Li, Dave 229 Katz, Mike Shand, Henk Smit, Rajesh Varadarajan, Jeff Swinton, Stacy 230 Smith provided constructive comments. 232 6. Security Consideration 234 ISIS security applies to the work presented. No specific security 235 issues with the proposed solutions are known. Things like IPSec may 236 influence the work in strange and unknown ways ;-) 238 References 240 [Alm92] P. Almquist. Type of Service in the Internet Protocol 241 Suite. INTERNET-RFC, Internet Engineering Task Force, July 242 1992. 244 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 245 INTERNET-RFC, Internet Engineering Task Force, February 246 1990. 248 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 249 Environments. INTERNET-RFC, Internet Engineering Task 250 Force, December 1990. 252 [ISO90] ISO. Information Technology - Telecommunications and 253 Information Exchange between Systems - Intermediate System 254 to Intermediate System Routing Exchange Protocol for 255 Use in Conjunction with the Protocol for Providing the 256 Connectionless-Mode Network Service. ISO, 1990. 258 [Kat92] D. Katz. Rfc 1377, The PPP OSI Network Layer Control 259 Protocol (OSINLCP). Internet Engineering Task Force, 260 November 1992. 262 [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, 263 July 1997. 265 [Pos81] J. Postel. Rfc 791, rfc Internet Protocol. Internet 266 Engineering Task Force, September 1981. 268 [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. 269 Internet Engineering Task Force, October 1994. 271 [Wai90] D. Waitzman. Rfc 1149, standard for the Transmission of 272 IP Datagrams on Avian Carriers. Internet Engineering Task 273 Force, April 1990. 275 Authors' Addresses 277 Tony Przygienda 278 Bell Labs, Lucent Technologies 279 101 Crawfords Corner Road 280 Holmdel, NJ 07733-3030 281 prz@dnrc.bell-labs.com 283 Ajay Patel 284 Bell Labs, Lucent Technologies 285 101 Crawfords Corner Road 286 Holmdel, NJ 07733-3030 287 ajayp@dnrc.bell-labs.com 289 Atul Bansal 290 FORE Systems, 291 1595 Spring Hill Rd 292 Vienna, VA 22181 293 bansal@fore.com