idnits 2.17.1 draft-ietf-trill-over-ip-10.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 (May 31, 2017) is 2522 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 ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 4 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: November 30, 2017 May 31, 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 49 2. Terminology.............................................5 51 3. Use Cases for TRILL over IP.............................6 52 3.1 Remote Office Scenario.................................6 53 3.2 IP Backbone Scenario...................................6 54 3.3 Important Properties of the Scenarios..................7 55 3.3.1 Security Requirements................................7 56 3.3.2 Multicast Handling...................................8 57 3.3.3 Neighbor Discovery...................................8 59 4. TRILL Packet Formats....................................9 60 4.1 General Packet Formats.................................9 61 4.2 General TRILL Over IP Packet Formats..................10 62 4.2.1 Without Security....................................10 63 4.2.2 With Security.......................................10 64 4.3 QoS Considerations....................................11 65 4.4 Broadcast Links and Multicast Packets.................12 66 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment....13 68 5. TRILL over IP Encapsulation Formats....................14 69 5.1 Encapsulation Considerations..........................14 70 5.2 Encapsulation Agreement...............................15 71 5.3 Broadcast Link Encapsulation Considerations...........16 72 5.4 Native Encapsulation..................................17 73 5.5 VXLAN Encapsulation...................................18 74 5.6 TCP Enacpulstion......................................18 75 5.7 Other Encapsulations..................................19 77 6. Handling Multicast.....................................20 79 7. Use of IPsec and IKEv2.................................21 80 7.1 Keying................................................21 81 7.1.1 Pairwise Keying.....................................21 82 7.1.2 Group Keying........................................22 83 7.2 Mandatory-to-Implement Algorithms.....................22 85 8. Transport Considerations...............................23 86 8.1 Congestion Considerations.............................23 87 8.1.1 Within a TMCE.......................................24 88 8.1.2 In Other Environments...............................24 89 8.2 Recursive Ingress.....................................24 90 8.3 Fat Flows.............................................25 91 8.4 MTU Considerations....................................26 92 8.5 Middlebox Considerations..............................27 94 Table of Contents (continued) 96 9. TRILL over IP Port Configuration.......................28 97 9.1 Per IP Port Configuration.............................28 98 9.2 Additional per IP Address Configuration...............28 99 9.2.1 Native Multicast Configuration......................29 100 9.2.2 Serial Unicast Configuration........................29 101 9.2.3 Encapsulation Specific Configuration................29 102 9.2.3.1 UDP and TCP Source Port...........................29 103 9.2.3.2 VXLAN Configuration...............................30 104 9.2.3.3 Other Encapsulation Configuration.................30 105 9.2.4 Security Configuration..............................30 107 10. Security Considerations...............................31 108 10.1 IPsec................................................31 109 10.2 IS-IS Security.......................................32 111 11. IANA Considerations...................................33 112 11.1 Port Assignments.....................................33 113 11.2 Multicast Address Assignments........................33 114 11.3 Encapsulation Method Support Indication..............34 116 Normative References......................................35 117 Informative References....................................37 119 Acknowledgements..........................................39 121 Authors' Addresses........................................40 123 1. Introduction 125 TRILL switches (also know as RBridges) are devices that implement the 126 IETF TRILL protocol [RFC6325] [RFC7177] [RFC7780]. TRILL provides 127 transparent forwarding of frames within an arbitrary network 128 topology, using least cost paths for unicast traffic. It supports 129 VLANs and Fine Grained Labels [RFC7172] as well as multipathing of 130 unicast and multi-destination traffic. It uses IS-IS [IS-IS] 131 [RFC7176] link state routing with a TRILL header having a hop count. 133 RBridge ports can communicate with each other over various protocols, 134 such as Ethernet [RFC6325], pseudowires [RFC7173], or PPP [RFC6361]. 136 This document specifies transmission of encapsulated TRILL data and 137 TRILL IS-IS over IP (v4 or v6 [rfc2460bis]). so as to use an IP 138 network as a TRILL link in a unified TRILL campus. Three 139 encapsulations specified herein, two based on UDP and one based on 140 TCP but provision is made to negotiate other encapsulations. TRILL 141 over IP allows RBridges with IP connectivity to form a single TRILL 142 campus, or multiple TRILL networks to be connected as a single TRILL 143 campus via a TRILL over IP backbone. 145 The protocol specified in this document connects RBridge ports using 146 transport over IP in such a way that the ports with IP connectivity 147 appear to TRILL to be connected by a single multi-access link. If a 148 set of more than two RBridge ports are connected via a single TRILL 149 over IP link, each RBridge port in the set can communicate with every 150 other RBridge port in the set. 152 To support the scenarios where RBridges are connected via IP paths 153 (including those over the public Internet) that are not under the 154 same administrative control as the TRILL campus and/or not physically 155 secure, this document specifies the use of IPsec [RFC4301] 156 Encapsulating Security Protocol (ESP) [RFC4303] for security. 158 To dynamically select a mutually supported TRILL over IP 159 encapsulation, normally one with good fast path hardware support, a 160 method is provided for agreement between adjacent TRILL switch ports 161 as to what encapsulation to use. Alternatively, where a common 162 encapsulation is known to be supported by the TRILL switch ports on a 163 link, they can simply be configured to always use that encapsulation. 165 This document updates [RFC7177] and [RFC7178] as described in 166 Sections 5 and 11.3 by making adjacency between TRILL over IP ports 167 dependent on having a method of encapsulation in common and by 168 redefining an interval of RBridge Channel protocol numbers to 169 indicate link technology specific capabilities, in this case 170 encapsulation methods supported for TRILL over IP. 172 2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 The following terms and acronyms have the meaning indicated: 180 DRB - Designated RBridge. The RBridge (TRILL switch) elected to be in 181 charge of certain aspects of a TRILL link that is not 182 configured as a point-to-point link [RFC6325] [RFC7177]. 184 ENCAP Hdr - See "encapsulation header". 186 encapsulation header - Protocol header or headers appearing between 187 the IP Header and the TRILL Header. See Sections 4 and 5. 189 ESP - IPsec Encapsulating Security Protocol [RFC4303]. 191 FGL - Fine Grained Label [RFC7172]. 193 Hdr - Used herein as an abbreviation for "Header". 195 link - In TRILL, a link connects TRILL ports and may, for example, be 196 a bridged LAN. 198 HKDF - Hash based Key Derivation Function [RFC5869]. 200 MTU - Maximum Transmission Unit. 202 RBridge - Routing Bridge. An alternative term for a TRILL switch. 203 [RFC6325] [RFC7780] 205 SNPA - Sub-Network Point of Attachment. 207 Sz - The campus wide MTU [RFC6325] [RFC7780]. 209 TMCE - Traffic-Managed Controlled Environment, see Section 8.1.1. 211 TRILL - Transparent Interconnection of Lots of Links or Tunneled 212 Routing in the Link Layer. The protocol specified in [RFC6325], 213 [RFC7177], [RFC7780], and related RFCs. 215 TRILL switch - A device implementing the TRILL protocol. 217 VNI - Virtual Network Identifier. In Virtual eXtensible Local Area 218 Network (VXLAN) [RFC7348], the VXLAN Network Identifier. 220 3. Use Cases for TRILL over IP 222 This section introduces two application scenarios (a remote office 223 scenario and an IP backbone scenario) which cover typical situations 224 where network administrators may choose to use TRILL over an IP 225 network to connect TRILL switches. 227 3.1 Remote Office Scenario 229 In the Remote Office Scenario, as shown in the example below, a 230 remote TRILL network is connected to a TRILL campus across a multihop 231 IP network, such as the public Internet. The TRILL network in the 232 remote office becomes a part of TRILL campus, and nodes in the remote 233 office can be attached to the same VLANs or Fine Grained Labels 234 [RFC7172] as local campus nodes. In many cases, a remote office may 235 be attached to the TRILL campus by a single pair of RBridges, one on 236 the campus end, and the other in the remote office. In this use case, 237 the TRILL over IP link will often cross logical and physical IP 238 networks that do not support TRILL, and are not under the same 239 administrative control as the TRILL campus. 241 /---------------\ /---------------\ 242 | Remote | | Remote | 243 | Office | | Office | 244 | | | | 245 | +-------+ | | +-------+ | 246 \---|RBridge|---/ \---|RBridge|---/ 247 +-----+-+ +-+-----+ 248 | | 249 /---------------------------------------------\ 250 | | The Internet | | 251 \---------------------------------------------/ 252 | | 253 +-+-----+ +-----+-+ 254 /----|RBridge|---------------|RBridge|----\ 255 | +-------+ +-------+ | 256 | | 257 | Main TRILL Campus | 258 \-----------------------------------------/ 260 3.2 IP Backbone Scenario 262 In the IP Backbone Scenario, as shown in the example below, TRILL 263 over IP is used to connect a number of TRILL networks to form a 264 single TRILL campus. For example, a TRILL over IP backbone could be 265 used to connect multiple TRILL networks on different floors of a 266 large building, or to connect TRILL networks in separate buildings of 267 a multi-building site. In this use case, there may often be several 268 TRILL switches on a single TRILL over IP link, and the IP link(s) 269 used by TRILL over IP are typically under the same administrative 270 control as the rest of the TRILL campus. 272 /---------------------------------------------\ 273 | Unified TRILL Campus | 274 | | 275 | TRILL Over IP Backbone | 276 | -----+------------+------------+----- | 277 | | | | | 278 | +---+---+ +---+---+ +---+---+ | 279 | |RBridge| |RBridge| |RBridge| | 280 | +---+---+ +---+---+ +---+---+ | 281 | | | | | 282 | ---+--- ---+--- ---+--- | 283 | TRILL Local Links or Networks | 284 | | 285 \---------------------------------------------/ 287 3.3 Important Properties of the Scenarios 289 There are a number of differences between the above two application 290 scenarios, some of which drive features of this specification. These 291 differences are especially pertinent to the security requirements of 292 the solution, how multicast data frames are handled, and how the 293 TRILL switch ports discover each other. 295 3.3.1 Security Requirements 297 In the IP Backbone Scenario, TRILL over IP is used between a number 298 of RBridge ports, on a network link that is in the same 299 administrative control as the remainder of the TRILL campus. While it 300 is desirable in this scenario to prevent the association of 301 unauthorized RBridges, this can be accomplished using existing IS-IS 302 security mechanisms. There may be no need to protect the data 303 traffic, beyond any protections that are already in place on the 304 local network. 306 In the Remote Office Scenario, TRILL over IP may run over a network 307 that is not under the same administrative control as the TRILL 308 network. Nodes on the network may think that they are sending traffic 309 locally, while that traffic is actually being sent, in an IP tunnel, 310 over the public Internet. It is necessary in this scenario to protect 311 the integrity and confidentiality of user traffic, as well as 312 ensuring that no unauthorized RBridges can gain access to the RBridge 313 campus. The issues of protecting integrity and confidentiality of 314 user traffic are addressed by using IPsec for both TRILL IS-IS and 315 TRILL Data packets between RBridges in this scenario. 317 3.3.2 Multicast Handling 319 In the IP Backbone scenario, native IP multicast may be supported on 320 the TRILL over IP link. If so, it can be used to send TRILL IS-IS and 321 multicast data packets, as discussed later in this document. 322 Alternatively, multi-destination packets can be transmitted serially 323 by IP unicast to the intended recipients. 325 In the Remote Office Scenario there will often be only one pair of 326 RBridges connecting a given site and, even when multiple RBridges are 327 used to connect a Remote Office to the TRILL campus, the intervening 328 network may not provide reliable (or any) multicast connectivity. 329 Issues such as complex key management also make it difficult to 330 provide strong data integrity and confidentiality protections for 331 multicast traffic. For all of these reasons, the connections between 332 local and remote RBridges will commonly be treated like point-to- 333 point links, and all TRILL IS-IS control messages and multicast data 334 packets that are transmitted between the Remote Office and the TRILL 335 campus will be serially transmitted by IP unicast, as discussed later 336 in this document. 338 3.3.3 Neighbor Discovery 340 In the IP Backbone Scenario, TRILL switches that use TRILL over IP 341 can use the normal TRILL IS-IS Hello mechanisms to discover the 342 existence of other TRILL switches on the link [RFC7177], and to 343 establish authenticated communication with them. 345 In the Remote Office Scenario, an IPsec session will need to be 346 established before TRILL IS-IS traffic can be exchanged, as discussed 347 below. In this case, one end will need to be configured to establish 348 a IPSEC session with the other. This will typically be accomplished 349 by configuring the TRILL switch or a border device at a Remote Office 350 to initiate an IPsec session and subsequent TRILL exchanges with a 351 TRILL over IP-enabled RBridge attached to the TRILL campus. 353 4. TRILL Packet Formats 355 To support TRILL two types of TRILL packets are transmitted between 356 TRILL switches: TRILL Data packets and TRILL IS-IS packets. 358 Section 4.1 describes general TRILL packet formats for data and IS-IS 359 independent of link technology. Section 4.2 specifies general TRILL 360 over IP packet formats including IPsec ESP encapsulation. Section 4.3 361 provides QoS Considerations. Section 4.4 discusses broadcast links 362 and multicast packets. And Section 4.5 provides TRILL IS-IS Hello 363 SubNetwork Point of Attachment (SNPA) considerations for TRILL over 364 IP. 366 4.1 General Packet Formats 368 The on-the-wire form of a TRILL Data packet in transit between two 369 neighboring TRILL switch ports is as shown below: 371 +----------------+----------+----------------+-----------+ 372 | Link Header | TRILL | Native Frame | Link | 373 | for TRILL Data | Header | Payload | Trailer | 374 +----------------+----------+----------------+-----------+ 376 The encapsulated Native Frame Payload is similar to an Ethernet frame 377 with a VLAN tag or Fine Grained Label [RFC7172] but with no trailing 378 Frame Check Sequence (FCS). 380 TRILL IS-IS packets are formatted on-the-wire as follows: 382 +-----------------+---------------+-----------+ 383 | Link Header | TRILL IS-IS | Link | 384 | for TRILL IS-IS | Payload | Trailer | 385 +-----------------+---------------+-----------+ 387 The Link Header and Link Trailer in these formats depend on the 388 specific link technology. The Link Header contains one or more fields 389 that distinguish TRILL Data from TRILL IS-IS. For example, over 390 Ethernet, the Link Header for TRILL Data ends with the TRILL 391 Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS- 392 IS Ethertype; on the other hand, over PPP, there are no Ethertypes in 393 the Link Header but PPP protocol code points are included that 394 distinguish TRILL Data from TRILL IS-IS. 396 4.2 General TRILL Over IP Packet Formats 398 In TRILL over IP, we use an IP (v4 or v6) header followed by an 399 encapsulation header, such as UDP, as the link header. (On the wire, 400 the IP header will normally be preceded by the lower layer header of 401 a protocol that is carrying IP; however, this does not concern us at 402 the level of this document.) 404 There are multiple IP based encapsulations usable for TRILL over IP 405 that differ in exactly what appears after the IP header and before 406 the TRILL Header or the TRILL IS-IS Payload. Those encapsulations 407 specified in this document are further detailed in Section 5. In the 408 general specification below, those encapsulation fields will be 409 represented as "ENCAP Hdr". 411 4.2.1 Without Security 413 When TRILL over IP link security is not being used, a TRILL over IP 414 packet on the wire looks like one of the following: 416 TRILL Data Packet 417 +---------+-----------+---------+------------------+ 418 | IP | ENCAP Hdr | TRILL | Native frame | 419 | Header | for Data | Header | Payload | 420 +---------+-----------+---------+------------------+ 421 <--- link header ----> 423 TRILL IS-IS Packet 424 +---------+-----------+-----------------+ 425 | IP | ENCAP Hdr | TRILL IS-IS | 426 | Header | for IS-IS | Payload | 427 +---------+-----------+-----------------+ 428 <--- link header ----> 430 As discussed above and further specified in Section 5, the ENCAP Hdr 431 indicates whether the packet is TRILL Data or IS-IS. 433 4.2.2 With Security 435 TRILL over IP link security uses IPsec Encapsulating Security 436 Protocol (ESP) in tunnel mode [RFC4303]. Since TRILL over IP always 437 starts with an IP Header (on the wire this appears after any lower 438 layer header that might be required), the modifications for IPsec are 439 independent of the TRILL over IP ENCAP Hdr that occurs after that IP 440 Header. The resulting packet formats are as follows for IPv4 and 441 IPv6: 443 With IPv4: 444 +-------------+-----+--------------+-----------+-----------+ 445 | new IP Hdr | ESP | TRILL IP Hdr | ENCAP Hdr | ESP |ESP| 446 |(any options)| Hdr | (any options)| + payload |Trailer|ICV| 447 +-------------+-----+--------------+-----------+-----------+ 448 |<---------- encryption ---------->| 449 |<-------------- integrity ------------->| 451 With IPv6: 452 +------+-------+-----+------+--------+-----------+-------+---+ 453 | new |new ext| ESP | orig |orig ext| ENCAP Hdr | ESP |ESP| 454 |IP Hdr| Hdrs | Hdr |IP Hdr| Hdrs | + payload |Trailer|ICV| 455 +------+-------+-----+------+--------+-----------+-------+---+ 456 |<----------- encryption ---------->| 457 |<--------------- integrity ------------->| 459 As shown above, IP Header options are considered part of the IPv4 460 Header but are extensions ("ext") of the IPv6 Header. For further 461 information on the IPsec ESP Hdr, Trailer, and ICV, see [RFC4303] and 462 Section 7 below. "ENCAP Hdr + payload" is the encapsulation header 463 (Section 5) and TRILL data or the encapsulation header and IS-IS 464 payload, that is, the material after the IP Header in the diagram in 465 Section 4.2.1. 467 This architecture permits the ESP tunnel end point to be separated 468 from the TRILL over IP RBridge port (see, for example, Section 1.1.3 469 of [RFC7296]). 471 4.3 QoS Considerations 473 In IP, QoS handling is indicated by the Differentiated Services Code 474 Point (DSCP [RFC2474] [RFC3168]) in the IP Header. The former Type 475 of Service (TOS) octet in the IPv4 Header and the Traffic Class octet 476 in the IPv6 Header has been divided as shown in the following diagram 477 adapted from [RFC3168]. (TRILL support of ECN is beyond the scope of 478 this document. See [TRILLECN].) 480 0 1 2 3 4 5 6 7 481 +-----+-----+-----+-----+-----+-----+-----+-----+ 482 | DSCP FIELD | ECN FIELD | 483 +-----+-----+-----+-----+-----+-----+-----+-----+ 485 DSCP: Differentiated Services Codepoint 486 ECN: Explicit Congestion Notification 488 Within a TRILL switch, priority is indicated by configuration for 489 TRILL IS-IS packets and for TRILL Data packets by a three bit (0 490 through 7) priority field and a Drop Eligibility Indicator bit (see 491 Sections 8.2 and 7 of [RFC7780]). (Typically TRILL IS-IS is 492 configured to use the highest two priorities depending on the IS-IS 493 PDU.) The priority affects queuing behavior at TRILL switch ports and 494 may be encoded into the link header, particularly if there could be 495 priority sensitive devices within the link. For example, if the link 496 is a bridged LAN, it is commonly encoded into an Outer.VLAN tag's 497 priority and DEI fields. 499 TRILL over IP implementations MUST support setting the DSCP value in 500 the outer IP Header of TRILL packets they send by mapping the TRILL 501 priority and DEI to the DSCP. They MAY support, for a TRILL Data 502 packet where the native frame payload is an IP packet, mapping the 503 DSCP in this inner IP packet to the outer IP Header with the default 504 for that mapping being to copy the DSCP without change. 506 The default TRILL priority and DEI to DSCP mapping, which may be 507 configured per TRILL over IP port, is an follows. Note that the DEI 508 value does not affect the default mapping and, to provide a 509 potentially lower priority service than the default priority 0, 510 priority 1 is considered lower priority than 0. So the priority 511 sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. 513 TRILL Priority DEI DSCP Field (Binary/decimal) 514 -------------- --- ----------------------------- 515 0 0/1 001000 / 8 516 1 0/1 000000 / 0 517 2 0/1 010000 / 16 518 3 0/1 011000 / 24 519 4 0/1 100000 / 32 520 5 0/1 101000 / 40 521 6 0/1 110000 / 48 522 7 0/1 111000 / 56 524 4.4 Broadcast Links and Multicast Packets 526 TRILL supports broadcast links. These are links to which more than 527 two TRILL switch ports can be attached and where a packet can be 528 broadcast or multicast from a port to all or a subset of the other 529 ports on the link as well as unicast to a specific other port on the 530 link. 532 As specified in [RFC6325], TRILL Data packets being forwarded between 533 TRILL switches can be unicast on a link to a specific TRILL switch 534 port or multicast on a link to all TRILL switch ports. TRILL IS-IS 535 packets are always multicast to all other TRILL switches on the link 536 except for IS-IS MTU PDUs, which may be unicast [RFC7177]. This 537 distinction is not significant if the link is inherently point-to- 538 point, such as a PPP link; however, on a broadcast link there will be 539 a packet outer link address that will be unicast or multicast as 540 appropriate. For example, over Ethernet links, the Ethernet multicast 541 addresses All-RBridges and All-IS-IS-RBridges are used for 542 multicasting TRILL Data and TRILL IS-IS respectively. For details on 543 TRILL over IP handling of multicast, see Section 6. 545 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment 547 IS-IS routers, including TRILL switches, establish adjacency through 548 the exchange of Hello PDUs on a link [RFC7176] [RFC7177]. The Hellos 549 transmitted out a port indicate what neighbor ports that port can see 550 on the link by listing what IS-IS refers to as the neighbor port's 551 SubNetwork Point of Attachment (SNPA). (For an Ethernet link, which 552 may be a bridged network, the SNPA is the port MAC address.) 554 In TRILL Hello PDUs on a TRILL over IP link, the IP addresses of the 555 IP ports connected to that link are their actual SNPA (SubNetwork 556 Point of Attachment [IS-IS]) addresses and, for IPv6, the 16-byte 557 IPv6 address is used as the SNPA; however, for easy in re-using code 558 designed for the common case of 48-bit SNPAs, in TRILL over IPv4 a 559 48-bit synthetic SNPA that looks like a unicast MAC address is 560 constructed for use in the SNPA field of TRILL Neighbor TLVs 561 [RFC7176] [RFC7177] in such Hellos. This synthetic SNPA is derived 562 from the port IPv4 address is as follows: 564 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 565 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 566 | 0xFE | 0x00 | 567 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 568 | IPv4 upper half | 569 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 570 | IPv4 lower half | 571 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 573 This synthetic SNPA (MAC) address has the local (0x02) bit on in the 574 first byte and so cannot conflict with any globally unique 48-bit 575 Ethernet MAC. However, when TRILL operates on an IP link, TRILL sees 576 only IP addresses on that link, not MAC stations, even if the TRILL 577 over IP Link is being carried over Ethernet. Therefore conflict on 578 the link between a real MAC address and a TRILL over IP synthetic 579 SNPA (MAC) address would be impossible in any case. 581 5. TRILL over IP Encapsulation Formats 583 There are a variety of TRILL over IP encapsulation formats possible. 584 By default TRILL over IP adopts a hybrid encapsulation approach. 586 There is one format, called "native encapsulation" that MUST be 587 implemented. Although native encapsulation does not typically have 588 good fast path support, as a lowest common denominator it can be used 589 by low bandwidth control traffic to determine a preferred 590 encapsulation with better performance. In particular, by default, all 591 TRILL IS-IS Hellos are sent using native encapsulation and those 592 Hellos are used to determine the encapsulation used for all TRILL 593 Data packets and all other TRILL IS-IS PDUs (with the exception of 594 IS-IS MTU-probe and MTU-ack PDUs used to establish adjacency). 596 Alternatively, the network operator can pre-configure a TRILL over IP 597 port to use a particular encapsulation chosen for their particular 598 network's needs and port capabilities. That encapsulation is then 599 used for all TRILL Data and IS-IS packets on ports so configured. 600 This is expected to frequently be the case for a managed campus of 601 TRILL switches. 603 Section 5.1 discusses general consideration for the TRILL over IP 604 encapsulation format. Section 5.2 discusses encapsulation agreement. 605 Section 5.3 discusses broadcast link encapsulation considerations. 606 The subsequent subsections discuss particular encapsulations. 608 5.1 Encapsulation Considerations 610 An encapsulation must provide a method to distinguish TRILL Data 611 packets and TRILL IS-IS packets or it is not useful for TRILL. In 612 addition, the following criteria can be helpful is choosing between 613 different encapsulations: 615 a) Fast path support - For most applications, it is highly desirable 616 to be able to encapsulate/decapsulate TRILL over IP at line speed 617 so a format where existing or anticipated fast path hardware can 618 do that is best. This is commonly the dominant consideration. 620 b) Ease of multi-pathing - The IP path between TRILL over IP ports 621 may include equal cost multipath routes internal to the IP link so 622 a method of encapsulation that provides variable fields available 623 for existing or anticipated fast path hardware multi-pathing is 624 preferred. 626 c) Robust fragmentation and re-assembly - The MTU of the IP link may 627 require fragmentation in which case an encapsulation with robust 628 fragmentation and re-assembly is important. There are known 629 problems with IPv4 fragmentation and re-assembly [RFC6864] which 630 generally do not apply to IPv6. Some encapsulations can fix these 631 problems but the encapsulations specified in this document do not. 632 Therefore, if fragmentation is anticipated with the encapsulations 633 specified in this document, the use of IPv6 is RECOMMENDED. 635 d) Checksum strength - Depending on the particular circumstances of 636 the TRILL over IP link, a checksum provided by the encapsulation 637 may be a significant factor. Use of IPsec can also provide a 638 strong integrity check. 640 5.2 Encapsulation Agreement 642 TRILL Hellos sent out a TRILL over IP port indicate the 643 encapsulations that port is willing to support through a mechanism 644 initially specified in [RFC7178] and [RFC7176] that is hereby 645 extended. Specifically, RBridge Channel Protocol numbers 0xFD0 646 through 0xFF7 are redefined to be link technology dependent flags 647 that, for TRILL over IP, indicate support for different 648 encapsulations, allowing support for up to 40 encapsulations to be 649 specified. Support for an encapsulation is indicated in the Hello 650 PDU in the same way that support for an RBridge Channel was 651 indicated. (See also section 11.3.) "Support" indicates willingness 652 to use that encapsulation for TRILL Data and TRILL IS-IS packets 653 (although TRILL IS-IS Hellos are still sent in native encapsulation 654 by default unless the port is configured to always use some other 655 encapsulation). 657 If, in a TRILL Hello on a TRILL over IP link, support is not 658 indicated for any encapsulation, then the port from which it was sent 659 is assumed to support only native encapsulation (see Section 5.4). 661 An adjacency can be formed between two TRILL over IP ports if the 662 intersection of the sets of encapsulation methods they support is not 663 null. If that intersection is null, then no adjacency is formed. In 664 particular, for a TRILL over IP link, the adjacency state machine 665 MUST NOT advance to the Report state unless the ports share an 666 encapsulation [RFC7177]. If no encapsulation is shared, the adjacency 667 state machine remains in the state from which it would otherwise have 668 transitioned to the Report state. 670 If a TRILL over IP port is using an encapsulation different from that 671 in which Hellos are being exchanged, it is RECOMMENDED that BFD 672 [RFC7175] or some other protocol that confirms adjacency using TRILL 673 Data packets be used. As provided in [RFC7177] adjacency is not 674 actually obtain until such confirmatory protocol succeeds. 676 If any TRILL over IP packet, other than an IS-IS Hello or MTU PDU in 677 native encapsulation, is received in an encapsulation for which 678 support is not being indicated by the receiver, that packet MUST be 679 discarded (see Section 5.3). 681 If there are two or more encapsulations in common between two 682 adjacent ports for unicast or the set of adjacent ports for 683 multicast, a transmitter is free to choose whichever of the 684 encapsulations it wishes to use. Thus transmissions between adjacent 685 ports P1 and P2 could use different encapsulations depending on which 686 port is transmitting and which is receiving. 688 It is expected to be the normal case in a well-configured network 689 that all the TRILL over IP ports connected to an IP link (i.e., an IP 690 network) that are intended to communicate with each other will 691 support the same encapsulation(s). 693 5.3 Broadcast Link Encapsulation Considerations 695 To properly handle TRILL protocol packets on a TRILL over IP link in 696 the general case, either native IP multicast mode is used on that 697 link or multicast must be simulated using serial IP unicast, as 698 discussed in Section 6. (Of course, if the IP link happens to 699 actually be point-to-point no special provision is needed for 700 handling IP multicast addressed packets.) 702 It is possible for the Hellos from a TRILL over IP port P1 to 703 establish adjacency with multiple other TRILL over IP ports (P2, P3, 704 ...) on a broadcast link. In a well-configured network one would 705 expect all of the IP ports involved to support the same 706 encapsulation(s); but, for example, if P1 supports multiple 707 encapsulations, it is possible that P2 and P3, do not have an 708 encapsulation in common that is supported by P1. [IS-IS] can handle 709 such non-transitive adjacencies that are reported as specified in 710 [RFC7177]. This is generally done, albeit with reduced efficiency, by 711 forwarding through the designated RBridge (router) on the link. Thus 712 it is RECOMENDED that all TRILL over IP ports on an IP link be 713 configured to support one encapsulation in common that has good fast 714 path support. 716 If serial IP unicast is being used by P1, it can use different 717 encapsulations for different transmissions. 719 If native IP multicast is available for use by P1, it can send one 720 transmission per encapsulation method by which it has a disjoint set 721 of adjacencies on the link. If the transmitting port has adjacencies 722 with overlapping sets of ports that are adjacent using different 723 encapsulations, use of native multicast with different encapsulations 724 may result in packet duplication. It would always be possible to use 725 native IP multicast for one encapsulation for which the transmitting 726 port has adjacencies, perhaps the encapsulation for which it has the 727 largest number of adjacencies, and serially unicast to other 728 receivers. These considerations are the reason that a TRILL over IP 729 port MUST discard any packet received with an encapsulation for which 730 it has not established an adjacency with the transmitter. Otherwise, 731 packets would be further duplicated. 733 5.4 Native Encapsulation 735 The mandatory to implement "native encapsulation" format of a TRILL 736 over IP packet, when used without security, is TRILL over UDP as 737 shown below. This provides simple and direct access by TRILL to the 738 native datagram service of IP. 740 +----------+--------+-----------------------+ 741 | IP | UDP | TRILL | 742 | Header | Header | Payload | 743 +----------+--------+-----------------------+ 745 Where the UDP Header is as follows: 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Source Port = Entropy | Destination Port | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | UDP Length | UDP Checksum | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | TRILL Payload ... 756 Source Port - see Section 8.3 758 Destination Port - indicates TRILL Data or IS-IS, see Section 759 11.1. 761 UDP Length - as specified in [RFC0768] 763 UDP Checksum - as specified in [RFC0768] 765 The TRILL Payload starts with the TRILL Header (not including the 766 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 767 Intradomain Routeing Protocol Discriminator byte (thus not including 768 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 770 5.5 VXLAN Encapsulation 772 VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, like 773 TRILL over Ethernet over VXLAN over UDP over IP. 775 +--------+--------+--------+----------+-----------+ 776 | IP | UDP | VXLAN | Ethernet | TRILL | 777 | Header | Header | Header | Header | Payload | 778 +--------+--------+--------+----------+-----------+ 780 The outer UDP uses a destination port number indicating VXLAN and the 781 outer UDP source port MAY be used for entropy as with native 782 encapsulation (see Section 8.3). The VXLAN header after the outer UDP 783 header adds a 24 bit Virtual Network Identifier (VNI). The Ethernet 784 header after the VXLAN header and before the TRILL header consists of 785 source MAC address, destination MAC address, and Ethertype. The 786 Ethertype distinguishes TRILL Data from TRILL IS-IS. The destination 787 and source MAC addresses in this Ethernet header are not used. 789 A TRILL over IP port using VXLAN encapsulation by default uses a VNI 790 of 1 for TRILL IS-IS traffic and a VNI of 2 for TRILL data traffic 791 but can be configured as described in Section 9.2.3.1 to use some 792 other fixed VNIs or to map from VLAN/FGL to VNI. 794 5.6 TCP Enacpulstion 796 TCP may be used for TRILL over IP as specified below. Use of TCP is 797 convenient to provide congestion control (see Section 8.1) and 798 reduced packet loss but is likely to cause substantial additional 799 jitter and delay compared with a UDP based encapsulation. 801 +----------+--------+-----------------------+ 802 | IP | TCP | TRILL | 803 | Header | Header | Payload | 804 +----------+--------+-----------------------+ 806 Where the TCP Header is as follows: 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Source Port = Entripy | Destination Port | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Sequence Number | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Acknowledgment Number | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Data | |U|A|P|R|S|F| | 818 | Offset| Reserved |R|C|S|S|Y|I| Window | 819 | | |G|K|H|T|N|N| | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | TCP Checksum | Urgent Pointer | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Options | Padding | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | TRILL Payload ... 827 Source Port - see Section 8.3 829 Destination Port - indicates TRILL Data or IS-IS, see Section 830 11.1. 832 Other TCP Header Fields - as specified in [RFC0793] 834 The TRILL Payload starts with the TRILL Header (not including the 835 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 836 Intradomain Routeing Protocol Discriminator byte (thus not including 837 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 839 5.7 Other Encapsulations 841 It is anticipated that additional TRILL over IP encapsulations will 842 be specified in future documents and allocated a link technology 843 specific flag bit as per Section 11.3. A primary consideration for 844 whether it is worth the effort to specify use of an encapsulation by 845 TRILL over IP is whether it has good existing or anticipated fast 846 path support. 848 6. Handling Multicast 850 By default, both TRILL IS-IS packets and multi-destination TRILL Data 851 packets are sent to an All-RBridges IPv4 or IPv6 IP multicast Address 852 as appropriate (see Section 11.2); however, a TRILL over IP port may 853 be configured (see Section 9) to use a different multicast address or 854 to use serial IP unicast with a list of one or more unicast IP 855 addresses of other TRILL over IP ports to which multi-destination 856 packets are sent. In the serial unicast case the outer IP header of 857 each copy of the packet sent shows an IP unicast destination address 858 even through the TRILL header has the M bit set to one to indicate 859 multi-destination. Serial unicast configuration is necessary if the 860 TRILL over IP port is connected to an IP network that does not 861 support IP multicast. In any case, unicast TRILL packets (those with 862 the M bit in the TRILL Header set to zero) are sent by unicast IP. 864 Even if a TRILL over IP port is configured to send multi-destination 865 packets with serial unicast, it MUST be prepared to receive IP 866 multicast TRILL packets. All TRILL over IP ports default to 867 periodically transmitting appropriate IGMP (IPv4 [RFC3376]) or MLD 868 (IPv6 [RFC2710]) packets, so that the TRILL multicast IP traffic can 869 be sent to them, but may be configured not to do so. 871 Although TRILL fully supports broadcast links with more than 2 872 RBridges connected to the link there may be good reasons for 873 configuring TRILL over IP ports to use serial unicast even where 874 native IP multicast is available. Use of serial unicast provides the 875 network manager with more precise control over adjacencies and how 876 TRILL over IP links will be formed in an IP network. In some 877 networks, unicast is more reliable than multicast. If multiple point- 878 to-point TRILL over IP connections between two parts of a TRILL 879 campus are configured, TRILL will in any case spread traffic across 880 them, treating them as parallel links, and appropriately fail over 881 traffic if a link fails or incorporate a new link that comes up. 883 7. Use of IPsec and IKEv2 885 All TRILL switches (RBridges) that support TRILL over IP MUST 886 implement IPsec [RFC4301] and support the use of IPsec Encapsulating 887 Security Protocol (ESP [RFC4303]) in tunnel mode to secure both TRILL 888 IS-IS and TRILL Data packets. When IPsec is used to secure a TRILL 889 over IP link and no IS-IS security is enabled, the IPsec session MUST 890 be fully established before any TRILL IS-IS or data packets are 891 exchanged. When there is IS-IS security [RFC5310] provided, 892 implementers SHOULD use IS-IS security to protect TRILL IS-IS 893 packets. However, in this case, the IPsec session still MUST be fully 894 established before any TRILL Data packets transmission, since IS-IS 895 security does not provide any protection to data packets, and SHOULD 896 be fully established before any TRILL IS-IS packet transmission other 897 than IS-IS Hello or MTU PDUs. 899 All RBridges that support TRILL over IP MUST implement the Internet 900 Key Exchange Protocol version 2 (IKEv2) for automated key management. 902 7.1 Keying 904 The following subsections discuss pairwise and group keying for TRILL 905 over IP IPsec. 907 7.1.1 Pairwise Keying 909 When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that 910 incorporates the IS-IS shared key in order to bind the TRILL data 911 session to the IS-IS session. The pre-shared key that will be used 912 for IKEv2 exchanges for TRILL over IP is determined as follows: 914 HKDF-Expand-SHA256 ( IS-IS-key, 915 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) 917 In the above "|" indicates concatenation, HKDF is as in [RFC5869], 918 SHA256 is as in [RFC6234], and "TRILL IP" is the eight byte US ASCII 919 [RFC0020] string indicated. "IS-IS-key" is an IS-IS key usable for 920 IS-IS security of link local IS-IS PDUs such as Hello, CSNP, and 921 PSNP. This SHOULD be a link scope IS-IS key. P1-System-ID and 922 P2-System ID are the six byte System IDs of the two TRILL RBridges, 923 and P1-Port and P2-Port are the TRILL Port IDs [RFC6325] of the ports 924 in use on each end. System IDs are guaranteed to be unique within the 925 TRILL campus. Both of the RBridges involved treat the larger 926 magnitude System ID, comparing System IDs as unsigned integers, as P1 927 and the smaller as P2 so both will derive the same key. 929 With [RFC5310] there could be multiple keys identified with 16-bit 930 key IDs. The key ID when an IS-IS key is in use is transmitted in an 931 IKEv2 ID_KEY_ID identity field [RFC7296] with Identification Data 932 length of 2 bytes (Payload Length 6 bytes). The Key ID of the IS-IS- 933 key is used to identify the IKEv2 shared secret derived as above that 934 is actually used. ID_KEY_ID identity field(s) of other lengths MAY 935 occur but their use is beyond the scope of this document. 937 The IS-IS-shared key from which the IKEv2 shared secret is derived 938 might expire and be updated as described in [RFC5310]. The IKEv2 939 pre-shared keys derived from an IS-IS shared key MUST expire within a 940 lifetime no longer than the IS-IS-shared key from which they were 941 derived. When the IKEv2 shared secret key expires, or earlier, the 942 IKEv2 Security Association must be rekeyed using a new shared secret 943 derived from a new IS-IS shared key. 945 IKEv2 with certificate based security MAY be used but details of 946 certificate contents and use policy for this application of IKEv2 are 947 beyond the scope of this document. 949 7.1.2 Group Keying 951 In the case of a TRILL over IP port configured as point-to-point (see 952 Section 4.2.4.1 of [RFC6325]), there is no group keying and the 953 pairwise keying determined as in Section 7.1.1 is used for multi- 954 destination TRILL traffic, which is unicast. 956 In the case of a TRILL over IP port configured as broadcast but where 957 the port is configured to use serial unicast (see Section 8), there 958 is no group keying and the pairwise keying determined as in Section 959 7.1.1 is used for multi-destination TRILL traffic, which is unicast. 961 The case of a TRILL over IP port configured as broadcast and using 962 native multicast is beyond the scope of this document. For security 963 as provided in this document, multicast is handled via serial 964 unicast. 966 7.2 Mandatory-to-Implement Algorithms 968 All RBridges that support TRILL over IP MUST implement IPsec ESP 969 [RFC4303] in tunnel mode. The implementation requirements for ESP 970 cryptographic algorithms are as specified for IPsec. That 971 specification is currently [RFC7321]. 973 8. Transport Considerations 975 This section discusses a variety of important transport 976 considerations. 978 8.1 Congestion Considerations 980 This subsection discusses TRILL over UDP congestion considerations. 981 These are applicable to the UDP based TRILL over IP encapsulation 982 headers specified in detail in this document. Other encapsulations 983 would likely have different congestion considerations and, in 984 particlar, the TCP encapsulation specified in Section 5.6 does not 985 need congestion control beyond that provided by TCP. Congestion 986 considerations for additional TRILL encapsulations will be provided 987 in the document specifying the encapsulation. 989 One motivation for including UDP or TCP as the outermost part of a 990 TRILL over IP encapsulation header is to improve the use of multipath 991 such as Equal Cost Multi-Path (ECMP) in cases where traffic is to 992 traverse routers that are able to hash on Port and IP address through 993 addition of entropy in the source port (see Section 8.3). In many 994 cases this may reduce the occurrence of congestion and improve usage 995 of available network capacity. However, it is also necessary to 996 ensure that the network, including applications that use the network, 997 responds appropriately in more difficult cases, such as when link or 998 equipment failures have reduced the available capacity. 1000 Section 3.1.11 of [RFC8085] discusses the congestion considerations 1001 for design and use of UDP tunnels; this is important because other 1002 flows could share the path with one or more UDP tunnels, 1003 necessitating congestion control [RFC2914] to avoid destructive 1004 interference. 1006 The default initial determination of the TRILL over IP encapsulation 1007 to be used is through the exchange of TRILL IS-IS Hellos. This is a 1008 low bandwidth process. Hellos are not permitted to be sent any more 1009 often than once per second, and so are very unlikely to cause 1010 congestion. Thus no additional controls are needed for Hellos even 1011 if sent, as is the default, over UDP. 1013 Congestion has potential impacts both on the rest of the network 1014 containing a UDP flow and on the traffic flows using the UDP 1015 encapsulation. These impacts depend upon what sort of traffic is 1016 carried in UDP, as well as the path it follows. The UDP based TRILL 1017 over IP encapsulations specified in this document do not provide any 1018 congestion control and are transmitted as regular UDP packets. 1020 The two subsections below discuss congestion for TRILL over IP 1021 traffic with UDP based encapsulation headers in traffic-managed 1022 controlled environments (TMCE, see [RFC8086]) and other environments. 1024 8.1.1 Within a TMCE 1026 Within a TMCE, that is, an IP network that is traffic-engineered 1027 and/or otherwise managed, for example via use of traffic rate 1028 limiters, to avoid congestion, UDP based TRILL over IP encapsulation 1029 headers are appropriate for carrying traffic that is not known to be 1030 congestion controlled. in such cases, operators of TMCE networks 1031 avoid congestion by careful provisioning of their networks, rate- 1032 limiting of user data traffic, and traffic engineering according to 1033 path capacity. 1035 When TRILL over IP using a UDP based encapsulation header carries 1036 traffic that is not known to be congestion controlled in a TMCE 1037 network, the traffic path MUST be entirely within that network, and 1038 measures SHOULD be taken to prevent the traffic from "escaping" the 1039 network to the general Internet. Examples of such measures are: 1041 o physical or logical isolation of the links carrying the traffic 1042 from the general Internet and 1044 o deployment of packet filters that block the UDP ports assigned 1045 for TRILL over IP. 1047 8.1.2 In Other Environments 1049 Where UDP based encapsulation headers are used in TRILL over IP in 1050 environments other than those discussed in Section 8.1.1, specific 1051 congestion control mechanisms are commonly needed. However, if the 1052 traffic being carried by the TRILL over IP link is already congestion 1053 controlled and the size and volatility of the TRILL IS-IS link state 1054 database is limited, then specific congestion control may not be 1055 needed. See [RFC8085] Section 3.1.11 for further guidance. 1057 8.2 Recursive Ingress 1059 TRILL is specified to transport data to and from end stations over 1060 Ethernet and IP is frequently transported over Ethernet. Thus, an end 1061 station native data Ethernet frame "EF" might get TRILL ingressed to 1062 TRILL(EF) that was subsequently sent to a next hop RBridge out a 1063 TRILL over IP over Ethernet port resulting in a packet on the wire of 1064 the form Ethernet(IP(TRILL(EF))). There is a risk of such a packet 1065 being re-ingressed by the same TRILL campus, due to physical or 1066 logical misconfiguration, looping round, being further re-ingressed, 1067 and so on. (Or this might occur through a cycle of TRILL campuses.) 1068 The packet would get discarded if it got too large but if 1069 fragmentation is enabled, it would just keep getting split into 1070 fragments that would continue to loop and grow and re-fragment until 1071 the path was saturated with junk and packets were being discarded due 1072 to queue overflow. The TRILL Header TTL would provide no protection 1073 because each TRILL ingress adds a new TRILL header with a new TTL. 1075 To protect against this scenario, a TRILL over IP port MUST, by 1076 default, test whether a TRILL packet it is about to transmit appears 1077 to be a TRILL ingress of a TRILL over IP over Ethernet packet. That 1078 is, is it of the form TRILL(Ethernet(IP(TRILL(...)))? If so, the 1079 default action of the TRILL over IP output port is to discard the 1080 packet rather than transmit it. However, there are cases where some 1081 level of nested ingress is desired so it MUST be possible to 1082 configure the port to allow such packets. 1084 8.3 Fat Flows 1086 For the purpose of load balancing, it is worthwhile to consider how 1087 to transport TRILL packets over any Equal Cost Multiple Paths (ECMPs) 1088 existing internal to the IP path between TRILL over IP ports. 1090 The ECMP election for the IP traffic could be based, for example with 1091 IPv4, on the quintuple of the outer IP header { Source IP, 1092 Destination IP, Source Port, Destination Port, and IP protocol }. 1093 Such tuples, however, could be exactly the same for all TRILL Data 1094 packets between two RBridge ports, even if there is a huge amount of 1095 data being sent between a variety of ingress and egress RBridges. One 1096 solution to this is to use the UDP Source Port as an entropy field. 1097 (This idea is also introduced in [RFC8086].) For example, for TRILL 1098 Data, this entropy field could be based on some hash of the 1099 Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. Unfortunately, 1100 this can conflict with middleboxes inside the TRILL over IP link (see 1101 8.5). Therefore, in order to better support ECMP, a RBridge SHOULD 1102 set the Source Port to a range of values as an entropy field for ECMP 1103 decisions; this range SHOULD be the ephemeral port range 1104 (49152-65535) except that, if there are middleboxes in the path (see 1105 Section 8.5), it MUST be possible to configure the range of different 1106 Source Port values to a sufficiently small range to avoid disrupting 1107 connectivity. 1109 8.4 MTU Considerations 1111 In TRILL each RBridge advertises in its LSP number zero the largest 1112 LSP frame it can accept (but not less than 1,470 bytes) on any of its 1113 interfaces (at least those interfaces with adjacencies to other TRILL 1114 switches in the campus) through the originatingLSPBufferSize TLV 1115 [RFC6325] [RFC7177]. The campus minimum MTU (Maximum Transmission 1116 Unit), denoted Sz, is then established by taking the minimum of this 1117 advertised MTU for all RBridges in the campus. Links that do not meet 1118 the Sz MTU are not included in the routing topology. This protects 1119 the operation of IS-IS from links that would be unable to accommodate 1120 the largest LSPs. 1122 A method of determining originatingLSPBufferSize for an RBridge with 1123 one or more TRILL over IP ports is described in [RFC7780]. However, 1124 if an IP link either can accommodate jumbo frames or is a link on 1125 which IP fragmentation is enabled and acceptable, then it is unlikely 1126 that the IP link will be a constraint on the originatingLSPBufferSize 1127 of an RBridge using the link. On the other hand, if the IP link can 1128 only handle smaller frames and fragmentation is to be avoided when 1129 possible, a TRILL over IP port might constrain the RBridge's 1130 originatingLSPBufferSize. 1132 Because TRILL sets the minimum values of Sz at 1,470 bytes, RBridges 1133 will not constrain LSPs or other TRILL IS-IS PDUs to a size smaller 1134 than that. Therefore there may be TRILL over IP links that require 1135 fragmentation to be enabled to accommodate such PDUs. When 1136 fragmentation is enabled, the effective link MTU from the TRILL point 1137 of view is larger than the RBridge port to RBridge port path MTU from 1138 the IP point of view. Path MTU discovery [RFC4821] should be useful 1139 in determining the IP MTU between a pair of RBridge ports with IP 1140 connectivity. 1142 TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in 1143 [RFC7177], can be used to obtain added assurance of the MTU of a 1144 link. An appropriate time to confirm MTU, or re-discover it if it 1145 has changed, is when an RBridge notices topology changes in a path 1146 that is in use for TRILL over IP due to LSP updates it receives; 1147 however, MTU can change at other times. For example, two RBridge 1148 ports are connected by a bridged LAN, topology or configuration 1149 changes within that bridged LAN could change the MTU between those 1150 RBridge ports. 1152 For further discussion of these issues, see [IntareaTunnels]. 1154 8.5 Middlebox Considerations 1156 This section gives some middlebox considerations for the IP 1157 encapsulations covered by this document, namely native and VXLAN 1158 encapsulation. 1160 The requirements for the usage of the zero UDP Checksum in a UDP 1161 tunnel protocol are detailed in [RFC6936]. These requirements apply 1162 to the UDP based TRILL over IP encapsulations specified herein 1163 (native and VXLAN), which are applications of UDP tunnel. 1165 Besides the Checksum, the Source Port number of a UDP or TCP based 1166 ENCAP Hdr is also pertinent to the middlebox behavior. Network 1167 Address/Port Translator (NAPT) is the most commonly deployed Network 1168 Address Translation (NAT) device [RFC4787]. For a UDP or TCP tunnel 1169 protocol, the NAPT device establishes a NAT session to translate the 1170 {private IP address, private source port number} tuple to a {public 1171 IP address, public source port number} tuple, and vice versa, for the 1172 duration of the session. This provides the tunnel protocol 1173 application with the "NAT-pass-through" function. NAPT allows 1174 multiple internal hosts to share a single public IP address. The 1175 Source Port number, is used as the demultiplexer of the multiple 1176 internal hosts. 1178 However, the above NAPT behavior conflicts with the behavior that the 1179 Source Port number is used as an entropy (See Section 8.3). Hence, 1180 the network operator MUST ensure the TRILL switch ports sending 1181 through local or remote NAPT middleboxes limit the entropy usage of 1182 the Source Port number, possibly to a single value. 1184 9. TRILL over IP Port Configuration 1186 This section specifies the configuration information needed at a 1187 TRILL over IP port beyond that needed for a general RBridge port. 1189 9.1 Per IP Port Configuration 1191 Each RBridge port used for a TRILL over IP link should have at least 1192 one IP (v4 or v6) address. If no IP address is associated with the 1193 port, perhaps as a transient condition during re-configuration, the 1194 port is disabled. Implementations MAY allow a single port to operate 1195 as multiple IPv4 and/or IPv6 logical ports. Each IP address 1196 constitutes a different logical port and the RBridge with those ports 1197 MUST associate a different Port ID (see Section 4.4.2 of [RFC6325]) 1198 with each logical port. 1200 By default a TRILL over IP port discards output packets that fail the 1201 possible recursive ingress test (see Section 10.1) unless configured 1202 to disable that test. 1204 9.2 Additional per IP Address Configuration 1206 The configuration information specified below is per TRILL over IP 1207 port IP address. 1209 The mapping from TRILL packet priority to TRILL over IP 1210 Differentiated Services Code Point (DSCP [RFC2474]) can be 1211 configured. If supported, mapping from an inner DSCP code point, when 1212 the TRILL payload is IP, to the outer TRILL over IP DSCP can be 1213 configured. (See Section 4.3.) 1215 Each TRILL over IP port has a list of acceptable encapsulations it 1216 will use as the basis of adjacency. By default this list consists of 1217 one entry for native encapsulation (see Section 7). Additional 1218 encapsulations MAY be configured and native encapsulation MAY be 1219 removed from this list by configuration. Additional configuration can 1220 be required or possible for specific encapsulations as described in 1221 Section 9.2.3. 1223 Each IP address at a TRILL over IP port uses native IP multicast by 1224 default but may be configured whether to use serial IP unicast 1225 (Section 9.2.2) or native IP multicast (Section 9.2.1). Each IP 1226 address at a TRILL over IP is configured whether or not to use IPsec 1227 (Section 9.2.4). 1229 Regardless of whether they will send IP multicast, TRILL over IP 1230 ports emit appropriate IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710]) 1231 packets unless configured not to do so. These are sent for the IP 1232 multicast group the port would use if it sent IP multicast. 1234 9.2.1 Native Multicast Configuration 1236 If a TRILL over IP port address is using native IP multicast for 1237 multi-destination TRILL packets (IS-IS and data), by default 1238 transmissions from that IP address use the IP multicast address (IPv4 1239 or IPv6) specified in Section 11.2. The TRILL over IP port may be 1240 configured to use a different IP multicast address for multicasting 1241 packets. 1243 9.2.2 Serial Unicast Configuration 1245 If a TRILL over IP port address has been configured to use serial 1246 unicast for multi-destination packets (IS-IS and data), it should 1247 have associated with it a non-empty list of unicast IP destination 1248 addresses with the same IP version as the version of the port's IP 1249 address (IPv4 or IPv6). Multi-destination TRILL packets are serially 1250 unicast to the addresses in this list. Such a TRILL over IP port will 1251 only be able to form adjacencies [RFC7177] with the RBridges at the 1252 addresses in this list as those are the only RBridges to which it 1253 will send TRILL Hellos. IP packets received from a source IP address 1254 not on the list are discarded. 1256 If this list of destination IP addresses is empty, the port is 1257 disabled. 1259 9.2.3 Encapsulation Specific Configuration 1261 Specific TRILL over IP encapsulation methods may provide for further 1262 configuration as specified below. 1264 9.2.3.1 UDP and TCP Source Port 1266 As discussed above, the UDP based encapsulation (Sections 5.4 and 1267 5.5) and the TCP encapuslation (Section 5.6) start with a header 1268 containing a source port number that can be used for entropy (Section 1269 8.3). The range of source port values used defaults to the ephemeral 1270 port range (49152-65535) but can be configured to any other range 1271 including to a single value. 1273 9.2.3.2 VXLAN Configuration 1275 A TRILL over IP port using VXLAN encapsulation can be configured with 1276 non-default VXLAN Network Identifiers (VNIs) that are used in that 1277 field of the VXLAN header for all TRILL IS-IS and TRILL Data packets 1278 sent using the encapsulation and required in those received using the 1279 encapsulation. The default VNI is 1 for TRILL IS-IS and 2 for TRILL 1280 Data. A TRILL packet received with the an unknown VNI is discarded. 1282 A TRILL over IP port using VXLAN encapsulation can also be configured 1283 to map the Inner.VLAN of a TRILL Data packet being transported to the 1284 value it places in the VNI field and/or to copy the Inner.FGL 1285 [RFC7172] of a TRILL Data packet to the VNI field. 1287 9.2.3.3 Other Encapsulation Configuration 1289 Additional encapsulation methods, beyond those specified in this 1290 document, are expected to be specified in future documents and may 1291 require further configuration. 1293 9.2.4 Security Configuration 1295 A TRILL over IP port can be configured, for the case where IS-IS 1296 security [RFC5310] is in use, as to whether or not IPsec must be 1297 fully established and used for any TRILL IS-IS transmissions other 1298 than IS-IS Hello or MTU PDUs (see Section 7). There may also be 1299 configuration whose details are outside the scope of this document 1300 concerning certificate based IPsec or use of shared keys other than 1301 IS-IS based shared key or how to select what IS-IS based shared key 1302 to use. 1304 10. Security Considerations 1306 TRILL over IP is subject to all of the security considerations for 1307 the base TRILL protocol [RFC6325]. In addition, there are specific 1308 security requirements for different TRILL deployment scenarios, as 1309 discussed in the "Use Cases for TRILL over IP", Section 3 above. 1311 For communication between end stations in a TRILL campus, security 1312 may be possible at three levels: end-to-end security between those 1313 end stations, edge-to-edge security between ingress and egress 1314 RBridges [LinkSec], and link security to protect a TRILL hop. Any 1315 combination of these can be used, including all three. 1317 TRILL over IP link security protects the contents of TRILL Data and 1318 IS-IS packets, including the identities of the end stations for 1319 data and the identities of the edge RBridges, from observers of 1320 the link and transit devices within the link such as bridges or IP 1321 routers, but does not encrypt the link local IP addresses used in 1322 a packet and does not protect against observation by the sending 1323 and receiving RBridges on the link. 1325 Edge-to-edge TRILL security would protect the contents of TRILL data 1326 packets including the identities of the end stations for data from 1327 transit RBridges but does not encrypt the identities of the edge 1328 RBridges involved and does not protect against observation by 1329 those edge RBridges. It is anticipated that edge-to-edge TRILL 1330 security will be covered in future documents. 1332 End-to-end security does not protect the identities of the end 1333 stations or edge RBridge involved but does protect the content of 1334 TRILL data packets from observation by all RBridges or other 1335 intervening devices between the end stations involved. End-to-end 1336 security should always be considered as an added layer of security 1337 to protect any particularly sensitive information from unintended 1338 disclosure. Such end station to end station security is generally 1339 beyond the scope of TRILL 1341 If VXLAN encapsulation is used, the unused Ethernet source and 1342 destination MAC addresses mentioned in Section 5.5, provide a 96 bit 1343 per packet side channel. 1345 10.1 IPsec 1347 This document specifies that all RBridges that support TRILL over IP 1348 links MUST implement IPsec for the security of such links, and makes 1349 it clear that it is both wise and good to use IPsec in all cases 1350 where a TRILL over IP link will traverse a network that is not under 1351 the same administrative control as the rest of the TRILL campus or is 1352 not secure. IPsec is important, in these cases, to protect the 1353 privacy and integrity of data traffic. However, in cases where IPsec 1354 is impractical due to lack of fast path support, use of TRILL edge- 1355 to-edge security or use by the end stations of end-to-end security 1356 can provide significant security. 1358 Further Security Considerations for IPsec ESP and for the 1359 cryptographic algorithms used with IPsec can be found in the RFCs 1360 referenced by this document. 1362 10.2 IS-IS Security 1364 TRILL over IP is compatible with the use of IS-IS Security [RFC5310], 1365 which can be used to authenticate TRILL switches before allowing them 1366 to join a TRILL campus. This is sufficient to protect against rogue 1367 devices impersonating TRILL switches, but is not sufficient to 1368 protect data packets that may be sent in TRILL over IP outside of the 1369 local network or across the public Internet. To protect the privacy 1370 and integrity of that traffic, use IPsec. 1372 In cases were IPsec is used, the use of IS-IS security may not be 1373 necessary, but there is nothing about this specification that would 1374 prevent using both IPsec and IS-IS security together. 1376 11. IANA Considerations 1378 IANA considerations are given below. 1380 11.1 Port Assignments 1382 IANA is requested to assign destination Ports in the Service Name and 1383 Transport Protocol Port Number Registry [PortRegistry] for TRILL IS- 1384 IS and TRILL Data as shown below. 1386 Service Name: TRILL-IS-IS 1387 Transport Protocol: udp, tcp 1388 Assignee: iesg@ietf.org 1389 Contact: chair@ietf.org 1390 Description: Transport of TRILL IS-IS control PDUs. 1391 Reference: [this document] 1392 Port Number: (TBD1) 1394 Service Name: TRILL-data 1395 Transport Protocol: udp, tcp 1396 Assignee: iesg@ietf.org 1397 Contact: chair@ietf.org 1398 Description: Transport of TRILL Data packets. 1399 Reference: [this document] 1400 Port Number: (TBD2) 1402 11.2 Multicast Address Assignments 1404 IANA is requested to assign one IPv4 and one IPv6 multicast address, 1405 as shown below, which correspond to both the All-RBridges and All-IS- 1406 IS-RBridges multicast MAC addresses that have been assigned for 1407 TRILL. Because the low level hardware MAC address dispatch 1408 considerations for TRILL over Ethernet do not apply to TRILL over IP, 1409 one IP multicast address for each version of IP is sufficient. 1411 (Values recommended to IANA in square brackets) 1413 Name IPv4 IPv6 1414 ------------ ------------------ -------------------------- 1415 All-RBridges TBD3[233.252.1.32] TBD4[FF0X:0:0:0:0:0:0:BAC1] 1417 The hex digit "X" in the IPv6 variable scope address indicates the 1418 scope and defaults to 8. The IPv6 All-RBridges IP address may be used 1419 with other values of X. 1421 11.3 Encapsulation Method Support Indication 1423 The existing "RBridge Channel Protocols" registry is re-named and a 1424 new sub-registry under that registry added as follows: 1426 The TRILL Parameters registry for "RBridge Channel Protocols" is 1427 renamed the "RBridge Channel Protocols and Link Technology Specific 1428 Flags" registry. [this document] is added as a second reference for 1429 this registry. The first part of the table is changed to the 1430 following: 1432 Range Registration Note 1433 ----------- ---------------- ---------------------------- 1434 0x002-0x0FF Standards Action 1435 0x100-0xFCF RFC Required allocation of a single value 1436 0x100-0xFCF IESG Approval allocation of multiple values 1437 0xFD0 0xFF7 see Note link technology dependent, 1438 see subregistry 1440 In the existing table of RBridge Channel Protocols, the following 1441 line is changed to two lines as shown: 1443 OLD 1444 0x004-0xFF7 Unassigned 1445 NEW 1446 0x004-0xFCF Unassigned 1447 0xFD0-0xFF7 (link technology dependent, see subregistry) 1449 A new indented subregistry under the re-named "RBridge Channel 1450 Protocols and Link Technology Specific Flags" registry is added as 1451 follows: 1453 Name: TRILL over IP Link Flags 1454 Registration Procedure: Expert Review 1455 Reference: [this document] 1457 Flag Meaning Reference 1458 ----------- ------------------------------ --------- 1459 0xFD0 Native encapsulation supported [this document] 1460 0xFD1 VXLAN encapsulation supported [this document] 1461 oxFD2 TCP encapsulation supported [this document] 1462 0xFD3-0xFF7 Unassigned 1464 Normative References 1466 [IS-IS] - "Intermediate system to Intermediate system routeing 1467 information exchange protocol for use in conjunction with the 1468 Protocol for providing the Connectionless-mode Network Service 1469 (ISO 8473)", ISO/IEC 10589:2002, 2002". 1471 [RFC0020] - Cerf, V., "ASCII format for network interchange", STD 80, 1472 RFC 20, DOI 10.17487/RFC0020, October 1969, . 1475 [RFC0768] - Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1476 10.17487/RFC0768, August 1980, . 1479 [RFC0793] - Postel, J., "Transmission Control Protocol", STD 7, RFC 1480 793, DOI 10.17487/RFC0793, September 1981, . 1483 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1484 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1485 March 1997, . 1487 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 1488 "Definition of the Differentiated Services Field (DS Field) in 1489 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 1490 December 1998, . 1492 [RFC2710] - Deering, S., Fenner, W., and B. Haberman, "Multicast 1493 Listener Discovery (MLD) for IPv6", RFC 2710, DOI 1494 10.17487/RFC2710, October 1999, . 1497 [RFC2914] - Floyd, S., "Congestion Control Principles", BCP 41, RFC 1498 2914, DOI 10.17487/RFC2914, September 2000, . 1501 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1502 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 1503 10.17487/RFC3168, September 2001, . 1506 [RFC3376] - Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1507 Thyagarajan, "Internet Group Management Protocol, Version 3", 1508 RFC 3376, DOI 10.17487/RFC3376, October 2002, . 1511 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1512 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1513 2005, . 1515 [RFC4303] - Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1516 4303, DOI 10.17487/RFC4303, December 2005, . . 1520 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1521 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1522 5310, DOI 10.17487/RFC5310, February 2009, . 1525 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 1526 Expand Key Derivation Function (HKDF)", RFC 5869, DOI 1527 10.17487/RFC5869, May 2010, . 1530 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1531 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1532 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1533 . 1535 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 1536 "Transparent Interconnection of Lots of Links (TRILL): 1537 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 1538 DOI 10.17487/RFC7175, May 2014, . 1541 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1542 D., and A. Banerjee, "Transparent Interconnection of Lots of 1543 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 1544 May 2014, . 1546 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1547 and V. Manral, "Transparent Interconnection of Lots of Links 1548 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 1549 . 1551 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1552 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1553 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 1554 2014, . 1556 [RFC7321] - McGrew, D. and P. Hoffman, "Cryptographic Algorithm 1557 Implementation Requirements and Usage Guidance for 1558 Encapsulating Security Payload (ESP) and Authentication Header 1559 (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 1560 . 1562 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1563 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1564 eXtensible Local Area Network (VXLAN): A Framework for 1565 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 1566 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 1569 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 1570 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 1571 Lots of Links (TRILL): Clarifications, Corrections, and 1572 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 1573 . 1575 Informative References 1577 [RFC4787] - Audet, F., Ed., and C. Jennings, "Network Address 1578 Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 1579 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, 1580 . 1582 [RFC4821] - Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1583 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1584 . 1586 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1587 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 1588 10.17487/RFC6234, May 2011, . 1591 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1592 Interconnection of Lots of Links (TRILL) Protocol Control 1593 Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, 1594 . 1596 [RFC6864] - Touch, J., "Updated Specification of the IPv4 ID Field", 1597 RFC 6864, DOI 10.17487/RFC6864, February 2013, . 1600 [RFC6936] - Fairhurst, G. and M. Westerlund, "Applicability Statement 1601 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1602 6936, DOI 10.17487/RFC6936, April 2013, . 1605 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1606 and D. Dutt, "Transparent Interconnection of Lots of Links 1607 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 1608 10.17487/RFC7172, May 2014, . 1611 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 1612 "Transparent Interconnection of Lots of Links (TRILL) Transport 1613 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 1614 . 1616 [RFC7296] - Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1617 Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", 1618 STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, 1619 . 1621 [RFC8085] - Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1622 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 1623 2017, . 1625 [RFC8086] - Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1626 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1627 2017, . 1629 [IntareaTunnels] - J. Touch, M. Townsley, "IP Tunnels int he Internet 1630 Architecture", draft-ietf-intarea-tunnels, work in progress. 1632 [LinkSec] - Eastlake, D., D. Zhang, "TRILL: Link Security", draft- 1633 eastlake-trill-link-security, work in progress. 1635 [TRILLECN] - Eastlake, D., B. Briscoe, "TRILL: ECN (Explicit 1636 Congestion Notification) Support", draft-ietf-trill-ecn- 1637 support, work in progress. 1639 [PortRegistry] - https://www.iana.org/assignments/service-names-port- 1640 numbers/service-names-port-numbers.xhtml 1642 Acknowledgements 1644 The following people have provided useful feedback on the contents of 1645 this document: Sam Hartman, Adrian Farrel, Radia Perlman, Ines 1646 Robles, Joe Touch, Mohammed Umair, Lucy Yong. 1648 Some of the material in this document is derived from [RFC8085] and 1649 [RFC8086]. 1651 The document was prepared in raw nroff. All macros used were defined 1652 within the source file. 1654 Authors' Addresses 1656 Margaret Cullen 1657 Painless Security 1658 14 Summer Street, Suite 202 1659 Malden, MA 02148 1660 USA 1662 Phone: +1-781-605-3459 1663 Email: margaret@painless-security.com 1664 URI: http://www.painless-security.com 1666 Donald Eastlake 1667 Huawei Technologies 1668 155 Beaver Street 1669 Milford, MA 01757 1670 USA 1672 Phone: +1 508 333-2270 1673 Email: d3e3e3@gmail.com 1675 Mingui Zhang 1676 Huawei Technologies 1677 No.156 Beiqing Rd. Haidian District, 1678 Beijing 100095 P.R. China 1680 EMail: zhangmingui@huawei.com 1682 Dacheng Zhang 1683 Huawei Technologies 1685 Email: dacheng.zhang@huawei.com 1687 Copyright, Disclaimer, and Additional IPR Provisions 1689 Copyright (c) 2017 IETF Trust and the persons identified as the 1690 document authors. All rights reserved. 1692 This document is subject to BCP 78 and the IETF Trust's Legal 1693 Provisions Relating to IETF Documents 1694 (http://trustee.ietf.org/license-info) in effect on the date of 1695 publication of this document. Please review these documents 1696 carefully, as they describe your rights and restrictions with respect 1697 to this document. Code Components extracted from this document must 1698 include Simplified BSD License text as described in Section 4.e of 1699 the Trust Legal Provisions and are provided without warranty as 1700 described in the Simplified BSD License.