idnits 2.17.1 draft-eastlake-trill-ia-appsubtlv-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 (October 20, 2013) is 3841 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) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) == Outdated reference: A later version (-09) exists of draft-ietf-trill-esadi-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Donald Eastlake 3 Intended status: Proposed Standard Yizhou Li 4 Huawei 5 Radia Perlman 6 Intel 7 Expires: April 19, 2014 October 20, 2013 9 TRILL: Interface Addresses APPsub-TLV 10 12 Abstract 13 This document specifies a TRILL (Transparent Interconnection of Lots 14 of Links) IS-IS application sub-TLV that enables the reporting by a 15 TRILL switch of sets of addresses such that all of the addresses in 16 each set designate the same interface (port). For example, an EUI-48 17 MAC (Extended Unique Identifier 48-bit, Media Access Control) 18 address, IPv4 address, and IPv6 address can be reported as all 19 corresponding to the same interface. Such information could be use in 20 some cases to synthesize responses to or by-pass the need for the 21 Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) 22 protocol, or the flooding of unknown MAC addresses. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the TRILL working group mailing list. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 1.1 Conventions Used in This Document......................3 52 2. Format of the Interface Addresses APPsub-TLV............5 54 3. IA APPsub-TLV sub-sub-TLVs.............................10 55 3.1 AFN Size sub-sub-TLV..................................10 56 3.2 Fixed Address sub-sub-TLV.............................11 57 3.3 Data Label sub-sub-TLV................................11 58 3.4 Topology sub-sub-TLV..................................12 60 4. Security Considerations................................14 62 5. IANA Considerations....................................15 63 5.1 Additional AFN Number Allocation......................15 64 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry................16 66 Acknowledgments...........................................17 68 Appendix A: Examples......................................18 69 A.1 Simple Example........................................18 70 A.2 Complex Example.......................................18 72 Normative References......................................21 73 Informational References..................................21 74 Authors' Addresses........................................23 76 1. Introduction 78 This document specifies a TRILL (Transparent Interconnection of Lots 79 of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV [RFC6823]) 80 that enables the convenient representation of sets of addresses such 81 that all of the addresses in each set designate the same interface 82 (port). For example, an EUI-48 MAC (Extended Unique Identifier 83 48-bit, Media Access Control [RFC5342bis]) address, IPv4 address, and 84 IPv6 address can be reported as all three designating the same 85 interface. In addition, a Data Label (VLAN or Fine Grained Label 86 (FGL [RFCfgl])) is specified for the interface along with the TRILL 87 switch and, optional the TRILL switch port, from which the interface 88 is reachable. Such information could be use in some cases to 89 synthesize responses to or by-pass the need for the Address 90 Resolution Protocol (ARP [RFC826]), the IPv6 Neighbor Discovery (ND 91 [RFC4861]) protocol, or the flooding of unknown MAC addresses 92 [DirectoryFramework]. 94 This APPsub-TLV appears inside the TRILL GENINFO TLV specified in 95 [ESADI] but may also occur in other application contexts. Directory 96 Assisted TRILL Edge services [DirectoryScheme] are expected to make 97 use of this APPsub-TLV. 99 Although, in some IETF protocols, address field types are represented 100 by Ethertype [RFC5342bis] or Hardware Type [RFC5494], only Address 101 Family Number (AFN) is used in this APPsub-TLV to represent address 102 field type. 104 1.1 Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 The terminology and acronyms of [RFC6325] are used herein along with 111 the following additional acronyms and terms: 113 AFN: Address Family Number 115 APPsub-TLV: Application sub-TLV [RFC6823]. 117 Data Label: VLAN or FGL. 119 FGL: Fine Grained Label [RFCfgl]. 121 IA: Interface Addresses. 123 RBridge: An alternative name for a TRILL switch. 125 TRILL switch: A device that implements the TRILL protocol. 127 2. Format of the Interface Addresses APPsub-TLV 129 The Interface Addresses (IA) APPsub-TLV is used to advertise that a 130 set of addresses indicate the same interface (port) within a Data 131 Label (VLAN or FGL) and to associate that interface with the TRILL 132 switch, and optionally the TRILL switch port, by which the interface 133 is reachable. These addresses can be in different address families. 134 For example, it can be used to declare that a particular interface 135 with specified IPv4, IPv6, and EUI-48 MAC addresses in some 136 particular Data Label is reachable from a particular TRILL switch. 138 The Template field in a particular Interface Addresses APPsub-TLV 139 indicates the exact format of each Address Set it carries. Certain 140 well-known sets of addresses are represented by special values. Other 141 sets of addresses are specified by a list of AFNs. The Template 142 format that uses a list of AFNs provides an explicit pattern for the 143 type and order of addresses in each Address Set in an IA APPsub-TLV. 145 A device or application making use of IA APPsub-TLV data is not 146 required to make use of all IA data. For example, a device or 147 application that was only interested in MAC and IPv6 addresses could 148 ignore any IPv4 or other types of address information that was 149 present. 151 +-+-+-+-+-+-+-+-+ 152 | Type = TBD | (1 byte) 153 +-+-+-+-+-+-+-+-+ 154 | Length | (1 byte) 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Nickname | (2 bytes) 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Flags | (1 byte) 159 +-+-+-+-+-+-+-+-+ 160 | Confidence | (1 byte) 161 +-+-+-+-+-+-+-+-+ 162 | Addr Sets End | (1 byte) 163 +-+-+-+-+-+-+-+-+-+- 164 | Template ... (variable) 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 166 | Address Set 1 (size determined by Template) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 168 | Address Set 2 (size determined by Template) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 170 | ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 172 | Address Set N (size determined by Template) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 174 | optional sub-sub-TLVs ... 175 +-+-+-+-+-+-+-+-+-+-+-+-... 177 Figure 1. The Interface Addresses APPsub-TLV 179 o Type: Interface Addresses TRILL APPsub-TLV type, set to TBD[#2 180 suggested] (IA-SUBTLV). 182 o Length: Variable, minimum 6, maximum 250 when inside a TRILL 183 GENINFO TLV [ESADI], maximum 255 in unconstrained contexts. If 184 length is 5 or less or if the APPsub-TLV extends beyond an 185 encompassing TRILL GENINFO TLV, the APPsub-TLV MUST be ignored. 187 o Nickname: The nickname of the TRILL switch by which the address 188 sets are reachable. If zero, the address sets are reachable from 189 the TRILL switch originating the message containing the APPsub-TLV 190 (for example, an [ESADI] message). 192 o Flags: A byte of flags as follows: 194 0 1 2 3 4 5 6 7 195 +-+-+-+-+-+-+-+-+ 196 |D|L|N| RESV | 197 +-+-+-+-+-+-+-+-+ 199 D: Directory flag: If D is one, the APPsub-TLV contains Push 200 Directory information. 202 L: Local flag: If L is one, the APPsub-TLV contains information 203 learned locally by observing ingressed frames. (Both D and L 204 can one in the same IA APPsub-TLV.) 206 N: Notify flag: When a TRILL switch receives a new IA APPsub- 207 TLV (one in a ESADI LSP fragment with a higher sequence 208 number or a new message of some other type) and the N bit is 209 one, the TRILL switch then checks the contens of the APPsub- 210 TLV for IP address to MAC address mappings. If an IPv4 to 211 MAC address mapping is found, gratuitous ARPs [RFC826] are 212 sent and if an IPv6 to MAC address mapping is found, 213 spontaneous Neighbor Advertisements [RFC4861] are sent. In 214 both cases, these are sent out all the ports of the TRILL 215 switch that offer end station service and are in the VLAN or 216 FGL of the APPsub-TLV information. 218 RESV: Additional reserved flag bits that MUST be sent as zero 219 and ignored on receipt. 221 o Confidence: This 8-bit unsigned quantity in the range 0 to 254 222 indicates the confidence level in the addresses being transported 223 [RFC6325]. A value of 255 is treated as if it was 254. 225 o Addr Sets End: The unsigned offset of the byte, within the IA 226 APPsub-TLV value part, of the last byte of the last Address Set. 228 This will be the byte just before the first sub-sub-TLV if any 229 sub-sub-TLVs are present (see Section 3). If this is equal to 230 Size, there are no sub-sub-TLVs. If this is greater than Size, the 231 IA APPsub-TLV is corrupt and MUST be discarded. 233 o Template: The initial byte of this field is the unsigned integer 234 K. If K has a value from 1 to 31, it indicates that this initial 235 byte is followed by a list of K AFNs (Address Family Numbers) that 236 specify the exact structure and order of each Address Set 237 occurring later in the APPsub-TLV. K can be 1, which is the 238 minimum valid value. If K is zero, the IA APPsub-TLV is ignored. 239 If K is 32 to 254, the length of the Template field is one byte 240 and its value is intended to correspond to a particular ordered 241 set of AFNs some of which are specified below. If K is 255, the 242 length of the Template filed is three bytes and the values of the 243 second and third byte, considered as an unsigned integer in 244 network byte order, are reserved to correspond to future specified 245 ordered sets of AFNs. 247 If the Template uses explicit AFNs, it looks like the following. 249 +-+-+-+-+-+-+-+-+ 250 | K | (1 byte) 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | AFN 1 | (2 bytes) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | AFN 2 | (2 bytes) 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | AFN K | (2 bytes) 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 For K in the 32 to 103 range, values indicate combinations of a 262 specific number of MAC addresses, IPv4 addresses, IPv6 addresses, 263 and TRILL switch port IDs in that order. The value of K is 265 K = 32 + M + 3*v4 + 9*v6 + 36*P 267 where M is 0, 1, or 2 (0 if no MAC address is present, 1 if a 268 48-bit MAC is present, 2 if a MAC/24 (see Section 5.1) is 269 present), v4 is the number of IPv4 addresses (limited to 0, 1, or 270 2) and v6 is the number of IPv6 addresses (limited to 0 through 3 271 inclusive), and P is the number of TRILL switch port IDs (limited 272 to 0 or 1). That equation specifies values of K from 32 through 273 103. Values from 104 through 254 of the byte value are available 274 for assignment by Expert Review (see Section 5). K = 255 indicates 275 a three byte Template field as specified above. All values (0 276 through 65,545) of this two byte value are available for 277 assignment by Expert Review. 279 If an unknown Template K value in the range 104 to 254 is received 280 or a K of 255 followed by an unknown two byte value, the IA 281 APPsub-TLV MUST be ignored. 283 o AFN: A two-byte Address Family Number. The number of AFNs present 284 is given by K. There are no AFNs if K is greater than 31. The AFN 285 sequence specifies the structure of the Address Sets occurring 286 later in the TLV. For example, if Template Size is 2 and the two 287 AFNs present are the AFNs for EUI-48 and IPv4, in that order, then 288 each Address set present will consist of a 6-byte MAC address 289 followed by a 4-byte IPv4 address. If any AFNs are present that 290 are unknown to the receiving IS and the length of the 291 corresponding address is not provided by a sub-sub-TLV as 292 specified below, the receiving IS will be unable to parse the 293 Address Sets and MUST ignore the IA APPsub-TLV. 295 o Address Set: Each address set in the APPsub-TLV consists of 296 exactly the same sequence of addresses of the types specified by 297 the Template earlier in the APPsub-TLV. No alignment, other than 298 to a byte boundary, is guaranteed. The addresses in each Address 299 Set are contiguous with no unused bytes between them and the 300 Address Sets are contiguous with no unused bytes between 301 successive Address Sets. The Address Sets must fit within the TLV. 302 If the product of the size of an Address Set and the number of 303 Address Sets is so large that this is not true, the IA APPsub-TLV 304 is ignored. 306 o sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do 307 not completely fill the Length of the APPsub-TLV, the remaining 308 bytes are parsed as sub-sub-TLVs [RFC5305]. Any such sub-sub-TLVs 309 that are not known to the receiving RBridge are ignored. Should 310 this parsing not be possible, for example there is only one 311 remaining byte or an apparent sub-sub-TLV extends beyond the end 312 of the TLV, the containing IA APPsub-TLV is considered corrupt and 313 is ignored. (Several sub-sub-TLV types are specified in Section 314 3.) 316 Different IA APPsub-TLVs within the same or different LSPs or other 317 data structures may have different Templates. The same AFN may occur 318 more than once in a Template and the same address may occur in 319 different address sets. For example, an EUI-48 MAC address interface 320 might have three different IPv6 addresses. This could be represented 321 by an IA APPsub-TLV whose Template specifically provided for one 322 EUI-48 address and three IPv6 addresses, which might be an efficient 323 format if there were multiple interfaces with that pattern. 324 Alternatively, a Template with one EUI-48 and one IPv6 address could 325 be used in an IA APPsub-TLV with three address sets each having the 326 same EUI-48 address but different IPv6 addresses, which might be the 327 most efficient format if only one interface had multiple IPv6 328 addresses and other interfaces had only one IPv6 address. 330 In order to be able to parse the Address Sets, a receiving RBridge 331 must know at least the size of the address each AFN the Template 332 specifies; however, the presence of the Addr Set End field means that 333 the sub-sub-TLVs, if any, can always be located by a receiver. An 334 RBridge can be assumed to know the size of the AFNs mentioned in 335 Section 5. Should an RBridge wish to include an AFN that some 336 receiving RBridge in the campus may not know, it SHOULD include an 337 AFN-Size sub-sub-TLV as described below. If an IA APPsub-TLV is 338 received with one or more AFNs in its template for which the 339 receiving RBridge does not know the length and for which an AFN-Size 340 sub-sub-TLV is not present, that IA APPsub-TLV MUST be ignored. 342 3. IA APPsub-TLV sub-sub-TLVs 344 IA APPsub-TLVs can have trailing sub-sub-TLVs [RFC5305] as specified 345 below. These sub-sub-TLVs occur after the Address Sets and the 346 amount of space available for sub-sub-TLVs is determined from the 347 overall IA APPsub-TLV length and the value of the Addr Set End byte. 349 There is no ordering restriction on sub-sub-TLVs. Unless otherwise 350 specified each sub-sub-TLV type can occur zero, one, or many times in 351 an IA APPsub-TLV. 353 3.1 AFN Size sub-sub-TLV 355 Using this sub-TLV, the originating RBridge can specify the size of 356 an address type. This is useful under two circumstances as follows: 358 1. One or more AFNs that are unknown to the receiving RBridge appears 359 in the template. If an AFN Size sub-sub-TLV is present for each 360 such AFN, then at least the IA APPsub-TLV can be parsed and 361 possibly other addresses in each address set can still be used. 363 2. If an AFN occurs in the Template that represents a variable length 364 address, this sub-sub-TLV gives its size for all occurrences in 365 that IA APPsub-TLV. (It is believed that the addresses specified 366 by all currently assigned AFNs are fixed length.) 368 +-+-+-+-+-+-+-+-+ 369 | Type = AFNsz | (1 byte) 370 +-+-+-+-+-+-+-+-+ 371 | Length | (1 byte) 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | AFN Size Record(s) | (3 bytes) 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Where each AFN Size Record is structured as follows: 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | AFN | (2 bytes) 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | AdrSize | (1 byte) 382 +-+-+-+-+-+-+-+-+ 384 o Type: AFN-Size sub-sub-TLV type, set to 1 (AFNsz). 386 o Length: 3*n where n is the number of AFN Size Records present. If 387 Length is not a multiple of 3, the sub-sub-TLV MUST be ignored. 389 o AFN Size Record(s): Zero or more 3-byte records, each giving the 390 size of an address type identified by an AFN, 392 o AFN: The AFN whose length is being specified by the AFN Size 393 Record. 395 o AdrSize: The length in bytes of addresses specified by the AFN 396 field as an unsigned integer. 398 An AFN Size sub-sub-TLV for any AFN known to the receiving RBridge is 399 compared with the size known to the RBridge. If they differ the IA 400 APPsub-TLV is assumed to be corrupt and MUST be ignored. 402 3.2 Fixed Address sub-sub-TLV 404 There may be cases where, in an Interface Addresses APP-subTLV, the 405 same address would appear in every address set across the APP-subTLV. 406 To avoid wasted space, this sub-sub-TLV can be used to indicate such 407 a fixed address. The address or addresses incorporated into the sets 408 by this sub-sub-TLV are NOT mentioned in the IA APPsub-TLV Template. 410 +-+-+-+-+-+-+-+-+ 411 | Type=FIXEDADR | (1 byte) 412 +-+-+-+-+-+-+-+-+ 413 | Length | (1 byte) 414 +-+-+-+-+-+-+-+-+ 415 | AFN | (2 bytes) 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 417 | Fixed Address (variable) 418 +-+-+-+-+-+-+-+-+-+-+-+-+-... 420 o Type: Data Label sub-sub-TLV type, set to 2 (FIXEDADR). 422 o Length: variable, minimum 3. If Length is 2 or less, the sub-sub- 423 TLV MUST be ignored. 425 o AFN: Address Family Number of the Fixed Address. 427 o Fixed Address: The address of the type indicated by the preceding 428 AFN field that is considered to be part of every Address Set in 429 the IA APPsub-TLV. 431 3.3 Data Label sub-sub-TLV 433 This sub-sub-TLV indicates the Data Label within which the interfaces 434 listed in the IA APPsub-TLV are reachable. It is useful if the IA 435 APPsub-TLV occurs outside of the context of an [ESADI] or other type 436 of message specifying the Data Label or if it is desired and 437 permitted to override that specification. Multiple occurrences of 438 this sub-sub-TLV indicate that the interface is reachable in all of 439 the Data Labels given. 441 +-+-+-+-+-+-+-+-+ 442 |Type=DATALEN | (1 byte) 443 +-+-+-+-+-+-+-+-+ 444 | Length | (1 byte) 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 446 | Data Label (variable) 447 +-+-+-+-+-+-+-+-+-+-+-+-+-... 449 o Type: Data Label sub-TLV type, set to 3 (LABEL). 451 o Length: 2 or 3. If Length is some other value, the sub-sub-TLV 452 is ignored. 454 o Data Label: If length is 2, the bottom 12 bits of the Data 455 Label are a VLAN ID and the top 4 bits are reserved (MUST be 456 sent as zero and ignored on receipt). If the length is 3, the 457 three Data Label bytes contain an FGL [RFCfgl]. 459 3.4 Topology sub-sub-TLV 461 The presence of this sub-sub-TLV indicates that the interfaces given 462 in the IA APPsub-TLV are reachable in the topology give. It is useful 463 if the IA APPsub-TLV occurs outside of the context of an [ESADI] or 464 other type of message indicating the topology or if it is desired and 465 permitted to override that specification. If it occurs multiple 466 times, then the Address Sets are in all of the topologies given. 468 +-+-+-+-+-+-+-+-+ 469 |Type=DATALEN | (1 byte) 470 +-+-+-+-+-+-+-+-+ 471 | Length | (1 byte) 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | RESV | Topology | (2 bytes) 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 o Type: Topology sub-TLV type, set to 4 (TOPOLOGY). 478 o Length: 2. If Length is some other values, the sub-sub-TLV is 479 ignored. 481 RESV: Four reserved bits. MUST be sent as zero and ignored on 482 receipt. 484 o Topology: The 12-bit topology number [RFC5120]. 486 4. Security Considerations 488 The integrity of address mapping and reachability information and the 489 correctness of Data Labels (VLANs or FLGs [RFCfgl]) are very 490 important. Forged, altered, or incorrect address mapping or Data 491 Labeling can lead to delivery of packets to the incorrect party, 492 violating security policy. However, this document merely describes a 493 data format and does not provide any explicit mechanisms for securing 494 that information, other than a few trivial consistency checks that 495 might detect some corrupted data. Security on the wire, or in 496 storage, for this data is to be providing by the transport or storage 497 used. For example, when transported with [ESADI], [ESADI] security 498 mechanisms can be used. 500 The address mapping and reachability information, if known to be 501 complete and correct, can be used to detect some cases of forged 502 packet source addresses [DirectoryFramework]. In particular, if 503 native traffic is received by a TRILL switch that would otherwise 504 accept it but authoritative data indicates the source address should 505 not be reachable from the receiving TRILL switch, that traffic should 506 be discarded. The data format specified in this document may 507 optionally include RBridge Port ID number so that this forged address 508 filtering can be optionally applied with port granularity. 510 See [RFC6325] for general TRILL Security Considerations. 512 5. IANA Considerations 514 As specified below, IANA has allocated new AFN numbers and IANA is 515 requested create the TRILL IS-APPsub-TLV sub-sub-TLV subregistry. 517 5.1 Additional AFN Number Allocation 519 IANA has alocated AFN numbers as follows: 521 Number Description References 522 ------ ----------- ---------- 524 16391 OUI This document. 525 16392 MAC/24 This document. 526 16393 MAC/40 This document. 527 16394 IPv6/64 This document. 528 16395 RBridge Port ID This document. 530 The OUI AFN is provided so that MAC addresses can be abbreviated if 531 they have the same upper 24 bits. In particular, if there is an OUI 532 provided as a Fixed Address sub-sub-TLV (see Section 5.2.2) then, 533 whenever a MAC/24 or MAC/40 address appears within an Address Set (as 534 indicated by the Template), the OUI is used as the first 24 bits of 535 the actual MAC address for the Address Set. An OUI provided by a 536 Fixed Address sub-sub-TLV is ignored if the IA APPsub-TLV has no 537 MAC/24 or MAC/40 in its template. 539 MAC/24 is a 24-bit suffix intended to be pre-fixed by an OUI as in 540 the previous paragraph. In the absence of an OUI specified as a Fixed 541 Address in the same APPsub-TLV, an Address Set MAC/24 address entry 542 cannot be used. 544 MAC/40 is a suffix as specified above except that it is 40-bit so the 545 result of combining it with an OUI is a 64-bit MAC address. 547 IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 548 address. If present, there will normally be an EUI-48 or EUI-64 549 address in the address set to provide the lower 64 bits of the IPv6 550 address. For this purpose, an EUI-48 is expanded to 64 bits as 551 described in [RFC5342bis]. 553 Other AFNs can be found at http://www.iana.org/assignments/address- 554 family-numbers 556 The following already allocated AFN values may be particularly useful 557 for IA APPsub-TLVs: 559 Hex Decimal Description References 560 ----- ------- ----------- ---------- 561 0001 1 IPv4 562 0002 2 IPv6 563 4005 16,389 48-bit MAC [RFC5342bis] 564 4006 16,390 64-bit MAC [RFC5342bis] 566 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry 568 IANA is requested to establish a new subregistry of the TRILL 569 Parameter Registry for sub-sub-TLVs of the Interface Addresses 570 APPsub-TLV with initial contents as shown below. 572 Name: Interface Addresses APPsub-TLV Sub-Sub-TLVs 574 Procedure: Expert Review 576 Reference: This document 578 Type Description Reference 579 ---- ----------- --------- 580 0 Reserved 581 1 AFN Size This document 582 2 Fixed Address This document 583 3 Data Label This document 584 4 Topology This document 585 5-254 Available 586 255 Reserved 588 Acknowledgments 590 The authors gratefully acknowledge the contributions and review by 591 the following: 593 Linda Dunbar 595 The document was prepared in raw nroff. All macros used were defined 596 within the source file. 598 Appendix A: Examples 600 Below are example IA APPsub-TLVs. 602 A.1 Simple Example 604 Below is an annotated IA APPsub-TLV carrying two simple pairs of 605 EUI-48 MAC addresses and IPv4 addresses from a Push Directory 606 [DirectoryFramework]. No sub-sub-TLVs are included. 608 0x02(TBD) Type: Interface Addresses 609 26 Size: 26 (=0x1A) 610 0x1234 RBridge Nickname from which reachable 611 0b10000000 Flags: Push Directory data 612 0xE3 Confidence 613 26 Address Sets End: 26 (=0x1A) 614 35 Template: 35 (0x23) = 32 + 1(MAC48) + 3*1(IPv4) 616 Address Set One 617 0x00005E0053A9 48-bitMAC address 618 198.51.100.23 IPv4 address 620 Address Set Two 621 0x00005E00536B 48-bit MAC address 622 203.0.113.201 IPv4 address 624 Size includes 6 for the fixed fields though and including the one 625 byte template, plus 2 times the Address Set size. Each Address Set is 626 10 bytes, 6 for the 48-bit MAC address plus 4 for the IPv4 address. 627 So total size is 6 + 2*10 = 26. 629 See Section 2 for more information on Template. 631 A.2 Complex Example 633 Below is an annotated IA APPsub-TLV carrying three sets of addresses, 634 each consisting of an EUI-48 MAC address, an IPv4 addresses, an IPv6 635 address, and an RBridge Port ID, all from a Push Directory 636 [DirectoryFramework]. The IPv6 address for each address set is 637 synthesized from the MAC address given in that set and the IPv6/64 638 64-bit prefix provided through a Fixed Address sub-sub-TLV. In 639 addition, a sub-sub-TLV is included that provides an FGL which 640 overrides whatever Data Label may be provided by the envelope (for 641 example [ESADI]) within which this IA APPsub-TLV occurs. 643 0x02(TBD) Type: Interface Addresses 644 59 Size: 59 (=0x3B) 645 0x4321 RBridge Nickname from which reachable 646 0b10000000 Flags: Push Directory data 647 0xD3 Confidence 648 42 Address Sets End: 42 (=0x2A) 649 72 Template: 72(0x48)=32+1(MAC48)+3*1(IPv4)+36*1(P) 651 Address Set One 652 0x00005E0053DE 48-bitMAC address 653 198.51.100.105 IPv4 address 654 0x1DE3 RBridge Port ID 656 Address Set Two 657 0x00005E0053E3 48-bit MAC address 658 203.0.113.89 IPv4 address 659 0x1DEE RBridge Port ID 661 Address Set Three 662 0x00005E0053D3 48-bit MAC address 663 192.0.2.139 IPv4 address 664 0x01DE RBridge Port ID 666 sub-sub-TLV One 667 0x03 Type: Data Label 668 0x03 Length: implies FGL 669 0xD3E3E3 Fine Grained Label 671 sub-sub-TLV Two 672 0x02 Type: Fixed Address 673 0x0A Size: 0x0A = 10 674 0x400A AFN: IPv6/64 675 0x0x20010DB800000000 IPv6 Prefix: 2001:DB8:: 677 See Section 2 for more information on Template. 679 The Fixed Address sub-sub-TLV causes the IPv6/64 value give to be 680 treated as if it occurred as a 4th entry inside each of the three 681 Address Sets. When there is an IPv6/64 entry and a 48-bit MAC entry, 682 the MAC value is expanded by inserting 0xFFFE immediately after the 683 OUI and the resulting 64-bit value is used as the lower 64 bits of 684 the resulting IPv6 address [RFC5342bis]. As a result, a receiving 685 TRILL switch would treat the three Address Sets shown as if they had 686 an IPv6 address in them as follows: 688 Address Set One 689 0x20010DB80000000000005EFFFE0053DE IPv6 Address 691 Address Set Two 692 0x20010DB80000000000005EFFFE0053E3 IPv6 Address 694 Address Set Three 695 0x20010DB80000000000005EFFFE0053D3 IPv6 Address 697 As an alternative to the compact "well know value" Template encoding 698 used in this example above, the less compact explicit AFN encoding 699 could have been used. In that case, the IA APPsub-TLV would have 700 started as follows: 702 0x02(TBD) Type: Interface Addresses 703 65 Size: 65 (=0x41) 704 0x4321 RBridge Nickname from which reachable 705 0b10000000 Flags: Push Directory data 706 0xD3 Confidence 707 48 Address Sets End: 48 (=0x30) 708 0x3 Template: 3 AFNs 709 0x4005 AFN: 48-bit MAC 710 0x0001 AFN: IPv4 711 0x400B AFN: RBridge Port ID 713 As a final point, since the 48-bit MAC addresses in these three 714 Address Sets all have the same OUI (the IANA OUI [RFC5342bis]), it 715 would have been possible to just have a MAC/24 value giving the lower 716 24 bits of the MAC in each Address Set. The OUI would them be 717 supplied by a second Fixed Address sub-sub-TLV proving the OUI. With 718 N Address Sets, this would have saved 3*N or 9 bytes in this case at 719 the cost of 7 bytes (1 each for the type and length of the sub-sub- 720 TLV, 2 for the OUI AFN number, and 3 for the OUI). So, even with just 721 three Address Sets, there would be a small net saving of 2 bytes. The 722 savings would grow with a larger number of Address Sets. 724 Normative References 726 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 727 826, November 1982. 729 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, March 1997 732 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 733 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 734 September 2007. 736 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 737 Topology (MT) Routing in Intermediate System to Intermediate 738 Systems (IS-ISs)", RFC 5120, February 2008. 740 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 741 Engineering", RFC 5305, October 2008. 743 [RFC5342bis] - Eastlake 3rd, D., "IANA Considerations and IETF 744 Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, 745 September 2008. 747 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 748 Ghanwani, "Routing Bridges (RBridges): Base Protocol 749 Specification", RFC 6325, July 2011. 751 [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising 752 Generic Information in IS-IS", RFC 6823, December 2012. 754 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 755 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine- 756 labeling-07.txt, in RFC Editor's queue. 758 Informational References 760 [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large 761 Data Centers", Oct 2010. 763 [DirectoryFramework] - Dunbar, L., D. Eastlake, R. Perlman, I. 764 Gashinsky, "TRILL Edge Directory Assistance Framework", draft- 765 ietf-trill-directory-framework-07.txt, in RFC Editor's queue. 767 [DirectoryScheme] - Dunbar, L., D. Eastlake, R. Perlman, I. 768 Gashinsky, Y. Li, "TRILL": Directory Assistance Mechanisms", 769 draft-dunbar-trill-scheme-for-directory-assist, work in 770 progress. 772 [ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O. Stokes, "TRILL 773 (Transparent Interconnection of Lots of Links): The ESADI (End 774 Station Address Distribution Information) Protocol", draft- 775 ietf-trill-esadi-03.txt, work in progress. 777 [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 778 for the Address Resolution Protocol (ARP)", RFC 5494, April 779 2009. 781 Authors' Addresses 783 Donald Eastlake 784 Huawei Technologies 785 155 Beaver Street 786 Milford, MA 01757 USA 788 Phone: +1-508-333-2270 789 Email: d3e3e3@gmail.com 791 Yizhou Li 792 Huawei Technologies 793 101 Software Avenue, 794 Nanjing 210012 China 796 Phone: +86-25-56622310 797 Email: liyizhou@huawei.com 799 Radia Perlman 800 Intel Labs 801 2200 Mission College Blvd. 802 Santa Clara, CA 95054-1549 USA 804 Phone: +1-408-765-8080 805 Email: Radia@alum.mit.edu 807 Copyright, Disclaimer, and Additional IPR Provisions 809 Copyright (c) 2013 IETF Trust and the persons identified as the 810 document authors. All rights reserved. 812 This document is subject to BCP 78 and the IETF Trust's Legal 813 Provisions Relating to IETF Documents 814 (http://trustee.ietf.org/license-info) in effect on the date of 815 publication of this document. Please review these documents 816 carefully, as they describe your rights and restrictions with respect 817 to this document. Code Components extracted from this document must 818 include Simplified BSD License text as described in Section 4.e of 819 the Trust Legal Provisions and are provided without warranty as 820 described in the Simplified BSD License. The definitive version of 821 an IETF Document is that published by, or under the auspices of, the 822 IETF. Versions of IETF Documents that are published by third parties, 823 including those that are translated into other languages, should not 824 be considered to be definitive versions of IETF Documents. The 825 definitive version of these Legal Provisions is that published by, or 826 under the auspices of, the IETF. Versions of these Legal Provisions 827 that are published by third parties, including those that are 828 translated into other languages, should not be considered to be 829 definitive versions of these Legal Provisions. For the avoidance of 830 doubt, each Contributor to the IETF Standards Process licenses each 831 Contribution that he or she makes as part of the IETF Standards 832 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 833 language to the contrary, or terms, conditions or rights that differ 834 from or are inconsistent with the rights and licenses granted under 835 RFC 5378, shall have any effect and shall be null and void, whether 836 published or posted by such Contributor, or included with or in such 837 Contribution.