idnits 2.17.1 draft-ietf-trill-rbridge-bfd-07.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 16, 2012) is 4299 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. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group V. Manral 2 INTERNET-DRAFT Hewlett Packard Co. 3 Intended status: Proposed Standard D. Eastlake 4 Huawei R&D USA 5 D. Ward 6 Cisco Systems 7 A. Banerjee 8 Cumulus Networks 9 Expires: January 15, 2013 July 16, 2012 11 TRILL (Transparent Interconnetion of Lots of Links): 12 Bidirectional Forwarding Detection (BFD) Support 13 15 Abstract 17 This document specifies use of the BFD (Bidirectional Forwarding 18 Detection) protocol in RBridge campuses based on the Rbridge Channel 19 extension to the the TRILL (TRansparent Interconnection of Lots of 20 Links) protocol. 22 BFD is a widely deployed OAM (Operations, Administration, and 23 Maintenance) mechanism in IP and MPLS (Multi Protocol Label 24 Switching) networks, using UDP and ACH (Associated Channel Header) 25 encapsulation respectively. This document specifies the BFD 26 encapsulation over TRILL. 28 Status of This Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. Distribution of this document is 32 unlimited. Comments should be sent to the TRILL working group mailing 33 list: . 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 46 Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Table of Contents 51 1. Introduction............................................4 52 1.1 Terminology............................................4 54 2. BFD over TRILL.........................................6 55 2.1 Sessions and Initialization............................6 57 3. TRILL BFD Control Protocol..............................8 58 3.1 One-Hop TRILL BFD Control..............................8 59 3.2 BFD Control Frame Processing...........................8 61 4. TRILL BFD Echo Protocol.................................9 62 4.1 BFD Echo Frame Processing.............................9 64 5. Management and Operations Considerations...............11 65 6. Default Authentication.................................12 66 7. Security Considerations................................14 67 8. IANA Considerations....................................15 68 9. Acknowledgements.......................................15 69 Normative References......................................16 70 Informative References....................................16 71 Recent Changes Record.....................................18 73 1. Introduction 75 Faster convergence is a critical feature of TRILL (Transparent 76 Interconnection of Lots of Links [RFC6325]) networks. The TRILL IS- 77 IS Hellos [RFC6327] [IS-IS] used between RBridges provide a basic 78 neighbor and continuity check for TRILL links. However, failure 79 detection by non- receipt of such Hellos is based on the holding time 80 parameter that is commonly set to a value of tens of seconds and, in 81 any case, has a minimum expressible value of one second. 83 Some applications, including voice over IP, may wish, with high 84 probability, to detect interruptions in continuity within a much 85 shorter time period. In some cases physical layer failures can be 86 detected very rapidly but this is not always possible, such as when 87 there is a failure between two bridges that are in turn between two 88 RBridges. There are also many subtle failures possible at higher 89 levels. For example, some forms of failure could affect unicast 90 frames while still letting multicast frames through; since all TRILL 91 IS-IS Hellos are multicast such a failure cannot be detected with 92 Hellos. Thus, a low overhead method for frequently testing 93 continuity for the TRILL Data between neighbor RBridges is necessary 94 for some applications. The BFD (Bi-directional Forwarding Detection 95 [RFC5880]) protocol provides a low-overhead method for the rapid 96 detection of connectivity failures. 98 BFD is a widely deployed OAM (Operations, Administration, and 99 Maintenance, [RFC6291]) mechanism in IP and MPLS (Multi Protocol 100 Label Switching) networks, using UDP and ACH (Associated Channel 101 Header) encapsulation respectively. This document describes a TRILL 102 encapsulation for BFD packets for networks that forward based on the 103 TRILL Header. 105 1.1 Terminology 107 This document uses the acronyms defined in [RFC6325] along with the 108 following: 110 BFD: Bi-directional Forwarding Detection 112 IP: Internet Protocol 114 IS-IS: Intermediate-System to Intermediate-System 116 MH: Multi-Hop 118 PPP: Point-to-Point Protocol 119 OAM: Operations, Administration, and Maintenance 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. BFD over TRILL 127 TRILL supports unicast neighbor BFD Echo and one-hop and multi-hop 128 BFD Control, as specified below, over the Rbridge Channel facility 129 [TRILLChannel]. (Multi-destination BFD is a work in progress 130 [MultiBFD].) BFD over TRILL support is similar to BFD over IP support 131 [RFC5881] except where differences are explicitly mentioned. 133 Asynchronous and demand modes MUST BE supported [RFC5880]. BFD over 134 TRILL supports the Echo function, however implementation of TRILL BFD 135 Echo is optional and it can only be used for single-hop sessions. 137 The TRILL Header hop count in the BFD packets is sent out with the 138 maximum value of 0x3F. To prevent spoofing attacks, the TRILL hop 139 count of a received session is checked [RFC5082]. For a single-hop 140 session if the hop count is less than 0x3F and the Rbridge Channel 141 Header MH flag is zero, the packet is discarded. For multihop 142 sessions the hop count check can be disabled if the MH flag is one. 144 As in BFD for IP the format of the Echo Packet content is not 145 defined. 147 New Rbridge Channel code points for BFD TRILL Control and BFD Echo 148 packets are specified. 150 Authentication mechanisms as supported in BFD are also supported for 151 BFD running over TRILL. 153 2.1 Sessions and Initialization 155 Within an RBridge campus, there will be no more than one TRILL BFD 156 Control session from any RBridge RB1 to RBridge RB2 for each RB1 157 TRILL port. This BFD session must be bound to this interface. As 158 such, both sides of a session MUST take the "Active" role (sending 159 initial BFD Control packets with a zero value of Your Discriminator), 160 and any BFD packet from the remote machine with a zero value of Your 161 Discriminator MUST be associated with the session bound to the remote 162 system and interface. 164 Note that TRILL BFD provides OAM facilities for the TRILL data plane. 165 This is above whatever protocol is in use on a particular link, such 166 as a PPP [RFC6361] link or an Ethernet link [RFC6325]. Link 167 technology specific OAM protocols may be used on a link between 168 neighbor RBridges, for example Continuity Fault Management [802.1Q] 169 if the link is Ethernet. But such link layer OAM and coordination 170 between it and TRILL data plane layer OAM, such as TRILL BFD, is 171 beyond the scope of this document. 173 If lower level mechanisms, such as link aggregation [802.1AX], are in 174 use that present a single logical interface to TRILL IS-IS, only a 175 single TRILL BFD session can be established to any other RBridge over 176 this logical interface. However, lower layer OAM could be aware of 177 and/or run separately on each of the components of an aggregation. 179 3. TRILL BFD Control Protocol 181 TRILL BFD Control frames are unicast TRILL Rbridge Channel frames 182 [TRILLChannel]. The Rbridge Channel Protocol value is given in 183 Section 8. The protocol specific data associated with the TRILL BFD 184 Control protocol is as shown in Section 4.1 of [RFC5880]. 186 3.1 One-Hop TRILL BFD Control 188 One-hop TRILL BFD Control is typically used to rapidly detect link 189 and RBridge failures. TRILL BFD frames over one hop for such 190 purposes SHOULD be sent with high priority; that is, the Inner.VLAN 191 tag priority should be 7, they should be queued for transmission as 192 maximum priority frames and, if they are being sent on an Ethernet 193 link where the output port is configured to include an Outer.VLAN 194 tag, that tag should specify priority 7. 196 For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL 197 BFD Control frames to the other only if TRILL IS-IS has detected bi- 198 directional connectivity, that is, the adjacency is in the Two-Way or 199 Report state [RFC6327] and both RBridges indicate support of TRILL 200 BFD is enabled. The BFD Enabled TLV is used to indicate this as 201 specified in [RFC6213]. 203 3.2 BFD Control Frame Processing 205 The following tests SHOULD be performed on received TRILL BFD Control 206 frames before generic BFD processing. 208 Is the M-bit in the TRILL Header non-zero? If so, discard the frame. 209 (Multi-destination BFD is a work in progress [MultiBFD].) Failure to 210 perform this test would make a denial-of-service attack using bogus 211 multi-destination BFD Control frames easier. 213 If the Channel Header MH flag is zero, indicating one-hop, test that 214 the TRILL Header hop count received was 0x3F (i.e., is 0x3E if it has 215 already been decremented) and if it is any other value discard the 216 frame. If the MH Channel flag is one, indicating multi-hop, test 217 that the TRILL Header hop count received was not less than a 218 configurable value that defaults to 0x30. If it is less, discard the 219 frame. Failure to perform these tests would make it easier to spoof 220 BFD Control frames. However, if forged BFD Control frames are a 221 concern, then BFD Authentication [RFC5880] should be used. 223 4. TRILL BFD Echo Protocol 225 A TRILL BFD Echo frame is a unicast Rbridge Channel frame, as 226 specified in [TRILLChannel], which should be forwarded back by an 227 immediate neighbor because both the ingress and egress nicknames are 228 set to a nickname of the originating RBridge. Normal TRILL Data 229 frame forwarding will cause the frame to be returned unless micro- 230 loop suppression logic in the neighbor RBrdge prohibits sending a 231 frame back out the port on which it was received or the like. 232 RBridges with such prohibitions cannot support BFD Echo. The TRILL 233 OAM protocol number for BFD Echo is given in Section 8. 235 TRILL BFD Echo frames SHOULD be sent on a link only if the following 236 conditions are met. An Echo originated under other circumstances will 237 consume bandwidth and CPU resources but is unlikely to be returned. 239 - A TRILL BFD Control session has been established, 241 - TRILL BFD Echo support is indicated by the potentially echo 242 responding RBridge, 244 - The adjacency is in the Report state [RFC6327], and 246 - The TRILL BFD Echo originating RBridge wishes to make use of this 247 optional feature. 249 Since the originating RBridge is the RBridge that will be processing 250 a returned Echo frame, the entire TRILL BFD Echo protocol specific 251 data area is considered opaque and left to the discretion of the 252 originating RBridge. Nevertheless, it is suggested that this data 253 include information by which the originating RBridge can authenticate 254 the returned BFD Echo frame and confirm the neighbor that echoed the 255 frame back. For example, it could include its own SystemID, the 256 neighbor's SystemID, a session identifier and a sequence count as 257 well as a Message Authentication Code. 259 4.1 BFD Echo Frame Processing 261 The following tests MUST be performed on returned TRILL BFD Echo 262 frames before other processing. The RBridge Channel document 263 requires that the information in the TRILL Header be given to the BFD 264 protocol. 266 Is the M-bit in the TRILL Header non-zero? If so, discard the frame. 267 (Multi-destination BFD is a work in progress [MultiBFD].) 269 The TRILL BFD Echo frame should have gone exactly two hops so test 270 that the TRILL Header hop count as received was 0x3E (i.e., 0x3D if 271 it has already been decremented) and if it is any other value discard 272 the frame. The Rbridge Channel Header in the frame MUST have the MH 273 bit equal to one and if it is zero, the frame is discarded. 275 5. Management and Operations Considerations 277 The TRILL BFD parameters on an RBridge are configurable. The default 278 values are the same as in the IP BFD case [RFC5881], except where 279 specified in this document such as for Hop Count. 281 It is up to the operator of an RBridge campus to configure the rates 282 at which TRILL BFD frames are transmitted on a link to avoid 283 congestion (e.g., link, I/O, CPU) and false failure detection. See 284 also the discussion of congestion in Section 2 of [RFC5881]. 286 As stated in [RFC5880]: 287 It is worth noting that a single BFD session does not consume a 288 large amount of bandwidth. An aggressive session that achieves a 289 detection time of 50 milliseconds, by using a transmit interval of 290 16.7 milliseconds and a detect multiplier of 3, will generate 60 291 packets per second. The maximum length of each packet on the wire 292 is on the order of 100 bytes, for a total of around 48 kilobits 293 per second of bandwidth consumption in each direction. 295 6. Default Authentication 297 Consistent with TRILL's goal of being able to operate with minimum 298 configuration, the default for BFD authentication between neighbor 299 RBridges is based on the state of IS-IS shared secret authentication 300 for Hellos between those RBridges as detaled below. The BFD 301 authentication algorithm and methods in this section MUST be 302 implemented at an RBridge if TRILL IS-IS authentication and BFD are 303 implemented at that RBrdge. If such BFD authentication is configured 304 then its configuration is not restricted by the configuration of IS- 305 IS security. 307 If IS-IS authentication is not in effect between neighbor RBridges 308 then, by default, TRILL BFD between those RBridges is also unsecured. 310 If such IS-IS authentication is in effect then, unless configured 311 otherwise, TRILL BFD Control frames sent between those RBridges MUST 312 use BFD Meticulous Keyed SHA1 authentication [RFC5880]. The BFD 313 authentication keys between neighbor RBridges by default are derived 314 from the IS-IS shared secret authentication keys for Hellos between 315 those RBridges as detailed below. However, such BFD authentication 316 keys MAY be configured to some other value. 318 HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ), 319 IS-IS-shared-key ) 321 In the above "|" indicates concatenation, HMAC-SHA256 is as described 322 in [FIPS180] [RFC6234], "TRILL BFD Control" is the seventeen byte US 323 ASCII [ASCII] string indicated that is then concatenated with the 324 2-byte Port ID of the originating port and the 6-bytes IS-IS SystemID 325 of the originating RBridge, the last two items being in network byte 326 order. The Port and System IDs are included to minimize exposure of 327 the same key to improve resistance to cryptanalysis. IS-IS-shared-key 328 is secret keying material being used for IS-IS authentication on the 329 link. 331 The use of the above derived key is accomplished by associating the 332 above default authentication type and key with the Key ID of the IS- 333 IS-shared key used in the derivation and then using that Key ID in 334 the Authentication Section of the BFD Control frame OAM protocol 335 specific data. Also Auth Type would be 5 and Auth Len would be 28 in 336 the Authentication Section. RBridges MAY be configured to use other 337 BFD security modes or keying material or configured to use no 338 security. 340 Authentication for TRILL BFD Echo is a local implementation issue as 341 BFD Echo frames are authenticated by their sender when returned by by 342 a neighbor. However, if TRILL IS-IS and BFD Control are being 343 authenticated to a neighbor and BFD Echo is in use, BFD Echo frames 344 to be returned by that neighbor should be authenticated and such 345 authentication should use different keying material from other types 346 of authentication. For example, it could use keying material derived 347 as follows, where "|" indicates concatenation: 349 HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ), 350 IS-IS-shared-key ) 352 7. Security Considerations 354 BFD over TRILL utilizes the RBridge Channel extension to the TRILL 355 protocol and is generally analogous to BFD over IP. As such, the BFD 356 authentication faciliity is available to authenticate BFD over TRILL 357 packet payloads but no encryption or other security features are 358 provided at the BFD over TRILL level. See the following: 360 - [RFC5881] for general BFD security considerations, 362 - [TRILLChannel] for general RBridge Channel security 363 considerations, and 365 - [RFC6325] for general TRILL protocol security considerations. 367 Section 3.2 above describes seurity concerns with multi-hop BFD 368 Control packets and failure to check the TRILL Header M bit in BFD 369 Control packets. 371 8. IANA Considerations 373 IANA is requested to allocate two Rbridge Channel Protocol numbers 374 [TRILLChannel] from the range allocated by Standards Actions, as 375 follows: 377 Protocol Number 378 -------- ------ 379 BFD Control TBD (2 suggested) 380 BFD Echo TBD (3 suggested) 382 9. Acknowledgements 384 The authors would like to specially thank Dave Katz, an author of 385 [RFC5880] and [RFC5881], from which some material herein has been 386 reproduced. 388 The following are thanked for their comments and suggestions: Scott 389 Bradner, Stewart Bryant, Stephen Farrell, Eric Gray, Brian Haberman, 390 Barry Leiba, Erik Nordmark, John Scudder, Robert Sparks, Martin 391 Stiemerling, an Sean Turner. 393 This documnt was prepared using raw nroff. All macros used were 394 defined in the source file. 396 Normative References 398 [ASCII] - American National Standards Institute (formerly United 399 States of America Standards Institute), "USA Code for 400 Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 401 has been replaced by newer versions with slight modifications, 402 but the 1968 version remains definitive for the Internet. 404 [FIPS180] - "Secure Hash Standard (SHS)", United States of American, 405 National Institute of Science and Technology, Federal 406 Information Processing Standard (FIPS) 180-4, March 2012, 407 http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf 409 [IS-IS] - International Organization for Standardization, 410 "Intermediate system to Intermediate system routeing 411 information exchange protocol for use in conjunction with the 412 Protocol for providing the Connectionless-mode NetworkService 413 (ISO 8473)," ISO/IEC 10589:2002, Second Edition, Nov 2002. 415 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC5880] - Katz, D. and D. Ward, "Bidirectional Forwarding Detection 419 (BFD)", RFC 5880, June 2010. 421 [RFC5881] - Katz, D. and D. Ward, "Bidirectional Forwarding Detection 422 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. 424 [RFC6213] - Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 425 6213, April 2011. 427 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 428 Ghanwani, "Routing Bridges (RBridges): Base Protocol 429 Specification", RFC 6325, July 2011. 431 [RFC6327] - Eastlake, D., R. Perlman, A. Ghanwani, D. Dutt, V. 432 Manral, "RBridges: Adjacency", RFC 6327, July 2011. 434 [TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward, 435 "RBridges: RBridge Channel Support in TRILL", draft-ietf-trill- 436 rbridge-channel, work in progress. 438 Informative References 440 [802.1AX] - IEEE, "IEEE Standard for Local and metropolitan area 441 networks / Link Aggregation", 802.1AX-2008, 1 January 2008. 443 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 444 networks - Virtual Bridged Local Area Networks", IEEE Std 445 802.1Q-2011, May 2011. 447 [MultiBFD] - Katz, D. and D. Ward, "draft-ietf-bfd-multipoint", work 448 in progress. 450 [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 451 Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 452 5082, October 2007. 454 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 455 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 456 2011. 458 [RFC6291] - Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 459 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 460 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 462 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 463 Interconnection of Lots of Links (TRILL) Protocol Control 464 Protocol", RFC 6361, August 2011. 466 Recent Changes Record 468 [RFC Editor Note: Please delete this section before publication.] 470 From -06 to -07: 472 1. Replace normative reference to RFC 20 with a refernce to [ASCII]. 474 2. Update Author Address information. 476 3. In the default BFD authentication key derivation, change 477 "OriginatorMAC" to the concatenation of the Port ID and the 478 System ID. OriginatorMAC is simpler and shorter but only works 479 for Ethernet links. TRILL supports arbitrary technology links 480 between RBridges so you need to use the combination of Port ID 481 and System ID to get a globally unique quantity. In addition, if 482 an IS-IS authentication method is in use the has a Key ID field 483 so that multiple shared secret keys may be in place, then by 484 default BFD authentication with such a Key ID field should also 485 be used with matching Key ID for matching derived key. 487 4. Clarify what it means that a single hop BFD control frame in 488 support of link connectivity is send at high priority for cases 489 other than Ethernet links. 491 5. Add reference in Section 5 to Section 2 of [RFC5881] in 492 conngection with congestion control. 494 6. Add mandatory to implement support for Demand Mode BFD. 496 7. Clarify that the BFD authentication algorithm and methods in 497 Section 6 MUST be implemented if TRILL IS-IS Authentication and 498 BFD are implemented. 500 8. Add some small pieces of explanatory and motivational text that 501 make no technical changes, as suggested by the Operations 502 Directorate review. 504 9. Delete comparison between RBridge Channel and MPLS Generic 505 Associated Channel. 507 10. Update Author Info. 509 11. Various editorial changes. 511 Authors' Addresses 513 Vishwas Manral 514 Hewlett Packard Co. 515 19111 Pruneridge Ave. 516 Cupertino, CA 95089 USA 518 Phone: +1-408-447-0000 519 Email: vishwas.manral@hp.com 521 Donald Eastlake 3rd 522 Huawei R&D USA 523 155 Beaver Street 524 Milford, MA 01757 USA 526 Phone: +1-508-333-2270 527 Email: d3e3e3@gmail.com 529 Dave Ward 530 Cisco Systems 531 170 W. Tasman Drive 532 San Jose, CA 95138 USA 534 Email: dward@cisco.com 536 Ayan Banerjee 537 Cumulus Networks 538 1089 West Evelyn Avenue 539 Sunnyvale, CA 94086 USA 541 EMail: ayabaner@gmail.com 543 Copyright and IPR Provisions 545 Copyright (c) 2012 IETF Trust and the persons identified as the 546 document authors. All rights reserved. 548 This document is subject to BCP 78 and the IETF Trust's Legal 549 Provisions Relating to IETF Documents 550 (http://trustee.ietf.org/license-info) in effect on the date of 551 publication of this document. Please review these documents 552 carefully, as they describe your rights and restrictions with respect 553 to this document. Code Components extracted from this document must 554 include Simplified BSD License text as described in Section 4.e of 555 the Trust Legal Provisions and are provided without warranty as 556 described in the Simplified BSD License. The definitive version of 557 an IETF Document is that published by, or under the auspices of, the 558 IETF. Versions of IETF Documents that are published by third parties, 559 including those that are translated into other languages, should not 560 be considered to be definitive versions of IETF Documents. The 561 definitive version of these Legal Provisions is that published by, or 562 under the auspices of, the IETF. Versions of these Legal Provisions 563 that are published by third parties, including those that are 564 translated into other languages, should not be considered to be 565 definitive versions of these Legal Provisions. For the avoidance of 566 doubt, each Contributor to the IETF Standards Process licenses each 567 Contribution that he or she makes as part of the IETF Standards 568 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 569 language to the contrary, or terms, conditions or rights that differ 570 from or are inconsistent with the rights and licenses granted under 571 RFC 5378, shall have any effect and shall be null and void, whether 572 published or posted by such Contributor, or included with or in such 573 Contribution.