INTERNET-DRAFT Donald Eastlake Intended status: Proposed Standard Yizhou Li Huawei Expires: December 29, 2014 June 30, 2015 TRILL: Interface Addresses APPsub-TLV Abstract This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses such that all of the addresses in each set designate the same interface (port) and the reporting for such a set of the TRILL switch by which it is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to or by-pass the need for the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. D. Eastlake and Y Li [Page 1] INTERNET-DRAFT TRILL: IA APPsub-TLV Table of Contents 1. Introduction............................................3 1.1 Conventions Used in This Document......................3 2. Format of the Interface Addresses APPsub-TLV............5 3. IA APPsub-TLV sub-sub-TLVs.............................11 3.1 AFN Size sub-sub-TLV..................................11 3.2 Fixed Address sub-sub-TLV.............................12 3.3 Data Label sub-sub-TLV................................13 3.4 Topology sub-sub-TLV..................................13 4. Security Considerations................................15 5. IANA Considerations....................................16 5.1 AFN Number Allocation.................................16 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry................17 5.3 IA APPsub-TLV Number..................................17 Acknowledgments...........................................18 Appendix A: Examples......................................19 A.1 Simple Example........................................19 A.2 Complex Example.......................................19 Appendix Z: Change History................................22 Normative References......................................23 Informational References..................................24 Authors' Addresses........................................25 D. Eastlake and Y Li [Page 2] INTERNET-DRAFT TRILL: IA APPsub-TLV 1. Introduction This document specifies a TRILL (Transparent Interconnection of Lots of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV [RFC6823]) that enables the convenient representation of sets of addresses such that all of the addresses in each set designate the same interface (port). For example, a 48-bit MAC (Media Access Control [RFC7042]) address, IPv4 address, and IPv6 address can be reported as all three designating the same interface. In addition, a Data Label (VLAN or Fine Grained Label (FGL [RFC7172])) is specified for the interface along with the TRILL switch, and optionally the TRILL switch port, from which the interface is reachable. Such information could be used in some cases to synthesize responses to or by-pass the need for the Address Resolution Protocol (ARP [RFC826]), the IPv6 Neighbor Discovery (ND [RFC4861]) protocol, the Reverse Address Resolution Protocol (RARP [RFC903]), or the flooding of unknown destination MAC addresses [RFC7042]. If the information reported is complete, it can also be used to detect and discard packets with forged source addresses. This APPsub-TLV appears inside the TRILL GENINFO TLV specified in ESADI [RFC7357] but may also occur in other application contexts. Directory Assisted TRILL Edge services [DirectoryScheme] are expected to make use of this APPsub-TLV. Although, in some IETF protocols, address field types are represented by Ethertype [RFC7042] or Hardware Type [RFC5494], only Address Family Number (AFN) is used in this APPsub-TLV to represent address field type. 1.1 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Capitalized IANA Considertions terms such as "Expert Review" are to be interpreted as described in [RFC5226]. The terminology and acronyms of [RFC6325] are used herein along with the following additional acronyms and terms: AFN: Address Family Number APPsub-TLV: Application sub-TLV [RFC6823] Data Label: VLAN or FGL FGL: Fine Grained Label [RFC7172] D. Eastlake and Y Li [Page 3] INTERNET-DRAFT TRILL: IA APPsub-TLV IA: Interface Addresses RBridge: An alternative name for a TRILL switch TRILL switch: A device that implements the TRILL protocol D. Eastlake and Y Li [Page 4] INTERNET-DRAFT TRILL: IA APPsub-TLV 2. Format of the Interface Addresses APPsub-TLV The Interface Addresses (IA) APPsub-TLV is used to advertise that a set of addresses indicate the same interface (port) within a Data Label (VLAN or FGL) and to associate that interface with the TRILL switch, and optionally the TRILL switch port, by which the interface is reachable. These addresses can be in different address families. For example, it can be used to declare that a particular interface with specified IPv4, IPv6, and 48-bit MAC addresses in some particular Data Label is reachable from a particular TRILL switch. The Template field in a particular Interface Addresses APPsub-TLV indicates the format of each Address Set it carries. Certain well- known sets of addresses are represented by special values. Other sets of addresses are specified by a list of AFNs. The Template format that uses a list of AFNs provides an explicit pattern for the type and order of addresses in each Address Set in the IA APPsub-TLV that includes that Template. A device or application making use of IA APPsub-TLV data is not required to make use of all IA data. For example, a device or application that was only interested in MAC and IPv6 addresses could ignore any IPv4 or other types of address information that was present. The figure below shows an IA APPsub-TLV as it would appear inside an IS-IS FS-LSP using an extended flooding scope [RFC7356] TLV, for example in ESADI [RFC7357]. Within an IS-IS FS-LSP using traditional [ISO-10589] TLVs, the Type and Length would be one byte unsigned integers equal to or less than 255. D. Eastlake and Y Li [Page 5] INTERNET-DRAFT TRILL: IA APPsub-TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD1 | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Sets End | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (1 byte) +-+-+-+-+-+-+-+-+ | Confidence | (1 byte) +-+-+-+-+-+-+-+-+-+- | Template ... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Address Set 1 (size determined by Template) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Address Set 2 (size determined by Template) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Address Set N (size determined by Template) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | optional sub-sub-TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-... Figure 1. The Interface Addresses APPsub-TLV o Type: Interface Addresses TRILL APPsub-TLV type, set to TBD1 (IA- SUBTLV). o Length: Variable, minimum 7. If length is 6 or less or if the APPsub-TLV extends beyond the size of an encompassing TRILL GENINFO TLV or other context, the APPsub-TLV MUST be ignored. o Addr Sets End: The unsigned integer offset of the byte, within the IA APPsub-TLV value part, of the last byte of the last Address Set. This will be the byte just before the first sub-sub-TLV if any sub-sub-TLVs are present (see Section 3). If this is equal to Length, there are no sub-sub-TLVs. If this is greater than Length or points to before the end of the Template, the IA APPsub-TLV is corrupt and MUST be discarded. This field is always two bytes in size. o Nickname: The nickname of the TRILL switch by which the address sets are reachable. If zero, the address sets are reachable from the TRILL switch originating the message containing the APPsub-TLV (for example, an ESADI [RFC7357] message). D. Eastlake and Y Li [Page 6] INTERNET-DRAFT TRILL: IA APPsub-TLV o Flags: A byte of flags as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D|L|N| RESV | +-+-+-+-+-+-+-+-+ D: Directory flag: If D is one, the APPsub-TLV contains Directory information [RFC7067]. L: Local flag: If L is one, the APPsub-TLV contains information learned locally by observing ingressed frames [RFC6325]. (Both D and L can be set to one in the same IA APPsub-TLV if a TRILL switch that had learned an address locally and also advertised it as a directory.) N: Notify flag: When a TRILL switch receives a new IA APPsub- TLV (one in an ESADI-LSP fragment with a higher sequence number or a new message of some other type) and the N bit is one, the TRILL switch then checks the contents of the APPsub-TLV for address sets including both an IP address and a MAC address. For each such address set it finds, a gratuitous ARP [RFC826] or spontaneous Neighbor Advertisement [RFC4861], depending on whether the IP address is IPv4 or IPv6 respectively, may be sent. In both cases, these are sent out all the ports of the TRILL switch offering end station service and are in the VLAN or FGL of the address set information, that is, are Appointed Forwarder for the VLAN or for the VLAN to which the FGL maps. RESV: Additional reserved flag bits that MUST be sent as zero and ignored on receipt. o Confidence: This 8-bit unsigned quantity in the range 0 to 254 indicates the confidence level in the addresses being transported (see Section 4.8.2 of [RFC6325]). A value of 255 is treated as if it was 254. o Template: The initial byte of this field is the unsigned integer K. If K has a value from 1 to 31, it indicates that this initial byte is followed by a list of K AFNs (Address Family Numbers) that specify the exact structure and order of each Address Set occurring later in the APPsub-TLV. K can be 1, which is the minimum valid value. If K is zero, the IA APPsub-TLV is ignored. If K is 32 to 254, the length of the Template field is one byte and its value is intended to correspond to a particular ordered set of AFNs some of which are specified below. If K is 255, the length of the Template field is three bytes and the values of the second and third byte, considered as an unsigned integer in D. Eastlake and Y Li [Page 7] INTERNET-DRAFT TRILL: IA APPsub-TLV network byte order, are reserved to correspond to future specified ordered sets of AFNs. If the Template uses explicit AFNs, it looks like the following, with the number of AFNs, up to 31, equal to K. +-+-+-+-+-+-+-+-+ | K | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN 1 | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN 2 | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN K | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For K in the 32 to 102 range, values indicate combinations of a specific number of MAC addresses, IPv4 addresses, IPv6 addresses, and TRILL switch port IDs appearing in that order. The value of K is K = 31 + M + 3*v4 + 9*v6 + 36*P where M is 0, 1, or 2 (0 if no MAC address is present, 1 if a 48-bit MAC is present, 2 if a MAC/24 (see Section 5.1) is present), v4 is the number of IPv4 addresses (limited to 0, 1, or 2) and v6 is the number of IPv6 addresses (limited to 0 through 3 inclusive), and P is the number of TRILL switch port IDs (limited to 0 or 1); however, the number of MAC, IPv4, and IPv6 addresses and TRILL switch ports cannot all be simultaneously zero. It is important that, when using this encoding, the values of M, v4, v6, and P do not exceed the limits given; otherwise, they cannot be unambiguously decoded. For example, v4 is limited to 0, 1, or 2. Attempting to encode a v4 value of 3 is indistinguishable from incrementing the v6 value by 1. Given that M, v4, v6, and P may not all be zero, this equation specifies values of K from 32 through 102. The value 31 is not permitted but instead represents an explicit Template with 31 AFNs. Values from 103 through 254 of the byte value are available for assignment by Expert Review (see Section 5). K = 255 indicates a three-byte Template field as specified above. All values (0 through 65,545) of this two-byte value are available for assignment by Expert Review. If an unknown Template K value in the range 103 to 254 is received or a K of 255 followed by an unknown two byte value, the IA APPsub-TLV MUST be ignored. D. Eastlake and Y Li [Page 8] INTERNET-DRAFT TRILL: IA APPsub-TLV o AFN: A two-byte Address Family Number. The number of AFNs present is given by K except that there are no AFNs if K is greater than 31. The AFN sequence specifies the structure of the Address Sets occurring later in the TLV. For example, if Template Size is 2 and the two AFNs present are the AFNs for a 48-bit MAC and an IPv4 address, in that order, then each Address set present will consist of a 6-byte MAC address followed by a 4-byte IPv4 address. If any AFNs are present that are unknown to the receiving IS and the length of the corresponding address is not provided by a sub-sub- TLV as specified below, the receiving IS will be unable to parse the Address Sets and MUST ignore the IA APPsub-TLV. o Address Set: Each address set in the APPsub-TLV consists of exactly the same sequence of addresses and types as specified by the Template earlier in the APPsub-TLV. No alignment, other than to a byte boundary, is provided. The addresses in each Address Set are contiguous with no unused bytes between them and the Address Sets are contiguous with no unused bytes between successive Address Sets. The Address Sets must fit within the TLV. o sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do not completely fill the Length of the APPsub-TLV, the remaining bytes are parsed as sub-sub-TLVs [RFC5305]. Any such sub-sub-TLVs that are not known to the receiving TRILL switch are ignored. Should this parsing not be possible, for example there is only one remaining byte or an apparent sub-sub-TLV extends beyond the end of the TLV, the containing IA APPsub-TLV is considered corrupt and is ignored. (Several sub-sub-TLV types are specified in Section 3.) Different IA APPsub-TLVs within the same or different LSPs or other data structures may have different Templates. The same AFN may occur more than once in a Template and the same address may occur in different address sets. For example, a 48-bit MAC address interface might have three different IPv6 addresses. This could be represented by an IA APPsub-TLV whose Template specifically provided for one EUI-48 address and three IPv6 addresses, which might be an efficient format if there were multiple interfaces with that pattern. Alternatively, a Template with one 48-bit MAC and one IPv6 address could be used in an IA APPsub-TLV with three address sets each having the same MAC address but different IPv6 addresses, which might be the most efficient format if only one interface had multiple IPv6 addresses and other interfaces had only one IPv6 address. In order to be able to parse the Address Sets, a receiving TRILL switch must know at least the size of the address for each AFN or address type the Template specifies; however, the presence of the Addr Set End field means that the sub-sub-TLVs, if any, can always be located by a receiver. A TRILL switch can be assumed to know the size of the AFNs mentioned in Section 5. Should a TRILL switch wish D. Eastlake and Y Li [Page 9] INTERNET-DRAFT TRILL: IA APPsub-TLV to include an AFN that some receiving TRILL switch in the campus may not know, it SHOULD include an AFN-Size sub-sub-TLV as described in Section 3.1. If an IA APPsub-TLV is received with one or more AFNs in its template for which the receiving TRILL switch does not know the length and for which an AFN-Size sub-sub-TLV is not present, that IA APPsub-TLV MUST be ignored. D. Eastlake and Y Li [Page 10] INTERNET-DRAFT TRILL: IA APPsub-TLV 3. IA APPsub-TLV sub-sub-TLVs IA APPsub-TLVs can have trailing sub-sub-TLVs [RFC5305] as specified below. These sub-sub-TLVs occur after the Address Sets and the amount of space available for sub-sub-TLVs is determined from the overall IA APPsub-TLV length and the value of the Addr Set End byte. There is no ordering restriction on sub-sub-TLVs. Unless otherwise specified each sub-sub-TLV type can occur zero, one, or many times in an IA APPsub-TLV. Any sub-sub-TLVs for which the Type is unknown are ignored. The sub-sub-TLVs data structures shown below, with two byte Types and Lengths, assume that the enclosing IA-APPsubTLV is in an extended LSP TLV [RFC7356] or some non-LSP context. If they were used in a IA- APPsubTLV in a non-extended LSP [ISO-10589], then only one byte Types and Lengths could be used. As a result, any sub-sub-TLV types greater than 255 could not be used and Length would be limited to 255. 3.1 AFN Size sub-sub-TLV Using this sub-sub-TLV, the originating TRILL switch can specify the size of an address type. This is useful under two circumstances as follows: 1. One or more AFNs that are unknown to the receiving TRILL switch appears in the template. If an AFN Size sub-sub-TLV is present for each such AFN, then at least the IA APPsub-TLV can be parsed and possibly other addresses in each address set can still be used. 2. If an AFN occurs in the Template that represents a variable length address, this sub-sub-TLV gives its size for all occurrences in that IA APPsub-TLV. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = AFNsz | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN Size Record 1 | (3 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN Size Record 2 | (3 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN Size Record N | (3 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D. Eastlake and Y Li [Page 11] INTERNET-DRAFT TRILL: IA APPsub-TLV Where each AFN Size Record is structured as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AdrSize | (1 byte) +-+-+-+-+-+-+-+-+ o Type: AFN-Size sub-sub-TLV type, set to 1 (AFNsz). o Length: 3*n where n is the number of AFN Size Records present. If Length is not a multiple of 3, the sub-sub-TLV MUST be ignored. o AFN Size Record(s): Zero or more 3-byte records, each giving the size of an address type identified by an AFN, o AFN: The AFN whose length is being specified by the AFN Size Record. o AdrSize: The length in bytes of addresses specified by the AFN field as an unsigned integer. An AFN Size sub-sub-TLV for any AFN known to the receiving TRILL switch is compared with the size known to the TRILL switch. If they differ the IA APPsub-TLV is assumed to be corrupt and MUST be ignored. 3.2 Fixed Address sub-sub-TLV There may be cases where, in a particular Interface Addresses APP- subTLV, the same address would appear in every address set across the APP-subTLV. To avoid wasted space, this sub-sub-TLV can be used to indicate such a fixed address. The address or addresses incorporated into the sets by this sub-sub-TLV are NOT mentioned in the IA APPsub- TLV Template. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=FIXEDADR | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFN | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fixed Address (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-... o Type: Data Label sub-sub-TLV type, set to 2 (FIXEDADR). D. Eastlake and Y Li [Page 12] INTERNET-DRAFT TRILL: IA APPsub-TLV o Length: variable, minimum 2. If Length is 0 or 1 or less, the sub- sub-TLV MUST be ignored. o AFN: Address Family Number of the Fixed Address. o Fixed Address: The address of the type indicated by the preceding AFN field that is considered to be part of every Address Set in the IA APPsub-TLV. The Length field implies a size for the Fixed Address. If that size differs from the size of the address type for the given AFN as known by the receiving TRILL switch, the Fixed Address sub-sub-TLV is considered corrupt and MUST be ignored. 3.3 Data Label sub-sub-TLV This sub-sub-TLV indicates the Data Label within which the interfaces listed in the IA APPsub-TLV are reachable. It is useful if the IA APPsub-TLV occurs outside of the context of a message specifying the Data Label or if it is desired and permitted to override that specification. Multiple occurrences of this sub-sub-TLV indicate that the interfaces are reachable in all of the Data Labels given. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=DATALEN | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Label (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-... o Type: Data Label sub-TLV type, set to 3 (LABEL). o Length: 2 or 3. If Length is some other value, the sub-sub-TLV MUST be ignored. o Data Label: If length is 2, the bottom 12 bits of the Data Label are a VLAN ID and the top 4 bits are reserved (MUST be sent as zero and ignored on receipt). If the length is 3, the three Data Label bytes contain an FGL [RFC7172]. 3.4 Topology sub-sub-TLV The presence of this sub-sub-TLV indicates that the interfaces given in the IA APPsub-TLV are reachable in the topology given. It is useful if the IA APPsub-TLV occurs outside of the context of a D. Eastlake and Y Li [Page 13] INTERNET-DRAFT TRILL: IA APPsub-TLV message indicating the topology or if it is desired and permitted to override that specification. If it occurs multiple times, then the Address Sets are in all of the topologies given. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=DATALEN | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: Topology sub-TLV type, set to 4 (TOPOLOGY). o Length: 2. If Length is some other values, the sub-sub-TLV MUST be ignored. o RESV: Four reserved bits. MUST be sent as zero and ignored on receipt. o Topology: The 12-bit topology number [RFC5120]. D. Eastlake and Y Li [Page 14] INTERNET-DRAFT TRILL: IA APPsub-TLV 4. Security Considerations The integrity of address mapping and reachability information and the correctness of Data Labels (VLANs or FGLs [RFC7172]) are very important. Forged, altered, or incorrect address mapping or Data Labeling can lead to delivery of packets to the incorrect party, violating security policy. However, this document merely describes a data format and does not provide any explicit mechanisms for securing that information, other than a few simple consistency checks that might detect some corrupted data. Security on the wire, or in storage, for this data is to be providing by the transport or storage used. For example, when transported with ESADI [RFC7357] or RBridge Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel] security mechanisms can be used, respectively. The address mapping and reachability information, if known to be complete and correct, can be used to detect some cases of forged packet source addresses [RFC7067]. In particular, if native traffic from an end station is received by a TRILL switch that would otherwise accept it but authoritative data indicates the source address should not be reachable from the receiving TRILL switch, that traffic should be discarded. The data format specified in this document may optionally include TRILL switch Port ID number so that this forged address filtering can be optionally applied with port granularity. See [RFC6325] for general TRILL Security Considerations. D. Eastlake and Y Li [Page 15] INTERNET-DRAFT TRILL: IA APPsub-TLV 5. IANA Considerations The following subsections specify IANA actions. 5.1 AFN Number Allocation IANA has allocated the following AFN values that may be useful for IA APPsub-TLVs: Hex Decimal Description References ----- ------- ----------- ---------- 0001 1 IPv4 0002 2 IPv6 4005 16389 48-bit MAC [RFC7042] 4006 16390 64-bit MAC [RFC7042] 4007 16391 OUI This document. 4008 16392 MAC/24 This document. 4009 16393 MAC/40 This document. 400A 16394 IPv6/64 This document. 400B 16395 RBridge Port ID This document. Other AFNs can be found at http://www.iana.org/assignments/address- family-numbers The OUI AFN is provided so that MAC addresses can be abbreviated if they have the same upper 24 bits. A MAC/24 is a 24-bit suffix intended to be pre-fixed by an OUI to create a 48-bit MAC address [RFC7042]; in the absence of an OUI, a MAC/24 entry cannot be used. A MAC/40 is a suffix intended to be pre-fixed by an OUI to create a 64-bit MAC address [RFC7042]; in the absence of an OUI, a MAC/40 entry cannot be used. Typically, an OUI would be provided as a Fixed Address sub-sub-TLV (see Section 3.2). After Fixed Address sub-sub-TLV processing above, each address set is processed by combining each OUI in the address set with each MAC/24 and each MAC/40 address in the address set. Depending on how many of each of these address types is present, zero or more 48-bit and/or 64-bit MAC addresses may be produced that are considered to be part of the address set. If there are no MAC/24 or MAC/40 addresses present, any OUI's are ignored. If there are no OUIs, any MAC/24 and/or MAC/40s are ignored. If there are K1 OUIs, K2 MAC/24s, and K3 MAC/40s, K1*K2 48-bit MACs are synthesized and K1*K3 64-bit MACs are synthesized. IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 D. Eastlake and Y Li [Page 16] INTERNET-DRAFT TRILL: IA APPsub-TLV address. IPv6/64s are ignored unless, after the processing above in this sub-section, there are one or more 48-bit and/or 64-bit MAC addresses in the address set to provide the lower 64 bits of the IPv6 address. For this purpose, an 48-bit MAC address is expanded to 64 bits as described in [RFC7042]. If there are K4 IPv6/64s present and K5 48- and 64-bit MAC addresses present, K4*K5 128-bit IPv6 addresses are synthesized. 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry IANA is requested to establish a new subregistry of the TRILL Parameter Registry for sub-sub-TLVs of the Interface Addresses APPsub-TLV with initial contents as shown below. Name: Interface Addresses APPsub-TLV Sub-Sub-TLVs Procedure: Expert Review Note: Types greater than 255 are not usable in some contexts. Reference: [This document] Type Description Reference ------ ----------- --------- 0 Reserved 1 AFN Size [This document] 2 Fixed Address [This document] 3 Data Label [This document] 4 Topology [This document] 5-254 Available 255 Reserved 256-65534 Available 65535 Reserved 5.3 IA APPsub-TLV Number IANA is requested to allocate TBD1 as the Type for the IA APPsub-TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry from the range under 256. In the registry the Name is "IA" and the Reference is this document. D. Eastlake and Y Li [Page 17] INTERNET-DRAFT TRILL: IA APPsub-TLV Acknowledgments The authors gratefully acknowledge the contributions and review by the following: Linda Dunbar and Gayle Noble The document was prepared in raw nroff. All macros used were defined within the source file. D. Eastlake and Y Li [Page 18] INTERNET-DRAFT TRILL: IA APPsub-TLV Appendix A: Examples Below are example IA APPsub-TLVs. "0x" indicates that the following quantity is in hexadecimal. "0b" indicates that the following quantity is in binary. Leading zeros are retained. A.1 Simple Example Below is an annotated IA APPsub-TLV carrying two simple pairs of EUI-48 MAC addresses and IPv4 addresses from a Push Directory [RFC7067]. No sub-sub-TLVs are included. 0x0002(TBD) Type: Interface Addresses 0x001B Length: 27 (=0x1B) 0x001B Address Sets End: 27 (=0x1B) 0x1234 RBridge Nickname from which reachable 0b10000000 Flags: Push Directory data 0xE3 Confidence = 227 35 Template: 35 (0x23) = 31 + 1(MAC48) + 3*1(IPv4) Address Set One 0x00005E0053A9 48-bitMAC address 198.51.100.23 IPv4 address Address Set Two 0x00005E00536B 48-bit MAC address 203.0.113.201 IPv4 address Size includes 7 for the fixed fields though and including the one byte template, plus 2 times the Address Set size. Each Address Set is 10 bytes, 6 for the 48-bit MAC address plus 4 for the IPv4 address. So total size is 7 + 2*10 = 27. See Section 2 for more information on Template. A.2 Complex Example Below is an annotated IA APPsub-TLV carrying three sets of addresses, each consisting of an EUI-48 MAC address, an IPv4 addresses, an IPv6 address, and an RBridge Port ID, all from a Push Directory [RFC7067]. The IPv6 address for each address set is synthesized from the MAC address given in that set and the IPv6/64 64-bit prefix provided through a Fixed Address sub-sub-TLV. In addition, a sub-sub-TLV is included that provides an FGL which overrides whatever Data Label may be provided by the envelope (for example an ESADI-LSP [RFC7357]) within which this IA APPsub-TLV occurs. D. Eastlake and Y Li [Page 19] INTERNET-DRAFT TRILL: IA APPsub-TLV 0x0002(TBD) Type: Interface Addresses 0x0036 Length: 54 (=0x36) 0x0021 Address Sets End: 33 (=0x21) 0x4321 RBridge Nickname from which reachable 0b10000000 Flags: Push Directory data 0xD3 Confidence = 211 72 Template: 72(0x48)=31+1(MAC48)+3*1(IPv4)+36*1(P) Address Set One 0x00005E0053DE 48-bitMAC address 198.51.100.105 IPv4 address 0x1DE3 RBridge Port ID Address Set Two 0x00005E0053E3 48-bit MAC address 203.0.113.89 IPv4 address 0x1DEE RBridge Port ID Address Set Three 0x00005E0053D3 48-bit MAC address 192.0.2.139 IPv4 address 0x01DE RBridge Port ID sub-sub-TLV One 0x0003 Type: Data Label 0x0003 Length: implies FGL 0xD3E3E3 Fine Grained Label sub-sub-TLV Two 0x0002 Type: Fixed Address 0x000A Size: 0x0A = 10 0x400A AFN: IPv6/64 0x20010DB800000000 IPv6 Prefix: 2001:DB8:: See Section 2 for more information on Template. The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be treated as if it occurred as a 4th entry inside each of the three Address Sets. When there is an IPv6/64 entry and a 48-bit MAC entry, the MAC value is expanded by inserting 0xFFFE immediately after the OUI and the resulting 64-bit value is used as the lower 64 bits of the resulting IPv6 address [RFC7042]. As a result, a receiving TRILL switch would treat the three Address Sets shown as if they had an IPv6 address in them as follows: D. Eastlake and Y Li [Page 20] INTERNET-DRAFT TRILL: IA APPsub-TLV Address Set One 0x20010DB80000000000005EFFFE0053DE IPv6 Address Address Set Two 0x20010DB80000000000005EFFFE0053E3 IPv6 Address Address Set Three 0x20010DB80000000000005EFFFE0053D3 IPv6 Address As an alternative to the compact "well know value" Template encoding used in this example above, the less compact explicit AFN encoding could have been used. In that case, the IA APPsub-TLV would have started as follows: 0x0002(TBD) Type: Interface Addresses 0x003C Length: 60 (=0x3C) 0x0027 Address Sets End: 39 (=0x27) 0x4321 RBridge Nickname from which reachable 0b10000000 Flags: Push Directory data 0xD3 Confidence = 211 0x3 Template: 3 AFNs 0x4005 AFN: 48-bit MAC 0x0001 AFN: IPv4 0x400B AFN: RBridge Port ID As a final point, since the 48-bit MAC addresses in these three Address Sets all have the same OUI (the IANA OUI [RFC7042]), it would have been possible to just have a MAC/24 value giving the lower 24 bits of the MAC in each Address Set. The OUI would them be supplied by a second Fixed Address sub-sub-TLV proving the OUI. With N Address Sets, this would have saved 3*N or 9 bytes in this case at the cost of 9 bytes (2 each for the type and length of the sub-sub-TLV, 2 for the OUI AFN number, and 3 for the OUI). So, with just three Address Sets, there would be no net saving; however, with a larger number of Address Sets, there would be a net savings. D. Eastlake and Y Li [Page 21] INTERNET-DRAFT TRILL: IA APPsub-TLV Appendix Z: Change History From -00 to -01 1. Update references for RFC publications. 2. Add this Change History Appendix. From -01 to -02 1. Fix off-by-one errors in body text and examples for well known Template values. 2. Update for drafts published as RFCs and change in Author Address. 3. Minor editorial improvements. From -02 to -03 Minor editorial improvements. From -03 to -04 Editorial improvements. From -04 to -05 Remove one author. D. Eastlake and Y Li [Page 22] INTERNET-DRAFT TRILL: IA APPsub-TLV Normative References [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002. [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984. [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", RFC 6823, December 2012. [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013. [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, September 2014, . D. Eastlake and Y Li [Page 23] INTERNET-DRAFT TRILL: IA APPsub-TLV [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, September 2014, . Informational References [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large Data Centers", draft-shah-armd-arp-reduction, work in progress. [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel Protocol", draft-eastlake-trill-channel-tunnel, work in progress. [DirectoryScheme] - Dunbar, L., D. Eastlake, R. Perlman, I. Gashinsky, Y. Li, "TRILL": Directory Assistance Mechanisms", draft-dunbar-trill-scheme-for-directory-assist, work in progress. [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", RFC 5494, April 2009. [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, November 2013. [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014. D. Eastlake and Y Li [Page 24] INTERNET-DRAFT TRILL: IA APPsub-TLV Authors' Addresses Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56622310 Email: liyizhou@huawei.com Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 USA Email: Radia@alum.mit.edu D. Eastlake and Y Li [Page 25] INTERNET-DRAFT TRILL: IA APPsub-TLV Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake and Y Li [Page 26]