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