idnits 2.17.1 draft-eastlake-isis-ia-tlv-01.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 (October 22, 2012) is 4176 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. 'ISO-10589' -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 2 INTERNET-DRAFT Yizhou Li 3 Intended status: Proposed Standard Huawei 4 Expires: April 21, 2013 October 22, 2012 6 Interface Addresses TLV 7 9 Abstract 11 This document specifies an IS-IS (Intermediate System to Intermediate 12 System) TLV that enables the reporting by an Intermediate System of 13 sets of addresses of different types such that all of the addresses 14 in each set designate the same interface (port). For example, an 15 EUI-48 MAC (Extended Unique Identifier 48-bit, Media Access Control) 16 address, IPv4 address, and IPv6 address can be reported as all 17 corresponding to the same interface. Such information could be used, 18 for example, to synthesize responses to or by-pass the need for the 19 Address Resolution Protocol (ARP) or the IPv6 Neighbor Discovery (ND) 20 protocol in some cases. 22 Status of This Memo 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 TRILL working group 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............................................3 48 1.1 Conventions Used in This Document......................3 50 2. The Interface Addresses TLV.............................4 52 3 IA-TLV sub-TLVs..........................................7 53 3.1 AFN Size sub-TLV.......................................7 54 3.2 Data Label sub-TLV.....................................8 55 3.3 Nickname sub-TLV.......................................9 56 3.4 Fixed Address sub-TLV..................................9 58 4. Example................................................11 60 5. IANA Considerations....................................12 61 6. Security Considerations................................13 62 7. Normative References...................................14 63 8. Informative References.................................14 64 Change History............................................16 65 00 to 01..................................................16 67 Acknowledgements..........................................17 69 1. Introduction 71 This document specifies an IS-IS (Intermediate System to Intermediate 72 System [ISO-10589] [RFC1195]) TLV that enables the reporting by an 73 Intermediate System in its LSP (Link State PDU) of sets of addresses 74 of different types such that all of the addresses in each set 75 designate the same interface (port). For example, an EUI-48 MAC 76 (Extended Unique Identifier 48-bit, Media Access Control [RFC5342]) 77 address, IPv4 address, and IPv6 address can be reported as all three 78 corresponding to the same interface. Such information could be used, 79 for example, to synthesize responses to or by-pass the need for the 80 Address Resolution Protocol (ARP, [RFC826]), Reverse Address 81 Resolution Protocol (RARP, [RFC903]) or the IPv6 Neighbor Discovery 82 (ND [RFC4861]) protocols in some cases. 84 Although, in some IETF protocols, address field types are represented 85 by EtherType [802] or Hardware Type [RFC5494] only Address Family 86 Number is used in this TLV. 88 1.1 Conventions Used in This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. The Interface Addresses TLV 96 The Interface Addresses TLV is used to indicate that a set of 97 addresses indicate the same interface. These addresses can be in 98 different address families. For example, it can be used to declare 99 that an interface has a particular IPv4 address, IPv6 address, and 100 EUI-48 MAC address. 102 The Template Size gives the number of AFNs present below. The set of 103 AFNs preent give a template for the type and order of addresses in 104 each Address Set. 106 +-+-+-+-+-+-+-+-+ 107 | Type = TBD | (1 byte) 108 +-+-+-+-+-+-+-+-+ 109 | Length | (1 byte) 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 |E|RESV | Topology-ID | (2 bytes) 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Addr Set End | (1 byte) 114 +-+-+-+-+-+-+-+-+ 115 | Confidence | (1 byte) 116 +-+-+-+-+-+-+-+-+ 117 | Template Size | (1 byte) 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | AFN 1 | (2 bytes) 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | AFN 2 | (2 bytes) 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | ... 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | AFN K | (2 bytes) 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 127 | Address Set 1 (size determined by Template) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 129 | Address Set 2 (size determined by Template) | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 131 | ... 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 133 | Address Set N (size determined by Template) | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 135 | optional sub-TLVs ... 136 +-+-+-+-+-+-+-+-+-+-+-+-... 138 Figure 1. The Interface Addresses TLV 140 o Type: Interface Addresses TLV type, set to TBD[#247 suggested] 141 (IA-TLV). 143 o Length: Variable, minimum 7. If length is 6 or less, the TLV MUST 144 be ignored. 146 o E: The E (rEachability) flag is set to one to indicate that the 147 interfaces whose addresses are being given in the TLV are 148 reachable through the Intermediate System that is advertising the 149 TLV. 151 o RESV: Reserved. MUST be sent as zero and ignored on receipt. 153 o Topology-ID: This field carries a topology ID [RFC5120] or zero if 154 topologies are not in use. 156 o Addr Set End: The unsigned offset of the byte, within the TLV 157 value part, of the last byte of the last Address Set. This will be 158 the byte just before the first sub-TLV if any sub-TLVs are 159 present. [RFC5305] 161 o Confidence: This 8-bit quantity indicates the confidence level in 162 the addresses being transported. The semantics of the Confidence 163 are further defined by the technology using the IA-TLV. 165 o Template Size: A byte containing the unsigned integer number K of 166 AFNs (Address Family Numbers) in the template specifying the 167 structure of each Address Set occurring later in the TLV. The 168 minimum valid value is 1 and there must be room in the TLV for the 169 AFNs. If Template Size is zero or too big, the TLV MUST be 170 ignored. 172 o AFN: A two-byte Address Family Number. The number of AFNs present 173 is given in the Template Size field. This sequence specifies the 174 structure of the Address Sets occurring later in the TLV. For 175 example, if Template Size is 2 and the two AFNs present are the 176 AFNs for IPv4 and EUI-48, in that order, then each Address set 177 present will consist of a 4-byte IPv4 address followed by a 6-byte 178 MAC address. If any AFNs are present that are unknown to the 179 receiving IS and the length of the corresponding address is not 180 provided by a sub-TLV as specified below, the receiving IS will be 181 unable to parse the Address Sets and MUST ignore the enclosing 182 TLV. 184 o Address Set: Each address set consists of a sequence of Template 185 Size number of addresses of the types given by the AFN sequence 186 template earlier in the TLV in the same order as those AFNs. No 187 alignment, other than to a byte boundary, is guaranteed. The 188 addresses in each Address Set are contiguous with no unused bytes 189 between them and the Address Sets are contiguous with no unused 190 bytes between Address Sets. The Address Sets must fit within the 191 TLV. If the product of the size of an Address Set and the number 192 of Address Sets is so large that this is not true, the TLV is 193 ignored. 195 o sub-TLVs: If the Address Sets indicated by Addr Sets End do not 196 completely fill the Length of the TLV, the remaining bytes are 197 parsed as sub-TLVs [RFC5305]. These sub-TLVs are from a new 198 sequence of sub-TLVs. Any such sub-TLVs that are not known to the 199 receiving IS are ignored. Should this not be possible, for example 200 there is only one remaining byte or an apparent sub-TLV extends 201 beyond the end of the TLV, the containing IA-TLV is considered 202 corrupt and is ignored. Several sub-TLV types are specified in 203 Section 3. 205 This Reachable Interface Addresses TLV occurs only within LSP PDUs 206 and may occur multiple times in the same or different LSP PDUs with 207 the same or different templates. 209 Different IA-TLVs within the same or different LSP PDUs from the same 210 IS may have different templates. The same AFN may occur more than 211 once in a template and the same address may occur in more than one 212 address set. For example, an EUI-48 MAC address interface might have 213 three IPv6 addresses. This could be represented by an IA-TLV whose 214 template specifically provided for one EUI-48 address and three IPv6 215 addresses, which might be an efficient format if there were multiple 216 interfaces with that pattern. Alternatively, a template with one 217 EUI-48 and one IPv6 address could be used in an IA-TLV with three 218 address sets each having the same EUI-48 address but different IPv6 219 addresses, which might be the most efficient format if only one 220 interface had multiple IPv6 addresses and other interfaces had only 221 one IPv6 address. 223 In order to be able to parse the Address Sets, a receiving IS must 224 know at least the size of the address each AFN in the Temple 225 specifies; however, the presence of the Addr Set End field means that 226 the sub-TLVs, if any, can always be located by a receiving IS. An IS 227 can be assumed to know the size of IPv4 and IPv6 addresses (AFNs 1 228 and 2) and the size of the additional AFNs allocated by the IANA 229 Considerations below. Should an IS wish to include an AFN that some 230 receiving IS in the campus may not know, it SHOULD include an AFN- 231 Size sub-TLV as described below. If an IA-RLV is received with one or 232 more AFNs in its template for which the receiving IS does not know 233 the length and for which an AFN-Size sub-TLV is not present, that IA- 234 TLV will be ignored. 236 3 IA-TLV sub-TLVs 238 IA-TLVs may have trailing sub-TLVs [RFC5305] as specified below. 239 These sub-TLVs occur after the Address Sets and the amount of space 240 available for sub-TLVs is determined from the overall IA-TLV length 241 and the value of the Addr Set End byte. 243 There is no ordering restriction on IA-TLV sub-TLVs. Unless otherwise 244 specified each sub-TLV type can occur zero, one, or many times in an 245 IA-TLV. 247 3.1 AFN Size sub-TLV 249 Using this sub-TLV, the originating IS can specify the size of an 250 address type. This is useful under two circumstances: 252 1. One or more AFNs that are unknown to the receiving IS appears in 253 the template. If an AFN Size sub-TLV is present for each such AFN, 254 the at least the IA-TLV can be parses the Address Sets and make 255 use of any address types present that it does understand. 257 2. If an AFN occurs in the template that represents a variable length 258 address, this sub-TLV gives its size for all occurrences in that 259 IA-TLV. 261 +-+-+-+-+-+-+-+-+ 262 |subType = AFNsz| (1 byte) 263 +-+-+-+-+-+-+-+-+ 264 | Length | (1 byte) 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | AFN Size Record(s) | (3 bytes) 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Where each AFN Size Record is structured as follows: 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | AFN | (2 bytes) 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | AdrSize | (1 byte) 275 +-+-+-+-+-+-+-+-+ 277 o Type: AFN-Size sub-TLV type, set to 1 (AFNsz). 279 o Length: 3*n where n is the number of AFN Size Records present. If 280 n is not a multiple of 3, the sub-TLV MUST be ignored. 282 o AFN Size Record(s): Zero or more 3-byte records, each giving the 283 size of an address type identified by an AFN, 285 o AFN: The AFN whose length is being specified by the AFN Size 286 Record. 288 o AdrSize: The length of the address specified by the AFN field. 290 This sub-TLV may occur multiple times in an enclosing IA-TLV. 292 The declaration of a size for an AFN address type controls for the 293 occurrences of the AFN in the enclosing IA-TLV and for and subsequent 294 IA-TLVs in the enclosing LSP PDU until the next occurrence in the LSP 295 PDU of an AFN Size sub-TLV for that AFN. Thus, an AFN Size sub-TLV 296 for a fixed size AFN need only be included in the first IA-TLV in a 297 PDU. But one must be included in or before first IA-TLV using an AFN 298 in each PDU where that AFN appears in the template if needed. 299 Otherwise Address Sets will not be parseable by a receiving IS. If 300 multiple AFN Size Records occur for the same AFN in the same AFN Size 301 sub-TLV the last size given controls. 303 An AFN Size sub-TLV for any AFN known to the receiving IS (which 304 always includes AFN 1 and 2 and the AFNs specified in Section 5) is 305 compared with the size known to the IS and if they differ, the 306 enclosing IA-TLV is ignored. 308 3.2 Data Label sub-TLV 310 +-+-+-+-+-+-+-+-+ 311 |Type==DATA-LABEL| (1 byte) 312 +-+-+-+-+-+-+-+-+ 313 | Length | (1 byte) 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 315 | Data Label (variable) 316 +-+-+-+-+-+-+-+-+-+-+-+-+-... 318 o Type: Data Label sub-TLV type, set to 2 (DATA-LABEL). 320 o Length: variable, minimum 1. If Length is zero, the sub-TLV MUST 321 be ignored. 323 o Data Label: A data label under which all the interfaces listed in 324 the TLV can be reached. Exact meaning for different lengths 325 depends on the technology in use. If absent, no label is 326 specified. If more than one different Data Label sub-TLV occurs in 327 an Interface Addresses TLV, it indicates that the interfaces 328 listed can be reach via all the labels given. 330 For TRILL use, if Length=2, the Data Label is a VLAN-ID which 331 appears right justified in two bytes with four leading bits that 332 MUST be sent as zero and ignored on receipt. 334 3.3 Nickname sub-TLV 336 +-+-+-+-+-+-+-+-+ 337 |Type=NICKNAME | (1 byte) 338 +-+-+-+-+-+-+-+-+ 339 | Length | (1 byte) 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 341 | Nickname (variable) 342 +-+-+-+-+-+-+-+-+-+-+-+-+-... 344 o Type: Data Label sub-TLV type, set to 3 (NICKNAME). 346 o Length: variable, minimum 1. If Length is zero, the sub-TLV MUST 347 be ignored. 349 o Nickname: The nickname of an Intermediate System through which all 350 the interfaces listed in the TLV can be reached. Exact meaning for 351 different lengths depends on the technology in use. If absent, no 352 nickname is specified. If more than one different Nickname sub-TLV 353 occurs in an Interface Addresses TLV, it indicates that the 354 interfaces listed can be reach via all the nicknames given. 355 Occurrence of one or more Nickname sub-TLVs in an Interface 356 Addresses TLV does not change the effect of the E flag bit in the 357 TLV initial fixed fields; the E flag having the value one still 358 indicates that the interfaces are reachable through the 359 Intermediate System advertising the TLV. 361 3.4 Fixed Address sub-TLV 363 There may be cases where, in an Interface Addresses TLV, the same 364 address would appear across every address set in the TLV. To avoid 365 having a larger template and wasted space in all Address Sets, this 366 sub-TLV can be used to indicate such a fixed address 368 +-+-+-+-+-+-+-+-+ 369 |Type=FIXEDADR | (1 byte) 370 +-+-+-+-+-+-+-+-+ 371 | Length | (1 byte) 372 +-+-+-+-+-+-+-+-+ 373 | AFN | (2 bytes) 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 375 | Fixed Address (variable) 376 +-+-+-+-+-+-+-+-+-+-+-+-+-... 378 o Type: Data Label sub-TLV type, set to 4 (FIXEDADR). 380 o Length: variable, minimum 3. If Length is 2 or less, the sub-TLV 381 MUST be ignored. 383 o AFN: Address Family Number of the Fixed Address. 385 o Fixed Address: The address of the type indicated by the preceeding 386 AFN field that is considered to be part of every Address Set in 387 the TLV. 389 4. Example 391 TBD 393 5. IANA Considerations 395 IANA is requested to allocate a new TLV number for IA-TLV [#247 396 suggested because #147 is the MAC Reachability (MAC-RI) TLV]. 398 IANA is requested to allocate three new AFN numbers as follows: 400 Number Description References 402 TBD(26) EUI-48 RFC 5342, this document 403 TBD(27) EUI-64 RFC 5342, this document 404 TBD(28) IPv6/64 This document. 406 [[[Curiously enough, the AFN RFC references seem to always use 407 "Address Family Identifier" although IANA uses "Address Family 408 Number". Furthermore, neither of the two RFCs pointed to by the IANA 409 Address Family Number Registry actually has IANA Considerations for 410 Address Family Numbers although the IANA Registry has shows policies 411 for different ranges of AFNs. Conceivably, such IANA Considerations 412 should appear in this document.]]] 414 IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 415 address. If present, there will normally be an EUI-64 or EUI-48 416 address in the address set to provide the lower 64 bits of the IPv6 417 address. For this purpose, an EUI-48 is expanded to 64 bits as 418 described in [RFC5342]. 420 IANA is requested to establish a new subregistry for sub-TLVs of the 421 IA-TLV with initial contents as shown below. 423 Name: Sub-TLVs for TLV TBD[#247] 424 Procedure: Expert Review 425 Reference: This document 427 Type Description Reference 428 ---- ----------- --------- 429 0 Reserved 430 1 AFN Size This document 431 2 Nickname This document 432 3 Data Label This document 433 4 Fixed Address This docment 434 5-254 Available This document 435 255 Reserved 437 [[[Should administrative tag sub-TLVs (see RFC 5130) be allowed?]]] 439 6. Security Considerations 441 This document raises no new security issues for IS-IS. IS-IS security 442 may be used to secure IS-IS PDUs containing the IA-TLV. See 443 [RFC5304] and [RFC5310]. 445 7. Normative References 447 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 448 System to Intermediate System Intra-Domain Routing Exchange 449 Protocol for use in Conjunction with the Protocol for Providing 450 the Connectionless-mode Network Service (ISO 8473)", 2002. 452 [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 453 Dual Environments", 1990. 455 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 459 Topology (MT) Routing in Intermediate System to Intermediate 460 Systems (IS-ISs)", RFC 5120, February 2008. 462 [RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic 463 Authentication", RFC 5304, October 2008. 465 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 466 Engineering", 2008. 468 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 469 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 470 5310, February 2009. 472 8. Informative References 474 [802] - IEEE, "Standard for Local and Metropolitan Area Networks: 475 Overview and Architecture", IEEE Std. 802-2001, 8 March 2002. 477 [RFC826] - Plummer, D., "Ethernet Address Resolution Protocol: Or 478 Converting Network Protocol Addresses to 48-bit Ethernet 479 Address for Transmission on Ethernet Hardware", STD 37, RFC 480 826, November 1982. 482 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 483 Reverse Address Resolution Protocol", STD 38, RFC 903, June 484 1984. 486 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 487 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 488 September 2007. 490 [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol 491 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 492 2008. 494 [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 495 for the Address Resolution Protocol (ARP)", RFC 5494, April 496 2009. 498 Change History 500 RFC Editor Note: Please delete this section before publication. 502 00 to 01 504 Add the Fixed Address sub-TLV. 506 Minor editorial changes. 508 Acknowledgements 510 The authors gratefully acknowledge the contributions and review by 511 the following: 513 Linda Dunbar 515 This document was produced with raw nroff. All macros used were 516 defined in the source files. 518 Authors' Addresses 520 Donald Eastlake 521 Huawei R&D USA 522 155 Beaver Street 523 Milford, MA 01757 USA 525 Phone: +1-508-333-2270 526 Email: d3e3e3@gmail.com 528 Yizhou Li 529 Huawei Technologies 530 101 Software Avenue, 531 Nanjing 210012, China 533 Phone: +86-25-56624558 534 Email: liyizhou@huawei.com 536 Copyright, Disclaimer, and Additional IPR Provisions 538 Copyright (c) 2012 IETF Trust and the persons identified as the 539 document authors. All rights reserved. 541 This document is subject to BCP 78 and the IETF Trust's Legal 542 Provisions Relating to IETF Documents 543 (http://trustee.ietf.org/license-info) in effect on the date of 544 publication of this document. Please review these documents 545 carefully, as they describe your rights and restrictions with respect 546 to this document. Code Components extracted from this document must 547 include Simplified BSD License text as described in Section 4.e of 548 the Trust Legal Provisions and are provided without warranty as 549 described in the Simplified BSD License. The definitive version of 550 an IETF Document is that published by, or under the auspices of, the 551 IETF. Versions of IETF Documents that are published by third parties, 552 including those that are translated into other languages, should not 553 be considered to be definitive versions of IETF Documents. The 554 definitive version of these Legal Provisions is that published by, or 555 under the auspices of, the IETF. Versions of these Legal Provisions 556 that are published by third parties, including those that are 557 translated into other languages, should not be considered to be 558 definitive versions of these Legal Provisions. For the avoidance of 559 doubt, each Contributor to the IETF Standards Process licenses each 560 Contribution that he or she makes as part of the IETF Standards 561 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 562 language to the contrary, or terms, conditions or rights that differ 563 from or are inconsistent with the rights and licenses granted under 564 RFC 5378, shall have any effect and shall be null and void, whether 565 published or posted by such Contributor, or included with or in such 566 Contribution.