idnits 2.17.1 draft-ietf-trill-ia-appsubtlv-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2016) is 2846 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: January 4, 2017 July 5, 2016 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. Each set of addresses reports all 14 of the addresses that designate the same interface (port) and also 15 reports the TRILL switch by which that interface is reachable. For 16 example, a 48-bit MAC (Media Access Control) address, IPv4 address, 17 and IPv6 address can be reported as all corresponding to the same 18 interface reachable by a particular TRILL switch. Such information 19 could be used in some cases to synthesize responses to or bypass the 20 need for the Address Resolution Protocol (ARP), the IPv6 Neighbor 21 Discovery (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.............................10 54 3.1 AFN Size sub-sub-TLV..................................10 55 3.2 Fixed Address sub-sub-TLV.............................11 56 3.3 Data Label sub-sub-TLV................................12 57 3.4 Topology sub-sub-TLV..................................13 59 4. Security Considerations................................14 61 5. IANA Considerations....................................15 62 5.1 AFN Number Allocation.................................15 63 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry................15 64 5.3 IA APPsub-TLV Number..................................16 66 6. Additional AFN Information.............................17 67 7. Processing Address Sets................................18 69 Acknowledgments...........................................19 71 Appendix A: Examples......................................20 72 A.1 Simple Example........................................20 73 A.2 Complex Example.......................................20 75 Appendix Z: Change History................................23 77 Normative References......................................24 78 Informational References..................................25 80 Authors' Addresses........................................26 82 1. Introduction 84 This document specifies a TRILL (Transparent Interconnection of Lots 85 of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV [RFC6823]) 86 that enables the convenient representation of sets of addresses where 87 all of the addresses in each set designate the same interface (port). 88 For example, a 48-bit MAC (Media Access Control [RFC7042]) address, 89 IPv4 address, and IPv6 address can be reported as all three 90 designating the same interface. In addition, a Data Label (VLAN or 91 Fine Grained Label (FGL [RFC7172])) is specified for the interface 92 along with the TRILL switch, and optionally the TRILL switch port, 93 from which the interface is reachable. Such information could be 94 used in some cases to synthesize responses to or bypass the need for 95 the Address Resolution Protocol (ARP [RFC826]), the IPv6 Neighbor 96 Discovery (ND [RFC4861]) protocol, the Reverse Address Resolution 97 Protocol (RARP [RFC903]), or the flooding of unknown destination MAC 98 addresses [ARPND]. If the information reported is complete, it can 99 also be used to detect and discard packets with forged source 100 addresses. 102 This APPsub-TLV appears inside the TRILL GENINFO TLV specified in the 103 ESADI RFC [RFC7357] but may also occur in other application contexts. 104 Directory Assisted TRILL Edge services [DirectoryScheme] are expected 105 to make use of this APPsub-TLV. 107 Although, in some IETF protocols, address field types are represented 108 by Ethertype [RFC7042] or Hardware Type [RFC5494], only Address 109 Family Number (AFN) is used in this APPsub-TLV to represent address 110 field type. 112 1.1 Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. Capitalized 117 IANA Considerations terms such as "Expert Review" are to be 118 interpreted as described in [RFC5226]. 120 The terminology and acronyms of [RFC6325] are used herein along with 121 the following additional acronyms and terms: 123 AFN: Address Family Number 124 (http://www.iana.org/assignments/address-family- 125 numbers/address-family-numbers.xhtml) 127 APPsub-TLV: Application sub-TLV [RFC6823] 129 Data Label: VLAN or FGL 130 FGL: Fine Grained Label [RFC7172] 132 IA: Interface Address(es) 134 MAC: Media Access Control 136 Nickname: A 16-bit TRILL switch identifier as specified in Section 137 3.7 of [RFC6325] as updated by Section 4 of [RFC7780]. 139 RBridge: An alternative name for a TRILL switch 141 TRILL switch: A device that implements the TRILL protocol 143 2. Format of the Interface Addresses APPsub-TLV 145 The Interface Addresses (IA) APPsub-TLV is used to advertise a set of 146 addresses indicating the same interface (port) within a Data Label 147 (VLAN or FGL). It also associates that interface with the TRILL 148 switch, and optionally the TRILL switch port, by which the interface 149 is reachable. These addresses can be in different address families. 150 For example, it can be used to declare that a particular interface 151 with specified IPv4, IPv6, and 48-bit MAC addresses in some 152 particular Data Label is reachable from a particular TRILL switch. 153 While those three types of address are likely to be the only types of 154 interest, any address type for which an AFN (Address Family Number) 155 has been assigned by IANA can be represented. 157 The Template field in a particular IA APPsub-TLV indicates the format 158 of each Address Set it carries. Certain well-known sets of addresses 159 are represented by special values. Other sets of addresses are 160 specified by a list of AFNs. The Template format that uses a list of 161 AFNs provides an explicit pattern for the type and order of addresses 162 in each Address Set in the IA APPsub-TLV that includes that Template. 164 A device or application making use of IA APPsub-TLV data is not 165 required to make use of all IA data. For example, a device or 166 application that was only interested in MAC and IPv6 addresses could 167 ignore any IPv4 or other types of address information that was 168 present. 170 The figure below shows an IA APPsub-TLV as it would appear inside an 171 IS-IS FS-LSP using an extended flooding scope [RFC7356] TLV, for 172 example in ESADI [RFC7357]. Within an IS-IS FS-LSP using traditional 173 [ISO-10589] TLVs, the Type and Length would be one byte unsigned 174 integers equal to or less than 255 but with an extended TLV the Type 175 and Length are a two byte unsigned integer. 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type = (TBD) | (2 bytes) 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Length | (2 bytes) 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Addr Sets End | (2 bytes) 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Nickname | (2 bytes) 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Flags | (1 byte) 187 +-+-+-+-+-+-+-+-+ 188 | Confidence | (1 byte) 189 +-+-+-+-+-+-+-+-+-+- 190 | Template ... (variable) 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 192 | Address Set 1 (size determined by Template) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 194 | Address Set 2 (size determined by Template) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 196 | ... 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 198 | Address Set N (size determined by Template) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 200 | optional sub-sub-TLVs ... 201 +-+-+-+-+-+-+-+-+-+-+-+-... 203 Figure 1. The Interface Addresses APPsub-TLV 205 o Type: Interface Addresses TRILL APPsub-TLV type, set to (TBD) (IA- 206 SUBTLV). 208 o Length: Variable, minimum 7. If length is 6 or less or if the 209 APPsub-TLV extends beyond the size of an encompassing TRILL 210 GENINFO TLV or other context, the APPsub-TLV MUST be ignored. For 211 manageability, a counter should be maintained of receipt of such 212 malformed IA APPsub-TLVs. 214 o Addr Sets End: The unsigned integer byte number, within the IA 215 APPsub-TLV value part, of the last byte of the last Address Set, 216 where the first byte is numbered 1. This will be the number of the 217 byte just before the first sub-sub-TLV if any sub-sub-TLVs are 218 present (see Section 3). The processing is as follows: 219 - If this field is greater than Length or points to before the 220 end of the Template, the IA APPsub-TLV is corrupt and MUST be 221 discarded. 222 - If this field is equal to Length, there are no sub-sub-TLVs. 223 - If this field is less than Length, sub-sub-TLVs are parsed as 224 specified in Section 3. 225 Note: This field is always two bytes in size. 227 o Nickname: The nickname (see Section 1.1) of the TRILL switch by 228 which the address sets are reachable. If zero, the address sets 229 are reachable from the TRILL switch originating the message 230 containing the APPsub-TLV (for example, an ESADI [RFC7357] 231 message). 233 o Flags: A byte of flags as follows: 235 0 1 2 3 4 5 6 7 236 +-+-+-+-+-+-+-+-+ 237 |D|L| RESV | 238 +-+-+-+-+-+-+-+-+ 240 D: Directory flag: If D is one, the APPsub-TLV contains 241 Directory information [RFC7067]. 243 L: Local flag: If L is one, the APPsub-TLV contains information 244 learned locally by observing ingressed frames [RFC6325]. 245 (Both D and L can be set to one in the same IA APPsub-TLV if 246 a TRILL switch that had learned an address locally and also 247 advertised it as a directory.) 249 RESV: Additional reserved flag bits that MUST be sent as zero 250 and ignored on receipt. 252 o Confidence: This 8-bit unsigned quantity in the range 0 to 254 253 indicates the confidence level in the addresses being transported 254 (see Section 4.8.2 of [RFC6325]). A value of 255 is treated as if 255 it was 254. 257 o Template: The initial byte of this field is the unsigned integer 258 K. If K has a value from 1 to 31, it indicates that this initial 259 byte is followed by a list of K AFNs (Address Family Numbers) that 260 specify the exact structure and order of each Address Set 261 occurring later in the APPsub-TLV. K can be 1, which is the 262 minimum valid value. If K is zero, the IA APPsub-TLV is ignored. 263 If K is 32 to 254, the length of the Template field is one byte 264 and its value is intended to correspond to a particular ordered 265 set of AFNs some of which are specified below. The value of 255 266 for K is reserved for future definition and causes the IA APPsub- 267 TLV to be ignored. 269 If the Template uses explicit AFNs, it looks like the following, 270 with the number of AFNs, up to 31, equal to K. 272 +-+-+-+-+-+-+-+-+ 273 | K | (1 byte) 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | AFN 1 | (2 bytes) 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | AFN 2 | (2 bytes) 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | AFN K | (2 bytes) 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 For K in the 32 to 39 range, values indicate a specific sequence 285 as specified below. The values of K from 40 to 254 are reserved 286 for future such specification. If the value of K is not understood 287 by a receiver of the IA-APPsub-TLV, any Address Sets present are 288 ignored. 290 K Addresses in order of occurrence 291 --- -------------------------------- 292 32 48-bit MAC 293 33 48-bit MAC, IPv4 294 34 48-bit MAC, IPv6 295 35 48-bit MAC, IPv4, IPv6 296 36 48-bit MAC, RBridge port 297 37 48-bit MAC, IPv4, RBridge port 298 38 48-bit MAC, IPv6, RBridge port 299 39 48-bit MAC, IPv4, IPv6, RBridge port 301 For ease of decoding, note that for values of K between 32 and 39 302 inclusive, the 0x01 bit indicates an IPv4 address is present, the 303 0x02 bit indicates an IPv6 address is present, and the 0x04 bit 304 indicates that an RBridge port ID is present. 306 o AFN: A two-byte Address Family Number. The number of AFNs present 307 is given by K except that there are no AFNs if K is greater than 308 31. The AFN sequence specifies the structure of the Address Sets 309 occurring later in the TLV. For example, if Template Size is 2 and 310 the two AFNs present are the AFNs for a 48-bit MAC and an IPv4 311 address, in that order, then each Address set present will consist 312 of a 6-byte MAC address followed by a 4-byte IPv4 address. If any 313 AFNs are present that are unknown to the receiving IS and the 314 length of the corresponding address is not provided by a sub-sub- 315 TLV as specified below, the receiving IS will be unable to parse 316 the Address Sets and MUST ignore the IA APPsub-TLV. 318 o Address Set: Each address set in the APPsub-TLV consists of 319 exactly the same sequence of addresses and types as specified by 320 the Template earlier in the APPsub-TLV. No alignment, other than 321 to a byte boundary, is provided. The addresses in each Address Set 322 are contiguous with no unused bytes between them and the Address 323 Sets are contiguous with no unused bytes between successive 324 Address Sets. The Address Sets must fit within the TLV. See 325 Section 7 on interpreting certain Address Sets. 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 For manageability, a counter should be maintained of ill-formed IA 365 APPsub-TLVs received and ignored due to unknown K, unknown AFN, and 366 the like, as described above. 368 3. IA APPsub-TLV sub-sub-TLVs 370 IA APPsub-TLVs can have trailing sub-sub-TLVs [RFC5305] as specified 371 below. These sub-sub-TLVs occur after the Address Sets and the 372 amount of space available for sub-sub-TLVs is determined from the 373 overall IA APPsub-TLV length and the value of the Addr Set End byte. 375 There is no ordering restriction on sub-sub-TLVs. Unless otherwise 376 specified each sub-sub-TLV type can occur zero, one, or many times in 377 an IA APPsub-TLV. Any sub-sub-TLVs for which the Type is unknown are 378 ignored. For manageability, a counter should be maintained of sub- 379 sub-TLVs received and ignored due to unknown Type or other reasons 380 described below. 382 The sub-sub-TLVs data structures shown below, with two byte Types and 383 Lengths, assume that the enclosing IA APPsub-TLV is in an extended 384 LSP TLV [RFC7356] or some non-LSP context. If they were used in a IA 385 APPsub-TLV in a non-extended LSP [ISO-10589], then only one byte 386 Types and Lengths could be used. As a result, any sub-sub-TLV types 387 greater than 255 could not be used and Length would be limited to 388 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 Figure 2. AFN Size sub-sub-TLV 421 Where each AFN Size Record is structured as follows: 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | AFN | (2 bytes) 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | AdrSize | (1 byte) 427 +-+-+-+-+-+-+-+-+ 429 o Type: AFN-Size sub-sub-TLV type, set to 1 (AFNsz). 431 o Length: 3*n where n is the number of AFN Size Records present. If 432 Length is not a multiple of 3, the sub-sub-TLV MUST be ignored. 434 o AFN Size Record(s): Zero or more 3-byte records, each giving the 435 size of an address type identified by an AFN, 437 o AFN: The AFN whose length is being specified by the AFN Size 438 Record. 440 o AdrSize: The length in bytes of addresses specified by the AFN 441 field as an unsigned integer. 443 An AFN Size sub-sub-TLV for any AFN known to the receiving TRILL 444 switch is compared with the size known to the TRILL switch. If they 445 differ the IA APPsub-TLV is assumed to be corrupt and MUST be 446 ignored. 448 3.2 Fixed Address sub-sub-TLV 450 There may be cases where, in a particular Interface Addresses (IA) 451 APPsub-TLV, the same address would appear in every address set across 452 the IA APPsub-TLV. To avoid wasted space, this sub-sub-TLV can be 453 used to indicate such a fixed address. The address or addresses 454 incorporated into the sets by this sub-sub-TLV are NOT mentioned in 455 the IA APPsub-TLV Template. 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type=FIXEDADR | (2 byte) 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Length | (2 byte) 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | AFN | (2 bytes) 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Fixed Address (variable) 465 +-+-+-+-+-+-+-+-+-+-+-+-+-... 467 Figure 3. Fixed Address sub-sub-TLV 469 o Type: Data Label sub-sub-TLV type, set to 2 (FIXEDADR). 471 o Length: variable, minimum 2. If Length is 0 or 1, the sub-sub-TLV 472 MUST be ignored. 474 o AFN: Address Family Number of the Fixed Address. 476 o Fixed Address: The address of the type indicated by the preceding 477 AFN field that is considered to be part of every Address Set in 478 the IA APPsub-TLV. 480 The Length field implies a size for the Fixed Address. If that size 481 differs from the size of the address type for the given AFN as known 482 by the receiving TRILL switch, the Fixed Address sub-sub-TLV is 483 considered corrupt and MUST be ignored. 485 3.3 Data Label sub-sub-TLV 487 This sub-sub-TLV indicates the Data Label within which the interfaces 488 listed in the IA APPsub-TLV are reachable. It is useful if the IA 489 APPsub-TLV occurs outside of the context of a message specifying the 490 Data Label or if it is desired and permitted to override that 491 specification. Multiple occurrences of this sub-sub-TLV indicate 492 that the interfaces are reachable in all of the Data Labels given. 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 |Type=DATALEN | (2 byte) 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Length | (2 byte) 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Data Label (variable) 500 +-+-+-+-+-+-+-+-+-+-+-+-+-... 502 Figure 4. Data Label sub-sub-TLV 504 o Type: Data Label sub-TLV type, set to 3 (LABEL). 506 o Length: 2 or 3. If Length is some other value, the sub-sub-TLV 507 MUST be ignored. 509 o Data Label: If length is 2, the bottom 12 bits of the Data 510 Label are a VLAN ID and the top 4 bits are reserved (MUST be 511 sent as zero and ignored on receipt). If the length is 3, the 512 three Data Label bytes contain an FGL [RFC7172]. 514 3.4 Topology sub-sub-TLV 516 The presence of this sub-sub-TLV indicates that the interfaces given 517 in the IA APPsub-TLV are reachable in the topology given. It is 518 useful if the IA APPsub-TLV occurs outside of the context of a 519 message indicating the topology or if it is desired and permitted to 520 override that specification. If it occurs multiple times, then the 521 Address Sets are in all of the topologies given. 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |Type=TOPOLOGY | (2 byte) 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Length | (2 byte) 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | RESV | Topology | (2 bytes) 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 5. Topology sub-sub-TLV 533 o Type: Topology sub-TLV type, set to 4 (TOPOLOGY). 535 o Length: 2. If Length is some other values, the sub-sub-TLV MUST 536 be ignored. 538 o RESV: Four reserved bits. MUST be sent as zero and ignored on 539 receipt. 541 o Topology: The 12-bit topology number [RFC5120]. 543 4. Security Considerations 545 The integrity of address mapping and reachability information and the 546 correctness of Data Labels (VLANs or FGLs [RFC7172]) are very 547 important. Forged, altered, or incorrect address mapping or Data 548 Labeling can lead to delivery of packets to the incorrect party, 549 violating security policy. However, this document merely describes a 550 data format and does not provide any explicit mechanisms for securing 551 that information, other than a few simple consistency checks that 552 might detect some corrupted data. Security on the wire, or in 553 storage, for this data is to be providing by the transport or storage 554 used. For example, when transported with ESADI [RFC7357] or RBridge 555 Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel] 556 security mechanisms can be used, respectively. 558 The address mapping and reachability information, if known to be 559 complete and correct, can be used to detect some cases of forged 560 packet source addresses [RFC7067]. In particular, if native traffic 561 from an end station is received by a TRILL switch that would 562 otherwise accept it but authoritative data indicates the source 563 address should not be reachable from the receiving TRILL switch, that 564 traffic should be discarded. The data format specified in this 565 document may optionally include TRILL switch Port ID number so that 566 this forged address filtering can be optionally applied with port 567 granularity. For manageability, a counter should be maintained of 568 frames so discarded. 570 See [RFC6325] for general TRILL Security Considerations. 572 5. IANA Considerations 574 The following subsections specify IANA actions. 576 5.1 AFN Number Allocation 578 IANA has allocated the AFN values below that may be useful for IA 579 APPsub-TLVs. The References will be updated as shown. 581 Hex Decimal Description References 582 ----- ------- ----------- ---------- 584 0001 1 IPv4 585 0002 2 IPv6 586 4005 16389 48-bit MAC Section 2.1 of [RFC7042] 587 4006 16390 64-bit MAC Section 2.2 of [RFC7042] 588 4007 16391 OUI Section 6 of [this doc] 589 4008 16392 MAC/24 Section 6 of [this doc] 590 4009 16393 MAC/40 Section 6 of [this doc] 591 400A 16394 IPv6/64 Section 6 of [this doc] 592 400B 16395 RBridge Port ID Section 6 of [this doc] 594 Other AFNs can be found at http://www.iana.org/assignments/address- 595 family-numbers 597 See Section 7 on interpreting address sets. 599 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry 601 IANA is requested to establish a new subregistry of the TRILL 602 Parameter Registry for sub-sub-TLVs of the Interface Addresses 603 APPsub-TLV with initial contents as shown below. 605 Name: Interface Addresses APPsub-TLV Sub-Sub-TLVs 607 Procedure: Expert Review 609 Note: Types greater than 255 are not usable in some contexts. 611 Reference: [This document] 613 Type Description Reference 614 ------ ----------- --------- 615 0 Reserved 616 1 AFN Size [This document] 617 2 Fixed Address [This document] 618 3 Data Label [This document] 619 4 Topology [This document] 620 5-254 Unassigned 621 255 Reserved 622 256-65534 Unassigned 623 65535 Reserved 625 Expert Guidance: A designated expert for this registry should decide 626 based on clear documentation of the proposed type provided by the 627 requester, such as a complete Internet Draft. New types should not 628 duplicate existing types. Requests should indicate whether a type 629 less than 255 is desired; such types can be used in contexts where 630 only one byte of type (and usually only one byte of length) is 631 permitted. Types greater than 255 can only be used where two byte 632 types are allowed such in E-L1FS or E-L1CS extended FS-LSPs 633 [RFC7356]; in those contexts lengths up to 65535 bytes can also be 634 expressed although they may not be usable if the resulting TLV would 635 not fit into a larger context restricted by MTU or the like. Values 636 within the region below 255 and the region above 255 should be 637 allocated sequentially unless there is an extraordinary reason for a 638 special value. 640 5.3 IA APPsub-TLV Number 642 IANA is requested to allocate (TBD) as the Type for the IA APPsub-TLV 643 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 644 Identifier 1" registry from the range under 256. In the registry the 645 Name is "IA" and the Reference is this document. 647 6. Additional AFN Information 649 This section provides additional information concerning AFNs that 650 were allocated in connection with this document. These AFNs are not 651 restricted to use in the IA APPsub-TLV and may be used in other 652 protocols where they would be an appropriate. 654 OUI: A 3 byte (24-bit) Organizationally Unique Identifier used as 655 the initial 3 bytes of a MAC address. See Section 2.1 of 656 [RFC7042] and Section 7 below. 658 MAC/24: A 3 byte (24-bit) quantity used as the final 3 bytes of a 659 48-bit MAC address. See Section 2.1 of [RFC7042] and Section 660 7 below. 662 MAC/40: A 5 byte (40-bit) quantity used as the final 5 bytes of a 663 64-bit MAC address. See Section 2.2 of [RFC7042] and Section 664 7 below. 666 IPv6/64: An 8 bytes (64-bit) quantity used as the initial 8 bytes of 667 an IPv6 address. See Section 7 below. 669 RBridge Port ID: A 16-bit quantity that uniquely identifies a port on 670 a TRILL switch (RBridge). See Section 4.4.2 of [RFC6325]. 672 7. Processing Address Sets 674 The following processes should be followed in interpreting sets of 675 AFN values in an IA APPsub-TLV to synthesize addresses. These apply 676 whether the AFN values came from sub-sub-TLVs or appeared within an 677 Address Set or came from both sources. In general, the processing is 678 applied separately to each Address Set as supplemented by any Fixed 679 Address sub-sub-TLVs that are present. 681 The OUI AFN value is provided so that MAC addresses can be 682 abbreviated if they have the same upper 24 bits. A MAC/24 is a 683 24-bit suffix intended to be pre-fixed by an OUI to create a 48-bit 684 MAC address [RFC7042]; in the absence of an OUI, a MAC/24 entry 685 cannot be used. A MAC/40 is a 40-bit suffix intended to be pre-fixed 686 by an OUI to create a 64-bit MAC address [RFC7042]; in the absence of 687 an OUI, a MAC/40 entry cannot be used. 689 Typically, an OUI would be provided as a Fixed Address sub-sub-TLV 690 (see Section 3.2) using the OUI AFN but there is no prohibition 691 against one or more OUIs appearing in an Address Set. 693 Each Address Set, after being supplemented by any Fixed Address sub- 694 sub-TLVs, is processed by combining each OUI in the Address Set with 695 each MAC/24 and each MAC/40 address in the address set. Depending on 696 how many of each of these address types is present, zero or more 697 48-bit and/or 64-bit MAC addresses may be synthesized that are 698 subsequently processed as if they had been part of the Address Set. 699 If there are no MAC/24 or MAC/40 addresses present, any OUI's are 700 ignored. If there are no OUIs, any MAC/24 and/or MAC/40s are ignored. 701 If there are K1 OUIs, K2 MAC/24s, and K3 MAC/40s, K1*K2 48-bit MACs 702 are synthesized and K1*K3 64-bit MACs are synthesized. 704 IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 705 address. IPv6/64s are ignored unless, after the processing above in 706 this sub-section, there are one or more 48-bit and/or 64-bit MAC 707 addresses in the Address Set to provide the lower 64 bits of the IPv6 708 address. For this purpose, a 48-bit MAC address is expanded to 64 709 bits as described in Section 2.2.1 of [RFC7042]. If there are K4 710 IPv6/64s present and K5 48- and 64-bit MAC addresses present, K4*K5 711 128-bit IPv6 addresses are synthesized. 713 Synthesized addresses are treated as if they had been members of the 714 Address Set. 716 Acknowledgments 718 The authors gratefully acknowledge the contributions and review by 719 the following: 721 Linda Dunbar, Sue Hares, Paul Kyzivat, Danny McPherson, and 722 Gayle Noble 724 The document was prepared in raw nroff. All macros used were defined 725 within the source file. 727 Appendix A: Examples 729 Below are example IA APPsub-TLVs. "0x" indicates that the following 730 quantity is in hexadecimal. "0b" indicates that the following 731 quantity is in binary. Leading zeros are retained. 733 A.1 Simple Example 735 Below is an annotated IA APPsub-TLV carrying two simple pairs of 736 EUI-48 MAC addresses and IPv4 addresses from a Push Directory 737 [RFC7067]. No sub-sub-TLVs are included. 739 0x0002(TBD) Type: Interface Addresses 740 0x001B Length: 27 (=0x1B) 741 0x001B Address Sets End: 27 (=0x1B) 742 0x1234 RBridge Nickname from which reachable 743 0b10000000 Flags: Push Directory data 744 0xE3 Confidence = 227 745 33 Template: 33 (0x21) = 32 + 1(IPv4) 747 Address Set One 748 0x00005E0053A9 48-bitMAC address 749 198.51.100.23 IPv4 address 751 Address Set Two 752 0x00005E00536B 48-bit MAC address 753 203.0.113.201 IPv4 address 755 Size includes 7 for the fixed fields though and including the one 756 byte template, plus 2 times the Address Set size. Each Address Set is 757 10 bytes, 6 for the 48-bit MAC address plus 4 for the IPv4 address. 758 So total size is 7 + 2*10 = 27. 760 See Section 2 for more information on Template. 762 A.2 Complex Example 764 Below is an annotated IA APPsub-TLV carrying three sets of addresses, 765 each consisting of an EUI-48 MAC address, an IPv4 addresses, an IPv6 766 address, and an RBridge Port ID, all from a Push Directory [RFC7067]. 767 The IPv6 address for each address set is synthesized from the MAC 768 address given in that set and the IPv6/64 64-bit prefix provided 769 through a Fixed Address sub-sub-TLV. In addition, a sub-sub-TLV is 770 included that provides an FGL which overrides whatever Data Label may 771 be provided by the envelope (for example an ESADI-LSP [RFC7357]) 772 within which this IA APPsub-TLV occurs. 774 0x0002(TBD) Type: Interface Addresses 775 0x0036 Length: 64 (=0x40) 776 0x0021 Address Sets End: 43 (=0x2B) 777 0x4321 RBridge Nickname from which reachable 778 0b10000000 Flags: Push Directory data 779 0xD3 Confidence = 211 780 37 Template: 37(0x25)=32+1(IPv4)+4(Port) 782 Address Set One 783 0x00005E0053DE 48-bitMAC address 784 198.51.100.105 IPv4 address 785 0x1DE3 RBridge Port ID 787 Address Set Two 788 0x00005E0053E3 48-bit MAC address 789 203.0.113.89 IPv4 address 790 0x1DEE RBridge Port ID 792 Address Set Three 793 0x00005E0053D3 48-bit MAC address 794 192.0.2.139 IPv4 address 795 0x01DE RBridge Port ID 797 sub-sub-TLV One 798 0x0003 Type: Data Label 799 0x0003 Length: implies FGL 800 0xD3E3E3 Fine Grained Label 802 sub-sub-TLV Two 803 0x0002 Type: Fixed Address 804 0x000A Size: 0x0A = 10 805 0x400A AFN: IPv6/64 806 0x20010DB800000000 IPv6 Prefix: 2001:DB8:: 808 See Section 2 for more information on Template. 810 The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be 811 treated as if it occurred as a 4th entry inside each of the three 812 Address Sets. When there is an IPv6/64 entry and a 48-bit MAC entry, 813 the MAC value is expanded by inserting 0xFFFE immediately after the 814 OUI and the local/global bit is inverted. The resulting Modified 815 EUI-64-bit value is used as the lower 64 bits of the resulting IPv6 816 address (Section 2.2.1 [RFC7042]). As a result, a receiving TRILL 817 switch would treat the three Address Sets shown as if they had an 818 IPv6 address in them as follows: 820 Address Set One 821 0x20010DB80000000002005EFFFE0053DE IPv6 Address 823 Address Set Two 824 0x20010DB80000000002005EFFFE0053E3 IPv6 Address 826 Address Set Three 827 0x20010DB80000000002005EFFFE0053D3 IPv6 Address 829 As an alternative to the compact "well know value" Template encoding 830 used in this example above, the less compact explicit AFN encoding 831 could have been used. In that case, the IA APPsub-TLV would have 832 started as follows: 834 0x0002(TBD) Type: Interface Addresses 835 0x003C Length: 60 (=0x3C) 836 0x0027 Address Sets End: 39 (=0x27) 837 0x4321 RBridge Nickname from which reachable 838 0b10000000 Flags: Push Directory data 839 0xD3 Confidence = 211 840 0x3 Template: 3 AFNs 841 0x4005 AFN: 48-bit MAC 842 0x0001 AFN: IPv4 843 0x400B AFN: RBridge Port ID 845 As a final point, since the 48-bit MAC addresses in these three 846 Address Sets all have the same OUI (the IANA OUI [RFC7042]), it would 847 have been possible to just have a MAC/24 value giving the lower 24 848 bits of the MAC in each Address Set. The OUI would them be supplied 849 by a second Fixed Address sub-sub-TLV providing the OUI. With N 850 Address Sets, this would have saved 3*N or 9 bytes in this case at 851 the cost of 9 bytes (2 each for the type and length of the sub-sub- 852 TLV, 2 for the OUI AFN number, and 3 for the OUI). So, with just 853 three Address Sets, there would be no net saving; however, with a 854 larger number of Address Sets, there would be a net savings. 856 Appendix Z: Change History 858 From -00 to -01 860 1. Update references for RFC publications. 862 2. Add this Change History Appendix. 864 From -01 to -02 866 1. Fix off-by-one errors in body text and examples for well known 867 Template values. 869 2. Update for drafts published as RFCs and change in Author Address. 871 3. Minor editorial improvements. 873 From -02 to -03 875 Minor editorial improvements. 877 From -03 to -04 879 Editorial improvements. 881 From -04 to -05 883 Remove one author. 885 From -05 to -06 887 Update for Shepherd review. Simplify Template for values of K over 888 31. Editorial improvements. 890 From -06 to -07 892 Add Acknowledgement. Remove one unused reference and add and refer to 893 a replacement reference. 895 From -07 to -08 897 Updated based on Routing Directorate review. 899 From -08 to -09 901 Updated based on GENART review. 903 Normative References 905 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 906 System to Intermediate System Intra-Domain Routing Exchange 907 Protocol for use in Conjunction with the Protocol for Providing 908 the Connectionless-mode Network Service (ISO 8473)", 2002. 910 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 911 RFC 826, November 1982. 913 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 914 Reverse Address Resolution Protocol", STD 38, RFC 903, June 915 1984. 917 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, March 1997 920 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 921 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 922 September 2007. 924 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 925 Topology (MT) Routing in Intermediate System to Intermediate 926 Systems (IS-ISs)", RFC 5120, February 2008. 928 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 929 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 930 2008. 932 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 933 Engineering", RFC 5305, October 2008. 935 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 936 Ghanwani, "Routing Bridges (RBridges): Base Protocol 937 Specification", RFC 6325, July 2011. 939 [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising 940 Generic Information in IS-IS", RFC 6823, December 2012. 942 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 943 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 944 BCP 141, RFC 7042, October 2013. 946 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 947 and D. Dutt, "Transparent Interconnection of Lots of Links 948 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 950 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 951 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 952 . 954 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 955 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 956 End Station Address Distribution Information (ESADI) Protocol", 957 RFC 7357, September 2014, . 960 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 961 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 962 Lots of Links (TRILL): Clarifications, Corrections, and 963 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 964 . 966 Informational References 968 [ARPND] - Y. Li, S. Eastlake, L. Dunbar, R. Perlman, I. Gashinsky, 969 "TRILL: ARP/ND Optimization", draft-ietf-trill-arp- 970 optimization, work in progress. 972 [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel 973 Protocol", draft-eastlake-trill-channel-tunnel, work in 974 progress. 976 [DirectoryScheme] - Dunbar, L., D. Eastlake, R. Perlman, I. 977 Gashinsky, Y. Li, "TRILL": Directory Assistance Mechanisms", 978 draft-dunbar-trill-scheme-for-directory-assist, work in 979 progress. 981 [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 982 for the Address Resolution Protocol (ARP)", RFC 5494, April 983 2009. 985 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 986 Gashinsky, "Directory Assistance Problem and High-Level Design 987 Proposal", RFC 7067, November 2013. 989 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 990 Ward, "Transparent Interconnection of Lots of Links (TRILL): 991 RBridge Channel Support", RFC 7178, May 2014. 993 Authors' Addresses 995 Donald Eastlake 996 Huawei Technologies 997 155 Beaver Street 998 Milford, MA 01757 USA 1000 Phone: +1-508-333-2270 1001 Email: d3e3e3@gmail.com 1003 Yizhou Li 1004 Huawei Technologies 1005 101 Software Avenue, 1006 Nanjing 210012 China 1008 Phone: +86-25-56622310 1009 Email: liyizhou@huawei.com 1011 Copyright, Disclaimer, and Additional IPR Provisions 1013 Copyright (c) 2016 IETF Trust and the persons identified as the 1014 document authors. All rights reserved. 1016 This document is subject to BCP 78 and the IETF Trust's Legal 1017 Provisions Relating to IETF Documents 1018 (http://trustee.ietf.org/license-info) in effect on the date of 1019 publication of this document. Please review these documents 1020 carefully, as they describe your rights and restrictions with respect 1021 to this document. Code Components extracted from this document must 1022 include Simplified BSD License text as described in Section 4.e of 1023 the Trust Legal Provisions and are provided without warranty as 1024 described in the Simplified BSD License. The definitive version of 1025 an IETF Document is that published by, or under the auspices of, the 1026 IETF. Versions of IETF Documents that are published by third parties, 1027 including those that are translated into other languages, should not 1028 be considered to be definitive versions of IETF Documents. The 1029 definitive version of these Legal Provisions is that published by, or 1030 under the auspices of, the IETF. Versions of these Legal Provisions 1031 that are published by third parties, including those that are 1032 translated into other languages, should not be considered to be 1033 definitive versions of these Legal Provisions. For the avoidance of 1034 doubt, each Contributor to the IETF Standards Process licenses each 1035 Contribution that he or she makes as part of the IETF Standards 1036 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1037 language to the contrary, or terms, conditions or rights that differ 1038 from or are inconsistent with the rights and licenses granted under 1039 RFC 5378, shall have any effect and shall be null and void, whether 1040 published or posted by such Contributor, or included with or in such 1041 Contribution.