idnits 2.17.1 draft-ietf-trill-over-ip-11.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 (December 2, 2017) is 2336 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. 'IS-IS' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Margaret Cullen 2 Intended Status: Proposed Standard Painless Security 3 Updates: 7177, 7178 Donald Eastlake 4 Mingui Zhang 5 Dacheng Zhang 6 Huawei 7 Expires: June 1, 2017 December 2, 2017 9 TRILL (Transparent Interconnection of Lots of Links) over IP 10 12 Abstract 13 The TRILL (Transparent Interconnection of Lots of Links) protocol 14 supports both point-to-point and multi-access links and is designed 15 so that a variety of link protocols can be used between TRILL switch 16 ports. This document specifies transmission of encapsulated TRILL 17 data and TRILL IS-IS over IP (v4 or v6). so as to use an IP network 18 as a TRILL link in a unified TRILL campus. This document updates RFC 19 7177 and updates RFC 7178. 21 Status of This Document 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the authors or the TRILL Working Group mailing list 28 . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................4 48 2. Terminology.............................................5 50 3. Use Cases for TRILL over IP.............................6 51 3.1 Remote Office Scenario.................................6 52 3.2 IP Backbone Scenario...................................6 53 3.3 Important Properties of the Scenarios..................7 54 3.3.1 Security Requirements................................7 55 3.3.2 Multicast Handling...................................8 56 3.3.3 Neighbor Discovery...................................8 58 4. TRILL Packet Formats....................................9 59 4.1 General Packet Formats.................................9 60 4.2 General TRILL Over IP Packet Formats..................10 61 4.2.1 Without Security....................................10 62 4.2.2 With Security.......................................10 63 4.3 QoS Considerations....................................11 64 4.4 Broadcast Links and Multicast Packets.................13 65 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment....13 67 5. TRILL over IP Encapsulation Formats....................15 68 5.1 Encapsulation Considerations..........................15 69 5.2 Encapsulation Agreement...............................16 70 5.3 Broadcast Link Encapsulation Considerations...........17 71 5.4 Native Encapsulation..................................18 72 5.5 VXLAN Encapsulation...................................19 73 5.6 TCP Enacpulstion......................................19 74 5.7 Other Encapsulations..................................21 76 6. Handling Multicast.....................................22 78 7. Use of IPsec and IKEv2.................................23 79 7.1 Keying................................................23 80 7.1.1 Pairwise Keying.....................................23 81 7.1.2 Group Keying........................................24 82 7.2 Mandatory-to-Implement Algorithms.....................24 84 8. Transport Considerations...............................25 85 8.1 Congestion Considerations.............................25 86 8.1.1 Within a TMCE.......................................26 87 8.1.2 In Other Environments...............................26 88 8.2 Recursive Ingress.....................................26 89 8.3 Fat Flows.............................................27 90 8.4 MTU Considerations....................................28 92 9. TRILL over IP Port Configuration.......................29 93 9.1 Per IP Port Configuration.............................29 94 9.2 Additional per IP Address Configuration...............29 96 Table of Contents (continued) 98 9.2.1 Native Multicast Configuration......................30 99 9.2.2 Serial Unicast Configuration........................30 100 9.2.3 Encapsulation Specific Configuration................30 101 9.2.3.1 UDP Source Port...................................30 102 9.2.3.2 VXLAN Configuration...............................31 103 9.2.3.3 Other Encapsulation Configuration.................31 104 9.2.4 Security Configuration..............................31 106 10. Security Considerations...............................32 107 10.1 IPsec................................................32 108 10.2 IS-IS Security.......................................33 110 11. IANA Considerations...................................34 111 11.1 Port Assignments.....................................34 112 11.2 Multicast Address Assignments........................34 113 11.3 Encapsulation Method Support Indication..............35 115 Normative References......................................36 116 Informative References....................................38 118 Acknowledgements..........................................40 119 Authors' Addresses........................................41 121 1. Introduction 123 TRILL switches (also know as RBridges) are devices that implement the 124 IETF TRILL protocol [RFC6325] [RFC7177] [RFC7780]. TRILL provides 125 transparent forwarding of frames within an arbitrary network 126 topology, using least cost paths for unicast traffic. It supports 127 VLANs and Fine Grained Labels [RFC7172] as well as multipathing of 128 unicast and multi-destination traffic. It uses IS-IS [IS-IS] 129 [RFC7176] link state routing with a TRILL header having a hop count. 131 RBridge ports can communicate with each other over various protocols, 132 such as Ethernet [RFC6325], pseudowires [RFC7173], or PPP [RFC6361]. 134 This document specifies transmission of encapsulated TRILL data and 135 TRILL IS-IS over IP (v4 or v6 [rfc2460bis]). so as to use an IP 136 network as a TRILL link in a unified TRILL campus. One mandatory to 137 implement UDP based encapsulation is specifies along with two option 138 to implement encpsulations, one based on UDP and one based on TCP. 139 Provision is made to negotiate other encapsulations. TRILL over IP 140 allows RBridges with IP connectivity to form a single TRILL campus, 141 or multiple TRILL networks to be connected as a single TRILL campus 142 via a TRILL over IP backbone. 144 The protocol specified in this document connects RBridge ports using 145 transport over IP in such a way that the ports with IP connectivity 146 appear to TRILL to be connected by a single multi-access link. If a 147 set of more than two RBridge ports are connected via a single TRILL 148 over IP link, each RBridge port in the set can communicate with every 149 other RBridge port in the set. 151 To support the scenarios where RBridges are connected via IP paths 152 (including those over the public Internet) that are not under the 153 same administrative control as the TRILL campus and/or not physically 154 secure, this document specifies the use of IPsec [RFC4301] 155 Encapsulating Security Protocol (ESP) [RFC4303] for security. 157 To dynamically select a mutually supported TRILL over IP 158 encapsulation, normally one with good fast path hardware support, a 159 method is provided for agreement between adjacent TRILL switch ports 160 as to what encapsulation to use. Alternatively, where a common 161 encapsulation is known to be supported by the TRILL switch ports on a 162 link, they can simply be configured to always use that encapsulation. 164 This document updates [RFC7177] and [RFC7178] as described in 165 Sections 5 and 11.3 by making adjacency between TRILL over IP ports 166 dependent on having a method of encapsulation in common and by 167 redefining an interval of RBridge Channel protocol numbers to 168 indicate link technology specific capabilities, in this case 169 encapsulation methods supported for TRILL over IP. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 The following terms and acronyms have the meaning indicated: 179 DRB - Designated RBridge. The RBridge (TRILL switch) elected to be in 180 charge of certain aspects of a TRILL link that is not 181 configured as a point-to-point link [RFC6325] [RFC7177]. 183 ENCAP Hdr - See "encapsulation header". 185 encapsulation header - Protocol header or headers appearing between 186 the IP Header and the TRILL Header. See Sections 4 and 5. 188 ESP - IPsec Encapsulating Security Protocol [RFC4303]. 190 FGL - Fine Grained Label [RFC7172]. 192 Hdr - Used herein as an abbreviation for "Header". 194 link - In TRILL, a link connects TRILL ports and may, for example, be 195 a bridged LAN. 197 HKDF - Hash based Key Derivation Function [RFC5869]. 199 MTU - Maximum Transmission Unit. 201 QoS - Quality of Service. 203 RBridge - Routing Bridge. An alternative term for a TRILL switch. 204 [RFC6325] [RFC7780] 206 SNPA - Sub-Network Point of Attachment. 208 Sz - The campus wide MTU [RFC6325] [RFC7780]. 210 TMCE - Traffic-Managed Controlled Environment, see Section 8.1.1. 212 TRILL - Transparent Interconnection of Lots of Links or Tunneled 213 Routing in the Link Layer. The protocol specified in [RFC6325], 214 [RFC7177], [RFC7780], and related RFCs. 216 TRILL switch - A device implementing the TRILL protocol. 218 VNI - Virtual Network Identifier. In Virtual eXtensible Local Area 219 Network (VXLAN) [RFC7348], the VXLAN Network Identifier. 221 3. Use Cases for TRILL over IP 223 This section introduces two application scenarios (a remote office 224 scenario and an IP backbone scenario) which cover typical situations 225 where network administrators may choose to use TRILL over an IP 226 network to connect TRILL switches. 228 3.1 Remote Office Scenario 230 In the Remote Office Scenario, as shown in the example below, a 231 remote TRILL network is connected to a TRILL campus across a multihop 232 IP network, such as the public Internet. The TRILL network in the 233 remote office becomes a part of TRILL campus, and nodes in the remote 234 office can be attached to the same VLANs or Fine Grained Labels 235 [RFC7172] as local campus nodes. In many cases, a remote office may 236 be attached to the TRILL campus by a single pair of RBridges, one on 237 the campus end, and the other in the remote office. In this use case, 238 the TRILL over IP link will often cross logical and physical IP 239 networks that do not support TRILL, and are not under the same 240 administrative control as the TRILL campus. 242 /---------------\ /---------------\ 243 | Remote | | Remote | 244 | Office | | Office | 245 | | | | 246 | +-------+ | | +-------+ | 247 \---|RBridge|---/ \---|RBridge|---/ 248 +-----+-+ +-+-----+ 249 | | 250 /---------------------------------------------\ 251 | | The Internet | | 252 \---------------------------------------------/ 253 | | 254 +-+-----+ +-----+-+ 255 /----|RBridge|---------------|RBridge|----\ 256 | +-------+ +-------+ | 257 | | 258 | Main TRILL Campus | 259 \-----------------------------------------/ 261 3.2 IP Backbone Scenario 263 In the IP Backbone Scenario, as shown in the example below, TRILL 264 over IP is used to connect a number of TRILL networks to form a 265 single TRILL campus. For example, a TRILL over IP backbone could be 266 used to connect multiple TRILL networks on different floors of a 267 large building, or to connect TRILL networks in separate buildings of 268 a multi-building site. In this use case, there may often be several 269 TRILL switches on a single TRILL over IP link, and the IP link(s) 270 used by TRILL over IP are typically under the same administrative 271 control as the rest of the TRILL campus. 273 /---------------------------------------------\ 274 | Unified TRILL Campus | 275 | | 276 | TRILL Over IP Backbone | 277 | -----+------------+------------+----- | 278 | | | | | 279 | +---+---+ +---+---+ +---+---+ | 280 | |RBridge| |RBridge| |RBridge| | 281 | +---+---+ +---+---+ +---+---+ | 282 | | | | | 283 | ---+--- ---+--- ---+--- | 284 | TRILL Local Links or Networks | 285 | | 286 \---------------------------------------------/ 288 3.3 Important Properties of the Scenarios 290 There are a number of differences between the above two application 291 scenarios, some of which drive features of this specification. These 292 differences are especially pertinent to the security requirements of 293 the solution, how multicast data frames are handled, and how the 294 TRILL switch ports discover each other. 296 3.3.1 Security Requirements 298 In the IP Backbone Scenario, TRILL over IP is used between a number 299 of RBridge ports, on a network link that is in the same 300 administrative control as the remainder of the TRILL campus. While it 301 is desirable in this scenario to prevent the association of 302 unauthorized RBridges, this can be accomplished using existing IS-IS 303 security mechanisms. There may be no need to protect the data 304 traffic, beyond any protections that are already in place on the 305 local network. 307 In the Remote Office Scenario, TRILL over IP may run over a network 308 that is not under the same administrative control as the TRILL 309 network. Nodes on the network may think that they are sending traffic 310 locally, while that traffic is actually being sent, in an IP tunnel, 311 over the public Internet. It is necessary in this scenario to protect 312 the integrity and confidentiality of user traffic, as well as 313 ensuring that no unauthorized RBridges can gain access to the RBridge 314 campus. The issues of protecting integrity and confidentiality of 315 user traffic are addressed by using IPsec for both TRILL IS-IS and 316 TRILL Data packets between RBridges in this scenario. 318 3.3.2 Multicast Handling 320 In the IP Backbone scenario, native IP multicast may be supported on 321 the TRILL over IP link. If so, it can be used to send TRILL IS-IS and 322 multicast data packets, as discussed later in this document. 323 Alternatively, multi-destination packets can be transmitted serially 324 by IP unicast to the intended recipients. 326 In the Remote Office Scenario there will often be only one pair of 327 RBridges connecting a given site and, even when multiple RBridges are 328 used to connect a Remote Office to the TRILL campus, the intervening 329 network may not provide reliable (or any) multicast connectivity. 330 Issues such as complex key management also make it difficult to 331 provide strong data integrity and confidentiality protections for 332 multicast traffic. For all of these reasons, the connections between 333 local and remote RBridges will commonly be treated like point-to- 334 point links, and all TRILL IS-IS control messages and multicast data 335 packets that are transmitted between the Remote Office and the TRILL 336 campus will be serially transmitted by IP unicast, as discussed later 337 in this document. 339 3.3.3 Neighbor Discovery 341 In the IP Backbone Scenario, TRILL switches that use TRILL over IP 342 can use the normal TRILL IS-IS Hello mechanisms to discover the 343 existence of other TRILL switches on the link [RFC7177], and to 344 establish authenticated communication with them. 346 In the Remote Office Scenario, an IPsec session will need to be 347 established before TRILL IS-IS traffic can be exchanged, as discussed 348 below. In this case, one end will need to be configured to establish 349 a IPSEC session with the other. This will typically be accomplished 350 by configuring the TRILL switch or a border device at a Remote Office 351 to initiate an IPsec session and subsequent TRILL exchanges with a 352 TRILL over IP-enabled RBridge attached to the TRILL campus. 354 4. TRILL Packet Formats 356 To support TRILL two types of TRILL packets are transmitted between 357 TRILL switches: TRILL Data packets and TRILL IS-IS packets. 359 Section 4.1 describes general TRILL packet formats for data and IS-IS 360 independent of link technology. Section 4.2 specifies general TRILL 361 over IP packet formats including IPsec ESP encapsulation. Section 4.3 362 provides QoS Considerations. Section 4.4 discusses broadcast links 363 and multicast packets. And Section 4.5 provides TRILL IS-IS Hello 364 SubNetwork Point of Attachment (SNPA) considerations for TRILL over 365 IP. 367 4.1 General Packet Formats 369 The on-the-wire form of a TRILL Data packet in transit between two 370 neighboring TRILL switch ports is as shown below: 372 +----------------+----------+----------------+-----------+ 373 | Link Header | TRILL | Native Frame | Link | 374 | for TRILL Data | Header | Payload | Trailer | 375 +----------------+----------+----------------+-----------+ 377 The encapsulated Native Frame Payload is similar to an Ethernet frame 378 with a VLAN tag or Fine Grained Label [RFC7172] but with no trailing 379 Frame Check Sequence (FCS). 381 TRILL IS-IS packets are formatted on-the-wire as follows: 383 +-----------------+---------------+-----------+ 384 | Link Header | TRILL IS-IS | Link | 385 | for TRILL IS-IS | Payload | Trailer | 386 +-----------------+---------------+-----------+ 388 The Link Header and Link Trailer in these formats depend on the 389 specific link technology. The Link Header contains one or more fields 390 that distinguish TRILL Data from TRILL IS-IS. For example, over 391 Ethernet, the Link Header for TRILL Data ends with the TRILL 392 Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS- 393 IS Ethertype; on the other hand, over PPP, there are no Ethertypes in 394 the Link Header but PPP protocol code points are included that 395 distinguish TRILL Data from TRILL IS-IS. 397 4.2 General TRILL Over IP Packet Formats 399 In TRILL over IP, we use an IP (v4 or v6) header followed by an 400 encapsulation header, such as UDP, as the link header. (On the wire, 401 the IP header will normally be preceded by the lower layer header of 402 a protocol that is carrying IP; however, this does not concern us at 403 the level of this document.) 405 There are multiple IP based encapsulations usable for TRILL over IP 406 that differ in exactly what appears after the IP header and before 407 the TRILL Header or the TRILL IS-IS Payload. Those encapsulations 408 specified in this document are further detailed in Section 5. In the 409 general specification below, those encapsulation fields will be 410 represented as "ENCAP Hdr". 412 4.2.1 Without Security 414 When TRILL over IP link security is not being used, a TRILL over IP 415 packet on the wire looks like one of the following: 417 TRILL Data Packet 418 +---------+-----------+---------+------------------+ 419 | IP | ENCAP Hdr | TRILL | Native frame | 420 | Header | for Data | Header | Payload | 421 +---------+-----------+---------+------------------+ 422 <--- link header ----> 424 TRILL IS-IS Packet 425 +---------+-----------+-----------------+ 426 | IP | ENCAP Hdr | TRILL IS-IS | 427 | Header | for IS-IS | Payload | 428 +---------+-----------+-----------------+ 429 <--- link header ----> 431 As discussed above and further specified in Section 5, the ENCAP Hdr 432 indicates whether the packet is TRILL Data or IS-IS. 434 4.2.2 With Security 436 TRILL over IP link security uses IPsec Encapsulating Security 437 Protocol (ESP) in tunnel mode [RFC4303]. Since TRILL over IP always 438 starts with an IP Header (on the wire this appears after any lower 439 layer header that might be required), the modifications for IPsec are 440 independent of the TRILL over IP ENCAP Hdr that occurs after that IP 441 Header. The resulting packet formats are as follows for IPv4 and 442 IPv6: 444 With IPv4: 445 +-------------+-----+--------------+-----------+-----------+ 446 | new IP Hdr | ESP | TRILL IP Hdr | ENCAP Hdr | ESP |ESP| 447 |(any options)| Hdr | (any options)| + payload |Trailer|ICV| 448 +-------------+-----+--------------+-----------+-----------+ 449 |<---------- encryption ---------->| 450 |<-------------- integrity ------------->| 452 With IPv6: 453 +------+-------+-----+------+--------+-----------+-------+---+ 454 | new |new ext| ESP | orig |orig ext| ENCAP Hdr | ESP |ESP| 455 |IP Hdr| Hdrs | Hdr |IP Hdr| Hdrs | + payload |Trailer|ICV| 456 +------+-------+-----+------+--------+-----------+-------+---+ 457 |<----------- encryption ---------->| 458 |<--------------- integrity ------------->| 460 As shown above, IP Header options are considered part of the IPv4 461 Header but are extensions ("ext") of the IPv6 Header. For further 462 information on the IPsec ESP Hdr, Trailer, and ICV, see [RFC4303] and 463 Section 7 below. "ENCAP Hdr + payload" is the encapsulation header 464 (Section 5) and TRILL data or the encapsulation header and IS-IS 465 payload, that is, the material after the IP Header in the diagram in 466 Section 4.2.1. 468 This architecture permits the ESP tunnel end point to be separated 469 from the TRILL over IP RBridge port (see, for example, Section 1.1.3 470 of [RFC7296]). 472 4.3 QoS Considerations 474 In IP, QoS handling is indicated by the Differentiated Services Code 475 Point (DSCP [RFC2474] [RFC3168]) in the IP Header. The former Type 476 of Service (TOS) octet in the IPv4 Header and the Traffic Class octet 477 in the IPv6 Header have been divided as shown in the following 478 diagram adapted from [RFC3168]. (TRILL support of ECN is beyond the 479 scope of this document. See [TRILLECN].) 481 0 1 2 3 4 5 6 7 482 +-----+-----+-----+-----+-----+-----+-----+-----+ 483 | DSCP FIELD | ECN FIELD | 484 +-----+-----+-----+-----+-----+-----+-----+-----+ 486 DSCP: Differentiated Services Codepoint 487 ECN: Explicit Congestion Notification 489 Although recommendations are provided below for mapping from TRILL 490 priority to DSCP, behavior for various DSCP values on the general 491 Internet is not predictable. The default mapping below are 492 appropriate where the TRILL campus is under the control of a network 493 manager or consists of islands connected by an Internet Service 494 Provider where that manager and/or provider support the DSCPs below 495 to provide the QoS indicated. 497 Within a TRILL switch, priority is indicated by configuration for 498 TRILL IS-IS packets and for TRILL Data packets by a three bit (0 499 through 7) priority field and a Drop Eligibility Indicator bit (see 500 Sections 8.2 and 7 of [RFC7780]). (Typically TRILL IS-IS is 501 configured to use the highest two priorities depending on the IS-IS 502 PDU.) The priority affects queuing behavior at TRILL switch ports and 503 may be encoded into the link header, particularly if there could be 504 priority sensitive devices within the link. For example, if the link 505 is a bridged LAN, it is commonly encoded into an Outer.VLAN tag's 506 priority and DEI fields. 508 TRILL over IP implementations MUST support setting the DSCP value in 509 the outer IP Header of TRILL packets they send by mapping the TRILL 510 priority and DEI to the DSCP. They MAY support, for a TRILL Data 511 packet where the native frame payload is an IP packet, mapping the 512 DSCP in this inner IP packet to the outer IP Header with the default 513 for that mapping being to copy the DSCP without change. 515 The default TRILL priority and DEI to DSCP mapping, which may be 516 configured per TRILL over IP port, is an follows. Note that the DEI 517 value does not affect the default mapping and, to provide a 518 potentially lower priority service than the default priority 0, 519 priority 1 is considered lower priority than 0. So the priority 520 sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. 522 TRILL Priority DEI DSCP Field (Binary/decimal) 523 -------------- --- ----------------------------- 524 0 0/1 001000 / 8 525 1 0/1 000010 / 0 526 2 0/1 010000 / 16 527 3 0/1 011000 / 24 528 4 0/1 100000 / 32 529 5 0/1 101000 / 40 530 6 0/1 110000 / 48 531 7 0/1 111000 / 56 533 The above all follow the recommended DSCP values from [RFC2474] 534 except for the placing of priority 1 below priority 0, as specified 535 in [802.1Q], and for the DSCP value of 000010 binary for low effort 536 as recommended in [LEphb]. 538 4.4 Broadcast Links and Multicast Packets 540 TRILL supports broadcast links. These are links to which more than 541 two TRILL switch ports can be attached and where a packet can be 542 broadcast or multicast from a port to all or a subset of the other 543 ports on the link as well as unicast to a specific other port on the 544 link. 546 As specified in [RFC6325], TRILL Data packets being forwarded between 547 TRILL switches can be unicast on a link to a specific TRILL switch 548 port or multicast on a link to all TRILL switch ports. TRILL IS-IS 549 packets are always multicast to all other TRILL switches on the link 550 except for IS-IS MTU PDUs, which may be unicast [RFC7177]. This 551 distinction is not significant if the link is inherently point-to- 552 point, such as a PPP link; however, on a broadcast link there will be 553 a packet outer link address that will be unicast or multicast as 554 appropriate. For example, over Ethernet links, the Ethernet multicast 555 addresses All-RBridges and All-IS-IS-RBridges are used for 556 multicasting TRILL Data and TRILL IS-IS respectively. For details on 557 TRILL over IP handling of multicast, see Section 6. 559 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment 561 IS-IS routers, including TRILL switches, establish adjacency through 562 the exchange of Hello PDUs on a link [RFC7176] [RFC7177]. The Hellos 563 transmitted out a port indicate what neighbor ports that port can see 564 on the link by listing what IS-IS refers to as the neighbor port's 565 SubNetwork Point of Attachment (SNPA). (For an Ethernet link, which 566 may be a bridged network, the SNPA is the port MAC address.) 568 In TRILL Hello PDUs on a TRILL over IP link, the IP addresses of the 569 IP ports connected to that link are their actual SNPA (SubNetwork 570 Point of Attachment [IS-IS]) addresses and, for IPv6, the 16-byte 571 IPv6 address is used as the SNPA; however, for easy in re-using code 572 designed for the common case of 48-bit SNPAs, in TRILL over IPv4 a 573 48-bit synthetic SNPA that looks like a unicast MAC address is 574 constructed for use in the SNPA field of TRILL Neighbor TLVs 575 [RFC7176] [RFC7177] in such Hellos. This synthetic SNPA is derived 576 from the port IPv4 address is as follows: 578 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 579 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 580 | 0xFE | 0x00 | 581 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 582 | IPv4 upper half | 583 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 584 | IPv4 lower half | 585 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 586 This synthetic SNPA (MAC) address has the local (0x02) bit on in the 587 first byte and so cannot conflict with any globally unique 48-bit 588 Ethernet MAC. However, when TRILL operates on an IP link, TRILL sees 589 only IP addresses on that link, not MAC stations, even if the TRILL 590 over IP Link is being carried over Ethernet. Therefore conflict on 591 the link between a real MAC address and a TRILL over IP synthetic 592 SNPA (MAC) address would be impossible in any case. 594 5. TRILL over IP Encapsulation Formats 596 There are a variety of TRILL over IP encapsulation formats possible. 597 By default TRILL over IP adopts a hybrid encapsulation approach. 599 There is one format, called "native encapsulation" that MUST be 600 implemented. Although native encapsulation does not typically have 601 good fast path support, as a lowest common denominator it can be used 602 by low bandwidth control traffic to determine a preferred 603 encapsulation with better performance. In particular, by default, all 604 TRILL IS-IS Hellos are sent using native encapsulation and those 605 Hellos are used to determine the encapsulation used for all TRILL 606 Data packets and all other TRILL IS-IS PDUs (with the exception of 607 IS-IS MTU-probe and MTU-ack PDUs used to establish adjacency which 608 also use native encapsulation by default). 610 Alternatively, the network operator can pre-configure a TRILL over IP 611 port to use a particular encapsulation chosen for their particular 612 network's needs and port capabilities. That encapsulation is then 613 used for all TRILL Data and IS-IS packets, including Hellos, on ports 614 so configured. This is expected to frequently be the case for a 615 managed campus of TRILL switches. 617 Section 5.1 discusses general consideration for the TRILL over IP 618 encapsulation format. Section 5.2 discusses encapsulation agreement. 619 Section 5.3 discusses broadcast link encapsulation considerations. 620 The subsequent subsections discuss particular encapsulations. 622 5.1 Encapsulation Considerations 624 An encapsulation must provide a method to distinguish TRILL Data 625 packets and TRILL IS-IS packets or it is not useful for TRILL. In 626 addition, the following criteria can be helpful is choosing between 627 different encapsulations: 629 a) Fast path support - For most applications, it is highly desirable 630 to be able to encapsulate/decapsulate TRILL over IP at line speed 631 so a format where existing or anticipated fast path hardware can 632 do that is best. This is commonly the dominant consideration. 634 b) Ease of multi-pathing - The IP path between TRILL over IP ports 635 may include equal cost multipath routes internal to the IP link so 636 a method of encapsulation that provides variable fields available 637 for existing or anticipated fast path hardware multi-pathing is 638 preferred. 640 c) Robust fragmentation and re-assembly - Fragmentation should 641 generally be avoided; however, the MTU of the IP link may require 642 fragmentation in which case an encapsulation with robust 643 fragmentation and re-assembly is important. There are known 644 problems with IPv4 fragmentation and re-assembly [RFC6864] which 645 generally do not apply to IPv6. Some encapsulations can fix these 646 problems but the encapsulations specified in this document do not. 647 Therefore, if fragmentation is anticipated with the encapsulations 648 specified in this document, the use of IPv6 is RECOMMENDED. 650 d) Checksum strength - Depending on the particular circumstances of 651 the TRILL over IP link, a checksum provided by the encapsulation 652 may be a significant factor. Use of IPsec can also provide a 653 strong integrity check. 655 5.2 Encapsulation Agreement 657 TRILL Hellos sent out a TRILL over IP port indicate the 658 encapsulations that port is willing to support through a mechanism 659 initially specified in [RFC7178] and [RFC7176] that is hereby 660 extended. Specifically, RBridge Channel Protocol numbers 0xFD0 661 through 0xFF7 are redefined to be link technology dependent flags 662 that, for TRILL over IP, indicate support for different 663 encapsulations, allowing support for up to 40 encapsulations to be 664 specified. Support for an encapsulation is indicated in the Hello 665 PDU in the same way that support for an RBridge Channel protocol was 666 indicated. (See also section 11.3.) "Support" indicates willingness 667 to use that encapsulation for TRILL Data and TRILL IS-IS packets 668 (although TRILL IS-IS Hellos are still sent in native encapsulation 669 by default unless the port is configured to always use some other 670 encapsulation). 672 If, in a TRILL Hello on a TRILL over IP link, support is not 673 indicated for any encapsulation, then the port from which it was sent 674 is assumed to support only native encapsulation (see Section 5.4). 676 An adjacency can be formed between two TRILL over IP ports if the 677 intersection of the sets of encapsulation methods they support is not 678 null. If that intersection is null, then no adjacency is formed. In 679 particular, for a TRILL over IP link, the adjacency state machine 680 MUST NOT advance to the Report state unless the ports share an 681 encapsulation [RFC7177]. If no encapsulation is shared, the adjacency 682 state machine remains in the state from which it would otherwise have 683 transitioned to the Report state. 685 If a TRILL over IP port is using an encapsulation different from that 686 in which Hellos are being exchanged, it is RECOMMENDED that BFD 687 [RFC7175] or some other protocol that confirms adjacency using TRILL 688 Data packets be used. As provided in [RFC7177] adjacency is not 689 actually obtained until such confirmatory protocol succeeds. 691 If any TRILL over IP packet, other than an IS-IS Hello or MTU PDU in 692 native encapsulation, is received in an encapsulation for which 693 support is not being indicated by the receiver, that packet MUST be 694 discarded (see Section 5.3). 696 If there are two or more encapsulations in common between two 697 adjacent ports for unicast or the set of adjacent ports for 698 multicast, a transmitter is free to choose whichever of the 699 encapsulations it wishes to use. Thus transmissions between adjacent 700 ports P1 and P2 could use different encapsulations depending on which 701 port is transmitting and which is receiving, that is to say they 702 could be asymmetric. 704 It is expected to be the normal case in a well-configured network 705 that all the TRILL over IP ports connected to an IP link (i.e., an IP 706 network) that are intended to communicate with each other will 707 support the same encapsulation(s). 709 5.3 Broadcast Link Encapsulation Considerations 711 To properly handle TRILL protocol packets on a TRILL over IP link in 712 the general case, either native IP multicast mode is used on that 713 link or multicast must be simulated using serial IP unicast, as 714 discussed in Section 6. (Of course, if the IP link happens to 715 actually be point-to-point no special provision is needed for 716 handling IP multicast addressed packets.) 718 It is possible for the Hellos from a TRILL over IP port P1 to 719 establish adjacency with multiple other TRILL over IP ports (P2, P3, 720 ...) on a broadcast link. In a well-configured network one would 721 expect all of the IP ports involved to support the same 722 encapsulation(s); but, for example, if P1 supports multiple 723 encapsulations, it is possible that P2 and P3, do not have an 724 encapsulation in common that is supported by P1. [IS-IS] can handle 725 such non-transitive adjacencies that are reported as specified in 726 [RFC7177]. This is generally done, albeit with reduced efficiency, by 727 forwarding through the designated RBridge (router) on the link. Thus 728 it is RECOMENDED that all TRILL over IP ports on an IP link be 729 configured to support one encapsulation in common that has good fast 730 path support. 732 If serial IP unicast is being used by P1, it can use different 733 encapsulations for different transmissions. 735 If native IP multicast is available for use by P1, it can send one 736 transmission per encapsulation method by which it has a disjoint set 737 of adjacencies on the link. If the transmitting port has adjacencies 738 with overlapping sets of ports that are adjacent using different 739 encapsulations, use of native multicast with different encapsulations 740 may result in packet duplication. It would always be possible to use 741 native IP multicast for one encapsulation or multiple encapsulations 742 supported by non-overlapping sets of receiving ports for which the 743 transmitting port has adjacencies, perhaps the encapsulation(s) for 744 which it has the largest number of adjacencies, and serially unicast 745 to other receivers. These considerations are the reason that a TRILL 746 over IP port MUST discard any packet received with an encapsulation 747 for which it has not established an adjacency with the transmitter. 748 Otherwise, packets would be further duplicated. 750 5.4 Native Encapsulation 752 The mandatory to implement "native encapsulation" format of a TRILL 753 over IP packet, when used without security, is TRILL over UDP as 754 shown below. This provides simple and direct access by TRILL to the 755 native datagram service of IP. 757 +----------+--------+-----------------------+ 758 | IP | UDP | TRILL | 759 | Header | Header | Payload | 760 +----------+--------+-----------------------+ 762 Where the UDP Header is as follows: 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Source Port = Entropy | Destination Port | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | UDP Length | UDP Checksum | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | TRILL Payload ... 773 Source Port - see Section 8.3. 775 Destination Port - indicates TRILL Data or IS-IS, see Section 776 11.1. 778 UDP Length - as specified in [RFC0768]. 780 UDP Checksum - as specified in [RFC0768]. Zero checksum MAY be 781 used if the requirements in [RFC6936] are met. tbd (see Section 782 6.2 of RFC 8086 as an example) 784 The TRILL Payload starts with the TRILL Header (not including the 785 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 786 Intradomain Routeing Protocol Discriminator byte (thus not including 787 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 789 5.5 VXLAN Encapsulation 791 VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, like 792 TRILL over Ethernet over VXLAN over UDP over IP. 794 +--------+--------+--------+----------+-----------+ 795 | IP | UDP | VXLAN | Ethernet | TRILL | 796 | Header | Header | Header | Header | Payload | 797 +--------+--------+--------+----------+-----------+ 799 The outer UDP uses a destination port number indicating VXLAN and the 800 outer UDP source port MAY be used for entropy as with native 801 encapsulation (see Section 8.3). The VXLAN header after the outer UDP 802 header adds a 24 bit Virtual Network Identifier (VNI). The Ethernet 803 header after the VXLAN header and before the TRILL header consists of 804 source MAC address, destination MAC address, and Ethertype. The 805 Ethertype distinguishes TRILL Data from TRILL IS-IS. The destination 806 and source MAC addresses in this Ethernet header are not used. 808 Zero checksum MAY be used in the UDP Header as discussed in Section 809 5.4. 811 A TRILL over IP port using VXLAN encapsulation by default uses a VNI 812 of 1 for TRILL IS-IS traffic and a VNI of 2 for TRILL data traffic 813 but can be configured as described in Section 9.2.3.1 to use some 814 other fixed VNIs or to map from VLAN/FGL to VNI for data traffic. 816 5.6 TCP Enacpulstion 818 TCP may be used for TRILL over IP as specified below. Use of TCP is 819 convenient to provide congestion control (see Section 8.1) and 820 reduced packet loss but is likely to cause substantial additional 821 jitter and delay compared with a UDP based encapsulation. 823 TCP supports only unicast communication. Thus, when TCP encapsulation 824 is being used, multi-destination packets must be sent by serial 825 unicast. Neighborhood discovery cannot be done with TCP, so if 826 discovery is to be supported at a TRILL over IP port, Hellos must be 827 sent with UDP. If a TRILL over IP port is configured to use TCP 828 encapsulation for all trafic, a list of IP addresses that port might 829 communicate with must be configured for the port (see Section 9). 831 All packets in a particular TCP stream SHOULD use the same DSCP 832 codepoint or packet re-ordering may occur. Therefore a TCP connection 833 is needed per QoS to be provided between TRILL switches. Contiguous 834 sets of priority levels MAY be mapped into a single TCP connection 835 with a single DSCP code point. Lower priority traffic MUST NOT be 836 given preference over higher priority traffic. 838 TCP is a stream protocol, not a record oriented protocol, so a TRILL 839 data packet with its header or a TRILL IS-IS packet might be split 840 across multiple TCP packet payloads or a single TCP packet payload 841 could include multiple TRILL packets. Thus a framing mechanism is 842 needed, as specified below, so that a received TRILL stream can be 843 parsed into TRILL packets. 845 +----------+--------+-----------------------+ 846 | IP | TCP | Framed TRILL | 847 | Header | Header | Payload material | 848 +----------+--------+-----------------------+ 850 Where the TCP Header is as follows: 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Source Port | Destination Port | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Sequence Number | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Acknowledgment Number | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Data | |U|A|P|R|S|F| | 862 | Offset| Reserved |R|C|S|S|Y|I| Window | 863 | | |G|K|H|T|N|N| | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | TCP Checksum | Urgent Pointer | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Options | Padding | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Framed TRILL Payload material ... 871 Source Port - along with Source IP, Destination IP, and 872 Destination Port, idetifies TCP flow. 874 Destination Port - indicates TRILL Data or IS-IS, see Section 875 11.1. 877 Other TCP Header Fields - as specified in [RFC0793]. 879 TRILL packets are framed for transmission over TCP as shown below. 881 +--------+-------- // ----+ | Length | TRILL packet | 882 +--------+----- // -------+ 883 Length - the length of the TRILL packet in bytes as a 2-byte 884 unsigned integer in network order. 886 TRILL packet - The TRILL packet within framing starts with the 887 TRILL or the L2-IS-IS Ethertype (0x22F3 or 0x22F4). If the 888 initial 2 bytes of the TRILL packet are not one of these 889 Ethertypes, then the receiver assumes that framing 890 synchronization has been lost and MUST close the TCP 891 connection. 893 Depending on performance requirements, in most cases consideration 894 should be given to tuning TCP. Methods for doing this are out of 895 scope for this document but see ..., [RFC7323], tbd 897 5.7 Other Encapsulations 899 Additional TRILL over IP encapsulations may be specified in future 900 documents and allocated a link technology specific flag bit as per 901 Section 11.3. A primary consideration for whether it is worth the 902 effort to specify use of an encapsulation by TRILL over IP is whether 903 it has good existing or anticipated fast path support. 905 6. Handling Multicast 907 By default, both TRILL IS-IS packets and multi-destination TRILL Data 908 packets are sent with UDP to an All-RBridges IPv4 or IPv6 IP 909 multicast Address as appropriate (see Section 11.2); however, a TRILL 910 over IP port may be configured (see Section 9) to use a different 911 multicast address or to use serial IP unicast with a list of one or 912 more unicast IP addresses of other TRILL over IP ports to which 913 multi-destination packets are sent. In the serial unicast case the 914 outer IP header of each copy of the a TRILL Data packet sent shows an 915 IP unicast destination address even through the TRILL header has the 916 M bit set to one to indicate multi-destination. Serial unicast 917 configuration is necessary if the TRILL over IP port is connected to 918 an IP network that does not support IP multicast. In any case, 919 unicast TRILL Data packets (those with the M bit in the TRILL Header 920 set to zero) are sent by unicast IP. When TCP encapsulation is being 921 used (see Section 5.4), serial unicast MUST be used. If a TRILL over 922 IP port is configured to send all traffic with TCP, adjacency and 923 data flow will only be possible with a list of IP addresses 924 configured at that port (see Section 9). 926 Even if a TRILL over IP port is configured to send multi-destination 927 packets with serial unicast, it MUST be prepared to receive IP 928 multicast TRILL packets. All TRILL over IP ports default to 929 periodically transmitting appropriate IGMP (IPv4 [RFC3376]) or MLD 930 (IPv6 [RFC2710]) packets, so that the TRILL multicast IP traffic can 931 be sent to them, but MAY be configured not to do so. 933 Although TRILL fully supports broadcast links with more than 2 934 RBridges connected to the link, there may be good reasons for 935 configuring TRILL over IP ports to use serial unicast even where 936 native IP multicast is available. Use of serial unicast provides the 937 network manager with more precise control over adjacencies and how 938 TRILL over IP links will be formed in an IP network. In some 939 networks, unicast is more reliable than multicast. If multiple point- 940 to-point TRILL over IP connections between two parts of a TRILL 941 campus are configured, TRILL will in any case spread traffic across 942 them, treating them as parallel links, and appropriately fail over 943 traffic if a link fails or incorporate a new link that comes up. 945 7. Use of IPsec and IKEv2 947 All TRILL switches (RBridges) that support TRILL over IP MUST 948 implement IPsec [RFC4301] and support the use of IPsec Encapsulating 949 Security Protocol (ESP [RFC4303]) in tunnel mode to secure both TRILL 950 IS-IS and TRILL Data packets. When IPsec is used to secure a TRILL 951 over IP link and no IS-IS security is enabled, the IPsec session MUST 952 be fully established before any TRILL IS-IS or data packets are 953 exchanged. When there is IS-IS security [RFC5310] provided, 954 implementers SHOULD use IS-IS security to protect TRILL IS-IS 955 packets. However, in this case, the IPsec session still MUST be fully 956 established before any TRILL Data packets transmission, since IS-IS 957 security does not provide any protection to data packets, and SHOULD 958 be fully established before any TRILL IS-IS packet transmission other 959 than IS-IS Hello or MTU PDUs. 961 All RBridges that support TRILL over IP MUST implement the Internet 962 Key Exchange Protocol version 2 (IKEv2) for automated key management. 964 7.1 Keying 966 The following subsections discuss pairwise and group keying for TRILL 967 over IP IPsec. 969 7.1.1 Pairwise Keying 971 When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that 972 incorporates the IS-IS shared key in order to bind the TRILL data 973 session to the IS-IS session. The pre-shared key that will be used 974 for IKEv2 exchanges for TRILL over IP is determined as follows: 976 HKDF-Expand-SHA256 ( IS-IS-key, 977 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) 979 In the above "|" indicates concatenation, HKDF is as in [RFC5869], 980 SHA256 is as in [RFC6234], and "TRILL IP" is the eight byte US ASCII 981 [RFC0020] string indicated. "IS-IS-key" is an IS-IS key usable for 982 IS-IS security of link local IS-IS PDUs such as Hello, CSNP, and 983 PSNP. This SHOULD be a link scope IS-IS key. P1-System-ID and 984 P2-System ID are the six byte System IDs of the two TRILL RBridges, 985 and P1-Port and P2-Port are the TRILL Port IDs [RFC6325] of the ports 986 in use on each end. System IDs are guaranteed to be unique within the 987 TRILL campus. Both of the RBridges involved treat the larger 988 magnitude System ID, comparing System IDs as unsigned integers, as P1 989 and the smaller as P2 so both will derive the same key. 991 With [RFC5310] there could be multiple keys identified with 16-bit 992 key IDs. The key ID when an IS-IS key is in use is transmitted in an 993 IKEv2 ID_KEY_ID identity field [RFC7296] with Identification Data 994 length of 2 bytes (Payload Length 6 bytes). The Key ID of the IS-IS- 995 key is used to identify the IKEv2 shared secret derived as above that 996 is actually used. ID_KEY_ID identity field(s) of other lengths MAY 997 occur but their use is beyond the scope of this document. 999 The IS-IS-shared key from which the IKEv2 shared secret is derived 1000 might expire and be updated as described in [RFC5310]. The IKEv2 1001 pre-shared keys derived from an IS-IS shared key MUST expire within a 1002 lifetime no longer than the IS-IS-shared key from which they were 1003 derived. When the IKEv2 shared secret key expires, or earlier, the 1004 IKEv2 Security Association must be rekeyed using a new shared secret 1005 derived from a new IS-IS shared key. 1007 IKEv2 with certificate based security MAY be used but details of 1008 certificate contents and use policy for this application of IKEv2 are 1009 beyond the scope of this document. 1011 7.1.2 Group Keying 1013 In the case of a TRILL over IP port configured as point-to-point (see 1014 Section 4.2.4.1 of [RFC6325]), there is no group keying and the 1015 pairwise keying determined as in Section 7.1.1 is used for multi- 1016 destination TRILL traffic, which is unicast. 1018 In the case of a TRILL over IP port configured as broadcast but where 1019 the port is configured to use serial unicast (see Section 8), there 1020 is no group keying and the pairwise keying determined as in Section 1021 7.1.1 is used for multi-destination TRILL traffic, which is unicast. 1023 The case of a TRILL over IP port configured as broadcast and using 1024 native multicast is beyond the scope of this document. For security 1025 as provided in this document, multicast is handled via serial 1026 unicast. 1028 7.2 Mandatory-to-Implement Algorithms 1030 All RBridges that support TRILL over IP MUST implement IPsec ESP 1031 [RFC4303] in tunnel mode. The implementation requirements for ESP 1032 cryptographic algorithms are as specified for IPsec. That 1033 specification is currently [RFC8221]. 1035 8. Transport Considerations 1037 This section discusses a variety of important transport 1038 considerations. NAT traversal is out of scope for this document. 1040 8.1 Congestion Considerations 1042 This subsection discusses TRILL over UDP congestion considerations. 1043 These are applicable to the UDP based TRILL over IP encapsulation 1044 headers specified in detail in this document. Other encapsulations 1045 would likely have different congestion considerations and, in 1046 particlar, the TCP encapsulation specified in Section 5.6 does not 1047 need congestion control beyond that provided by TCP. Congestion 1048 considerations for additional TRILL encapsulations will be provided 1049 in the document specifying the encapsulation. 1051 One motivation for including UDP or TCP as the outermost part of a 1052 TRILL over IP encapsulation header is to improve the use of multipath 1053 such as Equal Cost Multi-Path (ECMP) in cases where traffic is to 1054 traverse routers that are able to hash on Port and IP address through 1055 addition of entropy in the source port (see Section 8.3). In many 1056 cases this may reduce the occurrence of congestion and improve usage 1057 of available network capacity. However, it is also necessary to 1058 ensure that the network, including applications that use the network, 1059 responds appropriately in more difficult cases, such as when link or 1060 equipment failures have reduced the available capacity. 1062 Section 3.1.11 of [RFC8085] discusses the congestion considerations 1063 for design and use of UDP tunnels; this is important because other 1064 flows could share the path with one or more UDP tunnels, 1065 necessitating congestion control [RFC2914] to avoid destructive 1066 interference. 1068 The default initial determination of the TRILL over IP encapsulation 1069 to be used is through the exchange of TRILL IS-IS Hellos. This is a 1070 low bandwidth process. Hellos are not permitted to be sent any more 1071 often than once per second, and so are very unlikely to cause 1072 congestion. Thus no additional controls are needed for Hellos even 1073 if sent, as is the default, over UDP. 1075 Congestion has potential impacts both on the rest of the network 1076 containing a UDP flow and on the traffic flows using the UDP 1077 encapsulation. These impacts depend upon what sort of traffic is 1078 carried in UDP, as well as the path it follows. The UDP based TRILL 1079 over IP encapsulations specified in this document do not provide any 1080 congestion control and are transmitted as regular UDP packets. 1082 The two subsections below discuss congestion for TRILL over IP 1083 traffic with UDP based encapsulation headers in traffic-managed 1084 controlled environments (TMCE, see [RFC8086]) and other environments. 1086 8.1.1 Within a TMCE 1088 Within a TMCE, that is, an IP network that is traffic-engineered 1089 and/or otherwise managed, for example via use of traffic rate 1090 limiters, to avoid congestion, UDP based TRILL over IP encapsulation 1091 headers are appropriate for carrying traffic that is not known to be 1092 congestion controlled. in such cases, operators of TMCE networks 1093 avoid congestion by careful provisioning of their networks, rate- 1094 limiting of user data traffic, and traffic engineering according to 1095 path capacity. 1097 When TRILL over IP using a UDP based encapsulation header carries 1098 traffic that is not known to be congestion controlled in a TMCE 1099 network, the traffic path MUST be entirely within that network, and 1100 measures SHOULD be taken to prevent the traffic from "escaping" the 1101 network to the general Internet. Examples of such measures are: 1103 o physical or logical isolation of the links carrying the traffic 1104 from the general Internet and 1106 o deployment of packet filters that block the UDP ports assigned 1107 for TRILL over IP. 1109 8.1.2 In Other Environments 1111 Where UDP based encapsulation headers are used in TRILL over IP in 1112 environments other than those discussed in Section 8.1.1, specific 1113 congestion control mechanisms are commonly needed. However, if the 1114 traffic being carried by the TRILL over IP link is already congestion 1115 controlled and the size and volatility of the TRILL IS-IS link state 1116 database is limited, then specific congestion control may not be 1117 needed. See [RFC8085] Section 3.1.11 for further guidance. 1119 8.2 Recursive Ingress 1121 TRILL is specified to transport data to and from end stations over 1122 Ethernet and IP is frequently transported over Ethernet. Thus, an end 1123 station native data Ethernet frame "EF" might get TRILL ingressed to 1124 TRILL(EF) that was subsequently sent to a next hop RBridge out a 1125 TRILL over IP over Ethernet port resulting in a packet on the wire of 1126 the form Ethernet(IP(TRILL(EF))). There is a risk of such a packet 1127 being re-ingressed by the same TRILL campus, due to physical or 1128 logical misconfiguration, looping round, being further re-ingressed, 1129 and so on. (Or this might occur through a cycle of TRILL campuses.) 1130 The packet would get discarded if it got too large but if 1131 fragmentation is enabled, it would just keep getting split into 1132 fragments that would continue to loop and grow and re-fragment until 1133 the path was saturated with junk and packets were being discarded due 1134 to queue overflow. The TRILL Header TTL would provide no protection 1135 because each TRILL ingress adds a new TRILL header with a new TTL. 1137 To protect against this scenario, a TRILL over IP port MUST, by 1138 default, test whether a TRILL packet it is about to transmit appears 1139 to be a TRILL ingress of a TRILL over IP over Ethernet packet. That 1140 is, is it of the form TRILL(Ethernet(IP(TRILL(...)))? If so, the 1141 default action of the TRILL over IP output port is to discard the 1142 packet rather than transmit it. However, there are cases where some 1143 level of nested ingress is desired so it MUST be possible to 1144 configure the port to allow such packets. 1146 8.3 Fat Flows 1148 For the purpose of load balancing, it is worthwhile to consider how 1149 to transport TRILL packets over any Equal Cost Multiple Paths (ECMPs) 1150 existing internal to the IP path between TRILL over IP ports. 1152 The ECMP election for the IP traffic could be based, for example with 1153 IPv4, on the quintuple of the outer IP header { Source IP, 1154 Destination IP, Source Port, Destination Port, and IP protocol }. 1155 Such tuples, however, could be exactly the same for all TRILL Data 1156 packets between two RBridge ports, even if there is a huge amount of 1157 data being sent between a variety of ingress and egress RBridges. One 1158 solution to this is to use the UDP Source Port as an entropy field. 1159 (This idea is also introduced in [RFC8086].) For example, for TRILL 1160 Data, this entropy field could be based on some hash of the 1161 Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.Label. These are 1162 fields from the TRILL data payload which looks like an Ethernet frame 1163 (see [RFC7172] Figures 1 and 2). Unfortunately, this can conflict 1164 with middleboxes inside the TRILL over IP link (see 8.5). Therefore, 1165 in order to better support ECMP, a RBridge SHOULD set the Source Port 1166 to a range of values as an entropy field for ECMP decisions; this 1167 range SHOULD be the ephemeral port range (49152-65535) except that, 1168 if there are middleboxes in the path (see Section 8.5), it MUST be 1169 possible to configure the range of different Source Port values to a 1170 sufficiently small range to avoid disrupting connectivity. 1172 8.4 MTU Considerations 1174 In TRILL each RBridge advertises in its LSP number zero the largest 1175 LSP frame it can accept (but not less than 1,470 bytes) on any of its 1176 interfaces (at least those interfaces with adjacencies to other TRILL 1177 switches in the campus) through the originatingLSPBufferSize TLV 1178 [RFC6325] [RFC7177]. The campus minimum MTU (Maximum Transmission 1179 Unit), denoted Sz, is then established by taking the minimum of this 1180 advertised MTU for all RBridges in the campus. Links that cannot 1181 support the Sz MTU are not included in the routing topology. This 1182 protects the operation of IS-IS from links that would be unable to 1183 accommodate the largest LSPs. 1185 A method of determining originatingLSPBufferSize for an RBridge with 1186 one or more TRILL over IP ports is described in [RFC7780]. However, 1187 if a TRILL over IP port either (1) can accommodate jumbo frames, (2) 1188 is a link on which IP fragmentation is enabled and acceptable, or (3) 1189 is configure to use TCP encapsulation for all packets, then it is 1190 unlikely that the port will be a constraint on the 1191 originatingLSPBufferSize of the RBridge with that port. On the other 1192 hand, if the TRILL over port can only handle smaller frames, a UDP 1193 encapsulaton is in use at least for Hellos, and fragmentation is to 1194 be avoided when possible, a TRILL over IP port might constrain the 1195 RBridge's originatingLSPBufferSize. 1197 Because TRILL sets the minimum value of Sz at 1,470 bytes, RBridges 1198 will not constrain LSPs or other TRILL IS-IS PDUs to a size smaller 1199 than that. Therefore there may be TRILL over IP ports that require 1200 that either fragmentation be enabled or that TCP base encapsultion 1201 for all TRILL packet be used if TRILL communication over that IP port 1202 is desired. When fragmentation is enabled or TCP is in use, the 1203 effective link MTU from the TRILL point of view is larger than the 1204 RBridge port to RBridge port path MTU from the IP point of view. Path 1205 MTU discovery [RFC4821] should be useful in determining the IP MTU 1206 between a pair of RBridge ports with IP connectivity. 1208 TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in 1209 [RFC7177], MUST NOT be fragmented and can be used to obtain added 1210 assurance of the MTU of a link. This is also discussed in [RFC8249] 1211 An appropriate time to confirm MTU, or re-discover it if it has 1212 changed, is when an RBridge notices topology changes in a path that 1213 is in use for TRILL over IP due to LSP updates it receives; however, 1214 MTU can change at other times. For example, two RBridge ports are 1215 connected by a bridged LAN, topology or configuration changes within 1216 that bridged LAN could change the MTU between those RBridge ports. 1218 For further discussion of these issues, see [IntareaTunnels]. 1220 9. TRILL over IP Port Configuration 1222 This section specifies the configuration information needed at a 1223 TRILL over IP port beyond that needed for a general RBridge port. 1225 9.1 Per IP Port Configuration 1227 Each RBridge port used for a TRILL over IP link should have at least 1228 one IP (v4 or v6) address. If no IP address is associated with the 1229 port, perhaps as a transient condition during re-configuration, the 1230 port is disabled. Implementations MAY allow a single port to operate 1231 as multiple IPv4 and/or IPv6 logical ports. Each IP address 1232 constitutes a different logical port and the RBridge with those ports 1233 MUST associate a different Port ID (see Section 4.4.2 of [RFC6325]) 1234 with each logical port. 1236 By default a TRILL over IP port discards output packets that fail the 1237 possible recursive ingress test (see Section 10.1) unless configured 1238 to disable that test. 1240 9.2 Additional per IP Address Configuration 1242 The configuration information specified below is per TRILL over IP 1243 port IP address. 1245 The mapping from TRILL packet priority to TRILL over IP 1246 Differentiated Services Code Point (DSCP [RFC2474]) can be 1247 configured. If supported, mapping from an inner DSCP code point, when 1248 the TRILL payload is IP, to the outer TRILL over IP DSCP can be 1249 configured. (See Section 4.3.) 1251 Each TRILL over IP port has a list of acceptable encapsulations it 1252 will use as the basis of adjacency. By default this list consists of 1253 one entry for native encapsulation (see Section 7). Additional 1254 encapsulations MAY be configured and native encapsulation MAY be 1255 removed from this list by configuration. Additional configuration can 1256 be required or possible for specific encapsulations as described in 1257 Section 9.2.3. 1259 Each IP address at a TRILL over IP port uses native IP multicast by 1260 default but may be configured whether to use serial IP unicast 1261 (Section 9.2.2) or native IP multicast (Section 9.2.1). Each IP 1262 address at a TRILL over IP is configured whether or not to use IPsec 1263 (Section 9.2.4). 1265 Regardless of whether they will send IP multicast, TRILL over IP 1266 ports emit appropriate IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710]) 1267 packets unless configured not to do so. These are sent for the IP 1268 multicast group the port would use if it sent IP multicast. 1270 9.2.1 Native Multicast Configuration 1272 If a TRILL over IP port address is using native IP multicast for 1273 multi-destination TRILL packets (IS-IS and data), by default 1274 transmissions from that IP address use the IP multicast address (IPv4 1275 or IPv6) specified in Section 11.2. The TRILL over IP port may be 1276 configured to use a different IP multicast address for multicasting 1277 packets. 1279 9.2.2 Serial Unicast Configuration 1281 If a TRILL over IP port address has been configured to use serial 1282 unicast for multi-destination packets (IS-IS and data), it should 1283 have associated with it a non-empty list of unicast IP destination 1284 addresses with the same IP version as the version of the port's IP 1285 address (IPv4 or IPv6). Multi-destination TRILL packets are serially 1286 unicast to the addresses in this list. Such a TRILL over IP port will 1287 only be able to form adjacencies [RFC7177] with the RBridges at the 1288 addresses in this list as those are the only RBridges to which it 1289 will send TRILL Hellos. IP packets received from a source IP address 1290 not on the list are discarded. 1292 If this list of destination IP addresses is empty, the port is 1293 disabled. 1295 9.2.3 Encapsulation Specific Configuration 1297 Specific TRILL over IP encapsulation methods may provide for further 1298 configuration as specified below. 1300 9.2.3.1 UDP Source Port 1302 As discussed above, the UDP based encapsulations (Sections 5.4 and 1303 5.5) start with a header containing a source port number that can be 1304 used for entropy (Section 8.3). The range of source port values used 1305 defaults to the ephemeral port range (49152-65535) but can be 1306 configured to any other range including to a single value. 1308 9.2.3.2 VXLAN Configuration 1310 A TRILL over IP port using VXLAN encapsulation can be configured with 1311 non-default VXLAN Network Identifiers (VNIs) that are used in that 1312 field of the VXLAN header for all TRILL IS-IS and TRILL Data packets 1313 sent using the encapsulation and required in those received using the 1314 encapsulation. The default VNI is 1 for TRILL IS-IS and 2 for TRILL 1315 Data. A TRILL packet received with the an unknown VNI is discarded. 1317 A TRILL over IP port using VXLAN encapsulation can also be configured 1318 to map the Inner.VLAN of a TRILL Data packet being transported to the 1319 value it places in the VNI field and/or to copy the Inner.FGL 1320 [RFC7172] of a TRILL Data packet to the VNI field. 1322 9.2.3.3 Other Encapsulation Configuration 1324 Additional encapsulation methods, beyond those specified in this 1325 document, are expected to be specified in future documents and may 1326 require further configuration. 1328 9.2.4 Security Configuration 1330 A TRILL over IP port can be configured, for the case where IS-IS 1331 security [RFC5310] is in use, as to whether or not IPsec must be 1332 fully established and used for any TRILL IS-IS transmissions other 1333 than IS-IS Hello or MTU PDUs (see Section 7). There may also be 1334 configuration whose details are outside the scope of this document 1335 concerning certificate based IPsec or use of shared keys other than 1336 IS-IS based shared key or how to select what IS-IS based shared key 1337 to use. 1339 10. Security Considerations 1341 TRILL over IP is subject to all of the security considerations for 1342 the base TRILL protocol [RFC6325]. In addition, there are specific 1343 security requirements for different TRILL deployment scenarios, as 1344 discussed in the "Use Cases for TRILL over IP", Section 3 above. 1346 For communication between end stations in a TRILL campus, security 1347 may be possible at three levels: end-to-end security between those 1348 end stations, edge-to-edge security between ingress and egress 1349 RBridges, and link security to protect a TRILL hop. Any combination 1350 of these can be used, including all three. 1352 TRILL over IP link security protects the contents of TRILL Data and 1353 IS-IS packets, including the identities of the end stations for 1354 data and the identities of the edge RBridges, from observers of 1355 the link and transit devices within the link such as bridges or IP 1356 routers, but does not encrypt the link local IP addresses used in 1357 a packet and does not protect against observation by the sending 1358 and receiving RBridges on the link. 1360 Edge-to-edge TRILL security would protect the contents of TRILL data 1361 packets including the identities of the end stations for data from 1362 transit RBridges but does not encrypt the identities of the edge 1363 RBridges involved and does not protect against observation by 1364 those edge RBridges. Edge-to-edge TRILL security may be covered in 1365 future documents. 1367 End-to-end security does not protect the identities of the end 1368 stations or edge RBridge involved but does protect the content of 1369 TRILL data packets from observation by all RBridges or other 1370 intervening devices between the end stations involved. End-to-end 1371 security should always be considered as an added layer of security 1372 to protect any particularly sensitive information from unintended 1373 disclosure. Such end station to end station security is generally 1374 beyond the scope of TRILL 1376 If VXLAN encapsulation is used, the unused Ethernet source and 1377 destination MAC addresses mentioned in Section 5.5, provide a 96 bit 1378 per packet side channel. 1380 10.1 IPsec 1382 This document specifies that all RBridges that support TRILL over IP 1383 links MUST implement IPsec for the security of such links, and makes 1384 it clear that it is both wise and good to use IPsec in all cases 1385 where a TRILL over IP link will traverse a network that is not under 1386 the same administrative control as the rest of the TRILL campus or is 1387 not secure. IPsec is important, in these cases, to protect the 1388 privacy and integrity of data traffic. However, in cases where IPsec 1389 is impractical due to lack of fast path support, use of TRILL edge- 1390 to-edge security or use by the end stations of end-to-end security 1391 can provide significant security. 1393 Further Security Considerations for IPsec ESP and for the 1394 cryptographic algorithms used with IPsec can be found in the RFCs 1395 referenced by this document. 1397 10.2 IS-IS Security 1399 TRILL over IP is compatible with the use of IS-IS Security [RFC5310], 1400 which can be used to authenticate TRILL switches before allowing them 1401 to join a TRILL campus. This is sufficient to protect against rogue 1402 devices impersonating TRILL switches, but is not sufficient to 1403 protect data packets that may be sent in TRILL over IP outside of the 1404 local network or across the public Internet. To protect the privacy 1405 and integrity of that traffic, use IPsec. 1407 In cases were IPsec is used, the use of IS-IS security may not be 1408 necessary, but there is nothing about this specification that would 1409 prevent using both IPsec and IS-IS security together. 1411 11. IANA Considerations 1413 IANA considerations are given below. 1415 11.1 Port Assignments 1417 IANA is requested to assign destination Ports in the Service Name and 1418 Transport Protocol Port Number Registry [PortRegistry] for TRILL IS- 1419 IS and TRILL Data as shown below. 1421 Service Name: TRILL-IS-IS 1422 Transport Protocol: udp, tcp 1423 Assignee: iesg@ietf.org 1424 Contact: chair@ietf.org 1425 Description: Transport of TRILL IS-IS control PDUs. 1426 Reference: [this document] 1427 Port Number: (TBD1) 1429 Service Name: TRILL-data 1430 Transport Protocol: udp, tcp 1431 Assignee: iesg@ietf.org 1432 Contact: chair@ietf.org 1433 Description: Transport of TRILL Data packets. 1434 Reference: [this document] 1435 Port Number: (TBD2) 1437 11.2 Multicast Address Assignments 1439 IANA is requested to assign one IPv4 and one IPv6 multicast address, 1440 as shown below, which correspond to both the All-RBridges and All-IS- 1441 IS-RBridges multicast MAC addresses that have been assigned for 1442 TRILL. Because the low level hardware MAC address dispatch 1443 considerations for TRILL over Ethernet do not apply to TRILL over IP, 1444 one IP multicast address for each version of IP is sufficient. 1446 (Values recommended to IANA in square brackets) 1448 Name IPv4 IPv6 1449 ------------ ------------------ -------------------------- 1450 All-RBridges TBD3[233.252.1.32] TBD4[FF0X:0:0:0:0:0:0:BAC1] 1452 The hex digit "X" in the IPv6 variable scope address indicates the 1453 scope and defaults to 8. The IPv6 All-RBridges IP address may be used 1454 with other values of X. 1456 11.3 Encapsulation Method Support Indication 1458 The existing "RBridge Channel Protocols" registry is re-named and a 1459 new sub-registry under that registry added as follows: 1461 The TRILL Parameters registry for "RBridge Channel Protocols" is 1462 renamed the "RBridge Channel Protocols and Link Technology Specific 1463 Flags" registry. [this document] is added as a second reference for 1464 this registry. The first part of the table is changed to the 1465 following: 1467 Range Registration Note 1468 ----------- ---------------- ---------------------------- 1469 0x002-0x0FF Standards Action 1470 0x100-0xFCF RFC Required allocation of a single value 1471 0x100-0xFCF IESG Approval allocation of multiple values 1472 0xFD0 0xFF7 see Note link technology dependent, 1473 see subregistry 1475 In the existing table of RBridge Channel Protocols, the following 1476 line is changed to two lines as shown: 1478 OLD 1479 0x004-0xFF7 Unassigned 1480 NEW 1481 0x004-0xFCF Unassigned 1482 0xFD0-0xFF7 (link technology dependent, see subregistry) 1484 A new indented subregistry under the re-named "RBridge Channel 1485 Protocols and Link Technology Specific Flags" registry is added as 1486 follows: 1488 Name: TRILL over IP Link Flags 1489 Registration Procedure: Expert Review 1490 Reference: [this document] 1492 Flag Meaning Reference 1493 ----------- ------------------------------ --------- 1494 0xFD0 Native encapsulation supported [this document] 1495 0xFD1 VXLAN encapsulation supported [this document] 1496 oxFD2 TCP encapsulation supported [this document] 1497 0xFD3-0xFF7 Unassigned 1499 Normative References 1501 [IS-IS] - "Intermediate system to Intermediate system routeing 1502 information exchange protocol for use in conjunction with the 1503 Protocol for providing the Connectionless-mode Network Service 1504 (ISO 8473)", ISO/IEC 10589:2002, 2002". 1506 [RFC0020] - Cerf, V., "ASCII format for network interchange", STD 80, 1507 RFC 20, DOI 10.17487/RFC0020, October 1969, . 1510 [RFC0768] - Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1511 10.17487/RFC0768, August 1980, . 1514 [RFC0793] - Postel, J., "Transmission Control Protocol", STD 7, RFC 1515 793, DOI 10.17487/RFC0793, September 1981, . 1518 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1519 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1520 March 1997, . 1522 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 1523 "Definition of the Differentiated Services Field (DS Field) in 1524 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 1525 December 1998, . 1527 [RFC2710] - Deering, S., Fenner, W., and B. Haberman, "Multicast 1528 Listener Discovery (MLD) for IPv6", RFC 2710, DOI 1529 10.17487/RFC2710, October 1999, . 1532 [RFC2914] - Floyd, S., "Congestion Control Principles", BCP 41, RFC 1533 2914, DOI 10.17487/RFC2914, September 2000, . 1536 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1537 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 1538 10.17487/RFC3168, September 2001, . 1541 [RFC3376] - Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1542 Thyagarajan, "Internet Group Management Protocol, Version 3", 1543 RFC 3376, DOI 10.17487/RFC3376, October 2002, . 1546 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1547 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1548 2005, . 1550 [RFC4303] - Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1551 4303, DOI 10.17487/RFC4303, December 2005, . . 1555 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1556 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1557 5310, DOI 10.17487/RFC5310, February 2009, . 1560 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 1561 Expand Key Derivation Function (HKDF)", RFC 5869, DOI 1562 10.17487/RFC5869, May 2010, . 1565 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1566 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1567 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1568 . 1570 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 1571 "Transparent Interconnection of Lots of Links (TRILL): 1572 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 1573 DOI 10.17487/RFC7175, May 2014, . 1576 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1577 D., and A. Banerjee, "Transparent Interconnection of Lots of 1578 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 1579 May 2014, . 1581 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1582 and V. Manral, "Transparent Interconnection of Lots of Links 1583 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 1584 . 1586 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1587 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1588 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 1589 2014, . 1591 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1592 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1593 eXtensible Local Area Network (VXLAN): A Framework for 1594 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 1595 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 1598 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 1599 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 1600 Lots of Links (TRILL): Clarifications, Corrections, and 1601 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 1602 . 1604 [RFC8221] - Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 1605 Kivinen, "Cryptographic Algorithm Implementation Requirements 1606 and Usage Guidance for Encapsulating Security Payload (ESP) and 1607 Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, 1608 October 2017, . 1610 [RFC8249] - Zhang, M., Zhang, X., Eastlake 3rd, D., Perlman, R., and 1611 S. Chatterjee, "Transparent Interconnection of Lots of Links 1612 (TRILL): MTU Negotiation", RFC 8249, DOI 10.17487/RFC8249, 1613 September 2017, . 1615 [LEphb] - R. Bless, "A Lower Effort Per-Hop Behavior )LE PHB)", 1616 draft-ietf-tsvwg-le-phb, work in progress. 1618 Informative References 1620 [RFC4821] - Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1621 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1622 . 1624 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1625 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 1626 10.17487/RFC6234, May 2011, . 1629 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1630 Interconnection of Lots of Links (TRILL) Protocol Control 1631 Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, 1632 . 1634 [RFC6864] - Touch, J., "Updated Specification of the IPv4 ID Field", 1635 RFC 6864, DOI 10.17487/RFC6864, February 2013, . 1638 [RFC6936] - Fairhurst, G. and M. Westerlund, "Applicability Statement 1639 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1640 6936, DOI 10.17487/RFC6936, April 2013, . 1643 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1644 and D. Dutt, "Transparent Interconnection of Lots of Links 1645 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 1646 10.17487/RFC7172, May 2014, . 1649 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 1650 "Transparent Interconnection of Lots of Links (TRILL) Transport 1651 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 1652 . 1654 [RFC7296] - Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1655 Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", 1656 STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, 1657 . 1659 [RFC7323] - Borman, D., Braden, B., Jacobson, V., and R. 1660 Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 1661 7323, DOI 10.17487/RFC7323, September 2014, . 1664 [RFC8085] - Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1665 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 1666 2017, . 1668 [RFC8086] - Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1669 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1670 2017, . 1672 [IntareaTunnels] - J. Touch, M. Townsley, "IP Tunnels int he Internet 1673 Architecture", draft-ietf-intarea-tunnels, work in progress. 1675 [TRILLECN] - Eastlake, D., B. Briscoe, "TRILL: ECN (Explicit 1676 Congestion Notification) Support", draft-ietf-trill-ecn- 1677 support, work in progress. 1679 [PortRegistry] - https://www.iana.org/assignments/service-names-port- 1680 numbers/service-names-port-numbers.xhtml 1682 Acknowledgements 1684 The following people have provided useful feedback on the contents of 1685 this document: Sam Hartman, Adrian Farrel, Radia Perlman, Ines 1686 Robles, Joe Touch, Mohammed Umair, Magnus Westerlund, Lucy Yong. 1688 Some of the material in this document is derived from [RFC8085] and 1689 [RFC8086]. 1691 The document was prepared in raw nroff. All macros used were defined 1692 within the source file. 1694 Authors' Addresses 1696 Margaret Cullen 1697 Painless Security 1698 14 Summer Street, Suite 202 1699 Malden, MA 02148 1700 USA 1702 Phone: +1-781-605-3459 1703 Email: margaret@painless-security.com 1704 URI: http://www.painless-security.com 1706 Donald Eastlake 1707 Huawei Technologies 1708 155 Beaver Street 1709 Milford, MA 01757 1710 USA 1712 Phone: +1 508 333-2270 1713 Email: d3e3e3@gmail.com 1715 Mingui Zhang 1716 Huawei Technologies 1717 No.156 Beiqing Rd. Haidian District, 1718 Beijing 100095 P.R. China 1720 EMail: zhangmingui@huawei.com 1722 Dacheng Zhang 1723 Huawei Technologies 1725 Email: dacheng.zhang@huawei.com 1727 Copyright, Disclaimer, and Additional IPR Provisions 1729 Copyright (c) 2017 IETF Trust and the persons identified as the 1730 document authors. All rights reserved. 1732 This document is subject to BCP 78 and the IETF Trust's Legal 1733 Provisions Relating to IETF Documents 1734 (http://trustee.ietf.org/license-info) in effect on the date of 1735 publication of this document. Please review these documents 1736 carefully, as they describe your rights and restrictions with respect 1737 to this document. Code Components extracted from this document must 1738 include Simplified BSD License text as described in Section 4.e of 1739 the Trust Legal Provisions and are provided without warranty as 1740 described in the Simplified BSD License.