idnits 2.17.1 draft-ietf-pppext-trill-protocol-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 13, 2011) is 4698 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group James Carlson 2 INTERNET-DRAFT WorkingCode 3 Intended status: Proposed Standard Donald Eastlake 4 Huawei 5 Expires: December 12, 2011 June 13, 2011 7 PPP TRILL Protocol Control Protocol 8 10 Abstract 12 The Point-to-Point Protocol (PPP) defines a Link Control Protocol 13 (LCP) and a method for negotiating the use of multi-protocol traffic 14 over point-to-point links. This document describes PPP support for 15 the Transparent Interconnection of Lots of Links (TRILL) Protocol, 16 allowing direct communication between Routing Bridges (RBridges) via 17 PPP links. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Distribution of this document is unlimited. Comments should be sent 25 to the DNSEXT working group mailing list: . 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Table of Contents 45 1. Introduction............................................3 47 2. PPP TRILL Negotiation...................................4 48 2.1 TNCP Packet Format.....................................4 49 2.2 TNP Packet Format......................................5 50 2.3 TLSP Packet Format.....................................6 52 3. TRILL PPP Behavior......................................7 53 4. Security Considerations.................................8 54 5. IANA Considerations.....................................8 56 6. References..............................................9 57 6.1 Normative..............................................9 58 6.2 Informative............................................9 59 7. Acknowledgments........................................10 60 8. Authors' Addresses.....................................10 62 1. Introduction 64 The TRILL Protocol [RFCtrill] defines a set of mechanisms used to 65 communicate between RBridges. These devices can bridge together 66 large 802 networks using link-state protocols in place of the 67 traditional spanning tree mechanisms. 69 Over Ethernet, TRILL uses two separate Ethertypes to distinguish 70 between encapsulation headers, which carry user data, and link-state 71 messages, which compute network topology using a protocol based on 72 [IS-IS]. These two protocols must be distinguished from one another, 73 and segregated from all other traffic. 75 In a network where PPP [RFC1661] is used to interconnect routers 76 (often over telecommunications links), it may be advantageous to be 77 able to bridge between Ethernet segments over those PPP links, and 78 thus integrate remote networks with an existing TRILL cloud. The 79 existing Bridging Control Protocol (BCP) [RFC3518] allows direct 80 bridging of Ethernet frames over PPP. However, this mechanism is 81 inefficient and inadequate for TRILL, which can be optimized for use 82 over PPP links. 84 To interconnect these devices over PPP links, three protocol numbers 85 are needed, and are reserved as follows: 87 Value (in hex) Protocol Name 88 -------------- ------------------------------------- 89 TBD-00XX TRILL Network Protocol (TNP) 90 TBD-40YY TRILL Link State Protocol (TLSP) 91 TBD-80ZZ TRILL Network Control Protocol (TNCP) 93 The usage of these three protocols is described in detail in the 94 following section. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. PPP TRILL Negotiation 102 The TRILL Network Control Protocol (TNCP) is responsible for 103 negotiating the use of the TRILL Network Protocol (TNP) and TRILL 104 Link State Protocol (TLSP) on a PPP link. TNCP uses the same option 105 negotiation mechanism and state machine as described for LCP (section 106 4 of [RFC1661]). 108 TNCP packets MUST NOT be exchanged until PPP has reached the Network- 109 Layer Protocol phase. Any TNCP packets received when not in that 110 phase MUST be silently ignored. 112 The encapsulated network layer data, carried in TNP packets, and 113 topology information, carried in TLSP packets, MUST NOT be sent 114 unless TNCP is in Opened state. If a TNP or TLSP packet is received 115 when TNCP is not in Opened state and LCP is Opened, an implementation 116 MUST silently discard the unexpected TNP or TLSP packet. 118 2.1 TNCP Packet Format 120 Exactly one TNCP packet is carried in the PPP Information field, with 121 the PPP Protocol field set to hex TBD-80ZZ (TNCP). A summary of the 122 TNCP packet format is shown below. The fields are transmitted from 123 left to right. 125 0 1 2 3 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Code | Identifier | Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Data ... 131 +-+-+-+-+ 133 Code 135 Only LCP Code values 1 through 7 (Configure-Request, Configure- 136 Ack, Configure-Nak, Configure-Reject, Terminate-Request, 137 Terminate-Ack, and Code-Reject) are used. All other codes SHOULD 138 result in a TNCP Code-Reject reply. 140 Identifier and Length 142 These are as documented for LCP. 144 Data 146 This field contains data formatted as described in section 5 of 148 [RFC1661]. Codes 1-4 use Type-Length-Data sequences, Codes 5 and 149 6 use uninterpreted data, and Code 7 uses a Rejected-Packet, all 150 as described in [RFC1661]. 152 Because no Configuration Options have been defined for TNCP, 153 negotiating the use of TRILL Protocol with IS-IS for the link state 154 protocol is the default when no options are specified. A future 155 document may specify the use of Configuration Options to enable 156 different TRILL operating modes, such as the use of a different link 157 state protocol. 159 2.2 TNP Packet Format 161 When TNCP is in Opened state, TNP packets are sent by setting the PPP 162 Protocol field to hex TBD-00XX (TNP) and placing TRILL-encapsulated 163 data representing exactly one encapsulated packet in the PPP 164 Information field. 166 A summary of this format is provided below: 168 0 1 2 3 169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Ingress (RB1) Nickname | Inner Destination MAC ... 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 176 This is identical to the TRILL Ethernet format (section 4.1 of 177 [RFCtrill], "Ethernet Data Encapsulation,") except that the Outer MAC 178 header and Ethertype are replaced by the PPP headers and Protocol 179 Field, and the Ethernet FCS is not present. Both user data and ESADI 180 packets are encoded in this format. 182 The PPP FCS follows the encapsulated data on links where the PPP FCS 183 is in use. 185 Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC 186 addresses, so no outer MAC is present. (HDLC addresses MAY be 187 present in some situations; such usage is outside the scope of this 188 document.) 190 2.3 TLSP Packet Format 192 When TNCP is in Opened state, TLSP packets are sent by setting the 193 PPP Protocol field to hex TBD-40YY (TLSP) and placing exactly one IS- 194 IS Payload (section 4.2.3 of [RFCtrill], "TRILL IS-IS Frames") in the 195 PPP Information field. 197 Note that point-to-point IS-IS links have only an arbitrary Circuit 198 ID, and do not use MAC addresses for identification. 200 3. TRILL PPP Behavior 202 1. On a PPP link, TRILL always uses P2P Hellos. There is no need for 203 TRILL-Hello frames, nor is per-port configuration necessary. P2P 204 Hello messages, per "Point-to-Point IS to IS Hello PDU" (section 205 9.7 of [IS-IS]), do not use Neighbor IDs in the same manner as on 206 Ethernet. However, per section 4.2.4.1 of [RFCtrill], three-way 207 IS-IS handshake using extended circuit IDs is required on point- 208 to-point links, such as PPP. 210 2. RBridges are never appointed forwarders on PPP links. If an 211 implementation includes BCP [RFC3518], then it MUST ensure that 212 only one of BCP or TNCP is negotiated on a link, and not both. If 213 the peer is an RBridge, then there is no need to pass 214 unencapsulated frames, as the link can have no TRILL-ignorant peer 215 to be concerned about. If the peer is not an RBridge, then TNCP 216 negotiation fails and TRILL is not used on the link. 218 3. An implementation that has only PPP links might have no 219 Organizationally Unique Identifier (OUI) that can form an IS-IS 220 System ID. Resolving that issue is outside the scope of this 221 document, however it is strongly RECOMMENDED that all TRILL 222 implementations have at least one zero-configuration mechanism to 223 obtain a valid System ID. Refer to ISO/IEC 10589 regarding System 224 ID uniqueness requirements. 226 4. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of 227 [RFCtrill]) are not needed on a PPP link. Implementations MUST 228 NOT send MTU-probe and SHOULD NOT reply to these messages. The 229 MTU computed by LCP SHOULD be used instead. Negotiating an LCP 230 MTU of at least 1524, to allow for an inner Ethernet payload of 231 1500 octets, is RECOMMENDED. 233 4. Security Considerations 235 Existing PPP and IS-IS security mechanisms may play important roles 236 in a network of RBridges interconnected by PPP links. The IS-IS 237 authentication mechanism [RFC5304] [RFC5310], at the TRILL IS-IS 238 layer, prevents fabrication of link-state control messages. 240 Not all implementations need to include specific security mechanisms 241 at the PPP layer, for example if they are designed to be deployed 242 only in cases where the networking environment is trusted or where 243 other layers provide adequate security. A complete enumeration of 244 possible deployment scenarios and associated threats and options is 245 not possible and is outside the scope of this document. For 246 applications involving sensitive data, end-to-end security should 247 always be considered in addition to link security to provide security 248 in depth. 250 However, in case a PPP layer authentication mechanism to protect the 251 establishment of a link and identify a link with a known peer is 252 needed, implementation of PPP CHAP [RFC1994] is RECOMENDED. Should 253 greater flexibility be required than that provided by CHAP, EAP 254 [RFC3748] is a good alternative. 256 If TRILL over PPP packets also require confidentiality, the PPP ECP 257 link encryption mechanisms [RFC1968] can protect the confidentiality 258 and integrity of all packets on the PPP link. 260 And when PPP is run over tunneling mechanisms, such as L2TP 261 [RFC3931], tunnel security protocols may be available. 263 For general TRILL protocol security considerations, see [RFCtrill]. 265 5. IANA Considerations 267 IANA is requested to assigned three PPP Protocol field values, 268 TBD-00XX, TBD-40YY, and TBD-80ZZ, as described in Section 1 of this 269 document. 271 IANA is requested to create a new "PPP TNCP Configuration Option 272 Types" in the PPP-Numbers registry using the same format as the 273 existing "PPP LCP Configuration Option Types" table. 275 All TNCP Configuration Option Types except 00 are "Unassigned" and 276 available for future use, based on "IETF Review," as described in BCP 277 26 [RFC5226]. Option 00 is allocated for use with Vendor Specific 278 Options, as described in [RFC2153]. 280 6. References 282 Normative and Informational references are listed below. 284 6.1 Normative 286 [RFC1661] - W. Simpson, Editor, "The Point-to-Point Protocol (PPP)," 287 RFC 1661, July 1994 289 [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate 290 Requirement Levels," BCP 14 and RFC 2119, March 1997 292 [RFC5226] - T. Narten and H. Alvestrand, "Guidelines for Writing an 293 IANA Considerations Section in RFCs," BCP 26 and RFC 5226, May 294 2008 296 [RFCtrill] - R. Perlman, et al., "RBridges: Base Protocol 297 Specification," draft-ietf-trill-rbridge-protocol-16.txt, in 298 RFC Editor queue 300 6.2 Informative 302 [IS-IS] - International Organization for Standardization, 303 "Intermediate system to Intermediate system intra-domain 304 routeing information exchange protocol for use in conjunction 305 with the protocol for providing the connectionless-mode Network 306 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 307 2002 309 [RFC1968] - G. Meyer, "The PPP Encryption Control Protocol (ECP)," 310 RFC 1968, June 1996 312 [RFC1994] - W. Simpson, "PPP Challenge Handshake Authentication 313 Protocol (CHAP)," RFC 1994, August 1996 315 [RFC2153] - W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997 317 [RFC3518] - M. Higashiyama, et al., "Point-to-Point Protocol (PPP) 318 Bridging Control Protocol (BCP)," RFC 3518, April 2003 320 [RFC3748] - B. Aboba, et al., "Extensible Authentication Protocol 321 (EAP)," RFC 3748, June 2004 323 [RFC3931] - J. Lau, Ed., et al., "Layer Two Tunneling Protocol - 324 Version 3 (L2TPv3)," RFC 3931, March 2005 326 [RFC5304] - T. Li and R. Atkinson, "IS-IS Cryptographic 327 Authentication," RFC 5304, October 2008 329 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 330 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 331 5310, February 2009. 333 7. Acknowledgments 335 The authors thanks Jari Arkko, Stewart Bryant, Ralph Droms, Linda 336 Dunbar, Adrian Farrel, Stephen Farrell, Radia Perlman, Mike Shand, 337 and William A. Simpson for their comments and help. 339 8. Authors' Addresses 341 James Carlson 342 WorkingCode 343 25 Essex Street 344 North Andover, MA 01845 USA 346 Phone: +1-781-301-2471 347 Email: carlsonj@workingcode.com 349 Donald Eastlake, 3rd 350 Huawei Technologies 351 155 Beaver Street 352 Milford, MA 01757 USA 354 Phone: +1-508-333-2270 355 Email: d3e3e3@gmail.com 357 Copyright and IPR Provisions 359 Copyright (c) 2011 IETF Trust and the persons identified as the 360 document authors. All rights reserved. 362 This document is subject to BCP 78 and the IETF Trust's Legal 363 Provisions Relating to IETF Documents 364 (http://trustee.ietf.org/license-info) in effect on the date of 365 publication of this document. Please review these documents 366 carefully, as they describe your rights and restrictions with respect 367 to this document. Code Components extracted from this document must 368 include Simplified BSD License text as described in Section 4.e of 369 the Trust Legal Provisions and are provided without warranty as 370 described in the Simplified BSD License. The definitive version of 371 an IETF Document is that published by, or under the auspices of, the 372 IETF. Versions of IETF Documents that are published by third parties, 373 including those that are translated into other languages, should not 374 be considered to be definitive versions of IETF Documents. The 375 definitive version of these Legal Provisions is that published by, or 376 under the auspices of, the IETF. Versions of these Legal Provisions 377 that are published by third parties, including those that are 378 translated into other languages, should not be considered to be 379 definitive versions of these Legal Provisions. For the avoidance of 380 doubt, each Contributor to the IETF Standards Process licenses each 381 Contribution that he or she makes as part of the IETF Standards 382 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 383 language to the contrary, or terms, conditions or rights that differ 384 from or are inconsistent with the rights and licenses granted under 385 RFC 5378, shall have any effect and shall be null and void, whether 386 published or posted by such Contributor, or included with or in such 387 Contribution.