RFC 7961
Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV
Abstract ✨
Okay bestie, this is RFC 7961 🦋, "Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV." It's by D. Eastlake 3rd and Y. Li from Huawei, it's a Standards Track document, it came out in August 2016 (ISSN 2070-1721), and its title block doesn't list anything it obsoletes or updates 💅.
The big idea is a TRILL IS-IS application sub-TLV that lets a TRILL switch report sets of addresses 🌸. Every set holds all the addresses that point at the same interface (port), plus the TRILL switch that interface can be reached through. So a 48-bit MAC address, an IPv4 address, and an IPv6 address can all be reported as belonging to one interface behind one switch 🎀. That info can be used to fake answers to, or skip, ARP, IPv6 Neighbor Discovery, or flooding unknown MAC addresses 🙈. Iconic efficiency.
Status of This Memo 🌈
This is an Internet Standards Track document 📜.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More on Internet Standards is in Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7961 🔥.
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) as they stood on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 👑. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 ................................................241. Introduction 🎀
This document defines a TRILL [RFC6325] IS-IS application sub-TLV (APPsub-TLV) [RFC6823] that makes it easy to represent sets of addresses where every address in a set points at the same interface (port) 💖. For example, a 48-bit MAC (Media Access Control) [RFC7042] address, an IPv4 address, and an IPv6 address can all be reported as designating the same interface. On top of that, a Data Label (a VLAN or a Fine-Grained Label (FGL) [RFC7172]) gets specified for the interface, along with the TRILL switch and, optionally, the TRILL switch port the interface is reachable from ✨.
This info could be used in some cases to fake responses to, or skip, 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] 🙈. And if the reported info is complete, it can also be used to catch and toss packets with forged source addresses. Main character protection 🛡️.
The APPsub-TLV lives inside the TRILL GENINFO TLV defined in the End Station Address Distribution Information (ESADI) RFC [RFC7357], but it can also show up in other application contexts 🍓. The "directory assistance" TRILL Edge services [DirectoryScheme] are expected to use this APPsub-TLV 🌸.
Some IETF protocols represent address field types with an Ethertype [RFC7042] or a hardware address type [RFC5494]. This APPsub-TLV doesn't do that. It only uses the Address Family Number (AFN) 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 here, along with these extra 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
- 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 ✨
okay so the IA APPsub-TLV is how you advertise a bunch of addresses that all belong to the same interface (port) inside a Data Label (VLAN or FGL) 🎀. It also links that interface to the TRILL switch and, optionally, the TRILL switch port it's reachable through 🦋. The addresses can be different address families, and it's giving main character energy. For example, one IA APPsub-TLV can say a particular interface with an IPv4, an IPv6, and a 48-bit MAC address, in some Data Label, is reachable from a particular TRILL switch 💖. Those three are probably the big ones, but any address type with an AFN assigned by IANA can go in there 🌈.
The Template field is basically the blueprint for each Address Set in the TLV 📐. Some popular sets of addresses get special values, and everything else gets spelled out as a list of AFNs. The list-of-AFNs Template gives an explicit pattern for the type and order of addresses in every Address Set that uses it, so no guessing 💅.
A device or app that reads IA data does not have to use all of it 🫶. If you only care about MAC and IPv6, you can just ignore any IPv4 or other address info that shows up. Totally valid, no cap.
Figure 1 shows what an IA APPsub-TLV looks like inside an IS-IS Flooding Scope Link State PDU (FS-LSP) using an extended flooding scope [RFC7356] TLV, like in ESADI [RFC7357] 🧚. With traditional [ISO-10589] TLVs, the Type and Length are 1-byte unsigned integers that are less than or equal to 255. With an extended TLV, though, 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
Type: Interface Addresses TRILL APPsub-TLV type; set to 10 (IA-SUBTLV). 🎯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 📊.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 goes like this:- 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.
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 that originated the message containing the APPsub-TLV (for example, an ESADI [RFC7357] message) 🍓.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 learned an address locally and also advertised it as a directory. Iconic multitasking 💜.)
- RESV: Additional reserved flag bits that MUST be sent as zero and ignored on receipt 🙈.
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 ✨.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, the 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 portFor 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 🔢.
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 🚧.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 🧱.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 🌸.
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 ✨
okay so IA APPsub-TLVs can have sub-sub-TLVs (sub-TLVs of sub-TLVs, see [RFC5305]) hanging out at the end 🎀. They show up after the Address Sets, and how much room they get comes from the overall IA APPsub-TLV length and the value of the Addr Sets End byte 🧚.
There's no ordering rule, so they can appear in any order 💅. Unless it says otherwise, each sub-sub-TLV type can show up zero, one, or many times in an IA APPsub-TLV. Any sub-sub-TLV with an unknown Type gets ignored 🙈. For manageability, a counter of sub-sub-TLVs that were received and ignored because of an unknown Type or other reasons, as described below, should be maintained ✨.
The sub-sub-TLV structures below use 2-byte Types and Lengths. That assumes the enclosing IA APPsub-TLV is in an extended LSP TLV [RFC7356] or some non-LSP context. If you put them in an IA APPsub-TLV inside a non-extended LSP [ISO-10589], you only get 1-byte Types and Lengths 😭. So sub-sub-TLV types above 255 wouldn't work, and Length would be capped at 255 💀.
3.1. AFN Size Sub-sub-TLV
With this sub-sub-TLV, the originating TRILL switch can tell everyone the size of an address type 📏. It's super handy in two situations:
- One or more AFNs that the receiving TRILL switch doesn't know show up in the Template. If there's an AFN Size sub-sub-TLV for each of those AFNs, then at least the IA APPsub-TLV can be parsed, and maybe the other addresses in each Address Set can still be used 🫶.
- An AFN in the Template is a variable-length address. This sub-sub-TLV gives its size for every occurrence 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-TLVEach AFN Size Record is structured like this 🍓:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AdrSize | (1 byte)
+-+-+-+-+-+-+-+-+- Type: AFN Size sub-sub-TLV type; set to 1 (AFNsz).
- 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.
- AFN Size Record(s): Zero or more 3-byte records, each giving the size of an address type identified by an AFN.
- AFN: The AFN whose length is being specified by the AFN Size Record.
- 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 the receiving TRILL switch knows gets compared with the size the switch already has on file 🔍. If they differ, the IA APPsub-TLV is assumed to be corrupt and MUST be ignored 🚫.
3.2. Fixed Address Sub-sub-TLV
Sometimes, in a particular IA APPsub-TLV, the very same address shows up in every Address Set 👯. To avoid wasting space, this sub-sub-TLV can be used to flag that fixed address 📌. The address or addresses added to 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- Type: Data Label sub-sub-TLV type; set to 2 (FIXEDADR).
- Length: Variable; minimum 2. If Length is 0 or 1, the sub-sub-TLV MUST be ignored.
- AFN: Address Family Number of the Fixed Address.
- 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 doesn't match the size of the address type for the given AFN as the receiving TRILL switch knows it, the Fixed Address sub-sub-TLV is considered corrupt and MUST be ignored 💀.
3.3. Data Label Sub-sub-TLV
This one tells you the Data Label where the interfaces in the IA APPsub-TLV can be reached 🏷️. It's useful if the IA APPsub-TLV shows up outside of a message that specifies the Data Label, or if you want to override that specification (when it's allowed) 🦋. Multiple occurrences mean 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- Type: Data Label sub-TLV type; set to 3 (DATALEN).
- Length: 2 or 3. If Length is some other value, the sub-sub-TLV MUST be ignored.
- 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
If this sub-sub-TLV is present, the interfaces in the IA APPsub-TLV are reachable in the topology it names 🗺️. Like the Data Label one, it's handy when the IA APPsub-TLV shows up outside of a message that indicates the topology, or when you want to override that (if it's allowed) 💅. If it occurs multiple times, 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- Type: Topology sub-TLV type; set to 4 (TOPOLOGY).
- Length: 2. If Length is some other value, the sub-sub-TLV MUST be ignored.
- RESV: 4 reserved bits. MUST be sent as zero and ignored on receipt.
- Topology: The 12-bit topology number [RFC5120].
4. Security Considerations ✨
okay this section is SERIOUS bestie 😭🔐. The integrity of address mapping and reachability information, and the correctness of Data Labels (VLANs or FGLs [RFC7172]), are super important 💜. Forged, altered, or incorrect address mapping or data labeling can lead to packets being delivered to the wrong party, which breaks security policy 🚨. However, this document only describes a data format. It doesn't give any explicit mechanisms for securing that information, apart from a few simple consistency checks that might catch some corrupted data 🙈. Security on the wire, or in storage, for this data is up to the transport or storage being used 🛡️. For example, when it's transported with ESADI [RFC7357] or RBridge Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel] security mechanisms can be used, respectively 🔒.
If the address mapping and reachability information is known to be complete and correct, it can be used to catch some cases of forged packet source addresses [RFC7067] 🕵️♀️. Specifically, if native traffic from an end station is received by a TRILL switch that would otherwise accept it, but authoritative data says the source address shouldn't be reachable from that receiving TRILL switch, that traffic should be discarded 🗑️. The data format in this document may optionally include a TRILL switch Port ID number, so this forged address filtering can optionally be applied with port granularity 🎯. For manageability, a counter of frames discarded this way should be maintained 📊.
See [RFC6325] for general TRILL security considerations 📚.
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 7961Other AFNs can be found at <http://www.iana.org/assignments/address-family-numbers> 🔗.
See Section 7 on interpreting Address Sets 🫶.
5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry ✨
okay so IANA made a brand new sub-registry 🎀 inside the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry just for the sub-sub-TLVs of the Interface Addresses APPsub-TLV. Here's how it starts out:
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 7961The Expert Guidance is where the real tea is 🍓. A designated expert gets to decide whether a type gets assigned, and they base that on clear documentation from the requester, like a complete Internet-Draft. New types shouldn't copy an existing type, so no doubles, bestie 💅. Requesters should say whether they want a type under 255, because those small ones only work in contexts where a type gets just 1 byte (and usually the length only gets 1 byte too). Types over 255 only fit where 2-byte types are allowed, like the Extended Level 1 Flooding Scope (E-L1FS) or Extended Level 1 Circuit Scope (E-L1CS) extended FS-LSPs [RFC7356] 🦋. In those spots, lengths can go all the way up to 65535 bytes, but honestly they might not be usable if the resulting TLV wouldn't fit inside a bigger context that has an MTU setting or something similar. Last thing: values below 255 and values above 255 should get handed out in order, unless there's a seriously extraordinary reason to pick a special value 🌈.
5.3. IA APPsub-TLV Number 🧚
IANA gave type 10 to the IA APPsub-TLV. It lives in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry, and it came from the range under 256 💖. In that registry the name is "IA" and the reference is this document.
6. Additional AFN Information 💜
This section is the extra info about the AFNs that got allocated alongside this document. Quick heads-up: these AFNs aren't locked to the IA APPsub-TLV. Other protocols can use them too, wherever they make sense 🌸.
- OUI: A 3-byte (24-bit) Organizationally Unique Identifier used as the first 3 bytes of a MAC address. Check out Sections 2.1 and 2.2 of [RFC7042], plus Section 7 below 🎀.
- MAC/24: A 3-byte (24-bit) quantity used as the last 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 last 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 first 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 🧩
Okay, so this is the recipe for turning sets of AFN values in an IA APPsub-TLV into actual addresses 🍰. Follow these processes when you interpret them. They apply whether the AFN values came from sub-sub-TLVs, showed up inside an Address Set, or came from both places. Generally, you process each Address Set on its own, after you've added in any Fixed Address sub-sub-TLVs that are present 💅.
The OUI AFN value exists so MAC addresses can get shortened when they share the same upper 24 bits 🫶. A MAC/24 is a 24-bit suffix that's meant to get an OUI stuck in front of it to make a 48-bit MAC address [RFC7042]. Without an OUI, a MAC/24 entry can't be used at all 😭. A MAC/40 is a 40-bit suffix meant to get an OUI in front of it to make a 64-bit MAC address [RFC7042]. Same deal: no OUI, no MAC/40 entry 💀.
Usually an OUI shows up as a Fixed Address sub-sub-TLV (see Section 3.2) using the OUI AFN. Nothing stops one or more OUIs from showing up inside an Address Set though 🙈.
Once an Address Set has its Fixed Address sub-sub-TLVs added, you combine each OUI in that set with each MAC/24 and each MAC/40 address in the same set 🔥. Depending on how many of each you have, you might synthesize zero or more 48-bit and/or 64-bit MAC addresses. Those get processed as if they'd been part of the Address Set all along. If there are no MAC/24 or MAC/40 addresses, any OUIs get ignored. If there are no OUIs, any MAC/24s and/or MAC/40s get ignored too 🥺. So if you've got K1 OUIs, K2 MAC/24s, and K3 MAC/40s, you synthesize K1*K2 48-bit MACs and K1*K3 64-bit MACs ✨.
IPv6/64 is an 8-byte quantity: the first 64 bits of an IPv6 address 🌸. IPv6/64s get ignored unless, after the processing we just covered, there's at least one 48-bit and/or 64-bit MAC address in the Address Set to supply the lower 64 bits of the IPv6 address. For that purpose, a 48-bit MAC address gets expanded to 64 bits, as described in Section 2.2.1 of [RFC7042] 🧚. If there are K4 IPv6/64s and K5 48-bit and 64-bit MAC addresses, you synthesize K4*K5 128-bit IPv6 addresses 👑.
Synthesized addresses get treated as if they had been members of the Address Set. Iconic 🌈.
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>.
[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>.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>.Appendix A. Examples 🎀
Here come the example IA APPsub-TLVs 🫶. Just so you know the notation: 0x means the quantity is in hexadecimal, and 0b means it's in binary. Leading zeros are kept, so don't trim them off 🧠.
A.1. Simple Example ✨
okay so this is the tiniest IA APPsub-TLV ever 🧚 it carries two simple pairs of EUI-48 MAC addresses and IPv4 addresses, and it comes from a Push Directory (a directory that follows the Push Model [RFC7067]). no sub-sub-TLVs at all, we keep it lowkey 🎀
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 addressso the size is 7 for the fixed fields (everything up through and including the 1-byte Template) plus 2 times the Address Set size 🫶 each Address Set is 10 bytes, which is 6 for the 48-bit MAC address plus 4 for the IPv4 address. bestie math: 7 + 2*10 = 27. ✔️
see Section 2 for more info on the Template 💅
A.2. Complex Example 🦋
now we're going full main character energy 👑 this one is an IA APPsub-TLV carrying three sets of addresses. each set has an EUI-48 MAC address, an IPv4 address, an IPv6 address, and an RBridge Port ID, all from a Push Directory (again, a directory that follows the Push Model [RFC7067]). the IPv6 address in each Address Set gets synthesized from the MAC address in that set plus the IPv6/64 64-bit prefix that comes in through a Fixed Address sub-sub-TLV. and there's also a sub-sub-TLV that gives an FGL, which overrides whatever Data Label the envelope might have (like an ESADI-LSP [RFC7357]) that this IA APPsub-TLV sits inside of 🌸
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 info on the Template again, because it's that important 🙈
the Fixed Address sub-sub-TLV makes the IPv6/64 value act like it showed up as a fourth entry inside each of the three Address Sets 🧚 when there's an IPv6/64 entry and a 48-bit MAC entry together, the MAC value gets expanded by inserting 0xfffe right after the OUI, and then the local/global bit gets flipped. that resulting Modified EUI-64-bit value becomes the lower 64 bits of the IPv6 address (Section 2.2.1 of [RFC7042]). so a receiving TRILL switch would treat the three Address Sets like they had an IPv6 address in them, which looks like this:
Address Set One
0x20010db80000000002005efffe0053de IPv6 Address
Address Set Two
0x20010db80000000002005efffe0053e3 IPv6 Address
Address Set Three
0x20010db80000000002005efffe0053d3 IPv6 Addressnow, the compact "well-known value" Template encoding we just used isn't the only option 🎀 the less compact explicit AFN encoding could have been used instead. in that case, the IA APPsub-TLV would have started like this:
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 IDlast but not least 💜 since the 48-bit MAC addresses in these three Address Sets all share the same OUI (the IANA OUI [RFC7042]), you could've just used a MAC/24 value giving the lower 24 bits of the MAC in each Address Set. then the OUI would get supplied by a second Fixed Address sub-sub-TLV that provides 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's no net savings 😭 but with more Address Sets, there is a net savings 🔥
Acknowledgments
the authors thank these lovely people for their contributions and review 🫶
- Linda Dunbar
- Sue Hares
- Paul Kyzivat
- Danny McPherson
- 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📦 where this page comes from
- ietf: rfc7961 2016-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms