idnits 2.17.1 draft-ietf-trill-ia-appsubtlv-02.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 (November 24, 2014) is 3439 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 EMC 7 Expires: May 23, 2014 November 24, 2014 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) and the reporting for 17 such a set of the TRILL switch by which it is reachable. For example, 18 a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 19 address can be reported as all corresponding to the same interface 20 reachable by a particular TRILL switch. Such information could be 21 used in some cases to synthesize responses to or by-pass the need for 22 the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery 23 (ND) protocol, or the flooding of unknown MAC addresses. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the TRILL working group mailing list. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Table of Contents 50 1. Introduction............................................3 51 1.1 Conventions Used in This Document......................3 53 2. Format of the Interface Addresses APPsub-TLV............5 55 3. IA APPsub-TLV sub-sub-TLVs.............................10 56 3.1 AFN Size sub-sub-TLV..................................10 57 3.2 Fixed Address sub-sub-TLV.............................11 58 3.3 Data Label sub-sub-TLV................................12 59 3.4 Topology sub-sub-TLV..................................12 61 4. Security Considerations................................14 63 5. IANA Considerations....................................15 64 5.1 AFN Number Allocation.................................15 65 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry................16 66 5.3 IA APPsub-TLV Number..................................16 68 Acknowledgments...........................................17 70 Appendix A: Examples......................................18 71 A.1 Simple Example........................................18 72 A.2 Complex Example.......................................18 74 Appendix Z: Change History................................21 76 Normative References......................................22 77 Informational References..................................23 78 Authors' Addresses........................................24 80 1. Introduction 82 This document specifies a TRILL (Transparent Interconnection of Lots 83 of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV [RFC6823]) 84 that enables the convenient representation of sets of addresses such 85 that all of the addresses in each set designate the same interface 86 (port). For example, a 48-bit MAC (Media Access Control [RFC7042]) 87 address, IPv4 address, and IPv6 address can be reported as all three 88 designating the same interface. In addition, a Data Label (VLAN or 89 Fine Grained Label (FGL [RFC7172])) is specified for the interface 90 along with the TRILL switch, and optionally the TRILL switch port, 91 from which the interface is reachable. Such information could be 92 used in some cases to synthesize responses to or by-pass the need for 93 the Address Resolution Protocol (ARP [RFC826]), the IPv6 Neighbor 94 Discovery (ND [RFC4861]) protocol, the Reverse Address Resolution 95 Protocol (RARP [RFC903]), or the flooding of unknown destination MAC 96 addresses [RFC7042]. If the information report is complete, it can 97 also be used to detect and discard packets with forged source 98 addresses. 100 This APPsub-TLV appears inside the TRILL GENINFO TLV specified in 101 ESADI [RFC7357] but may also occur in other application contexts. 102 Directory Assisted TRILL Edge services [DirectoryScheme] are expected 103 to make use of this APPsub-TLV. 105 Although, in some IETF protocols, address field types are represented 106 by Ethertype [RFC7042] or Hardware Type [RFC5494], only Address 107 Family Number (AFN) is used in this APPsub-TLV to represent address 108 field type. 110 1.1 Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. Capitalized 115 IANA Considertions terms such as "Expert Review" are to be 116 interpreted as described in [RFC5226]. 118 The terminology and acronyms of [RFC6325] are used herein along with 119 the following additional acronyms and terms: 121 AFN: Address Family Number 123 APPsub-TLV: Application sub-TLV [RFC6823] 125 Data Label: VLAN or FGL 127 FGL: Fine Grained Label [RFC7172] 128 IA: Interface Addresses 130 RBridge: An alternative name for a TRILL switch 132 TRILL switch: A device that implements the TRILL protocol 134 2. Format of the Interface Addresses APPsub-TLV 136 The Interface Addresses (IA) APPsub-TLV is used to advertise that a 137 set of addresses indicate the same interface (port) within a Data 138 Label (VLAN or FGL) and to associate that interface with the TRILL 139 switch, and optionally the TRILL switch port, by which the interface 140 is reachable. These addresses can be in different address families. 141 For example, it can be used to declare that a particular interface 142 with specified IPv4, IPv6, and 48-bit MAC addresses in some 143 particular Data Label is reachable from a particular TRILL switch. 145 The Template field in a particular Interface Addresses APPsub-TLV 146 indicates the format of each Address Set it carries. Certain well- 147 known sets of addresses are represented by special values. Other sets 148 of addresses are specified by a list of AFNs. The Template format 149 that uses a list of AFNs provides an explicit pattern for the type 150 and order of addresses in each Address Set in the IA APPsub-TLV that 151 includes that Template. 153 A device or application making use of IA APPsub-TLV data is not 154 required to make use of all IA data. For example, a device or 155 application that was only interested in MAC and IPv6 addresses could 156 ignore any IPv4 or other types of address information that was 157 present. 159 The figure below shows an IA APPsub-TLV as it would appear inside an 160 IS-IS FS-LSP using an extended flooding scope [RFC7356] TLV, for 161 example in ESADI [RFC7357]. Within an IS-IS PDU using traditional 162 [ISO-10589] TLVs, the Type and Length would be one byte unsigned 163 integers equal to or less than 255. 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type = TBD1 | (2 bytes) 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Length | (2 bytes) 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Addr Sets End | (2 bytes) 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Nickname | (2 bytes) 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Flags | (1 byte) 175 +-+-+-+-+-+-+-+-+ 176 | Confidence | (1 byte) 177 +-+-+-+-+-+-+-+-+-+- 178 | Template ... (variable) 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 180 | Address Set 1 (size determined by Template) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 182 | Address Set 2 (size determined by Template) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 184 | ... 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 186 | Address Set N (size determined by Template) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 188 | optional sub-sub-TLVs ... 189 +-+-+-+-+-+-+-+-+-+-+-+-... 191 Figure 1. The Interface Addresses APPsub-TLV 193 o Type: Interface Addresses TRILL APPsub-TLV type, set to TBD1 (IA- 194 SUBTLV). 196 o Length: Variable, minimum 7. If length is 6 or less or if the 197 APPsub-TLV extends beyond the size of an encompassing TRILL 198 GENINFO TLV or other context, the APPsub-TLV MUST be ignored. 200 o Addr Sets End: The unsigned integer offset of the byte, within the 201 IA APPsub-TLV value part, of the last byte of the last Address 202 Set. This will be the byte just before the first sub-sub-TLV if 203 any sub-sub-TLVs are present (see Section 3). If this is equal to 204 Length, there are no sub-sub-TLVs. If this is greater than Length 205 or points to before the end of the Template, the IA APPsub-TLV is 206 corrupt and MUST be discarded. This field is always two bytes in 207 size. 209 o Nickname: The nickname of the TRILL switch by which the address 210 sets are reachable. If zero, the address sets are reachable from 211 the TRILL switch originating the message containing the APPsub-TLV 212 (for example, an ESADI [RFC7357] message). 214 o Flags: A byte of flags as follows: 216 0 1 2 3 4 5 6 7 217 +-+-+-+-+-+-+-+-+ 218 |D|L|N| RESV | 219 +-+-+-+-+-+-+-+-+ 221 D: Directory flag: If D is one, the APPsub-TLV contains 222 Directory information [RFC7067]. 224 L: Local flag: If L is one, the APPsub-TLV contains information 225 learned locally by observing ingressed frames [RFC6325]. 226 (Both D and L can be one in the same IA APPsub-TLV if a 227 TRILL switch that had learned an address locally and also 228 advertised it as a directory.) 230 N: Notify flag: When a TRILL switch receives a new IA APPsub- 231 TLV (one in a ESADI-LSP fragment with a higher sequence 232 number or a new message of some other type) and the N bit is 233 one, the TRILL switch then checks the contents of the 234 APPsub-TLV for address sets including both an IP address and 235 a MAC address. For each such address set it finds, a 236 gratuitous ARP [RFC826] or spontaneous Neighbor 237 Advertisement [RFC4861], depending on whether the IP address 238 is IPv4 or IPv6 respectively, may be sent. In both cases, 239 these are sent out all the ports of the TRILL switch 240 offering end station service and are in the VLAN or FGL of 241 the address set information, that is, are Appointed 242 Forwarder for the VLAN or for the VLAN to which the FGL 243 maps. 245 RESV: Additional reserved flag bits that MUST be sent as zero 246 and ignored on receipt. 248 o Confidence: This 8-bit unsigned quantity in the range 0 to 254 249 indicates the confidence level in the addresses being transported 250 [RFC6325]. A value of 255 is treated as if it was 254. 252 o Template: The initial byte of this field is the unsigned integer 253 K. If K has a value from 1 to 31, it indicates that this initial 254 byte is followed by a list of K AFNs (Address Family Numbers) that 255 specify the exact structure and order of each Address Set 256 occurring later in the APPsub-TLV. K can be 1, which is the 257 minimum valid value. If K is zero, the IA APPsub-TLV is ignored. 258 If K is 32 to 254, the length of the Template field is one byte 259 and its value is intended to correspond to a particular ordered 260 set of AFNs some of which are specified below. If K is 255, the 261 length of the Template filed is three bytes and the values of the 262 second and third byte, considered as an unsigned integer in 263 network byte order, are reserved to correspond to future specified 264 ordered sets of AFNs. 266 If the Template uses explicit AFNs, it looks like the following, 267 with the number of AFNs up to 31 equal to K. 269 +-+-+-+-+-+-+-+-+ 270 | K | (1 byte) 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | AFN 1 | (2 bytes) 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | AFN 2 | (2 bytes) 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | ... 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | AFN K | (2 bytes) 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 For K in the 32 to 102 range, values indicate combinations of a 282 specific number of MAC addresses, IPv4 addresses, IPv6 addresses, 283 and TRILL switch port IDs appearing in that order. The value of K 284 is 286 K = 31 + M + 3*v4 + 9*v6 + 36*P 288 where M is 0, 1, or 2 (0 if no MAC address is present, 1 if a 289 48-bit MAC is present, 2 if a MAC/24 (see Section 5.1) is 290 present), v4 is the number of IPv4 addresses (limited to 0, 1, or 291 2) and v6 is the number of IPv6 addresses (limited to 0 through 3 292 inclusive), and P is the number of TRILL switch port IDs (limited 293 to 0 or 1); however, the number of MAC, IPv4, and IPv6 addresses 294 and TRILL switch ports cannot all be simultaneously zero. That 295 equation specifies values of K from 32 through 102, the value 31 296 not being permitted but instead representing an explicit Template 297 with 31 AFNs. Values from 103 through 254 of the byte value are 298 available for assignment by Expert Review (see Section 5). K = 255 299 indicates a three-byte Template field as specified above. All 300 values (0 through 65,545) of this two-byte value are available for 301 assignment by Expert Review. 303 If an unknown Template K value in the range 103 to 254 is received 304 or a K of 255 followed by an unknown two byte value, the IA 305 APPsub-TLV MUST be ignored. 307 o AFN: A two-byte Address Family Number. The number of AFNs present 308 is given by K except that there are no AFNs if K is greater than 309 31. The AFN sequence specifies the structure of the Address Sets 310 occurring later in the TLV. For example, if Template Size is 2 and 311 the two AFNs present are the AFNs for a 48-bit MAC and an IPv4 312 address, in that order, then each Address set present will consist 313 of a 6-byte MAC address followed by a 4-byte IPv4 address. If any 314 AFNs are present that are unknown to the receiving IS and the 315 length of the corresponding address is not provided by a sub-sub- 316 TLV as specified below, the receiving IS will be unable to parse 317 the Address Sets and MUST ignore the IA APPsub-TLV. 319 o Address Set: Each address set in the APPsub-TLV consists of 320 exactly the same sequence of addresses of the types specified by 321 the Template earlier in the APPsub-TLV. No alignment, other than 322 to a byte boundary, is guaranteed. The addresses in each Address 323 Set are contiguous with no unused bytes between them and the 324 Address Sets are contiguous with no unused bytes between 325 successive Address Sets. The Address Sets must fit within the TLV. 327 o sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do 328 not completely fill the Length of the APPsub-TLV, the remaining 329 bytes are parsed as sub-sub-TLVs [RFC5305]. Any such sub-sub-TLVs 330 that are not known to the receiving TRILL switch are ignored. 331 Should this parsing not be possible, for example there is only one 332 remaining byte or an apparent sub-sub-TLV extends beyond the end 333 of the TLV, the containing IA APPsub-TLV is considered corrupt and 334 is ignored. (Several sub-sub-TLV types are specified in Section 335 3.) 337 Different IA APPsub-TLVs within the same or different LSPs or other 338 data structures may have different Templates. The same AFN may occur 339 more than once in a Template and the same address may occur in 340 different address sets. For example, a 48-bit MAC address interface 341 might have three different IPv6 addresses. This could be represented 342 by an IA APPsub-TLV whose Template specifically provided for one 343 EUI-48 address and three IPv6 addresses, which might be an efficient 344 format if there were multiple interfaces with that pattern. 345 Alternatively, a Template with one 48-bit MAC and one IPv6 address 346 could be used in an IA APPsub-TLV with three address sets each having 347 the same MAC address but different IPv6 addresses, which might be the 348 most efficient format if only one interface had multiple IPv6 349 addresses and other interfaces had only one IPv6 address. 351 In order to be able to parse the Address Sets, a receiving TRILL 352 switch must know at least the size of the address for each AFN or 353 address type the Template specifies; however, the presence of the 354 Addr Set End field means that the sub-sub-TLVs, if any, can always be 355 located by a receiver. A TRILL switch can be assumed to know the 356 size of the AFNs mentioned in Section 5. Should a TRILL switch wish 357 to include an AFN that some receiving TRILL switch in the campus may 358 not know, it SHOULD include an AFN-Size sub-sub-TLV as described in 359 Section 3.1. If an IA APPsub-TLV is received with one or more AFNs in 360 its template for which the receiving TRILL switch does not know the 361 length and for which an AFN-Size sub-sub-TLV is not present, that IA 362 APPsub-TLV MUST be ignored. 364 3. IA APPsub-TLV sub-sub-TLVs 366 IA APPsub-TLVs can have trailing sub-sub-TLVs [RFC5305] as specified 367 below. These sub-sub-TLVs occur after the Address Sets and the 368 amount of space available for sub-sub-TLVs is determined from the 369 overall IA APPsub-TLV length and the value of the Addr Set End byte. 371 There is no ordering restriction on sub-sub-TLVs. Unless otherwise 372 specified each sub-sub-TLV type can occur zero, one, or many times in 373 an IA APPsub-TLV. Any sub-sub-TLVs for which the Type is unknown are 374 ignored. 376 The sub-sub-TLVs data structures shown below, with two byte Types and 377 Lengths, assume that the enclosing IA-APPsubTLV is in an extended LSP 378 TLV [RFC7356] or some non-LSP context. If they were used in a IA- 379 APPsubTLV in a traditional LSP [ISO-10589], the only one byte Types 380 and Lengths could be used. As a result, any sub-sub-TLV types greater 381 than 255 could not be used and Length would be limited to 255. 383 3.1 AFN Size sub-sub-TLV 385 Using this sub-sub-TLV, the originating TRILL switch can specify the 386 size of an address type. This is useful under two circumstances as 387 follows: 389 1. One or more AFNs that are unknown to the receiving TRILL switch 390 appears in the template. If an AFN Size sub-sub-TLV is present for 391 each such AFN, then at least the IA APPsub-TLV can be parsed and 392 possibly other addresses in each address set can still be used. 394 2. If an AFN occurs in the Template that represents a variable length 395 address, this sub-sub-TLV gives its size for all occurrences in 396 that IA APPsub-TLV. 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type = AFNsz | (2 byte) 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Length | (2 byte) 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | AFN Size Record 1 | (3 bytes) 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | AFN Size Record 2 | (3 bytes) 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | ... 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | AFN Size Record N | (3 bytes) 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Where each AFN Size Record is structured as follows: 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | AFN | (2 bytes) 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | AdrSize | (1 byte) 418 +-+-+-+-+-+-+-+-+ 420 o Type: AFN-Size sub-sub-TLV type, set to 1 (AFNsz). 422 o Length: 3*n where n is the number of AFN Size Records present. If 423 Length is not a multiple of 3, the sub-sub-TLV MUST be ignored. 425 o AFN Size Record(s): Zero or more 3-byte records, each giving the 426 size of an address type identified by an AFN, 428 o AFN: The AFN whose length is being specified by the AFN Size 429 Record. 431 o AdrSize: The length in bytes of addresses specified by the AFN 432 field as an unsigned integer. 434 An AFN Size sub-sub-TLV for any AFN known to the receiving TRILL 435 switch is compared with the size known to the TRILL switch. If they 436 differ the IA APPsub-TLV is assumed to be corrupt and MUST be 437 ignored. 439 3.2 Fixed Address sub-sub-TLV 441 There may be cases where, in a particular Interface Addresses APP- 442 subTLV, the same address would appear in every address set across the 443 APP-subTLV. To avoid wasted space, this sub-sub-TLV can be used to 444 indicate such a fixed address. The address or addresses incorporated 445 into the sets by this sub-sub-TLV are NOT mentioned in the IA APPsub- 446 TLV Template. 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type=FIXEDADR | (2 byte) 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Length | (2 byte) 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | AFN | (2 bytes) 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Fixed Address (variable) 456 +-+-+-+-+-+-+-+-+-+-+-+-+-... 458 o Type: Data Label sub-sub-TLV type, set to 2 (FIXEDADR). 460 o Length: variable, minimum 2. If Length is 0 or 1 or less, the sub- 461 sub-TLV MUST be ignored. 463 o AFN: Address Family Number of the Fixed Address. 465 o Fixed Address: The address of the type indicated by the preceding 466 AFN field that is considered to be part of every Address Set in 467 the IA APPsub-TLV. 469 The Length field implies a size for the Fixed Address. If that size 470 differs from the size of the address type for the given AFN as known 471 by the receiving TRILL switch, the Fixed Address sub-sub-TLV is 472 considered corrupt and MUST be ignored. 474 3.3 Data Label sub-sub-TLV 476 This sub-sub-TLV indicates the Data Label within which the interfaces 477 listed in the IA APPsub-TLV are reachable. It is useful if the IA 478 APPsub-TLV occurs outside of the context of a message specifying the 479 Data Label or if it is desired and permitted to override that 480 specification. Multiple occurrences of this sub-sub-TLV indicate 481 that the interfaces are reachable in all of the Data Labels given. 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |Type=DATALEN | (2 byte) 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Length | (2 byte) 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Data Label (variable) 489 +-+-+-+-+-+-+-+-+-+-+-+-+-... 491 o Type: Data Label sub-TLV type, set to 3 (LABEL). 493 o Length: 2 or 3. If Length is some other value, the sub-sub-TLV 494 MUST be ignored. 496 o Data Label: If length is 2, the bottom 12 bits of the Data 497 Label are a VLAN ID and the top 4 bits are reserved (MUST be 498 sent as zero and ignored on receipt). If the length is 3, the 499 three Data Label bytes contain an FGL [RFC7172]. 501 3.4 Topology sub-sub-TLV 503 The presence of this sub-sub-TLV indicates that the interfaces given 504 in the IA APPsub-TLV are reachable in the topology give. It is useful 505 if the IA APPsub-TLV occurs outside of the context of a message 506 indicating the topology or if it is desired and permitted to override 507 that specification. If it occurs multiple times, then the Address 508 Sets are in all of the topologies given. 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |Type=DATALEN | (2 byte) 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Length | (2 byte) 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | RESV | Topology | (2 bytes) 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 o Type: Topology sub-TLV type, set to 4 (TOPOLOGY). 520 o Length: 2. If Length is some other values, the sub-sub-TLV MUST 521 be ignored. 523 RESV: Four reserved bits. MUST be sent as zero and ignored on 524 receipt. 526 o Topology: The 12-bit topology number [RFC5120]. 528 4. Security Considerations 530 The integrity of address mapping and reachability information and the 531 correctness of Data Labels (VLANs or FGLs [RFC7172]) are very 532 important. Forged, altered, or incorrect address mapping or Data 533 Labeling can lead to delivery of packets to the incorrect party, 534 violating security policy. However, this document merely describes a 535 data format and does not provide any explicit mechanisms for securing 536 that information, other than a few trivial consistency checks that 537 might detect some corrupted data. Security on the wire, or in 538 storage, for this data is to be providing by the transport or storage 539 used. For example, when transported with ESADI [RFC7357] or RBridge 540 Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel] 541 security mechanisms can be used, respectively. 543 The address mapping and reachability information, if known to be 544 complete and correct, can be used to detect some cases of forged 545 packet source addresses [RFC7067]. In particular, if native traffic 546 from an end station is received by a TRILL switch that would 547 otherwise accept it but authoritative data indicates the source 548 address should not be reachable from the receiving TRILL switch, that 549 traffic should be discarded. The data format specified in this 550 document may optionally include TRILL switch Port ID number so that 551 this forged address filtering can be optionally applied with port 552 granularity. 554 See [RFC6325] for general TRILL Security Considerations. 556 5. IANA Considerations 558 The following subsections specify IANA actions. 560 5.1 AFN Number Allocation 562 IANA has allocated the following AFN values that may be particularly 563 useful for IA APPsub-TLVs: 565 Hex Decimal Description References 566 ----- ------- ----------- ---------- 568 0001 1 IPv4 569 0002 2 IPv6 570 4005 16389 48-bit MAC [RFC7042] 571 4006 16390 64-bit MAC [RFC7042] 572 4007 16391 OUI This document. 573 4008 16392 MAC/24 This document. 574 4009 16393 MAC/40 This document. 575 400A 16394 IPv6/64 This document. 576 400B 16395 RBridge Port ID This document. 578 Other AFNs can be found at http://www.iana.org/assignments/address- 579 family-numbers 581 The OUI AFN is provided so that MAC addresses can be abbreviated if 582 they have the same upper 24 bits. A MAC/24 is a 24-bit suffix 583 intended to be pre-fixed by an OUI to create a 48-bit MAC address 584 [RFC7042]; in the absence of an OUI, a MAC/24 entry cannot be used. 585 A MAC/40 is a suffix intended to be pre-fixed by an OUI to create a 586 64-bit MAC address [RFC7042]; in the absence of an OUI, a MAC/40 587 entry cannot be used. 589 Typically, an OUI would be provided as a Fixed Address sub-sub-TLV 590 (see Section 3.2). 592 After Fixed Address sub-sub-TLV processing above, each address set is 593 processed by combining each OUI in the address set with each MAC/24 594 and each MAC/40 address in the address set. Depending on how many of 595 each of these address types is present, zero or more 48-bit and/or 596 64-bit MAC addresses may be produced that are considered to be part 597 of the address set. If there are no MAC/24 or MAC/40 addresses 598 present, any OUI's are ignored. If there are no OUIs, any MAC/24 599 and/or MAC/40s are ignored. If there are K1 OUIs, K2 MAC/24s, and K3 600 MAC/40s, K1*K2 48-bit MACs are synthesized and K1*K3 64-bit MACs are 601 synthesized. 603 IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 604 address. IPv6/64s are ignored unless, after the processing above in 605 this sub-section, there are one or more 48-bit and/or 64-bit MAC 606 addresses in the address set to provide the lower 64 bits of the IPv6 607 address. For this purpose, an 48-bit MAC address is expanded to 64 608 bits as described in [RFC7042]. If there are K4 IPv6/64s present and 609 K5 48- and 64-bit MAC addresses present, K4*K5 128-bit IPv6 addresses 610 are synthesized. 612 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry 614 IANA is requested to establish a new subregistry of the TRILL 615 Parameter Registry for sub-sub-TLVs of the Interface Addresses 616 APPsub-TLV with initial contents as shown below. 618 Name: Interface Addresses APPsub-TLV Sub-Sub-TLVs 620 Procedure: Expert Review 622 Note: Types greater than 255 are not usable in some contexts. 624 Reference: This document 626 Type Description Reference 627 ------ ----------- --------- 628 0 Reserved 629 1 AFN Size This document 630 2 Fixed Address This document 631 3 Data Label This document 632 4 Topology This document 633 5-254 Available 634 255 Reserved 635 256-65534 Available 636 65535 Reserved 638 5.3 IA APPsub-TLV Number 640 IANA has allocated TBD1 as the Type for the IA APPsub-TLV in the 641 "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" 642 registry from the range under 256. In the registry the Name is "IA" 643 and the Reference is this document. 645 Acknowledgments 647 The authors gratefully acknowledge the contributions and review by 648 the following: 650 Linda Dunbar 652 The document was prepared in raw nroff. All macros used were defined 653 within the source file. 655 Appendix A: Examples 657 Below are example IA APPsub-TLVs. 659 A.1 Simple Example 661 Below is an annotated IA APPsub-TLV carrying two simple pairs of 662 EUI-48 MAC addresses and IPv4 addresses from a Push Directory 663 [RFC7042]. No sub-sub-TLVs are included. 665 0x0002(TBD) Type: Interface Addresses 666 0x001B Length: 27 (=0x1B) 667 0x001B Address Sets End: 27 (=0x1B) 668 0x1234 RBridge Nickname from which reachable 669 0b10000000 Flags: Push Directory data 670 0xE3 Confidence = 227 671 35 Template: 35 (0x23) = 31 + 1(MAC48) + 3*1(IPv4) 673 Address Set One 674 0x00005E0053A9 48-bitMAC address 675 198.51.100.23 IPv4 address 677 Address Set Two 678 0x00005E00536B 48-bit MAC address 679 203.0.113.201 IPv4 address 681 Size includes 7 for the fixed fields though and including the one 682 byte template, plus 2 times the Address Set size. Each Address Set is 683 10 bytes, 6 for the 48-bit MAC address plus 4 for the IPv4 address. 684 So total size is 7 + 2*10 = 27. 686 See Section 2 for more information on Template. 688 A.2 Complex Example 690 Below is an annotated IA APPsub-TLV carrying three sets of addresses, 691 each consisting of an EUI-48 MAC address, an IPv4 addresses, an IPv6 692 address, and an RBridge Port ID, all from a Push Directory [RFC7042]. 693 The IPv6 address for each address set is synthesized from the MAC 694 address given in that set and the IPv6/64 64-bit prefix provided 695 through a Fixed Address sub-sub-TLV. In addition, a sub-sub-TLV is 696 included that provides an FGL which overrides whatever Data Label may 697 be provided by the envelope (for example an ESADI-LSP [RFC7357]) 698 within which this IA APPsub-TLV occurs. 700 0x0002(TBD) Type: Interface Addresses 701 0x0036 Length: 54 (=0x36) 702 0x0021 Address Sets End: 33 (=0x21) 703 0x4321 RBridge Nickname from which reachable 704 0b10000000 Flags: Push Directory data 705 0xD3 Confidence = 211 706 72 Template: 72(0x48)=31+1(MAC48)+3*1(IPv4)+36*1(P) 708 Address Set One 709 0x00005E0053DE 48-bitMAC address 710 198.51.100.105 IPv4 address 711 0x1DE3 RBridge Port ID 713 Address Set Two 714 0x00005E0053E3 48-bit MAC address 715 203.0.113.89 IPv4 address 716 0x1DEE RBridge Port ID 718 Address Set Three 719 0x00005E0053D3 48-bit MAC address 720 192.0.2.139 IPv4 address 721 0x01DE RBridge Port ID 723 sub-sub-TLV One 724 0x0003 Type: Data Label 725 0x0003 Length: implies FGL 726 0xD3E3E3 Fine Grained Label 728 sub-sub-TLV Two 729 0x0002 Type: Fixed Address 730 0x000A Size: 0x0A = 10 731 0x400A AFN: IPv6/64 732 0x20010DB800000000 IPv6 Prefix: 2001:DB8:: 734 See Section 2 for more information on Template. 736 The Fixed Address sub-sub-TLV causes the IPv6/64 value give to be 737 treated as if it occurred as a 4th entry inside each of the three 738 Address Sets. When there is an IPv6/64 entry and a 48-bit MAC entry, 739 the MAC value is expanded by inserting 0xFFFE immediately after the 740 OUI and the resulting 64-bit value is used as the lower 64 bits of 741 the resulting IPv6 address [RFC7042]. As a result, a receiving TRILL 742 switch would treat the three Address Sets shown as if they had an 743 IPv6 address in them as follows: 745 Address Set One 746 0x20010DB80000000000005EFFFE0053DE IPv6 Address 748 Address Set Two 749 0x20010DB80000000000005EFFFE0053E3 IPv6 Address 751 Address Set Three 752 0x20010DB80000000000005EFFFE0053D3 IPv6 Address 754 As an alternative to the compact "well know value" Template encoding 755 used in this example above, the less compact explicit AFN encoding 756 could have been used. In that case, the IA APPsub-TLV would have 757 started as follows: 759 0x0002(TBD) Type: Interface Addresses 760 0x003C Length: 60 (=0x3C) 761 0x0027 Address Sets End: 39 (=0x27) 762 0x4321 RBridge Nickname from which reachable 763 0b10000000 Flags: Push Directory data 764 0xD3 Confidence = 211 765 0x3 Template: 3 AFNs 766 0x4005 AFN: 48-bit MAC 767 0x0001 AFN: IPv4 768 0x400B AFN: RBridge Port ID 770 As a final point, since the 48-bit MAC addresses in these three 771 Address Sets all have the same OUI (the IANA OUI [RFC7042]), it would 772 have been possible to just have a MAC/24 value giving the lower 24 773 bits of the MAC in each Address Set. The OUI would them be supplied 774 by a second Fixed Address sub-sub-TLV proving the OUI. With N Address 775 Sets, this would have saved 3*N or 9 bytes in this case at the cost 776 of 9 bytes (2 each for the type and length of the sub-sub-TLV, 2 for 777 the OUI AFN number, and 3 for the OUI). So, with just three Address 778 Sets, there would be no net saving; however, with a larger number of 779 Address Sets, there would be a net savings. 781 Appendix Z: Change History 783 From -00 to -01 785 1. Update references for RFC publications. 787 2. Add this Change History Appendix. 789 From -01 to -02 791 1. Fix off-by-one errors in body text and examples for well known 792 Template values. 794 2. Update for drafts published as RFCs and change in Author Address. 796 3. Minor editorial improvements. 798 Normative References 800 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 801 System to Intermediate System Intra-Domain Routing Exchange 802 Protocol for use in Conjunction with the Protocol for Providing 803 the Connectionless-mode Network Service (ISO 8473)", 2002. 805 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 806 RFC 826, November 1982. 808 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 809 Reverse Address Resolution Protocol", STD 38, RFC 903, June 810 1984. 812 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997 815 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 816 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 817 September 2007. 819 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 820 Topology (MT) Routing in Intermediate System to Intermediate 821 Systems (IS-ISs)", RFC 5120, February 2008. 823 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 824 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 825 2008. 827 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 828 Engineering", RFC 5305, October 2008. 830 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 831 Ghanwani, "Routing Bridges (RBridges): Base Protocol 832 Specification", RFC 6325, July 2011. 834 [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising 835 Generic Information in IS-IS", RFC 6823, December 2012. 837 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 838 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 839 BCP 141, RFC 7042, October 2013. 841 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 842 and D. Dutt, "Transparent Interconnection of Lots of Links 843 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 845 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 846 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 847 . 849 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 850 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 851 End Station Address Distribution Information (ESADI) Protocol", 852 RFC 7357, September 2014, . 855 Informational References 857 [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large 858 Data Centers", draft-shah-armd-arp-reduction, work in progress. 860 [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel 861 Protocol", draft-eastlake-trill-channel-tunnel, work in 862 progress. 864 [DirectoryScheme] - Dunbar, L., D. Eastlake, R. Perlman, I. 865 Gashinsky, Y. Li, "TRILL": Directory Assistance Mechanisms", 866 draft-dunbar-trill-scheme-for-directory-assist, work in 867 progress. 869 [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 870 for the Address Resolution Protocol (ARP)", RFC 5494, April 871 2009. 873 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 874 Gashinsky, "Directory Assistance Problem and High-Level Design 875 Proposal", RFC 7067, November 2013. 877 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 878 Ward, "Transparent Interconnection of Lots of Links (TRILL): 879 RBridge Channel Support", RFC 7178, May 2014. 881 Authors' Addresses 883 Donald Eastlake 884 Huawei Technologies 885 155 Beaver Street 886 Milford, MA 01757 USA 888 Phone: +1-508-333-2270 889 Email: d3e3e3@gmail.com 891 Yizhou Li 892 Huawei Technologies 893 101 Software Avenue, 894 Nanjing 210012 China 896 Phone: +86-25-56622310 897 Email: liyizhou@huawei.com 899 Radia Perlman 900 EMC 901 2010 256th Avenue NE, #200 902 Bellevue, WA 98007 USA 904 Email: Radia@alum.mit.edu 906 Copyright, Disclaimer, and Additional IPR Provisions 908 Copyright (c) 2014 IETF Trust and the persons identified as the 909 document authors. All rights reserved. 911 This document is subject to BCP 78 and the IETF Trust's Legal 912 Provisions Relating to IETF Documents 913 (http://trustee.ietf.org/license-info) in effect on the date of 914 publication of this document. Please review these documents 915 carefully, as they describe your rights and restrictions with respect 916 to this document. Code Components extracted from this document must 917 include Simplified BSD License text as described in Section 4.e of 918 the Trust Legal Provisions and are provided without warranty as 919 described in the Simplified BSD License. The definitive version of 920 an IETF Document is that published by, or under the auspices of, the 921 IETF. Versions of IETF Documents that are published by third parties, 922 including those that are translated into other languages, should not 923 be considered to be definitive versions of IETF Documents. The 924 definitive version of these Legal Provisions is that published by, or 925 under the auspices of, the IETF. Versions of these Legal Provisions 926 that are published by third parties, including those that are 927 translated into other languages, should not be considered to be 928 definitive versions of these Legal Provisions. For the avoidance of 929 doubt, each Contributor to the IETF Standards Process licenses each 930 Contribution that he or she makes as part of the IETF Standards 931 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 932 language to the contrary, or terms, conditions or rights that differ 933 from or are inconsistent with the rights and licenses granted under 934 RFC 5378, shall have any effect and shall be null and void, whether 935 published or posted by such Contributor, or included with or in such 936 Contribution.