diff options
Diffstat (limited to 'doc/rfc/rfc7961.txt')
| -rw-r--r-- | doc/rfc/rfc7961.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7961.txt b/doc/rfc/rfc7961.txt new file mode 100644 index 0000000..8695431 --- /dev/null +++ b/doc/rfc/rfc7961.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Eastlake 3rd +Request for Comments: 7961 Y. Li +Category: Standards Track Huawei +ISSN: 2070-1721 August 2016 + + + Transparent Interconnection of Lots of Links (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. Each set of addresses reports all + of the addresses that designate the same interface (port) and also + reports the TRILL switch by which that interface 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 bypass 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 is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7961. + + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 1] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +Copyright Notice + + Copyright (c) 2016 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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................3 + 2. Format of the Interface Addresses APPsub-TLV ....................4 + 3. IA APPsub-TLV Sub-sub-TLVs ......................................9 + 3.1. AFN Size Sub-sub-TLV ......................................10 + 3.2. Fixed Address Sub-sub-TLV .................................11 + 3.3. Data Label Sub-sub-TLV ....................................12 + 3.4. Topology Sub-sub-TLV ......................................12 + 4. Security Considerations ........................................13 + 5. IANA Considerations ............................................14 + 5.1. Allocation of AFN Values ..................................14 + 5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry ...................15 + 5.3. IA APPsub-TLV Number ......................................16 + 6. Additional AFN Information .....................................16 + 7. Processing Address Sets ........................................16 + 8. References .....................................................18 + 8.1. Normative References ......................................18 + 8.2. Informative References ....................................20 + Appendix A. Examples ..............................................21 + A.1. Simple Example ............................................21 + A.2. Complex Example ...........................................22 + Acknowledgments ...................................................24 + Authors' Addresses ................................................24 + + + + + + + + + + + +Eastlake & Li Standards Track [Page 2] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +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 where + 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 bypass 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 [ARPND]. 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 the + End Station Address Distribution Information (ESADI) RFC [RFC7357] + but may also occur in other application contexts. The + "directory assistance" TRILL Edge services [DirectoryScheme] are + expected to make use of this APPsub-TLV. + + Although in some IETF protocols address field types are represented + by an Ethertype [RFC7042] or a hardware address type [RFC5494], only + the Address Family Number (AFN) is used in this APPsub-TLV to + represent the 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-related 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 + (http://www.iana.org/assignments/address-family-numbers/) + + APPsub-TLV: Application sub-TLV [RFC6823] + + Data Label: VLAN or FGL + + + +Eastlake & Li Standards Track [Page 3] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + FGL: Fine-Grained Label [RFC7172] + + IA: Interface Address(es) + + MAC: Media Access Control + + Nickname: A 16-bit TRILL switch identifier, as specified in + Section 3.7 of [RFC6325] and as updated by Section 4 of [RFC7780] + + RBridge: An alternative name for a TRILL switch + + TRILL switch: A device that implements the TRILL protocol + +2. Format of the Interface Addresses APPsub-TLV + + The Interface Addresses (IA) APPsub-TLV is used to advertise a set of + addresses indicating the same interface (port) within a Data Label + (VLAN or FGL). It also associates 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, the IA APPsub-TLV 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. While those three types of addresses are + likely to be the only types of interest, any address type for which + an AFN has been assigned by IANA can be represented. + + The Template field in a particular IA 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. + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 4] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + Figure 1 shows an IA APPsub-TLV as it would appear inside an IS-IS + Flooding Scope Link State PDU (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 1-byte unsigned integers equal to or less than 255, but with + an extended TLV, the Type and Length are 2-byte unsigned integers. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = (10) | (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: Interface Addresses APPsub-TLV + + o Type: Interface Addresses TRILL APPsub-TLV type; set to 10 + (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. For + manageability, a counter reflecting the receipt of such malformed + IA APPsub-TLVs should be maintained. + + + + + + + + +Eastlake & Li Standards Track [Page 5] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + o Addr Sets End: The unsigned integer byte number, within the IA + APPsub-TLV value part, of the last byte of the last Address Set, + where the first byte is numbered 1. This will be the number of + the byte just before the first sub-sub-TLV if any sub-sub-TLVs are + present (see Section 3). The processing is as follows: + + - If this field is greater than Length or points to before the + end of the Template, the IA APPsub-TLV is corrupt and MUST be + discarded. + + - If this field is equal to Length, there are no sub-sub-TLVs. + + - If this field is less than Length, sub-sub-TLVs are parsed as + specified in Section 3. + + Note: This field is always 2 bytes in size. + + o Nickname: The nickname (see Section 1.1) of the TRILL switch by + which the Address Sets are reachable. If 0, the Address Sets are + reachable from the TRILL switch originating the message containing + the APPsub-TLV (for example, an ESADI [RFC7357] message). + + o Flags: A byte of flags, as follows: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |D|L| RESV | + +-+-+-+-+-+-+-+-+ + + D: Directory flag: If D is 1, the APPsub-TLV contains directory + information [RFC7067]. + + L: Local flag: If L is 1, the APPsub-TLV contains information + learned locally by observing ingressed frames [RFC6325]. + (Both D and L can be set to 1 in the same IA APPsub-TLV if a + TRILL switch had learned an address locally and also + advertised it as a directory.) + + 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. + + + + + + +Eastlake & Li Standards Track [Page 6] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + 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 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 0, the IA APPsub-TLV is ignored. If K is 32 to 254, the length + of the Template field is 1 byte, and its value is intended to + correspond to a particular ordered set of AFNs, some of which are + specified below. The value of 255 for K is reserved for future + definition and causes the IA APPsub-TLV to be ignored. + + 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 range 32 to 39, values indicate a specific sequence, + as specified below. The values of K from 40 to 254 are reserved + for future specification. If the value of K is not understood by + a receiver of the IA-APPsub-TLV, any Address Sets present are + ignored. + + K Addresses in order of occurrence + --- -------------------------------- + 32 48-bit MAC + 33 48-bit MAC, IPv4 + 34 48-bit MAC, IPv6 + 35 48-bit MAC, IPv4, IPv6 + 36 48-bit MAC, RBridge port + 37 48-bit MAC, IPv4, RBridge port + 38 48-bit MAC, IPv6, RBridge port + 39 48-bit MAC, IPv4, IPv6, RBridge port + + For ease of decoding, note that for values of K between 32 and 39 + inclusive, the 0x01 bit indicates that an IPv4 address is present, + the 0x02 bit indicates that an IPv6 address is present, and the + 0x04 bit indicates that an RBridge Port ID is present. + + + + +Eastlake & Li Standards Track [Page 7] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + o AFN: A 2-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 the 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. See Section 7 on interpreting certain Address Sets. + + o sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do + not completely fill the length of the APPsub-TLV (as indicated by + the Length field), then per Section 4 of [RFC5305] the remaining + bytes are parsed as sub-sub-TLVs. 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; this 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; this might be the + most efficient format if only one interface had multiple IPv6 + addresses and other interfaces had only one IPv6 address. + + + + + + +Eastlake & Li Standards Track [Page 8] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + 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 Sets 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 + 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. + + For manageability, a counter of ill-formed IA APPsub-TLVs received + and ignored due to unknown K, unknown AFN, and the like (as described + above) should be maintained. + +3. IA APPsub-TLV Sub-sub-TLVs + + IA APPsub-TLVs can have sub-sub-TLVs (sub-TLVs of sub-TLVs [RFC5305]) + at the end, as specified below. These sub-sub-TLVs occur after the + Address Sets. The amount of space available for sub-sub-TLVs is + determined from the overall IA APPsub-TLV length and the value of the + Addr Sets 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. For manageability, a counter of sub-sub-TLVs received + and ignored due to an unknown Type or other reasons, as described + below, should be maintained. + + The data structures of the sub-sub-TLVs shown below, with 2-byte + Types and Lengths, assume that the enclosing IA APPsub-TLV is in an + extended LSP TLV [RFC7356] or some non-LSP context. If they were + used in an IA APPsub-TLV in a non-extended LSP [ISO-10589], then only + 1-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. + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 9] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +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 the following two + circumstances: + + 1. One or more AFNs that are unknown to the receiving TRILL switch + appear 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 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AFN Size Record 1 | (3 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AFN Size Record 2 | (3 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AFN Size Record N | (3 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: AFN Size Sub-sub-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. + + + + + +Eastlake & Li Standards Track [Page 10] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + 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 IA APPsub-TLV, the same + address would appear in every Address Set across the IA APPsub-TLV. + 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 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AFN | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Fixed Address (variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-... + + Figure 3: Fixed Address Sub-sub-TLV + + o Type: Data Label sub-sub-TLV type; set to 2 (FIXEDADR). + + o Length: Variable; minimum 2. If Length is 0 or 1, 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. + + + + + +Eastlake & Li Standards Track [Page 11] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +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 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Label (variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-... + + Figure 4: Data Label Sub-sub-TLV + + o Type: Data Label sub-TLV type; set to 3 (DATALEN). + + 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 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 + 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 = TOPOLOGY | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESV | Topology | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Topology Sub-sub-TLV + + + + +Eastlake & Li Standards Track [Page 12] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + o Type: Topology sub-TLV type; set to 4 (TOPOLOGY). + + o Length: 2. If Length is some other value, the sub-sub-TLV MUST be + ignored. + + o RESV: 4 reserved bits. MUST be sent as zero and ignored on + receipt. + + o Topology: The 12-bit topology number [RFC5120]. + +4. Security Considerations + + The integrity of address mapping and reachability information as well + as 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 provided 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 that 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 a TRILL switch Port ID number so that + this forged address filtering can be optionally applied with port + granularity. For manageability, a counter of frames so discarded + should be maintained. + + See [RFC6325] for general TRILL security considerations. + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 13] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +5. IANA Considerations + + The following subsections specify IANA allocations. + +5.1. Allocation of AFN Values + + IANA has allocated values in the "Address Family Numbers" registry + that may be useful for IA APPsub-TLVs. The values are as follows: + + Hex Decimal Description References + ----- ------- ----------- ---------- + 0001 1 IPv4 + 0002 2 IPv6 + 4005 16389 48-bit MAC Section 2.1 of [RFC7042] + 4006 16390 64-bit MAC Section 2.2 of [RFC7042] + 4007 16391 OUI Section 6 of RFC 7961 + 4008 16392 MAC/24 Section 6 of RFC 7961 + 4009 16393 MAC/40 Section 6 of RFC 7961 + 400A 16394 IPv6/64 Section 6 of RFC 7961 + 400B 16395 RBridge Port ID Section 6 of RFC 7961 + + Other AFNs can be found at <http://www.iana.org/assignments/ + address-family-numbers>. + + See Section 7 on interpreting Address Sets. + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 14] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry + + IANA has established a new sub-registry of the "Transparent + Interconnection of Lots of Links (TRILL) Parameters" registry for + sub-sub-TLVs of the Interface Addresses APPsub-TLV, with the + following initial contents: + + Name: Interface Addresses APPsub-TLV Sub-sub-TLVs + + Procedure: Expert Review + + Note: Types greater than 255 are not usable in some contexts. + + Reference: RFC 7961 + + Type Description Reference + ------ ----------- --------- + 0 Reserved RFC 7961 + 1 AFN Size RFC 7961 + 2 Fixed Address RFC 7961 + 3 Data Label RFC 7961 + 4 Topology RFC 7961 + 5-254 Unassigned + 255 Reserved RFC 7961 + 256-65534 Unassigned + 65535 Reserved RFC 7961 + + Expert Guidance: A designated expert for this registry should decide + whether to permit the assignment of a type based on clear + documentation of the proposed type as provided by the requester, + such as a complete Internet-Draft. New types should not duplicate + existing types. Requests should indicate whether a type less than + 255 is desired; such types can be used in contexts where only + 1 byte of a type (and usually only 1 byte of the length) is + permitted. Types greater than 255 can only be used where 2-byte + types are allowed, such as in Extended Level 1 Flooding Scope + (E-L1FS) or Extended Level 1 Circuit Scope (E-L1CS) extended + FS-LSPs [RFC7356]; in those contexts, lengths up to 65535 bytes + can also be expressed, although they may not be usable if the + resulting TLV would not fit into a larger context restricted by an + MTU setting or the like. Values within the region below 255 and + the region above 255 should be allocated sequentially, unless + there is an extraordinary reason for a special value. + + + + + + + + +Eastlake & Li Standards Track [Page 15] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +5.3. IA APPsub-TLV Number + + IANA has allocated type 10 as 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. + +6. Additional AFN Information + + This section provides additional information concerning AFNs that + were allocated in connection with this document. These AFNs are not + restricted to use in the IA APPsub-TLV and may be used in other + protocols where they would be appropriate. + + OUI: A 3-byte (24-bit) Organizationally Unique Identifier used as the + initial 3 bytes of a MAC address. See Sections 2.1 and 2.2 of + [RFC7042], and Section 7 below. + + MAC/24: A 3-byte (24-bit) quantity used as the final 3 bytes of a + 48-bit MAC address. See Section 2.1 of [RFC7042] and Section 7 + below. + + MAC/40: A 5-byte (40-bit) quantity used as the final 5 bytes of a + 64-bit MAC address. See Section 2.2 of [RFC7042] and Section 7 + below. + + IPv6/64: An 8-byte (64-bit) quantity used as the initial 8 bytes of + an IPv6 address. See Section 7 below. + + RBridge Port ID: A 16-bit quantity that uniquely identifies a port on + a TRILL switch (RBridge). See Section 4.4.2 of [RFC6325]. + +7. Processing Address Sets + + The following processes should be followed in interpreting sets of + AFN values in an IA APPsub-TLV to synthesize addresses. These apply + whether the AFN values came from sub-sub-TLVs, appeared within an + Address Set, or came from both sources. In general, the processing + is applied separately to each Address Set as supplemented by any + Fixed Address sub-sub-TLVs that are present. + + The OUI AFN value 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 prefixed 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 40-bit suffix intended to be prefixed + by an OUI to create a 64-bit MAC address [RFC7042]; in the absence of + an OUI, a MAC/40 entry cannot be used. + + + +Eastlake & Li Standards Track [Page 16] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + Typically, an OUI would be provided as a Fixed Address sub-sub-TLV + (see Section 3.2) using the OUI AFN, but there is no prohibition + against one or more OUIs appearing in an Address Set. + + Each Address Set, after being supplemented by any Fixed Address + sub-sub-TLVs, 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 are present, + zero or more 48-bit and/or 64-bit MAC addresses may be synthesized + that are subsequently processed as if they had been part of the + Address Set. If there are no MAC/24 or MAC/40 addresses present, any + OUIs are ignored. If there are no OUIs, any MAC/24s 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 + address. IPv6/64s are ignored unless, after the processing described + above in this subsection, 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, a 48-bit MAC address is expanded to + 64 bits as described in Section 2.2.1 of [RFC7042]. If there are K4 + IPv6/64s present and K5 48-bit and 64-bit MAC addresses present, + K4*K5 128-bit IPv6 addresses are synthesized. + + Synthesized addresses are treated as if they had been members of the + Address Set. + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 17] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +8. References + +8.1. Normative References + + [ISO-10589] + International Organization for Standardization, + "Intermediate System to Intermediate System intra-domain + routeing information exchange protocol for use in + conjunction with the protocol for providing the + connectionless-mode network service (ISO 8473)", + ISO Standard 10589, 2002. + + [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, DOI 10.17487/RFC0826, November 1982, + <http://www.rfc-editor.org/info/rfc826>. + + [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A + Reverse Address Resolution Protocol", STD 38, RFC 903, + DOI 10.17487/RFC0903, June 1984, + <http://www.rfc-editor.org/info/rfc903>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + <http://www.rfc-editor.org/info/rfc4861>. + + [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: + Multi Topology (MT) Routing in Intermediate System to + Intermediate Systems (IS-ISs)", RFC 5120, + DOI 10.17487/RFC5120, February 2008, + <http://www.rfc-editor.org/info/rfc5120>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, + October 2008, <http://www.rfc-editor.org/info/rfc5305>. + + + + +Eastlake & Li Standards Track [Page 18] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, + <http://www.rfc-editor.org/info/rfc6325>. + + [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising + Generic Information in IS-IS", RFC 6823, + DOI 10.17487/RFC6823, December 2012, + <http://www.rfc-editor.org/info/rfc6823>. + + [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and + IETF Protocol and Documentation Usage for IEEE 802 + Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, + October 2013, <http://www.rfc-editor.org/info/rfc7042>. + + [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, + DOI 10.17487/RFC7172, May 2014, + <http://www.rfc-editor.org/info/rfc7172>. + + [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding + Scope Link State PDUs (LSPs)", RFC 7356, + DOI 10.17487/RFC7356, September 2014, + <http://www.rfc-editor.org/info/rfc7356>. + + [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, DOI 10.17487/RFC7357, + September 2014, <http://www.rfc-editor.org/info/rfc7357>. + + [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., + Ghanwani, A., and S. Gupta, "Transparent Interconnection + of Lots of Links (TRILL): Clarifications, Corrections, and + Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, + <http://www.rfc-editor.org/info/rfc7780>. + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 19] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +8.2. Informative References + + [ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., and R. Perlman, + "TRILL: ARP/ND Optimization", Work in Progress, + draft-ietf-trill-arp-optimization-06, April 2016. + + [ChannelTunnel] + Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge + Channel Header Extension", Work in Progress, + draft-ietf-trill-channel-tunnel-11, August 2016. + + [DirectoryScheme] + Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, + "TRILL: Edge Directory Assist Mechanisms", Work in + Progress, draft-ietf-trill-directory-assist-mechanisms-07, + February 2016. + + [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines + for the Address Resolution Protocol (ARP)", RFC 5494, + DOI 10.17487/RFC5494, April 2009, + <http://www.rfc-editor.org/info/rfc5494>. + + [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. + Gashinsky, "Directory Assistance Problem and High-Level + Design Proposal", RFC 7067, DOI 10.17487/RFC7067, + November 2013, <http://www.rfc-editor.org/info/rfc7067>. + + [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, + DOI 10.17487/RFC7178, May 2014, + <http://www.rfc-editor.org/info/rfc7178>. + + + + + + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 20] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +Appendix A. Examples + + Below are example IA APPsub-TLVs. "0x" indicates that the quantity + is in hexadecimal. "0b" indicates that the 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 + (a directory conforming to the Push Model [RFC7067]). No + sub-sub-TLVs are included. + + 0x0002(10) 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 + 33 Template: 33 (0x21) = 32 + 1(IPv4) + + Address Set One + 0x00005E0053A9 48-bit MAC address + 198.51.100.23 IPv4 address + + Address Set Two + 0x00005E00536B 48-bit MAC address + 203.0.113.201 IPv4 address + + The size includes 7 for the fixed fields through and including the + 1-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. Therefore, the total size is 7 + 2*10 = 27. + + See Section 2 for more information on the Template. + + + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 21] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +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 address, an IPv6 + address, and an RBridge Port ID, all from a Push Directory + (a directory conforming to the Push Model [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 that overrides whatever Data Label may be + provided by the envelope (for example, an ESADI-LSP [RFC7357]) within + which this IA APPsub-TLV occurs. + + 0x0002(10) Type: Interface Addresses + 0x0036 Length: 64 (= 0x40) + 0x0021 Address Sets End: 43 (= 0x2B) + 0x4321 RBridge Nickname from which reachable + 0b10000000 Flags: Push Directory data + 0xD3 Confidence = 211 + 37 Template: 37(0x25) = 32 + 1(IPv4) + 4(Port) + + Address Set One + 0x00005E0053DE 48-bit MAC 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 the Template. + + + +Eastlake & Li Standards Track [Page 22] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + + The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be + treated as if it occurred as a fourth 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 local/global bit is inverted. The resulting + Modified EUI-64-bit value is used as the lower 64 bits of the + resulting IPv6 address (Section 2.2.1 of [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: + + Address Set One + 0x20010db80000000002005efffe0053de IPv6 Address + + Address Set Two + 0x20010db80000000002005efffe0053e3 IPv6 Address + + Address Set Three + 0x20010db80000000002005efffe0053d3 IPv6 Address + + As an alternative to the compact "well-known value" Template encoding + used in the 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(10) 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 then be + supplied by a second Fixed Address sub-sub-TLV providing the OUI. + With N Address Sets, this would have saved 3*N or 9 bytes, at a cost + of 9 bytes (2 each for the Type and Length of the sub-sub-TLV, 2 for + the OUI AFN, and 3 for the OUI). So, with just three Address Sets, + there would be no net savings; however, with a larger number of + Address Sets, there would be a net savings. + + + + + + +Eastlake & Li Standards Track [Page 23] + +RFC 7961 TRILL: IA APPsub-TLV August 2016 + + +Acknowledgments + + The authors gratefully acknowledge the contributions and review by + the following: + + Linda Dunbar, Sue Hares, Paul Kyzivat, Danny McPherson, and + Gayle Noble + +Authors' Addresses + + Donald Eastlake 3rd + Huawei Technologies + 155 Beaver Street + Milford, MA 01757 + United States of America + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Eastlake & Li Standards Track [Page 24] + |