idnits 2.17.1 draft-ietf-trill-over-ip-03.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 (July 6, 2015) is 3215 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 7348 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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 Huawei 6 Dacheng Zhang 7 Alibaba 8 Expires: January 5, 2016 July 6, 2015 10 Transparent Interconnection of Lots of Links (TRILL) over IP 11 13 Abstract 14 The Transparent Interconnection of Lots of Links (TRILL) protocol is 15 implemented by devices called TRILL Switches or RBridges (Routing 16 Bridges). TRILL supports both point-to-point and multi-access links 17 and is designed so that a variety of link protocols can be used 18 between TRILL switch ports. This document standardizes methods for 19 encapsulating TRILL in IP (v4 or v6) so as to use IP as a TRILL link 20 protocol in a unified TRILL campus. It updates RFC 7177 and RFC 7178. 22 Status of This Document 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the author or the DNSEXT mailing list . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................4 48 2. Terminology.............................................4 50 3. Use Cases for TRILL over IP.............................5 51 3.1 Remote Office Scenario.................................5 52 3.2 IP Backbone Scenario...................................5 53 3.3 Important Properties of the Scenarios..................5 54 3.3.1 Security Requirements................................6 55 3.3.2 Multicast Handling...................................6 56 3.3.3 RBridge Neighbor Discovery...........................7 58 4. TRILL Packet Formats....................................8 59 5. Some Link Protocol Specifics............................9 61 6. TRILL over IP Port Configuration.......................10 62 6.1 Per IP Port Configuration.............................10 63 6.2 Additional per IP Address Cofiguration................10 64 6.2.1 Native Multicast Configuration......................10 65 6.2.2 Serial Unicast Configuration........................11 66 6.2.3 Encapsulation Specific Configuration................11 67 6.2.3.1 VXLAN Configuration...............................11 68 6.2.3.2 Other Encapsulation Configuration.................12 69 6.2.4 Security Configuration..............................12 71 7. TRILL over IP Encapsulation Formats....................13 72 7.1 Encapsulation Agreement...............................14 73 7.2 IPsec ESP Format......................................14 74 7.3 Broadcast Link Encapsulation Considerations...........15 75 7.4 Native Encapsulaton...................................15 76 7.5 VXLAN Encapsulation...................................16 77 7.6 Other Encpaulsations..................................17 79 8. Handling Multicast.....................................18 81 9. Use of IPsec...........................................19 82 9.1 Default Keys..........................................19 83 9.2 Mandatory-to-Implement Algorithms.....................19 85 10. Transport Considerations..............................20 86 10.1 Recursive Ingress....................................20 87 10.2 Fat Flows............................................20 88 10.3 Congestion Considerations............................21 89 10.4 MTU Considerations...................................22 90 10.5 QoS Considerations...................................23 92 11. Middlebox Considerations..............................24 93 12. Security Considerations...............................25 95 Table of Contents (continued) 97 13. IANA Considerations...................................26 98 13.1 Port Assignments.....................................26 99 13.2 Multicast Address Assignments........................26 100 13.3 Encapsulation Method Support Indication..............26 102 Normative References......................................28 103 Informative References....................................30 105 Acknowledgements..........................................31 107 Authors' Addresses........................................32 109 1. Introduction 111 TRILL switches (RBridges) are devices that implement the IETF TRILL 112 protocol [RFC6325] [RFC7177] [rfc7180bis]. 114 RBridges provide transparent forwarding of frames within an arbitrary 115 network topology, using least cost paths for unicast traffic. They 116 support not only VLANs and Fine Grained Labels [RFC7172] but also 117 multipathing of unicast and multi-destination traffic. They use IS-IS 118 link state routing and encapsulation with a hop count. 120 Ports on different RBridges can communicate with each other over 121 various link types, such as Ethernet [RFC6325], pseudowires 122 [RFC7173], or PPP [RFC6361]. 124 This document defines a method for RBridges to communicate over IP 125 (v4 or v6). TRILL over IP will allow Internet-connected RBridges to 126 form a single TRILL campus, or multiple TRILL over IP networks within 127 a campus to be connected as a single TRILL campus via a TRILL over IP 128 backbone. 130 TRILL over IP connects RBridge ports using IPv4 or IPv6 as a 131 transport in such a way that the ports appear to TRILL to be 132 connected by a single multi-access link. Therefore, if more than two 133 RBridge ports are connected via a single TRILL over IP link, any pair 134 of them can communicate. 136 To support the scenarios where RBridges are connected via IP paths 137 (such as over the public Internet) that are not under the same 138 administrative control as the TRILL campus and/or not physically 139 secure, this document specifies the use of IPsec [RFC4301] 140 Encapsulating Security Protocol [RFC4303] to secure all or part of 141 such paths. 143 To support the use of TRILL over IP encapsulation with good fast path 144 hardware support, a method is provided for agreement between adjacent 145 TRILL switches as to what encapsulation to use. This document 146 updates [RFC7177] and [RFC7178] as described in Section 7 by 147 redefining an interval of RBridge Channel protocol numbers to 148 indicate encapsulation method support for TRILL over IP and by making 149 adjacency between TRILL over IP ports dependent on having a method of 150 encapsulation in common. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 3. Use Cases for TRILL over IP 160 This section introduces two application scenarios (a remote office 161 scenario and an IP backbone scenario) which cover typical situations 162 where network administrators may choose to use TRILL over an IP 163 network to connect TRILL switches. 165 3.1 Remote Office Scenario 167 In the Remote Office Scenario, a remote TRILL network is connected to 168 a TRILL campus across a multihop IP network, such as the public 169 Internet. The TRILL network in the remote office becomes a part of 170 TRILL campus, and nodes in the remote office can be attached to the 171 same VLANs or Fine Grained Labels [RFC7172] as local campus nodes. In 172 many cases, a remote office may be attached to the TRILL campus by a 173 single pair of RBridges, one on the campus end, and the other in the 174 remote office. In this use case, the TRILL over IP link will often 175 cross logical and physical IP networks that do not support TRILL, and 176 are not under the same administrative control as the TRILL campus. 178 3.2 IP Backbone Scenario 180 In the IP Backbone Scenario, TRILL over IP is used to connect a 181 number of TRILL networks to form a single TRILL campus. For example, 182 a TRILL over IP backbone could be used to connect multiple TRILL 183 networks on different floors of a large building, or to connect TRILL 184 networks in separate buildings of a multi-building site. In this use 185 case, there may often be several TRILL switches on a single TRILL 186 over IP link, and the IP link(s) used by TRILL over IP are typically 187 under the same administrative control as the rest of the TRILL 188 campus. 190 3.3 Important Properties of the Scenarios 192 There are a number of differences between the above two application 193 scenarios, some of which drive features of this specification. These 194 differences are especially pertinent to the security requirements of 195 the solution, how multicast data frames are handled, and how the 196 TRILL switch ports discover each other. 198 3.3.1 Security Requirements 200 In the IP Backbone Scenario, TRILL over IP is used between a number 201 of RBridge ports, on a network link that is in the same 202 administrative control as the remainder of the TRILL campus. While it 203 is desirable in this scenario to prevent the association of 204 unauthorized RBridges, this can be accomplished using existing IS-IS 205 security mechanisms. There may be no need to protect the data 206 traffic, beyond any protections that are already in place on the 207 local network. 209 In the Remote Office Scenario, TRILL over IP may run over a network 210 that is not under the same administrative control as the TRILL 211 network. Nodes on the network may think that they are sending traffic 212 locally, while that traffic is actually being sent, in an IP tunnel, 213 over the public Internet. It is necessary in this scenario to protect 214 the integrity and confidentiality of user traffic, as well as 215 ensuring that no unauthorized RBridges can gain access to the RBridge 216 campus. The issues of protecting integrity and confidentiality of 217 user traffic are addressed by using IPsec for both TRILL IS-IS and 218 TRILL Data packets between RBridges in this scenario. 220 3.3.2 Multicast Handling 222 In the IP Backbone scenario, native IP multicast may be supported on 223 the TRILL over IP link. If so, it can be used to send TRILL IS-IS and 224 multicast data packets, as discussed later in this document. 225 Alternatively, multi-destination packets can be transmitted serially 226 by IP unicast to the intended recipients. 228 In the Remote Office Scenario there will often be only one pair of 229 RBridges connecting a given site and, even when multiple RBridges are 230 used to connect a Remote Office to the TRILL campus, the intervening 231 network may not provide reliable (or any) multicast connectivity. 232 Issues such as complex key management also make it difficult to 233 provide strong data integrity and confidentiality protections for 234 multicast traffic. For all of these reasons, the connections between 235 local and remote RBridges will commonly be treated like point-to- 236 point links, and all TRILL IS-IS control messages and multicast data 237 packets that are transmitted between the Remote Office and the TRILL 238 campus will be serially transmitted by IP unicast, as discussed later 239 in this document. 241 3.3.3 RBridge Neighbor Discovery 243 In the IP Backbone Scenario, RBridges that use TRILL over IP can use 244 the normal TRILL IS-IS Hello mechanisms to discover the existence of 245 other RBridges on the link [RFC7177], and to establish authenticated 246 communication with those RBridges. 248 In the Remote Office Scenario, an IPsec session will need to be 249 established before TRILL IS-IS traffic can be exchanged, as discussed 250 below. In this case, one end will need to be configured to establish 251 a IPSEC session with the other. This will typically be accomplished 252 by configuring the RBridge or a border device at a Remote Office to 253 initiate an IPsec session and subsequent TRILL exchanges with a TRILL 254 over IP-enabled RBridge attached to the TRILL campus. 256 4. TRILL Packet Formats 258 To support the TRILL base protocol standard [RFC6325], two types of 259 packets are transmitted between RBridges: TRILL Data packets and 260 TRILL IS-IS packets. 262 The on-the-wire form of a TRILL Data packet in transit between two 263 neighboring RBridges is as shown below: 265 +--------------+----------+----------------+-----------+ 266 | TRILL Data | TRILL | Native Frame | Link | 267 | Link Header | Header | Payload | Trailer | 268 +--------------+----------+----------------+-----------+ 270 Where the encapsulated Native Frame Payload is similar to an Ethernet 271 frame with a VLAN tag or Fine Grained Label [RFC7172] but with no 272 trailing Frame Check Sequence (FCS). 274 TRILL IS-IS packets are formatted on-the-wire as follows: 276 +--------------+---------------+-----------+ 277 | TRILL IS-IS | TRILL IS-IS | Link | 278 | Link Header | Payload | Trailer | 279 +--------------+---------------+-----------+ 281 The Link Header and Link Trailer in these formats depend on the 282 specific link technology. The Link Header contains one or more fields 283 that distinguish TRILL Data from TRILL IS-IS. For example, over 284 Ethernet, the TRILL Data Link Header ends with the TRILL Ethertype 285 while the TRILL IS-IS Link Header ends with the L2-IS-IS Ethertype; 286 on the other hand, over PPP, there are no Ethertypes but PPP protocol 287 code points are included that distinguish TRILL Data from TRILL IS- 288 IS. 290 In TRILL over IP, we will use IP (v4 or v6) in the link header. (On 291 the wire, the IP header will be preceeded by the lower layer protocol 292 that is carrying IP, such as Ethernet.) However, there are several IP 293 based encapsulations usable for TRILL over IP as further discussed in 294 Section 7 that differ in exactly what appears after the IP header and 295 before the TRILL header. 297 5. Some Link Protocol Specifics 299 TRILL Data packets can be unicast to a specific RBridge or multicast 300 to all RBridges on a link. TRILL IS-IS packets are always multicast 301 to all other RBridge on the link (except for MTU PDUs, which may be 302 unicast [RFC7177]. On Ethernet links, the Ethernet multicast address 303 All-RBridges is used for TRILL Data and All-IS-IS-RBridges for TRILL 304 IS-IS. 306 To properly handle TRILL base protocol packets on a TRILL over IP 307 link in the general case, either native IP multicast mode must be 308 used on that link, or multicast must be simulated using serial IP 309 unicast, as discussed in Section 8. (Of course, if the IP link 310 happens to actually be point-to-point no special provision is needed 311 for handling multicast addressed packets.) 313 In TRILL Hello PDUs used on TRILL IP links, the IP addresses of the 314 connected IP ports are their real SNPA (SubNetwork Point of 315 Attachment [IS-IS]) addresses and, for IPv6, the 16-byte IPv6 address 316 is used as the SNPA; however, for easy in re-using code designed for 317 common 48-bit IS-IS SNPAs, for TRILL over IPv4, a 48-bit synthetic 318 SNPA that looks like a unicast MAC address is constructed for use in 319 the SNPA field of TRILL Neighbor TLVs [RFC7176] [RFC7177] on that 320 link. This synthetic SNPA derived from an IPv4 address is as follows: 322 1 1 1 1 1 1 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | 0xFE | 0x00 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | IPv4 upper half | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | IPv4 lower half | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 This synthetic SNPA (MAC) address has the local (0x02) bit on in the 333 first byte and so cannot conflict with any globally unique 48-bit 334 Ethernet MAC. However, at the IP level, where TRILL operates on an IP 335 link, TRILL sees only IP stations, not MAC stations, even if the 336 TRILL over IP Link is being carried over Ethernet, so conflict on the 337 link in TRILL IS-IS between a real MAC address and the synethic SNPA 338 (MAC) address as above would be impossible in any case. 340 6. TRILL over IP Port Configuration 342 This section specifies the configuration information needed at a 343 TRILL over IP port beyond that needed for a general RBridge port. 345 6.1 Per IP Port Configuration 347 Each RBridge port used for a TRILL over IP link should have at least 348 one IP (v4 or v6) address. If no IP address is associated with the 349 port, perhaps as a transient condition during re-configuration, the 350 port is disabled. Implementations MAY allow a single port to operate 351 as multiple IPv4 and/or IPv6 logical ports. Each IP address 352 constitutes a different logical port and the RBridge with those ports 353 MUST associate a different Port ID (see Section 4.4.2 of [RFC6325]) 354 with each logical port. 356 By default an TRILL over IP port discards output packets that fail 357 the possible recursive ingress test (see Section 10.1) unless 358 configured to disable that test. 360 6.2 Additional per IP Address Cofiguration 362 The configuration information specified below is per IP address at a 363 TRILL over IP port. 365 The mapping from TRILL packet priority to Differentiated Services 366 Code Point (DSCP [RFC2474]) can be configured (see Section 10.5). 368 Each TRILL over IP port has a list of acceptable encapsulations it 369 will use. By default this list consists of one entry for native 370 encapsulation. (See Section 7.) Additional configuration is possible 371 for specific encapsulations as described in Section 6.2.3. 373 Each IP address at a TRILL over IP port uses native IP multicast by 374 default but may be configured whether to use serial IP unicast 375 (Section 6.2.2) or native IP multicast (Section 6.2.1). Each IP 376 address at a TRILL over IP is configured whether or not to use IPsec 377 (Section 6.2.3). 379 6.2.1 Native Multicast Configuration 381 If a TRILL over IP port address is using native IP multicast for 382 multi-destination TRILL packets (IS-IS and data), by default 383 transmissions from that IP address use the appropriate IP multicast 384 address (IPv4 or IPv6) specified in Section 13.2. The TRILL over IP 385 port may be configured to use a different IP multicast address for 386 multi-destination packets. 388 6.2.2 Serial Unicast Configuration 390 If a TRILL over IP port address has been configured to use serial 391 unicast for multi-destination packets (IS-IS and data), it should 392 have associated with it a non-empty list of unicast IP destination 393 addresses with the same IP version as the version of the ports IP 394 address (IPv4 or IPv6). Multi-destination TRILL packets are serially 395 unicast to the addresses in this list. Such a TRILL over IP port will 396 only be able to form adjacencies [RFC7177] with the RBridges at the 397 addresses in this list as those are the only RBridges to which it 398 will send TRILL Hellos. 400 If this list of destination IP addresses is empty, there is no way to 401 transmit a multi-destination TRILL over IP packet such as a TRILL 402 Hello. Thus it is impossible to achieve adjacency [RFC7177] or if 403 adjacency had been achieved (perhaps the list was non-empty and has 404 just been configured to be empty), no way to maintain such adjacency. 405 Thus, in the empty list case, TRILL Data multi-destination packets 406 cannot be sent and TRILL Data unicast packets will not start flowing 407 or, if they are already flowing, will soon cease, effectively 408 disabling the port. 410 6.2.3 Encapsulation Specific Configuration 412 Specific TRILL over IP encapsulation methods may provide for futher 413 configuration as specified in the subsections below. 415 6.2.3.1 VXLAN Configuration 417 A TRILL over IP port using VXLAN encapsulation can be configured with 418 a non-default VXLAN Network Identifier (VNI) which is used in that 419 field of the VXLAN header for all TRILL packets sent using the 420 encapsulation and required in all TRILL packets received using the 421 encapsulation. In this case, a TRILL packet received with the wrong 422 VNI is discarded. 424 A TRILL over IP port using VXLAN encapsulation can also be configured 425 to place the Inner.VLAN or Inner.FGL of a TRILL Data packet being 426 transported in the VNI field. 428 6.2.3.2 Other Encapsulation Configuration 430 [Specific configuration for other encapsulation methods will be added 431 here.] 433 6.2.4 Security Configuration 435 tbd ... 437 7. TRILL over IP Encapsulation Formats 439 There are a variety of TRILL over IP formats possible. In all cases, 440 there must be a method specified, with each format, to distinguish 441 TRILL Data and TRILL IS-IS packets, or that format is not useful for 442 TRILL. The following criteria can be helpful is choosing between 443 different encapsulations: 445 a) Fast path support - For most applications, it is highly desireable 446 to be able to encapsulate/decpasulate TRILL over IP at line speed 447 so a format where existing or anticipated fast path hardware can 448 do that is best. 450 b) Ease of multi-pathing - The IP path between TRILL over IP port may 451 include internal equal cost multipath routes so a method of 452 encapsulation that provides variable fields available for existing 453 or anticipated fast path hardware multi-pathing is better. 455 c) Fragmentaton and robust ID support - tbd 457 d) Checksum strength - Depending on the particular circumstances of 458 the TRILL over IP link, a checksum provided by the encapsulation 459 may be an important factor. Use of IPsec as provided herein can 460 also provide a strong integrity check. 462 TRILL over IP adopts a hybrid encapsulation approach by default. 464 There is one format, called "native encapsulation" that MUST be 465 implemented. Although native encapsulation does not typically have 466 good fast path support, as a lowest common denominator it can be used 467 with low bandwidth control messages to detetmine a preferred 468 encapsulation with better performance. In particular, by default all 469 TRILL IS-IS Hellos are sent using native encapsulation and those 470 Hellos are used to determine the encpasulation used for all TRILL 471 Data packets and all other TRILL IS-IS PDUs with the possible 472 exception of IS-IS MTU-probe and MTU-ack PDUs as discussed in Section 473 7. 475 Alternatively, the network operator can pre-configure a TRILL over IP 476 port to use a particular encapsulation choosen for their particular 477 network needs and TRILL over IP port capabiliies for all TRILL data 478 and IS-IS packets. 480 Section 7.1 discusses encapsulation agreement. Section 7.2 discusses 481 TRILL over IP IPsec ESP format, which is independent of 482 encapsulation. Section 7.3 discusses broadcast link encapsulation 483 considerations. The subsequent subsections discuss particular 484 encapsulations. 486 7.1 Encapsulation Agreement 488 TRILL Hellos sent out a TRILL over IP port indicate the 489 encapsulations that port is willing to use through the mechanism 490 described in [RFC7178] and [RFC7176]. RBridge Channel Protocol 491 numbers 0xFC0 through 0xFF7 are hereby redefined to be link 492 technology dependent flags that, for TRILL over IP, indicate support 493 for different encapsulations, allowing for up to 24 encapsulations to 494 be specified. Support for an encapsulation is indicated in the Hello 495 PDU in the same way that support for an RBridge Channel was 496 indicated. (See also section 13.3.) "Support" indicates willingness 497 to use that encapsulation for TRILL data and TRILL IS-IS other than 498 Hellos. Even if support is not indicated for native encapsulation, by 499 default support for native encapsulation of TRILL Hellos is assumed. 501 If no encapsulation support is indicated in a TRILL Hello, then the 502 port from which it was sent is assumed to support only native 503 encapsualtion (see Section 7.4). 505 An adjacency is formed between two TRILL over IP ports ONLY if the 506 intersection of the sets of encapsulation methods they support is not 507 null. If that intersection is null, then no adjaceny is formed. In 508 particular, for a TRILL over IP link, the adjacency state machine 509 MUST NOT advance to the Report state unless the ports share an 510 encapsulation [RFC7177]. 512 If any TRILL over IP packet, other than a IS-IS Hello or MTU PDU in 513 native encapsulation, is received in an encapsulation for which 514 support is not being indicated, it MUST be discarded (see Section 515 7.3). 517 It expected to normally be the case in a well configured network that 518 all the TRILL over IP ports connected to an IP network that are 519 intended to communicate with each other will support the same 520 encapsulation. But the network will operate correctly if this is not 521 true. 523 7.2 IPsec ESP Format 525 TRILL over IP link security uses IPsec Encapsulating Security 526 Protocol (ESP) in tunnel mode [RFC4303]. Since TRILL over IP always 527 starts with an IP Header (on the wire this appears right after any 528 required Layer 2 header), the modifications when IPsec is in effect 529 are independent of the TRILL over IP encapsulation fields that occur 530 after that IP Header and before the TRILL Header. The resulting 531 packet formats are as follows for IPv4 and IPv6: 533 ------------------------------------------------------------ 534 IPv4 | new IP hdr | | TRILL IP hdr | TRILL | ESP | ESP| 535 |(any options)| ESP | (any options) | Encap2 |Trailer| ICV| 536 ------------------------------------------------------------ 537 |<--------- encryption ---------->| 538 |<------------- integrity ------------->| 540 ------------------------------------------------------------- 541 IPv6 | new |new ext | | orig |orig ext | TRILL | ESP | ESP| 542 |IP hdr| hdrs |ESP|IP hdr| hdrs | Encap2 |Trailer| ICV| 543 ------------------------------------------------------------. 544 |<--------- encryption ----------->| 545 |<------------ integrity ------------->| 547 The "TRILL Encap2" above includes whatever additional fields are 548 required by the encapsulation in use followed by the TRILL Header and 549 then the native frame payload (see Section 4). 551 This architecture permits the ESP tunnel termination to be separated 552 from the TRILL over IP RBridge port and, for example, placed at a 553 physical or administrative security boundary. 555 7.3 Broadcast Link Encapsulation Considerations 557 It is possible for the Hellos from a TRILL over IP port P1 to 558 establish adjacency with multiple other TRILL over IP ports (P2, P3, 559 ...) forming a broadcast link. In a well configured network one would 560 expect such multiple other IP ports to support the same encapsulation 561 but, if P1 supports multiple encapsulations, it is possible that P2 562 and P3, for example, do not have an encapsulation in common that is 563 supported by P1. IS-IS can handle such non-transitive adjacencies 564 which are reported as specified in [RFC7177]. If serial IP unicast is 565 being used by P1, it can use different encapsulatons for different 566 transmission. If native IP multicast is being used by P1, it will 567 have to send one transmission per encapsulation method by which it 568 has an adjanceny on the link. (It is for this reason that a TRILL 569 over IP port MUST discard any packet received with the wrong 570 encapsulation. Otherwise, packets would be duplicated.) 572 7.4 Native Encapsulaton 574 The mandatory to implement "native encapsulaton" format of a TRILL 575 over IP packet, when used without security, is TRILL over UDP as 576 shown below. 578 +----------+--------+-----------------------+ 579 | IP | UDP | TRILL | 580 | Header | Header | Payload | 581 +----------+--------+-----------------------+ 583 Where the UDP Header is as follows: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Source Port = Entropy | Destination Port | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | UDP Length | UDP Checksum | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | TRILL Payload ... 594 Source Port - see Section 10.2 596 Destination Port - indicates TRILL Data or IS-IS, see Section 13 598 UDP Length - as specified in [RFC0768] 600 UDP Checksum - as specified in [RFC0768] 602 The TRILL Payload starts with the TRILL Header (not including the 603 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 604 Intradomain Routeing Protocol Discriminator byte (thus not including 605 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 607 7.5 VXLAN Encapsulation 609 VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, as 610 TRILL over Ethernet over VXLAN over UDP over IP. 612 The outer UDP uses a destination port number indicating VXLAN and the 613 outer UDP source port may be used for entropy as with native 614 encapsulation (see Section 7.2). The VXLAN header after the outer UDP 615 header adds a 24 bit Virtual Network Identifier. The Ethernet header 616 after the VXLAN header and before the TRILL header provides an 617 Ethertype field that distinguishes TRILL data from TRILL IS-IS; 618 however, the destination and source MAC addresses in this inner 619 Ethernet header before the TRILL header are not used and represent 12 620 wasted bytes. 622 A TRILL over IP port using VXLAN encapsulation by default uses a VNI 623 of 1 but can be configured as described in Section 6.2.3.1. 625 7.6 Other Encpaulsations 627 [Additional encpasulations will be added here as additional 628 subsections.] 630 8. Handling Multicast 632 By default, both TRILL IS-IS packets and multi-destination TRILL Data 633 packets are sent to an All-RBridges IPv4 or IPv6 IP multicast Address 634 as appropriate (see Section 13.2); however, a TRILL over IP port may 635 be configured (see Section 6) to use serial IP unicast with a list of 636 one or more unicast IP addresses of other TRILL over IP ports to 637 which multi-destination packets are sent. In that case the outer IP 638 header shows the IP unicast even through the TRILL header has the M 639 bit set to one to indicate multi-destination. Serial unicast 640 configuration is necessary if the TRILL over IP port is connected to 641 an IP network that does not support IP multicast. In any case, 642 unicast TRILL packets are sent by unicast IP. 644 When a TRILL over IP port is using IP multicast, it MUST periodically 645 transmit appropriate IGMP (IPv4 [RFC3376] or MLD (IPv6 [RFC2710]) 646 packets so that the TRILL multicast IP traffic will be sent to it. 648 Although TRILL fully supports broadcast links with more than 2 649 RBridges connected to the link, even where native IP multicast is 650 available, there may be good reasons for configuring TRILL over IP 651 ports to use serial unicast. In some networks, unicast is more 652 reliable than multicast. If multiple unicast connections between 653 parts of a TRILL campus are configured, TRILL will in any case spread 654 traffic across them, treating them as parallel links, and 655 appropriately fail over traffic if a link ceases to operate or 656 incorporate a new link that comes up. 658 9. Use of IPsec 660 All RBridges that support TRILL over IP MUST implement IPsec 661 [RFC4301] and support the use of IPsec Encapsulating Security 662 Protocol (ESP [RFC4303]) to secure both TRILL IS-IS and TRILL data 663 packets. When IPsec is used to secure a TRILL over IP link and no IS- 664 IS security is enabled, the IPsec session MUST be fully established 665 before any TRILL IS-IS or data packets are exchanged. When there is 666 IS-IS security [RFC5310] provided, implementors may elect use IS-IS 667 security to protect TRILL IS-IS packets. However, in this case, the 668 IPsec session still MUST be fully established before any data packets 669 transmission since IS-IS security does not provide any protection to 670 data packets. 672 9.1 Default Keys 674 The default pre-shared keys for IPsec usage are derived as follows: 676 HMAC-SHA256 ("TRILL IP"| IS-IS-shared key ) 678 In the above "|" indicates concatenation, HMAC-SHA256 is as described 679 in [FIPS180] [RFC6234] and "TRILL IP" is the eight byte US ASCII 680 [RFC0020] string indicated. "IS-IS-shared key" is a link (or wider 681 scope) IS-IS key usable for IS-IS security of link local IS-IS local 682 PDUs such as Hello, CSNP, and PSNP. With [RFC5310] there could be 683 multiple keys identified with 16-bit key IDs. In this case, the Key 684 ID of IS-IS-shared key is also used to identify the derived key. 686 Although we are using pre-shared keys at the IPsec level, the IS-IS- 687 shared keys from which they are derived expire and can be updated as 688 described in RFC 5310. The derived keys MUST expire within the 689 lifetime as the IS-IS-shared keys from which they were derived. 691 9.2 Mandatory-to-Implement Algorithms 693 All RBridges that support TRILL over IP MUST implement the following 694 algorithms for IPsec ESP, as recommended in [RFC4308]: 696 Protocol ESP [RFC4303] 697 ESP encryption AES with 128-bit keys in CBC mode [RFC3602] 698 ESP integrity AES-XCBC-MAC-96 [RFC3566] 700 10. Transport Considerations 702 This section discusses a variety of transport considerations. 704 10.1 Recursive Ingress 706 TRILL is designed to transport end station traffic to and from end 707 stations over IEEE 802.3 and IP is frequently transported over IEEE 708 802.3 or similar protocols. Thus, an end station native data frame EF 709 might get TRILL ingressed to TRILL(EF) which was then sent oout a 710 TRILL over IP over 802.3 port resulting in an 802.3 frame of the form 711 802.3(IP(TRILL(EF))). There is a risk of such a packet being re- 712 ingressed by the same TRILL campus, due to physical or logical 713 misconfiguration, looping round, being further re-ingressed, etc. The 714 packet might get discarded if it got too large but if fragmentation 715 is enabled, it would just keep getting split into fragments that 716 would continue to loop and grow and re-fragment until the path was 717 saturated with junk and packets were being discarded due to queue 718 overflow. The TRILL Header TTL would provide no protection because 719 each TRILL ingress adds a new Header and TTL. 721 To protect against this scenario, a TRILL over IP port MUST by, 722 default, test whether a TRILL packet it is about to transmit is, in 723 fact a TRILL ingress of a TRILL over IP over 802.3 or the like 724 packets. That is, is it of the form TRILL(802.3(IP(TRILL(...)))? If 725 so, the default action of the TRILL over IP output port is to discard 726 the packet rather than transmit it. However, there are cases where 727 some level of nested ingress is desired so it MUST be possible to 728 configure the port to allow such packets. 730 10.2 Fat Flows 732 For the purpose of load balancing, it is worthwhile to consider how 733 to transport the TRILL packets over the Equal Cost Multiple Paths 734 (ECMPs) existing internal to the IP path between two TRILL over IP 735 ports. 737 The ECMP election for the IP traffic could be based, at least for 738 IPv4, on the quintuple of the outer IP header { Source IP, 739 Destination IP, Source Port, Destination Port, and IP protocol }. 740 Such tuples, however, could be exactly the same for all TRILL Data 741 packets between two RBridge ports, even if there is a huge amount of 742 data being sent between a variety of ingress and egress RBridges. 743 Therefore, in order to better support ECMP, a RBridge SHOULD set the 744 Source Port as an entropy field for ECMP decisions. (This idea is 745 also introduced in [gre-in-udp].) For example, for TRILL Data this 746 entropy field could be based on the Inner.MacDA, Inner.MacSA, and 747 Inner.VLAN or Inner.FGL. 749 10.3 Congestion Considerations 751 Section 3.1.3 of [RFC5405] discussed the congestion implications of 752 UDP tunnels. As discussed in [RFC5405], because other flows can share 753 the path with one or more UDP tunnels, congestion control [RFC2914] 754 needs to be considered. 756 The default initial determination of the TRILL over IP encapsulation 757 to be used through the exchange of TRILL IS-IS Hellos is a low 758 bandwidth process. Hellos are not permitted to be sent any more often 759 than once per second, and so are unlikely to cause congestion. 761 One motivation for including UDP in a TRILL encapsulation is to 762 improve the use of multipath (such as ECMP) in cases where traffic is 763 to traverse routers which are able to hash on UDP Port and IP 764 address. In many cases this may reduce the occurrence of congestion 765 and improve usage of available network capacity. However, it is also 766 necessary to ensure that the network, including applications that use 767 the network, responds appropriately in more difficult cases, such as 768 when link or equipment failures have reduced the available capacity. 770 The impact of congestion must be considered both in terms of the 771 effect on the rest of the network of a UDP tunnel that is consuming 772 excessive capacity, and in terms of the effect on the flows using the 773 UDP tunnels. The potential impact of congestion from a UDP tunnel 774 depends upon what sort of traffic is carried over the tunnel, as well 775 as the path of the tunnel. 777 TRILL is used to carry a wide range of traffic. In many cases TRILL 778 is used to carry IP traffic. IP traffic is generally assumed to be 779 congestion controlled, and thus a tunnel carrying general IP traffic 780 (as might be expected to be carried across the Internet) generally 781 does not need additional congestion control mechanisms. As specified 782 in [RFC5405]: 784 "IP-based traffic is generally assumed to be congestion- controlled, 785 i.e., it is assumed that the transport protocols generating IP-based 786 traffic at the sender already employ mechanisms that are sufficient 787 to address congestion on the path. Consequently, a tunnel carrying 788 IP-based traffic should already interact appropriately with other 789 traffic sharing the path, and specific congestion control mechanisms 790 for the tunnel are not necessary". 792 For this reason, where TRILL is sent using UDP and used to carry IP 793 traffic that is known to be congestion controlled, the UDP paths MAY 794 be used across any combination of a single or cooperating service 795 providers or across the general Internet. 797 However, TRILL is also used to carry traffic that is not necessarily 798 congestion controlled. For example, TRILL may be used to carry 799 traffic where specific bandwidth guarantees are provided. 801 In such cases congestion may be avoided by careful provisioning of 802 the network and/or by rate limiting of user data traffic. Where TRILL 803 is carried, directly or indirectly, over UDP over IP, the identity of 804 each individual TRILL flow is in general lost. 806 For this reason, where the TRILL traffic is not congestion 807 controlled, TRILL over UDP/IP MUST only be used within a single 808 service provider that utilizes careful provisioning (e.g., rate 809 limiting at the entries of the network while over-provisioning 810 network capacity) to ensure against congestion, or within a limited 811 number of service providers who closely cooperate in order to jointly 812 provide this same careful provisioning. As such, TRILL over UDP/IP 813 MUST NOT be used over the general Internet, or over non-cooperating 814 service providers, to carry traffic that is not congestion- 815 controlled. 817 Measures SHOULD be taken to prevent non-congestion-controlled TRILL 818 over UDP/IP traffic from "escaping" to the general Internet, for 819 example the following: 821 a. Physical or logical isolation of the TRILL over IP links from the 822 general Internet. 824 b. Deployment of packet filters that block the UDP ports assigned for 825 TRILL-over-UDP. 827 c. Imposition of restrictions on TRILL over UDP/IP traffic by 828 software tools used to set up TRILL over UDP paths between 829 specific end systems (as might be used within a single data 830 center). 832 d. Use of a "Managed Circuit Breaker" for the TRILL traffic as 833 described in [circuit-breaker]. 835 10.4 MTU Considerations 837 In TRILL each RBridge advertises in its LSP number zero the largest 838 LSP frame it can accept (but not less than 1,470 bytes) on any of its 839 interfaces (at least those interfaces with adjacencies to other 840 RBridges in the campus) through the originatingLSPBufferSize TLV 841 [RFC6325] [RFC7177]. The campus minimum MTU, denoted Sz, is then 842 established by taking the minimum of this advertised MTU for all 843 RBridges in the campus. Links that do not meet the Sz MTU are not 844 included in the routing topology. This protects the operation of IS- 845 IS from links that would be unable to accommodate some LSPs. 847 A method of determining originatingLSPBufferSize for an RBridge with 848 one or more TRILL over IP ports is described in [rfc7180bis]. 849 However, if an IP link either can accommodate jumbo frames or is a 850 link on which IP fragmentation is enabled and acceptable, then it is 851 unlikely that the IP link will be a constraint on the 852 originatingLSPBufferSize of an RBridge using the link. On the other 853 hand, if the IP link can only handle smaller frames and fragmentation 854 is to be avoided when possible, a TRILL over IP port might constrain 855 the RBridge's originatingLSPBufferSize. Because TRILL sets the 856 minimum values of Sz at 1,470 bytes, there may be links that meet the 857 minimum MTU for the IP protocol (1,280 bytes for IPv6, theoretically 858 68 bytes for IPv4) on which it would be necessary to enable 859 fragmentation for TRILL use. 861 The optional use of TRILL IS-IS MTU PDUs, as specified in [RFC6325] 862 and [RFC7177] can provide added assurance of the actual MTU of a 863 link. 865 10.5 QoS Considerations 867 Within TRILL, priority is indicated by a three bit (0 through 7) 868 priority field in TRILL data packets and by configuration for TRILL 869 IS-IS packets. When TRILL packets are sent on a TRILL over IP link, 870 this priority is mapped to a Differential Services Code Point (DSCP 871 [RFC2474] Section 4.2.2). 873 The default mapping, which may be configured per TRILL over IP port, 874 is an follows. Note that, to provide a potentially lower priority 875 service than the default 0, priority 1 is considered lower priority 876 than 0. So the priority squence from lower to higher priority is 1, 877 0, 2, 3, 4, 5, 6, 7. 879 TRILL Priority DiffServ Field (Binary/decimal) 880 -------------- ------------------------------- 881 0 00100000 / 8 882 1 00000000 / 0 883 2 01000000 / 16 884 3 01100000 / 24 885 4 10000000 / 32 886 5 10100000 / 40 887 6 11000000 / 48 888 7 11100000 / 56 890 11. Middlebox Considerations 892 TBD ... 894 12. Security Considerations 896 TRILL over IP is subject to all of the security considerations for 897 the base TRILL protocol [RFC6325]. In addition, there are specific 898 security requirements for different TRILL deployment scenarios, as 899 discussed in the "Use Cases for TRILL over IP" section above. 901 This document specifies that all RBridges that support TRILL over IP 902 MUST implement IPsec, and makes it clear that it is both wise and 903 good to use IPsec in all cases where a TRILL over IP link will 904 traverse a network that is not under the same administrative control 905 as the rest of the TRILL campus or is not physically secure. IPsec is 906 necessary, in these cases to protect the privacy and integrity of 907 data traffic. 909 TRILL over IP is compatible with the use of IS-IS Security [RFC5310], 910 which can be used to authenticate RBridges before allowing them to 911 join a TRILL campus. This is sufficient to protect against rogue 912 RBridges, but is not sufficient to protect data packets that may be 913 sent in IP outside of the local network, or even across the public 914 Internet. To protect the privacy and integrity of that traffic, use 915 IPsec. 917 In cases were IPsec is used, the use of IS-IS security may not be 918 necessary, but there is nothing about this specification that would 919 prevent using both IPsec and IS-IS security together. In cases where 920 both types of security are enabled, by default, a key derived from 921 the IS-IS key will be used for IPsec. 923 13. IANA Considerations 925 IANA considerations are given below. 927 13.1 Port Assignments 929 IANA has allocated the following destination UDP Ports for the TRILL 930 IS-IS and Data channels: 932 UDP Port Protocol 933 ---------- --------------------- 934 (TBD1) TRILL IS-IS Channel 935 (TBD2) TRILL Data Channel 937 13.2 Multicast Address Assignments 939 IANA has allocated one IPv4 and one IPv6 multicast address, as shown 940 below, which correspond to the All-RBridges and All-IS-IS-RBridges 941 multicast MAC addresses that the IEEE Registration Authority has 942 assigned for TRILL. Because the low level hardware MAC address 943 dispatch considerations for TRILL over Ethernet do not apply to TRILL 944 over IP, one IP multicast address for each version of IP is 945 sufficient. 947 (Values recommended to IANA in square brackets) 949 Name IPv4 IPv6 950 ------------ ------------------ -------------------------- 951 All-RBridges TBD3[233.252.14.0] TBD4[FF0X:0:0:0:0:0:0:205] 953 Note: when these IPv4 and IPv6 multicast addresses are used and the 954 resulting IP frame is sent over Ethernet, the usual IP derived MAC 955 address is used. 957 [Need to discuss scopes for IPv6 multicast (the "X" in the addresses) 958 somewhere. Default to "site" scope but MUST be configurable?] 960 13.3 Encapsulation Method Support Indication 962 The existing "RBridge Channel Protocols" registry is re-named and a 963 new sub-registry under that registry added as follows: 965 The TRILL Parameters registry for "RBridge Channel Protocols" is 966 renamed the "RBridge Channel Protocols and Link Technology Flags" 967 registry. [this document] is added as a second reference for this 968 registry. The first part of the table is changed to the following: 970 Range Registration Note 971 ----------- ---------------- ---------------------------- 972 0x002-0x0FF Standards Action 973 0x100-0xFBF RFC Required allocation of a single value 974 0x100-0xFBF IESG Approval allocation of multiple values 975 0xFC0 0xFF7 see Note link technology dependent, 976 see subregistry 978 In the existing table of RBridge Channel Protocols, the following 979 line is changed to two lines as shown: 981 OLD 982 0x004-0xFF7 Unassigned 983 NEW 984 0x004-0xFBF Unassigned 985 0xFC0-0xFF7 (link technology dependent, see subregistry) 987 A new subregistry under the newly named "RBridge Channel Protocols 988 and Link Technology Flags" registry is added as follows: 990 Name: TRILL over IP Link Flags 991 Registration Procedure: IETF Review 992 Reference: [this document] 994 Flag Meaning 995 ----------- ------------------------------ 996 0xFC0 Native encapsulation supported 997 0xFC1 VXLAN encapsulation supported 998 0xFC2-0xFF7 Unassigned 1000 Normative References 1002 [IS-IS] - "Intermediate system to Intermediate system routeing 1003 information exchange protocol for use in conjunction with the 1004 Protocol for providing the Connectionless-mode Network Service 1005 (ISO 8473)", ISO/IEC 10589:2002, 2002". 1007 [RFC0020] - Cerf, V., "ASCII format for network interchange", STD 80, 1008 RFC 20, DOI 10.17487/RFC0020, October 1969, . 1011 [RFC0768] - Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1012 10.17487/RFC0768, August 1980, . 1015 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1017 March 1997, . 1019 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 1020 "Definition of the Differentiated Services Field (DS Field) in 1021 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 1022 December 1998, . 1024 [RFC2710] - Deering, S., Fenner, W., and B. Haberman, "Multicast 1025 Listener Discovery (MLD) for IPv6", RFC 2710, DOI 1026 10.17487/RFC2710, October 1999, . 1029 [RFC2914] - Floyd, S., "Congestion Control Principles", BCP 41, RFC 1030 2914, DOI 10.17487/RFC2914, September 2000, . 1033 [RFC3376] - Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1034 Thyagarajan, "Internet Group Management Protocol, Version 3", 1035 RFC 3376, DOI 10.17487/RFC3376, October 2002, . 1038 [RFC3566] - Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 1039 Algorithm and Its Use With IPsec", RFC 3566, DOI 1040 10.17487/RFC3566, September 2003, . 1043 [RFC3602] - Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1044 Algorithm and Its Use with IPsec", RFC 3602, DOI 1045 10.17487/RFC3602, September 2003, . 1048 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1049 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1050 2005, . 1052 [RFC4303] - Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1053 4303, DOI 10.17487/RFC4303, December 2005, . 1056 [RFC4308] - Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 1057 DOI 10.17487/RFC4308, December 2005, . 1060 [RFC5405] - Li, T. and R. Atkinson, "IS-IS Cryptographic 1061 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, 1062 . 1064 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1065 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1066 5310, DOI 10.17487/RFC5310, February 2009, . 1069 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1070 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1071 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1072 . 1074 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1075 D., and A. Banerjee, "Transparent Interconnection of Lots of 1076 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 1077 May 2014, . 1079 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1080 and V. Manral, "Transparent Interconnection of Lots of Links 1081 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 1082 . 1084 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1085 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1086 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 1087 2014, . 1089 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1090 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1091 eXtensible Local Area Network (VXLAN): A Framework for 1092 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 1093 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 1096 [rfc7180bis] - Eastlake, D., et al, "TRILL: Clarifications, 1097 Corrections, and Updates", draft-ietf-trill-rfc7180bis, work in 1098 progress. 1100 [FIPS180] - "Secure Hash Standard (SHS)", United States of American, 1101 National Institute of Science and Technology, Federal 1102 Information Processing Standard (FIPS) 180-4, March 2012. 1104 Informative References 1106 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1107 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 1108 10.17487/RFC6234, May 2011, . 1111 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1112 Interconnection of Lots of Links (TRILL) Protocol Control 1113 Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, 1114 . 1116 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1117 and D. Dutt, "Transparent Interconnection of Lots of Links 1118 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 1119 10.17487/RFC7172, May 2014, . 1122 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 1123 "Transparent Interconnection of Lots of Links (TRILL) Transport 1124 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 1125 . 1127 [gre-in-udp] - Crabbe, E., Yong, L., and X. Xu, "Generic UDP 1128 Encapsulation for IP Tunneling", draft-yong-tsvwg-gre-in-udp- 1129 encap, work in progress. 1131 [circuit-breaker] - Fairhurst, G., "Network Transport Circuit 1132 Breakers", draft-ietf-tsvwg-circuit-breaker, work in progress. 1134 Acknowledgements 1136 The following people have provided useful feedback on the contents of 1137 this document: Sam Hartman, Adrian Farrel. 1139 Some material in Section 10.2 is derived from draft-ietf-mpls-in-udp 1140 by Xiaohu Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, and 1141 Yongbing Fan. 1143 The document was prepared in raw nroff. All macros used were defined 1144 within the source file. 1146 Authors' Addresses 1148 Margaret Cullen 1149 Painless Security 1150 356 Abbott Street 1151 North Andover, MA 01845 1152 USA 1154 Phone: +1 781 405-7464 1155 Email: margaret@painless-security.com 1156 URI: http://www.painless-security.com 1158 Donald Eastlake 1159 Huawei Technologies 1160 155 Beaver Street 1161 Milford, MA 01757 1162 USA 1164 Phone: +1 508 333-2270 1165 Email: d3e3e3@gmail.com 1167 Mingui Zhang 1168 Huawei Technologies 1169 No.156 Beiqing Rd. Haidian District, 1170 Beijing 100095 P.R. China 1172 EMail: zhangmingui@huawei.com 1174 Dacheng Zhang 1175 Alibaba 1176 Beijing, Chao yang District 1177 P.R. China 1179 Email: dacheng.zdc@alibaba-inc.com 1181 Copyright, Disclaimer, and Additional IPR Provisions 1183 Copyright (c) 2015 IETF Trust and the persons identified as the 1184 document authors. All rights reserved. 1186 This document is subject to BCP 78 and the IETF Trust's Legal 1187 Provisions Relating to IETF Documents 1188 (http://trustee.ietf.org/license-info) in effect on the date of 1189 publication of this document. Please review these documents 1190 carefully, as they describe your rights and restrictions with respect 1191 to this document. Code Components extracted from this document must 1192 include Simplified BSD License text as described in Section 4.e of 1193 the Trust Legal Provisions and are provided without warranty as 1194 described in the Simplified BSD License.