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