RFC 2909
The Multicast Address-Set Claim (MASC) Protocol
Part 1 of 12 🎀
The Multicast Address-Set Claim (MASC) Protocol ✨
okay bestie, RFC 2909 is here and the title block has all the tea 🫶
- Network Working Group: the group that published it
- Number: RFC 2909
- Category: Experimental 🧪
- Date: September 2000 📅
- Authors: P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, and D. Thaler 💅
- Affiliations: USC/ISI for Radoslavov, Estrin, Govindan, and Kumar, ACIRI for Handley, and Microsoft for Thaler 🏫
- Obsoletes / Updates: the title block doesn't list any RFCs being obsoleted or updated 🙅♀️
Status of this Memo 📜
So this memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested, so bring your ideas 💬 Distribution of this memo is unlimited 📮
Copyright Notice ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🦋
So this doc describes MASC, the Multicast Address-Set Claim protocol, which is used for inter-domain multicast address set allocation. MASC is how a node (usually a router) claims and allocates one or more address prefixes for its domain. A domain doesn't have to allocate an address set so its hosts can allocate group addresses, but doing it does make sure inter-domain group-specific distribution trees are locally-rooted, and traffic only leaves the domain when and where external receivers exist. Main character energy 👑
Table of Contents 📑
1 Introduction .................................................. 4
1.1 Terminology ................................................. 4
1.2 Definitions ................................................. 4
2 Requirements for Inter-Domain Address Allocation .............. 5
3 Overall Architecture .......................................... 5
3.1 Claim-Collide vs. Query-Response Rationale .................. 6
4 MASC Topology ................................................. 6
4.1 Managed vs Locally-Allocated Space .......................... 8
4.2 Prefix Lifetime ............................................. 8
4.3 Active vs. Deprecated Prefixes .............................. 9
4.4 Multi-Parent Sibling-to-Sibling and Internal Peering ........ 9
4.5 Administratively-Scoped Address Allocation .................. 9
5 Protocol Details .............................................. 10
5.1 Claiming Space .............................................. 10
5.1.1 Claim Comparison Function ................................. 12
5.2 Renewing an Existing Claim .................................. 12
5.3 Expanding an Existing Prefix ................................ 12
5.4 Releasing Allocated Space ................................... 13
6 Constants ..................................................... 13
7 Message Formats ............................................... 14
7.1 Message Header Format ....................................... 14
7.2 OPEN Message Format ......................................... 15
7.3 UPDATE Message Format ....................................... 17
7.4 KEEPALIVE Message Format .................................... 21
7.5 NOTIFICATION Message Format ................................. 21
8 MASC Error Handling ........................................... 24
8.1 Message Header Error Handling ............................... 24
8.2 OPEN Message Error Handling ................................. 25
8.3 UPDATE Message Error Handling ............................... 26
8.4 Hold Timer Expired Error Handling ........................... 28
8.5 Finite State Machine Error Handling ......................... 28
8.6 NOTIFICATION Message Error Handling ......................... 28
8.7 Cease ....................................................... 29
8.8 Connection Collision Detection .............................. 29
9 MASC Version Negotiation ...................................... 30
10 MASC Finite State Machine .................................... 30
10.1 Open/Close MASC Connection FSM ............................. 31
11 UPDATE Message Processing .................................... 35
11.1 Accept/Reject an UPDATE .................................... 36
11.2 PREFIX_IN_USE Message Processing ........................... 38
11.2.1 PREFIX_IN_USE by PARENT .................................. 38
11.2.2 PREFIX_IN_USE by SIBLING ................................. 38
11.2.3 PREFIX_IN_USE by CHILD ................................... 38
11.2.4 PREFIX_IN_USE by INTERNAL_PEER ........................... 38
11.3 CLAIM_DENIED Message Processing ............................ 39
11.3.1 CLAIM_DENIED by CHILD or SIBLING ......................... 39
11.3.2 CLAIM_DENIED by INTERNAL_PEER ............................ 39
11.3.3 CLAIM_DENIED by PARENT ................................... 39
11.4 CLAIM_TO_EXPAND Message Processing ......................... 39
11.4.1 CLAIM_TO_EXPAND by PARENT ................................ 39
11.4.2 CLAIM_TO_EXPAND by SIBLING ............................... 40
11.4.3 CLAIM_TO_EXPAND by CHILD ................................. 40
11.4.4 CLAIM_TO_EXPAND by INTERNAL_PEER ......................... 40
11.5 NEW_CLAIM Message Processing ............................... 41
11.6 PREFIX_MANAGED Message Processing. ........................ 41
11.6.1 PREFIX_MANAGED by PARENT ................................. 41
11.6.2 PREFIX_MANAGED by CHILD or SIBLING ....................... 41
11.6.3 PREFIX_MANAGED by INTERNAL_PEER .......................... 41
11.7 WITHDRAW Message Processing ................................ 42
11.7.1 WITHDRAW by CHILD ........................................ 42
11.7.2 WITHDRAW by SIBLING ...................................... 42
11.7.3 WITHDRAW by INTERNAL ..................................... 42
11.7.4 WITHDRAW by PARENT ....................................... 43
11.8 UPDATE Message Ordering .................................... 43
11.8.1 Parent to Child .......................................... 43
11.8.2 Child to Parent .......................................... 44
11.8.3 Sibling to Sibling ....................................... 44
11.8.4 Internal to Internal ..................................... 44
12 Operational Considerations ................................... 45
12.1 Bootup Operations .......................................... 45
12.2 Leaf and Non-leaf MASC Domain Operation .................... 45
12.3 Clock Skew Workaround ...................................... 45
12.4 Clash Resolving Mechanism .................................. 46
12.5 Changing Network Providers ................................. 47
12.6 Debugging .................................................. 47
12.6.1 Prefix-to-Domain Lookup .................................. 47
12.6.2 Domain-to-Prefix Lookup .................................. 47
13 MASC Storage ................................................. 47
14 Security Considerations ...................................... 48
15 IANA Considerations .......................................... 48
16 Acknowledgments .............................................. 48
17 APPENDIX A: Sample Algorithms ................................ 49
17.1 Claim Size and Prefix Selection Algorithm .................. 49
17.1.1 Prefix Expansion ......................................... 49
17.1.2 Reducing Allocation Latency .............................. 50
17.1.3 Address Space Utilization ................................ 50
17.1.4 Prefix Selection After Increase of Demand ................ 50
17.1.5 Prefix Selection After Decrease of Demand ................ 51
17.1.6 Lifetime Extension Algorithm ............................. 51
18 APPENDIX B: Strawman Deployment .............................. 51
19 Authors' Addresses ........................................... 52
20 References ................................................... 54
21 Full Copyright Statement ..................................... 561. Introduction ✨
okay so this document describes MASC, a protocol for inter-domain multicast address set allocation 🌸 MASC is a Layer-3 protocol in the multicast address allocation architecture [MALLOC], and a node (typically a router) uses it to claim and allocate one or more address prefixes for that node's domain. Each prefix has an associated lifetime and is picked out of a larger prefix whose lifetime is at least as long, in a way that keeps prefixes aggregatable 🧩 At any time, each MASC node (a Prefix Coordinator in [MALLOC]) will typically advertise several prefixes with different lifetimes and scopes. That lets Multicast Address Allocation Servers (MAAS's) in that domain or in child MASC domains pick the right addresses for their clients 💖
The set of prefixes ("address set") for a domain gets injected into an inter-domain routing protocol (e.g., BGP4+ [MBGP]). From there, an inter-domain multicast tree construction protocol (e.g., BGMP [BGMP]) can use it to build inter-domain group-shared trees 🌳
👀 Note: a domain doesn't need an address set for its hosts to allocate group addresses, and allocating one doesn't guarantee that hosts in other domains won't use an address in the set. For example, hosts aren't forced to contact a MAAS before using a group address. Allocating an address set to a domain does, however, make sure inter-domain group-specific multicast distribution trees for any group in the address set are locally-rooted, and that traffic only goes outside the given domain when and where external receivers exist 🦋
1.1. Terminology
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 RFC 2119 [RFC2119]. these are the BCP 14 vibes, iykyk 📚
Constants used by this protocol are shown as [NAME_OF_CONSTANT], and they're summarized in Section 6 🔢
1.2. Definitions
this spec uses a bunch of terms that might not be familiar to you 🧁 This section defines some of them and points you to other documents for the rest.
MAAS (Multicast Address Allocation Server)
a host providing multicast address allocation services to end users (e.g. via MADCAP [MADCAP]) 🧚
MASC server
a node running MASC 💜
Peer
other MASC speakers a node directly communicates with 🫶
Multicast
IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6 in [RFC2460] 🌈
Multicast Address
an IP multicast address or group address, as defined in [RFC1112] and [RFC2373]. it's an identifier for a group of nodes 🔥
2. Requirements for Inter-Domain Address Allocation ✨
okay so the key design requirements for the inter-domain address allocation mechanism are a whole vibe 💅
- Efficient address space utilization when space is scare 🥺, which naturally means address allocations should be based on the actual address usage patterns, and therefore it should be dynamic 🔥
- Address aggregation, which means the address allocation mechanism should be hierarchical 🌈
- Minimize flux in the allocated address sets (e.g. the address sets should be reused when possible) 🦋
- Robustness, by using decentralized mechanisms 🫶
the timeliness in obtaining an address set is not a major design constraint bc it's taken care of at a lower level [MALLOC] 🧚
3. Overall Architecture
okay bestie, the Multicast Address Set Claim (MASC) protocol is what MASC domains use to claim and allocate address sets for use by Multicast Address Allocation Servers (MAASs) within each domain 🎀 Typically one or more border routers of each domain that needs multicast address space of its own would run MASC. Throughout this document, the term "MASC domain" refers to a domain that has at least one node running MASC, and typically these domains will be Autonomous Systems (AS's) 💖
so a MASC node (on behalf of its domain) picks an address set to claim, sends a claim to other MASC domains in the network, and then waits while listening for any colliding claims 👀 If there's a collision, the losing claimer gives up the colliding claim and claims a different address set. no drama, just move on 💅
after a sufficiently long collision-free waiting period, the address set the MASC node picked is considered allocated to that node's domain ✨ Three things may then happen:
a) The allocated prefix can then be injected as a "multicast route" into the inter-domain routing protocol (e.g., BGP4+ [MBGP]) as "G-RIB" Network Layer Reachability Information (NLRI) 🌸, where it may be used by an inter-domain multicast routing protocol (e.g., BGMP [BGMP]) to construct group-shared trees 🌳. To reduce the size and slow the growth of the G-RIB, MASC nodes may perform CIDR-like aggregation [CIDR] of the multicast NLRI information. This is why we need an algorithm that picks prefixes for domains in a way that ensures good aggregation, on top of getting good address space utilization 🧠
b) The node's domain may assign to itself a sub-prefix which can be used by MAASs within the domain 🍓
c) Sub-prefixes may be allocated to child domains, if any 🫧
3.1. Claim-Collide vs. Query-Response Rationale
okay so why claim-collide and not query-response?? 🤔 We choose a claim-collide mechanism instead of a query-response mechanism for the following reasons. In a query-response mechanism, replicas of the MASC node would be needed in parent MASC domains so their responses can be robust to failures 🙃. That brings along the problem of synchronizing the replicas, and possibly additional fragmentation of the address space 💀. Plus, even in this mechanism, address collisions would still need to be handled. The proposed claim-collide mechanism is believed to be simpler and more robust than a query-response mechanism, and honestly that's giving main character energy ✨
4. MASC Topology
the domain hierarchy used by MASC is congruent to the somewhat hierarchical structure of the inter-domain topology 🌈, e.g., backbones connected to regionals, regionals connected to metropolitan providers, etc. Just like BGP, MASC connections are locally configured. A MASC domain that is a customer of other MASC domains will have one or more of those provider domains as its parent. For example, a MASC domain that is a regional provider will choose one (or more) of its backbone provider domains as its parent(s). Children are configured with their parent MASC domain, and parents are configured with their children domains. At the top, a number of Top-Level Domains are connected in a (sparse) mesh and share the global multicast address space 👑. To improve the robustness, a pair of children of the same parent domain MAY be configured as siblings with regard to that parent 🫶
Figure 1 illustrates a sample topology. Double-line links denote intra-domain TCP peering sessions, and single-line links denote inter-domain TCP connections 🦋. T1 and T2 are Top-Level Domains (e.g., backbone providers), containing MASC speakers T1a and T2a, respectively. P3 and P4 are regional domains, containing (P3a, P3b), and (P4a, P4b) respectively. P3 has a single customer (or "child"), C5, containing (C5a, C5b, C5c). P4 has three children, C5, C6, C7, containing (C5a, C5b, C5c), (C6a, C6b), and (C7a) respectively.
T1a-----------T2a
| |
| |
| |
P3a====P3b P4a====P4b
| | / | / | \
| | _______/ | / | \
| | / | / | \______
| | / | / | \
C5a====C5b C6a====C6b----------C7a
\\ //
\\//
C5cFigure 1: Example MASC Topology 🌸
All MASC communications use TCP. Each MASC node is connected to and communicates directly with other MASC nodes. The local node acts in exactly one of the following four roles with respect to each remote note 🧚:
INTERNAL_PEER: The local and remote nodes are both in the same MASC domain. For example, P4b is an INTERNAL_PEER of P4a.CHILD: A customer relationship exists whereby the local node may obtain address space from the remote node. For example, C6a is a CHILD in its session with P4a.PARENT: A provider relationship exists whereby the remote node may obtain address space from the local node. For example, T2a is a PARENT in its session with P4a. Whether space is actually requested is up to the implementation and local policy configuration 🤷♀️SIBLING: No customer-provider relationship exists. For example, T2a is a SIBLING in its session with T1a (Top-Level Domain SIBLING peering). Also, C6b is a SIBLING in its session with C7a with regard to their common parent P4.
a node's message will be propagated to its parent, all siblings with the same parent, and its children 📣. Since a domain doesn't need a direct peering session with every sibling, a MASC domain must propagate messages from a child domain to other children, can propagate messages from a parent domain to other siblings, and, if it's a Top-Level Domain, it must propagate messages from a sibling to other siblings. Otherwise it may propagate messages from a sibling domain to its parent and other siblings 🔥
4.1. Managed vs Locally-Allocated Space
so each domain has a "Managed" Address Set and a "Locally-Allocated" Address Set 🍰. The "managed" space includes all address space which a domain has successfully claimed via MASC. The "locally-allocated" space, on the other hand, includes all address space which MAASs inside the domain may use. Thus, the locally-allocated space is a subset of the managed space, and refers to the portion which a domain allocates for its own use 🫧.
For leaf domains (ones with no children), these two sets are identical, since all claimed space is allocated for local use 🌷. A parent domain, on the other hand, "manages" all address space which it has claimed via MASC, while sub-prefixes can be allocated to itself and to its children 💜
4.2. Prefix Lifetime
every prefix has an associated lifetime ⏳. If a domain wants to use a prefix longer than its lifetime, that domain must "renew" the prefix BEFORE its lifetime expires (see Section 5.2). If the lifetime cannot be extended, then the domain should either retry later to extend, or should choose and claim another prefix 🔄.
After a prefix's lifetime expires, MASC nodes in the domain that own that prefix must stop using that prefix 🛑. The corresponding entry from the G-RIB database must be removed, and all information associated with the expired prefix may be deleted from the MASC node's local memory 🧹.
the lifetime thing is lowkey the most important part, so don't skip it, bestie 💀
4.3. Active vs. Deprecated Prefixes
each prefix advertised by a parent to its children can be either "active" or "deprecated" 🌈. A "deprecated" prefix is a prefix that the parent wishes to discontinue using after its lifetime expires. The "active" prefixes are the only candidates for size expansion or lifetime extension. Usually, a child will use this information as a hint to know which of the parent's prefixes might have their lifetime extended 🦋.
4.4. Multi-Parent Sibling-to-Sibling and Internal Peering
two sibling nodes that have more than one common parent will create and use between them a number of transport-level connections, one per each common parent 🧦. The information associated with a parent will be sent over the connection that corresponds to the same parent. Internal peers do not need to open multiple connections between them; a single connection is used for all information 🫶
4.5. Administratively-Scoped Address Allocation
MASC can also be used for sub-allocating prefixes of addresses within an administrative scope zone [SCOPE], but only if the scope is "divisible" (as described in [MALLOC] and [MZAP]) 🌸. A MASC node can learn what scopes it resides within by listening to MZAP [MZAP] messages 👂.
a "Zone TLD" is a domain which has no parent domain within the scope zone 👑. Zone TLDs act as TLDs for the prefix associated with the scope. Figure 2 gives an example, where a scope boundary around domains P3 and C5 has been added to Figure 1. Domain P3 is a Zone TLD, since its only parent (T1) is outside the boundary. Hence, P3 can claim space directly out of the prefix associated with the scope itself 🙌. Domain C5, on the other hand, has a parent within the scope (namely, P3), and hence is not a Zone TLD.
T1a-----------T2a
| |
............|....... |
. | . |
. P3a====P3b . P4a
. | | . /
. | | _______/
. | | / .
. | | / .
. C5a====C5b .
. \\ // .
. \\// .
. C5c .
. .
. Admin Scope Zone .
....................Figure 2: Scope Zone Example 🧚
it is assumed that the role of a node (as discussed in Section 4) with respect to a given peering session is the same for every scope in which both ends are contained 🫧. A peering session that crosses a scope boundary (such as the session between C5b and P4a in Figure 2) is ignored when propagating messages that pertain to the given scope. That is, such messages are not sent across such sessions 🚫
5. Protocol Details ✨
5.1. Claiming Space 💅
okay so when a MASC node is acting for its MASC domain and realizes it needs more address space 🥺, it gets to decide locally how big the prefix(es) should be and which address prefix to claim from one of its parents. Its call, bestie ✨. It might look at what it knows about its parent's address set, its siblings' claims and allocations, its own address set, the claim messages its siblings send, and/or the demand from its children and the local domain. There's a sample algorithm in Appendix A if you want to peek 👀.
A MASC node that is not in a top-level domain can initiate a claim toward a parent MASC domain if and only if it currently has an established connection with at least one node in that parent domain. No connection, no claim 🙅♀️
Once the prefix address and size are decided, the claim goes like this:
a) The claim gets scheduled to go out after a random delay somewhere in the interval (0, [INITIATE_CLAIM_DELAY]). If a claim from a node in the same MASC domain shows up and that claim removes the need for the local one, the local claim gets canceled and that's the end of it 🫶
b) The claim gets sent to one of the parents (if the domain is not a top-level domain), to all known siblings with the same parent, and to all internal peers. Then a Claim-Timer starts at [WAITING_PERIOD], and the node starts listening for colliding claims 👂
c) If a colliding claim comes in while the Claim-Timer is running, it gets compared with the locally initiated claim using the function described in Section 5.1.1. If the local claim is the loser, a new prefix must be chosen to claim, and the loser claim's Claim-Timer must be canceled. The loser claim can either be explicitly withdrawn, or be left to expire without taking further actions. If the winning claim was originated by a node from the same MASC domain, no new claim will be initiated. If the local claim is the winner, no actions need to be taken 🏆
d) If the Claim-Timer expires, the claimed prefix becomes associated with the claimer's domain. That means it's considered allocated to that domain, and the following actions can be performed:
- Advertise the prefix to its parent, and to all siblings with the same parent, by sending a PREFIX_IN_USE claim to them.
- Inject the prefix into the G-RIB of the inter-domain routing protocol.
- Send a PREFIX_MANAGED message to all children and internal peers, informing them that they may issue claims within the managed space. A sub-prefix may then be claimed for local usage (see Section 12.2).
Each MASC node receives all claims from its siblings and children. A received claim must be evaluated against all claims saved in the local cache using the function described in Section 5.1.1. The output of that function will define the further processing of that claim (see Section 11). 🌸
5.1.1. Claim Comparison Function 🔍
Each claim message includes:
- a "type", being one of: PREFIX_IN_USE, CLAIM_DENIED, CLAIM_TO_EXPAND, or NEW_CLAIM (PREFIX_MANAGED and WITHDRAW are not considered as claims that have to be compared)
- timestamp when the claim was initiated
- the claimed prefix and lifetime
- MASC Identifier of the node that originated the claim
When two claims get compared, the type is checked first, using this precedence: PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM.
If the types are the same, the timestamps decide it. In practice, two claims share a type when it's NEW_CLAIM (an ordinary collision) or PREFIX_IN_USE (a signal for a clash). When timestamps get compared, the claim with the smallest, i.e. earliest, timestamp wins. If the timestamps are the same, the claim with the smallest Origin Node Identifier wins 🥇
5.2. Renewing an Existing Claim 🔁
Extending the lifetime of prefixes that are already in use works the same way as claiming new space (see Section 5.1), with two twists. The claim type must be CLAIM_TO_EXPAND, and the Address and the Mask of the claim (see Section 7.3) must be the same as the prefix that's already allocated. If the Claim-Timer expires and there is no collision, the desired lifetime is assumed 🎀
5.3. Expanding an Existing Prefix 🌈
Same vibe as the renewal: extending a prefix that's already in use works like claiming new space (see Section 5.1). The difference is that the claim type must be CLAIM_TO_EXPAND, and the Address and the Mask of the claim (see Section 7.3) must be set to the desired values. If the Claim-Timer expires and there is no collision, the desired larger prefix becomes associated with the local domain 📈
5.4. Releasing Allocated Space 🦋
If the lifetime of a prefix allocated to the local domain expires and the domain does not need to reuse it, all resources associated with this prefix are deleted and no further actions are taken. If the lifetime hasn't expired yet, and no subranges of that prefix have been allocated for local usage or by any of the children domains, the space may be released by sending a withdraw message to the parent domain, all known siblings with the same parent, and all internal peers. Bye bye, space 👋
6. Constants 🎀
MASC uses the following constants:
[PORT_NUMBER]: 2587. The TCP port number used to listen for incoming MASC connections, as assigned by IANA.[WAITING_PERIOD]: The amount of time (in seconds) that must pass between a NEW_CLAIM (or CLAIM_TO_EXPAND), and a PREFIX_IN_USE for the same prefix. This must be long enough to reasonably span any single inter-domain network partition. Default: 172800 seconds (i.e. 48 hours).[INITIATE_CLAIM_DELAY]: The amount of time (in seconds) a MASC node must wait before initiating a new claim or a claim for space expansion. This must be a random value in the interval (0, [INITIATE_CLAIM_DELAY]). Default value for [INITIATE_CLAIM_DELAY]: 600 seconds (i.e. 10 minutes).[TLD_ID]: The Parent Domain Identifier used by a Top-Level Domain (which has no parent). Must be 0.[HOLDTIME]: The amount of time (in seconds) that must pass without any messages received from a remote node before considering the connection is down. Default: 240 seconds (i.e. 4 minutes).
7. Message Formats 📨
This section is where we get into what MASC messages actually look like 👀
Messages are sent over a reliable transport protocol connection. A message is processed only after it is entirely received. The maximum message size is 4096 octets. All implementations are required to support this maximum message size.
7.1. Message Header Format 🧚
Each message has a fixed-size (4-octets) header. There may or may not be a data portion following the header, depending on the message type. The layout of these fields is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, e.g., it allows one to locate in the transport-level stream the start of the next message. The value of the Length field must always be at least 4 and no greater than 4096, and may be further constrained, depending on the message type. No "padding" of extra data after the message is allowed, so the Length field must have the smallest value required given the rest of the message.Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVEReserved: This 1-octet field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver. 🙈
7.2. OPEN Message Format ✨
okay bestie, so once a transport protocol connection is established, the very first message each side sends is an OPEN message 💖 If the OPEN message is acceptable, a KEEPALIVE gets sent back to confirm it 🫶 Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged ✨
The minimum length of the OPEN message is 20 octets (including message header). On top of the fixed-size MASC header, the OPEN message carries these fields 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |R| AddrFam |Rol| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MASC Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent's Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version: This 1-octet unsigned integer indicates the protocol version number of the message. The current MASC version number is 1. 🦋
R bit: This 1-bit field is reserved. MUST be set to zero by the sender, and MUST be ignored by the receiver. 🙈
AddrFam: This 5-bit field is the IANA-assigned address family number of the encoded prefix [IANA]. These include (among others):
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)My Role (Rol): This 2-bit field indicates the proposed relationship of the sending system to the receiving system:
00 = INTERNAL_PEER (sent from one internal peer to another)01 = CHILD (sent from a child to its parent)10 = SIBLING (sent from one sibling to another)11 = PARENT (sent from a parent to its child)
Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, a MASC speaker MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time for that peer and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation may reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages by the sender. RECOMMENDED value is [HOLDTIME] seconds. ⏰
Sender Domain Identifier: A globally unique identifier. Its length is determined based on the Address Family, and should be treated as an unsigned integer (e.g. a 4-octet integer for IPv4, or a 16-octet integer for IPv6), but must be at least 4 octets long. It should be set to the Autonomous System number of the sender, but the network unicast prefix address is also acceptable. 👑
Sender MASC Node Identifier: This field's length and format are same as the Sender Domain Identifier field, and indicates the MASC Node Identifier of the sender. A given MASC speaker sets the value of its MASC Node Identifier to a globally-unique value assigned to that MASC speaker (e.g., an IPv4 or IPv6 address). The value of the MASC Node Identifier is determined on startup and is the same for every MASC session opened. 🌈
Parent's Domain Identifier: This field's length and format are same as the Sender Domain Identifier field, and is set to the Domain Identifier of the sender's parent (e.g. the parent's Autonomous System number, or network prefix address), or is set to [TLD_ID] if the sender is a TLD. Used only when Rol is INTERNAL_PEER or SIBLING, otherwise is ignored. This field is used to determine the common parents between siblings, to associate each sibling-to-sibling connection with a particular parent, and to discover TLD-related configuration problems among internal peers. If a non-TLD node does not know yet the Domain ID of any of its parents, it can use its own Domain ID in the OPEN messages to its internal peers. 🧚
Optional Parameters: This field may contain a list of optional parameters, where each parameter is encoded as a <Parameter Length, Parameter Type, Parameter Value> triplet. The combined length of all optional parameters can be derived from the Length field in the message header.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Length | Parm. Type | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...Parameter Length is a one octet field that contains the length of the Parameter Value field in octets. Parameter Type is a one octet field that unambiguously identifies individual parameters. Parameter Value is a variable length field that is interpreted according to the value of the Parameter Type field. Unrecognized optional parameters MUST be silently ignored. 🫶
This document does not define any optional parameters. 💅
7.3. UPDATE Message Format ✨
okay so UPDATE messages are how MASC speakers pass Claim/Collision/PrefixManaged info between each other 💌 every UPDATE always has the fixed-size MASC header plus one or more attributes, and the smallest one you can send is 40 octets (header included) 🎀
Each attribute looks like this 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+All attributes are 4-octets aligned 🧚
- Length: this is the length of the whole attribute, so the length, type, and data fields all count. If other attributes are nested inside the data field, the length covers all of those nested ones too 💅
- Type: a 1-octet unsigned integer that tells you the type code of the attribute 🔥 these are the codes that are defined:
0 = PREFIX_IN_USE (prefix is being used by the origin)
1 = CLAIM_DENIED (the claim is refused (probably by the
origin's parent domain))
2 = CLAIM_TO_EXPAND (origin is trying to expand the size of
an existing prefix)
3 = NEW_CLAIM (origin is trying to claim a new prefix)
4 = PREFIX_MANAGED (parent is informing child of space
available)
5 = WITHDRAW (origin is withdrawing a previous claim)Types 128-255 are saved for "optional" attributes 🌈 if you hit a required attribute you don't recognize, a NOTIFICATION with UPDATE Error Code and Unrecognized Required Attribute subcode will be sent 😭 unrecognized optional attributes just get ignored, no drama 🫶
- Reserved: this 1-octet field is reserved. It MUST be set to zero by the sender, and MUST be ignored by the receiver 🌸
Types 0-3 are collectively called "CLAIMs" 🦋 the message format below describes how a CLAIM, PREFIX_MANAGED and WITHDRAW get encoded:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 |D| AddrFam |Rol| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Reserved1: this 1-octet field is reserved. It MUST be set to zero by the sender, and MUST be ignored by the receiver 🍓
- D-bit: the DEPRECATED_PREFIX bit 💜 if it's set, the advertised address prefix is Deprecated. Otherwise the prefix is Active (see Section 4.3) ✨
- AddrFam: this 5-bit field is the IANA-assigned address family number of the encoded prefix [IANA] 🌈
- Rol: this 2-bit field tells you the relationship/role of the Origin of the message to the node that sent it 👑 the values are:
00 = INTERNAL (originated by the sender's domain)
01 = CHILD (originated by a child of the sender's domain)
10 = SIBLING (originated by a sibling of the sender's domain)
11 = PARENT (originated by a parent of the sender's domain)- Reserved2: this 2-octet field is reserved. It MUST be set to zero by the sender, and MUST be ignored by the receiver 🫧
- Claim Timestamp: the timestamp of the claim when it was originated ⏰ it's counted in seconds since midnight (0 hour), January 1, 1970, Greenwich 🌍
- Claim Lifetime: the time in seconds between the Claim Timestamp and the moment the prefix becomes free 🦋
- Claim Holdtime: the time in seconds between the Claim Timestamp and the moment the claim should be deleted from the local cache 🙈 for PREFIX_IN_USE and PREFIX_MANAGED claims it should be equal to Claim Lifetime. For CLAIM_TO_EXPAND, NEW_CLAIM, and CLAIM_DENIED it should be equal to [WAITING_PERIOD] 💖
- Origin Domain Identifier: the domain identifier of the claim originator 🧚 its length and format are the same as the Sender Domain Identifier (see Section 7.2) 🎀
- Origin Node Identifier: the MASC Node ID of the claim originator 🌸 its length and format are the same as the Sender MASC Node Identifier (see Section 7.2) 💅
- Address: the address associated with the given prefix that's being encoded 🔥 the length depends on the Address Family (e.g. 4 octets for IPv4, 16 for IPv6) 🌐
- Mask: the mask associated with the given prefix 🎀 its length is the same as the Address field and is determined by the Address Family. The field contains the full bitmask 💜
- Optional Parameters: this field may hold a list of optional parameters, where each one is encoded in the same format as the optional parameters of an OPEN message (see Section 7.2) ✨ unrecognized optional parameters MUST be silently ignored 🫶 this document doesn't define any optional parameters, so it's a pretty chill field rn 🌙
7.4. KEEPALIVE Message Format 💗
okay this one's giving simplicity 💅 MASC doesn't use any transport protocol-based keep-alive mechanism to check whether peers are reachable 🙅♀️ instead, KEEPALIVE messages get swapped between peers often enough that the Hold Timer never expires ⏳ a reasonable maximum time between the last KEEPALIVE or UPDATE message sent and the moment the next KEEPALIVE is sent would be one third of the Hold Time interval 🧁 KEEPALIVE messages MUST NOT be sent more frequently than one per second ⚡ an implementation MAY adjust how often it sends KEEPALIVE messages as a function of the Hold Time interval 🦄
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent 🙈
A KEEPALIVE message is just a message header, nothing else, and it has a length of 4 octets 🫧 so small, so iconic 🥹
7.5. NOTIFICATION Message Format 🚨
okay so a NOTIFICATION message gets sent whenever an error condition is detected 😭. Depending on the error, the MASC connection might or must be closed right after the message goes out. If the sender decides the connection is closing, it says so by zeroing the O-bit in the NOTIFICATION message (more on that below) 💀.
In addition to the fixed-size MASC header, the NOTIFICATION message has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+O-bit (Open-bit) 🔓: if it's zero, the sender will close the connection. If it's '1', the sender has chosen to keep the connection open 🌸.
Error Code 🎀: this 7-bit unsigned integer tells you what type of NOTIFICATION it is. These Error Codes have been defined:
Error Code Symbolic Name Reference
1 Message Header Error Section 8.1
2 OPEN Message Error Section 8.2
3 UPDATE Message Error Section 8.3
4 Hold Timer Expired Section 8.4
5 Finite State Machine Error Section 8.5
6 NOTIFICATION Message Error Section 8.6
7 Cease Section 8.7Error subcode 💅: this 1-octet unsigned integer gives more specific info about what went wrong. Each Error Code can have one or more Error Subcodes attached. If there's no appropriate Error Subcode defined, a zero (Unspecific) value is used for the Error Subcode field, and the O-bit must be zero (aka the connection will be closed). The notation in the error descriptions below is: MC = Must Close connection = O-bit is zero; CC = Can Close connection = O-bit might be zero ✨.
Message Header Error subcodes:
0 - Unspecific (MC)
1 - Bad Message Length (MC)
2 - Bad Message Type (CC)
OPEN Message Error subcodes:
0 - Unspecific (MC)
1 - Unsupported Version Number (MC)
2 - Bad Peer Domain ID (MC)
3 - Bad Peer MASC Node ID (MC)
6 - Unacceptable Hold Time (MC)
7 - Invalid Parent Configuration (MC)
8 - Inconsistent Role (MC)
9 - Bad Parent Domain ID (MC)
10 - No Common Parent (MC)
13 - Unrecognized Address Family (MC)
UPDATE Message Error subcodes:
0 - Unspecific (MC)
1 - Malformed Attribute List (MC)
2 - Unrecognized Required Attribute (CC)
5 - Attribute Length Error (MC)
10 - Invalid Address field (CC)
11 - Invalid Mask field (CC)
12 - Non-Contiguous Mask (CC)
13 - Unrecognized Address Family (MC)
14 - Claim Type Error (CC)
15 - Origin Domain ID Error (CC)
16 - Origin Node ID Error (CC)
17 - Claim Lifetime Too Short (CC)
18 - Claim Lifetime Too Long (CC)
19 - Claim Timestamp Too Old (CC)
20 - Claim Timestamp Too New (CC)
21 - Claim Prefix Size Too Small (CC)
22 - Claim Prefix Size Too Large (CC)
23 - Illegal Origin Role Error (CC)
24 - No Appropriate Parent Prefix (CC)
25 - No Appropriate Child Prefix (CC)
26 - No Appropriate Internal Prefix (CC)
27 - No Appropriate Sibling Prefix (CC)
28 - Claim Holdtime Too Short (CC)
29 - Claim Holdtime Too Long (CC)
Hold Timer Expired subcodes (the O-bit is always zero):
0 - Unspecific (MC)
Finite State Machine Error subcodes:
0 - Unspecific (MC)
1 - Open/Close MASC Connection FSM Error (MC)
2 - Unexpected Message Type FSM Error (MC)
Cease subcodes (the O-bit is always zero):
0 - Unspecific (MC)
NOTIFICATION subcodes (the O-bit is always zero):
0 - Unspecific (MC)Data 🧁: this variable-length field is there to help diagnose why the NOTIFICATION was sent. What's inside the Data field depends on the Error Code and Error Subcode. See Section 8 for more details 🫶.
Also, the length of the Data field can be worked out from the message Length field with this formula:
Message Length = 6 + Data LengthThe minimum length of the NOTIFICATION message is 6 octets (including the message header) ✨.
8. MASC Error Handling ✨
okay this section is all about what to do when things go sideways while processing MASC messages 🥺. MASC Error Handling is pretty similar to that of BGP [BGP], so if you know BGP you're already halfway there 💜.
When any of the conditions described here are detected, a NOTIFICATION message goes out with the indicated Error Code, Error Subcode, and Data fields. On top of that, the MASC connection might be closed. If no Error Subcode is specified, then a zero (Unspecific) must be used 🙈.
"The MASC connection is closed" means the transport protocol connection has been closed and all the resources for that MASC connection have been deallocated 🌈.
Unless it's specified explicitly, the Data field of the NOTIFICATION message is empty 🍓.
8.1. Message Header Error Handling 🎀
All errors found while processing the Message Header get indicated by sending a NOTIFICATION message with Error Code Message Header Error. The Error Subcode spells out the specific nature of the error, and the Data field holds the erroneous Message (including the message header) 🧚.
If the Length field of the message header is less than 4 or greater than 4096, or if the length of an OPEN message is less than the minimum length of the OPEN message, or if the length of an UPDATE message is less than the minimum length of the UPDATE message, or if the length of a KEEPALIVE message is not equal to 4, then the Error Subcode is set to Bad Message Length 📏.
If the Type field of the message header isn't recognized, then the Error Subcode is set to Bad Message Type 🤷♀️.
8.2. OPEN Message Error Handling 🌸
All errors found while processing the OPEN message get indicated by sending a NOTIFICATION message with Error Code OPEN Message Error. The Error Subcode says exactly what went wrong. The Data field contains the erroneous OPEN Message (excluding the Message Header), unless stated otherwise 👑.
If the version number in the Version field of the received OPEN message isn't supported, then the Error Subcode is set to Unsupported Version Number. The Data field is a 1-octet unsigned integer, which indicates the largest locally supported version number that's less than the version the remote MASC node bid (as shown in the received OPEN message) 🦋.
If the Sender Domain Identifier field of the OPEN message is unacceptable, then the Error Subcode is set to Bad Peer Domain ID. Figuring out which Domain IDs are acceptable is outside the scope of this protocol 🌍.
If the Sender MASC Node Identifier field of the OPEN message is unacceptable, then the Error Subcode is set to Bad Peer MASC Node ID. Figuring out which Node IDs are acceptable is also outside the scope of this protocol 🫠.
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Unacceptable Hold Time. An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation that accepts a Hold Time MUST use the negotiated value for the Hold Time ⏰.
If the remote system's proposed Role is INTERNAL_PEER, and either (but not both) the local system or the remote system's Parent Domain ID is [TLD_ID], then the Error Subcode is set to Invalid Parent Configuration. The Data field must be filled with all the local system's Parent Domain IDs 🧩.
If the remote system's proposed Role conflicts with its expected role (based on the local system's configured Role), then the Error Subcode is set to Inconsistent Role. The Data field is 1-octet long and contains the local system's configured Role 🥴.
If the remote system's Parent Domain ID is unacceptable, then the Error Subcode is set to Bad Parent Domain ID, and the Data field is filled with the erroneous Parent Domain ID. Figuring out which Parent Domain IDs are acceptable is outside the scope of this protocol 🙅♀️.
If the remote system is supposed to be a sibling, but it doesn't have a common parent with the local system (based on the Parent Domain ID information in the OPEN message), the Error Subcode is set to No Common Parent, and the Data field is filled with all Parent Domain IDs of the local MASC domain 👯♀️.
If the Address Family is unrecognized, then the Error Subcode is set to Unrecognized Address Family 💀.
8.3. UPDATE Message Error Handling ✨
okay so every UPDATE message error gets reported with a NOTIFICATION message, Error Code UPDATE Message Error 💌 and the subcode tells you which kind of oops it was. the Data field holds the erroneous UPDATE Message (attribute header included, Message Header excluded) unless it says otherwise 🫶
if a recognized attribute has an Attribute Length that doesn't match what its type code expects, the subcode is Attribute Length Error 📏
if any mandatory well-known attributes aren't recognized, the subcode is Unrecognized Required Attribute 🙅♀️
if the Address field has an invalid address (except 0), the subcode is Invalid Address 🗺️
if the Mask field has an invalid mask (like one that starts with 0), the subcode is Invalid Mask 🎭
if the Mask field is non-contiguous and that MASC server doesn't support it or isn't configured for non-contiguous masks, the subcode is Non-Contiguous Mask 🧩
if the Address Family is unrecognized, the subcode is Unrecognized Address Family 🌈
if the Origin Role/Claim Type combo isn't one of these, the subcode is Claim Type Error 💀
Origin Claim
Role Type
ICS PREFIX_IN_USE (0)
I P CLAIM_DENIED (1)
ICS CLAIM_TO_EXPAND (2)
ICS NEW_CLAIM (3)
I P PREFIX_MANAGED (4)
ICSP WITHDRAW (5)if there's reason to believe the Origin Domain ID is invalid, the subcode is Origin Domain ID Error. same vibe for Origin Node ID, which gets Origin Node ID Error 🆔
if a node (usually a parent getting a claim from a child) decides the Claim Lifetime is too short (like less than 172800, i.e. 48 hours), it MAY send an UPDATE Message Error with subcode Claim Lifetime Too Short ⏳
if that same node decides the Claim Lifetime is too long (like more than 15,768,000, i.e. half a year), it MAY send an UPDATE Message Error with subcode Claim Lifetime Too Long 🕰️ ngl the glow-up move here is that a parent should usually send CLAIM_DENIED collision messages first, with the Claim Lifetime field filled with the longest acceptable lifetime. if the child refuses to claim with a shorter lifetime, THEN Claim Lifetime Too Long should be sent 💅
if that node decides the Claim Timestamp is too small (too old, like when it's super confident its own clock is accurate), it MUST send an UPDATE Message Error with subcode Claim Timestamp Too Old ⏪ Claim Timestamp Too New is defined the same way 🔮
if the prefix size implied by the Mask field is too small (like smaller than 16 addresses), it MAY send an UPDATE Message Error with subcode Claim Prefix Size Too Small 🔍
if the prefix size implied by the Mask field is too large, it MAY send an UPDATE Message Error with subcode Claim Prefix Size Too Large 🐘 same energy as before: a parent usually should send CLAIM_DENIED collision messages for some subrange of the child's big claimed range first. if the child won't shrink the claim, then Claim Prefix Size Too Large should be sent 🫠
if the computed Updated Origin Role of the received UPDATE is illegal (see Table 1 in Section 11.1), the subcode is Illegal Origin Role Error 🚫
if the received UPDATE needs to be associated with a parent's prefix but the association doesn't work out, the subcode is No Appropriate Parent Prefix 🙈 No Appropriate Child Prefix, No Appropriate Internal Prefix, and No Appropriate Sibling Prefix Error Subcodes are defined similarly 🧚
if a node decides the Claim Holdtime is too short (like just a few seconds), it MAY send an UPDATE Message Error with subcode Claim Holdtime Too Short ⚡
if a node decides the Claim Holdtime is too long (like more than 15,768,000, i.e. half a year), then it SHOULD send an UPDATE Message Error with subcode Claim Holdtime Too Long 🥱
if any other error shows up while processing attributes, the subcode is Malformed Attribute List, and the erratic attribute goes in the data field 🗑️
8.4. Hold Timer Expired Error Handling ⏰
if a system doesn't get successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages within the period in the Hold Time field of the OPEN message, then it must send a NOTIFICATION message with Hold Timer Expired Error Code and close the MASC connection 📴 no more waiting around, bestie 😤
8.5. Finite State Machine Error Handling 🌀
any error the MASC Finite State Machine detects (like getting an unexpected event) gets reported by sending a NOTIFICATION message with Error Code Finite State Machine Error 🎢 the Error Subcode tells you the specific flavor of the mess 💋
8.6. NOTIFICATION Message Error Handling 📨
okay this one is a whole plot twist 😭 if a node sends a NOTIFICATION message, there's an error in that message, and the O-bit of that message isn't zero, then a NOTIFICATION with the O-bit zeroed, Error Code of NOTIFICATION Error, and subcode Unspecific must be sent. the Data field must also include the erratic NOTIFICATION message 🫣
but if the erratic NOTIFICATION message already had the O-bit zeroed, then any error (like an unrecognized Error Code or Error Subcode) should be noticed, logged locally, and brought to the attention of the administrator of the remote node 📣 how that actually happens is outside the scope of this document, so that's a problem for another day 🫶
8.7. Cease 🚪
if there are no fatal errors (the ones listed in this section), a MASC node may choose at any time to close its MASC connection by sending a NOTIFICATION message with Error Code Cease 👋 however, the Cease NOTIFICATION message must not be used when a fatal error from this section does exist 🛑 that's a hard no, babe
8.8. Connection Collision Detection 💥
if a pair of MASC speakers try to set up a TCP connection to each other at the exact same time, two parallel connections between them might totally form. that's called a connection collision 😵💫 obviously one of those has to go. if the nodes were siblings and each connection was tied to a different parent, then it doesn't count as a collision (see Section 4.4) 🤝
there's a convention based on the MASC Node Identifier for figuring out which connection to keep. you compare the MASC Node Identifiers of the remote nodes involved and keep only the connection started by the MASC speaker with the higher-valued MASC Node Identifier 👑
when a local system gets an OPEN message, it has to check all of its connections that are in the OpenConfirm state. a MASC speaker may also check connections in an OpenSent state if it knows the remote node's MASC Node Identifier from outside the protocol 🕵️♀️ if any of those connections goes to a remote MASC speaker whose MASC Node Identifier equals the one in the OPEN message (and, for sibling-to-sibling connections, its Parent Domain ID equals the one in the OPEN message), then the local system runs this collision resolution procedure:
- The MASC Node Identifier of the local system is compared to the MASC Node Identifier of the remote system (as given in the OPEN message). Comparing them means treating them as unsigned integers (for example, 4 octets long for IPv4 and 16 octets long for IPv6) 🔢
- If the local MASC Node Identifier is less than the remote one, the local system closes the MASC connection that already exists (the one already in the OpenConfirm state) and accepts the MASC connection the remote system started 🙌
- Otherwise, the local system closes the newly created MASC connection (the one tied to the newly received OPEN message) and keeps using the existing one (the one already in the OpenConfirm state) 💁♀️
a collision with an existing MASC connection in the Established state means the newly created connection gets closed, no questions asked 🚫 also, a connection collision can't be detected with connections in the Idle, Connect, or Active states (see Section 10) 🫥
closing the MASC connection that comes out of the collision resolution procedure is done by sending a NOTIFICATION message with the Error Code Cease 💌
9. MASC Version Negotiation 🎀
MASC speakers can negotiate the protocol version by making several attempts to open a MASC connection, starting with the highest version number each one supports 🪜 if an open attempt fails with Error Code OPEN Message Error and Error Subcode Unsupported Version Number, then the MASC speaker has the version number it tried, the version number the remote node tried, the version number the remote node passed back in the NOTIFICATION message, and the version numbers it supports 📋 if the two speakers support one or more versions in common, this lets them quickly figure out the highest common version 🏆 and to make MASC version negotiation work, future versions of MASC must keep the format of the OPEN and NOTIFICATION messages 🔒 that's the whole trick, bestie 💖
10. MASC Finite State Machine 🧠
this section specifies how MASC operates in terms of a Finite State Machine (FSM) 🎰 the FSM and the operations are about the peer peering session. here's a quick summary and overview of MASC operations by state, as this FSM determines them 🌸
initially, the peering session is in the Idle state 🌙
10.1. Open/Close MASC Connection FSM ✨
Idle state 💤
Okay bestie, in Idle MASC refuses every incoming MASC connection from the peer 🙅♀️, and it doesn't allocate any resources to the remote node. When the Start event shows up (whether the system or an operator triggers it), the local system initializes all its MASC resources, starts the ConnectRetry timer, and dials out to the remote node over a transport connection. While that's happening it also listens for the remote MASC node to call first. Then it moves to Connect. The exact value of the ConnectRetry timer is a local decision, but it should be big enough for TCP to finish initializing 🧦.
If a MASC speaker detects an error, it shuts the connection down and goes back to Idle. To get out of Idle you need a Start event. If those Start events get generated automatically, persistent MASC errors could cause persistent flapping of the speaker 🙃. To avoid that drama, it is recommended that Start events should not be generated immediately for a node that was dropped into Idle because of an error. For such a node, the time between consecutive automatic Start events (if they are automatic) shall increase exponentially. The initial timer value shall be 60 seconds. The time doubles with each consecutive retry, but it shall not go past 24 hours.
Any other event received in Idle just gets ignored 🫶.
Connect state 🔌
In Connect, MASC is waiting for the transport protocol connection to complete.
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, finishes initialization, sends an OPEN message to the remote node, and changes its state to OpenSent 🎉. If the transport protocol connect fails (for example, a retransmission timeout), the local system restarts the ConnectRetry timer, keeps listening for a connection the remote MASC node might start, and changes its state to Active 😬.
When the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, initiates a transport connection to the other MASC node, keeps listening for a connection the remote MASC node might start, and stays in Connect 🔁.
The Start event is ignored in Connect. 🙈
In response to any other event (from either the system or an operator), the local system releases all MASC resources tied to this connection and changes its state to Idle 💔.
Active state 👂
In Active, MASC is trying to acquire a remote node by listening for a transport protocol connection that the remote node initiates.
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, finishes initialization, sends an OPEN message to the remote node, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of [HOLDTIME] seconds is suggested 🌸.
When the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, initiates a transport connection to the other MASC node, keeps listening for a connection the remote MASC node might start, and changes its state to Connect.
If the local system notices that a remote node is trying to set up a MASC connection with it, and that remote node's IP address is not an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, keeps listening for a connection the remote MASC node might start, and stays in Active 🚫.
The Start event is ignored in Active. 🙅♀️
In response to any other event (from either the system or an operator), the local system releases all MASC resources tied to this connection and changes its state to Idle.
OpenSent state 📨
In OpenSent, MASC waits for an OPEN message from the remote node. When one arrives, every field gets checked for correctness. If the MASC message header checking or the OPEN message checking detects an error (see Section 8.2), or if there's a connection collision (see Section 8.8), the local system sends a NOTIFICATION message. If the connection is going to be closed, it also changes its state to Idle 😤.
If the locally configured role is SIBLING and there is no parent domain whose Domain ID equals the Parent Domain ID in the OPEN message, the local system sends a NOTIFICATION Open Message Error with Error Subcode set to No Common Parent. The connection must be closed, and the local system's state must be changed to Idle 🚪.
If there are no errors in the OPEN message, MASC sends a KEEPALIVE message and sets a KeepAlive timer ✅. The Hold Timer, which had been set to a large value (see above), is replaced with the negotiated Hold Time value (see Section 7.2). If the negotiated Hold Time value is zero, then the Hold Time timer and the KeepAlive timer are not started. If the MASC Domain ID field matches the local MASC Domain ID, and the Role field of the OPEN message is set to INTERNAL_PEER, then the connection is an "internal" connection. Otherwise it's "external" 🏠. Finally, the state changes to OpenConfirm.
If a disconnect notification comes in from the underlying transport protocol, the local system closes the MASC connection, restarts the ConnectRetry timer, keeps listening for a connection the remote MASC node might start, and goes into Active 🥀.
If the Hold Timer expires, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle ⏰.
In response to the Stop event (from either the system or an operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle 🛑.
The Start event is ignored in OpenSent. 🙈
In response to any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Open/Close MASC Connection FSM Error, and changes its state to Idle 💥.
Whenever MASC changes its state from OpenSent to Idle, it closes the MASC (and transport-level) connection and releases all resources associated with that connection 🧹.
OpenConfirm state 🤝
In OpenConfirm, MASC waits for a KEEPALIVE or NOTIFICATION message.
If the local system receives a KEEPALIVE message, it changes its state to Established 🥳.
If the Hold Timer expires before a KEEPALIVE message is received, the local system sends a NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle ⏰.
If the local system receives a NOTIFICATION message with the O-bit zeroed, it changes its state to Idle 😭.
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer 💓.
If a disconnect notification comes in from the underlying transport protocol, the local system changes its state to Idle 🔌.
In response to the Stop event (from either the system or an operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle 🛑.
The Start event is ignored in OpenConfirm. 🙈
In response to any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and Error Subcode Unspecific, and changes its state to Idle 💀.
Whenever MASC changes its state from OpenConfirm to Idle, it closes the MASC (and transport-level) connection and releases all resources associated with that connection 🧹.
Established state 🌈
In Established, MASC can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with the remote node. This is the main event 👑.
If the local system receives an UPDATE message, a KEEPALIVE message, or a NOTIFICATION message with the O-bit set, it restarts its Hold Timer, as long as the negotiated Hold Time value is non-zero ⏱️.
If the local system receives a NOTIFICATION message with the O-bit zeroed, it changes its state to Idle 😭.
If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 8.3) detects an error, the local system sends a NOTIFICATION message. If the O-bit was zeroed, it also changes its state to Idle 🚨.
If a disconnect notification comes in from the underlying transport protocol, the local system changes its state to Idle 🔌.
If the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle ⏰.
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer 💓.
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero 🔁.
In response to the Stop event (from either the system or an operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle 🛑.
The Start event is ignored in Established. 🙈
After entering Established, if the local system has UPDATE messages to send to the remote node, they must be sent immediately (see Section 11.8) 🚀.
In response to any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error, with the O-bit zeroed and Error Subcode Unspecific, and changes its state to Idle 💥.
Whenever MASC changes its state from Established to Idle, it closes the MASC (and transport-level) connection, releases all resources associated with that connection, and deletes all state derived from that connection 🧹✨.
11. UPDATE Message Processing ✨
UPDATE messages are accepted only when the system is in the Established state 💌.
In the text below, a MASC domain is treated as a child of itself for claims related to address space with local usage purpose (that is, space to be used by the MAASs within that domain). For example, a NEW_CLAIM that a MASC node starts to obtain more space for local usage from a prefix managed by that domain will have the field Role = CHILD 🧸.
If an UPDATE is to be propagated further, it should not be sent back to the node the UPDATE was received from, unless there is an indication that the connection to that node went down and was then restored 🔄.
If the local system receives an UPDATE message and there is no indication of an error, it checks whether to accept or reject the message. If the message is not rejected, the UPDATE is processed based on its type 🧠.
If an UPDATE message must be associated with a parent domain, then there must be a PREFIX_MANAGED by some parent domain for a prefix that covers the prefix of that UPDATE 🌳.
11.1. Accept/Reject an UPDATE 💅
okay so first thing every UPDATE gets is a role check 👀 The Origin Role field gets compared against your local configured Role using Table 1, which tells you how the origin relates to you. Locally-Configured Role just means your own config, from the point of view of whoever forwarded the message to you. If the table says ---, that UPDATE is illegal and should generate a NOTIFICATION 🙅♀️ Any other result is the Origin Role you use as the "Updated" value when you pass the UPDATE along. It's basically like bumping a metric when you learn a route, based on the link's metric 🧚
Locally-Configured Role
Origin
Role || INTERNAL_PEER | CHILD | SIBLING | PARENT
=========++===============+=========+=========+=========
INTERNAL || INTERNAL_PEER | PARENT | SIBLING | CHILD
CHILD || CHILD | SIBLING | --- | ---
SIBLING || SIBLING | --- | SIBLING | CHILD
PARENT || PARENT | --- | PARENT | ---
Table 1: Updated Origin Role ComputationAfter you've updated the Origin Role, there are three extra checks you need to run 🔍
- The first one: if the Updated Origin Role computed from the table is SIBLING, but the Origin Domain ID matches your local MASC domain, you change the Updated Origin Role to INTERNAL. This is needed in case a MASC node gets its own UPDATEs back from a parent or sibling after a reboot, or because of internal partitioning, when INTERNAL_PEERs are swapping UPDATEs through other MASC domains (a parent or siblings) 🫶
- The second one: if both the Locally-Configured Role and the Origin Role are PARENT, and the Origin Domain ID matches your local MASC domain, you change the Updated Origin Role to INTERNAL. This lets a parent receive its own UPDATEs through its own children. The parent might still drop them if it has a reason not to trust its children 🌸
- The third one: if both the Locally-Configured Role and the Origin Role are PARENT, the Origin Domain ID matches the remote MASC domain, and the UPDATE type is
CLAIM_DENIED, you change the Updated Origin Role to INTERNAL. This lets a parent get back theCLAIM_DENIEDit originated, through the child whose claim got denied. If the Origin Domain ID is not the remote MASC domain but matches some of the other MASC children domains, the Updated Origin Role still should be changed to INTERNAL. The parent might drop that UPDATE if it has a reason not to trust a third-party child 🤔
If the Updated Origin Role is INTERNAL, but the Origin Domain ID is different from the local Domain ID, a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> must be sent back, and the claim is rejected 🚫
If Claim Timestamp and Claim Holdtime show the claim has expired (e.g. Timestamp + Claim Holdtime <= CurrentTime), the UPDATE is silently dropped and you take no further actions 👻
Every new arriving UPDATE gets compared with all the claims in your local cache. These fields get compared, and if every single one matches, the message is silently rejected and nothing else happens 🙈
- Role, D-bit, Type
- AddrFam
- Claim Timestamp
- Claim Lifetime
- Claim Holdtime
- Origin Domain Identifier
- Origin Node Identifier
- Address
- Mask
Anything past that depends on the UPDATE's type and the Updated Origin Role ✨
11.2. PREFIX_IN_USE Message Processing 🌈
11.2.1. PREFIX_IN_USE by PARENT
The claim gets rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back 🙅♀️
11.2.2. PREFIX_IN_USE by SIBLING
If the claim can't be associated with any of the parent's PREFIX_MANAGED, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back, and no further actions should be taken 💀
If the claim collides with some of the local domain's pending claims, you stop considering the local claims, and you must cancel the Claim-Timer of each of them. If the received PREFIX_IN_USE claim clashes with and wins over some of the local domain's allocated prefixes, resolve the clash according to Section 12.4 🥊 Finally, the claim must be propagated further to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain, and all known siblings with the same parent domain 🦋
11.2.3. PREFIX_IN_USE by CHILD
If the claim's prefix is not a subrange of any of the local domain's PREFIX_MANAGED, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back, and no further actions should be taken. Otherwise, the claim must be propagated further to all INTERNAL_PEERs and all MASC children domains 🍓
11.2.4. PREFIX_IN_USE by INTERNAL_PEER
If the MASC node decides the local domain doesn't need that prefix any more, it may be withdrawn. Otherwise, the claim is processed as PREFIX_MANAGED 🧹
11.3. CLAIM_DENIED Message Processing 💜
11.3.1. CLAIM_DENIED by CHILD or SIBLING
The message gets rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back 🙅♀️
11.3.2. CLAIM_DENIED by INTERNAL_PEER
Propagate it to all INTERNAL_PEERs and all MASC children nodes 📣
11.3.3. CLAIM_DENIED by PARENT
If the Origin Domain ID is not the same as the local domain ID, and the UPDATE can't be associated with any parent domain, the message gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back, and no further actions should be taken 😭
If the Origin Domain ID is not the same as the local domain ID, and the UPDATE can be associated with a parent domain, the message is propagated to all nodes from that parent domain, all INTERNAL_PEERs, and all known SIBLINGs with regard to that parent 🌐
If the Origin Domain ID is the same as the local domain ID, and there's no matching pending claim originated by the local MASC domain (i.e. a NEW_CLAIM or CLAIM_TO_EXPAND with the same AddrFam, Origin Domain ID, Claim Timestamp, Address and Mask), a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back, and no further actions should be taken. Otherwise, the matching NEW_CLAIM or CLAIM_TO_EXPAND's Claim-Timer must be canceled and the claim must not be considered further. Finally, the received CLAIM_DENIED must be propagated to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain, and all known SIBLINGs with regard to that parent ✨
11.4. CLAIM_TO_EXPAND Message Processing 🎀
11.4.1. CLAIM_TO_EXPAND by PARENT
The claim gets rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back 🙅♀️
11.4.2. CLAIM_TO_EXPAND by SIBLING
If the claim can't be associated with any of the parent's PREFIX_MANAGED, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back, and no further actions should be taken 💀
If there's no overlapping PREFIX_IN_USE by the same MASC domain, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix> must be sent back, and no further actions should be taken 🫠
If the claim collides with and wins over some of the local domain's pending claims, the losing claims must not be considered further, and you must cancel the Claim-Timer of each of them. The received claim must also be propagated further to all INTERNAL_PEERs, all MASC nodes from the corresponding parent MASC domain, and all known siblings with the same parent domain 🥇
11.4.3. CLAIM_TO_EXPAND by CHILD
If the claim can't be associated with any of the local domain's PREFIX_MANAGED, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back, and no further actions should be taken 💅
If there's no overlapping PREFIX_IN_USE by the same MASC domain, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix> must be sent back, and no further actions should be taken 🙈
Otherwise, the claim has to be propagated to all INTERNAL_PEERs. If the claim's lifetime is longer than the lifetime of the corresponding prefix managed by the local domain, or if there's an administratively configured reason to stop the child from successfully allocating the claimed prefix, a CLAIM_DENIED must be sent to all MASC children nodes that have the same Domain ID as the Origin Domain ID in the received message. The CLAIM_DENIED must be the same as the received claim, except Rol=INTERNAL, and Claim Lifetime should be set to the maximum allowed lifetime. Otherwise, propagate the claim to all children as well 🧚
11.4.4. CLAIM_TO_EXPAND by INTERNAL_PEER
If the claim can't be associated with any parent's PREFIX_MANAGED, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> must be sent back, and no further action should be taken 🙃
If there's no overlapping PREFIX_IN_USE by the local MASC domain, the claim gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> must be sent back, and no further actions should be taken 😤
If the MASC node decides the local domain doesn't need that pending claim any more, it MAY be withdrawn. Otherwise, the claim must be propagated to all INTERNAL_PEERs and all MASC nodes from the corresponding parent MASC domain 🌷
11.5. NEW_CLAIM Message Processing 🌟
If the claim's Address field is 0 (i.e. a hint from a child to a parent to get more space), the claim should be propagated only among the nodes that belong to the child Origin Domain and the parent domain 🐣
Otherwise, process it like a CLAIM_TO_EXPAND, except that no check for overlapping PREFIX_IN_USE needs to be performed 🔁
11.6. PREFIX_MANAGED Message Processing. 🍑
11.6.1. PREFIX_MANAGED by PARENT
If the Origin Domain ID matches one of the parents' domain IDs, the prefix is recorded and can be used by the address allocation algorithm for allocating subranges. The message is also propagated to all MASC nodes of the corresponding parent domain, all INTERNAL_PEERs, and SIBLINGs with the same parent 📬
11.6.2. PREFIX_MANAGED by CHILD or SIBLING
The message gets rejected, and a NOTIFICATION of <UPDATE Message Error, Illegal Origin Role> should be sent back 🙅♀️
11.6.3. PREFIX_MANAGED by INTERNAL_PEER
The prefix is recorded as allocated to the local domain and propagated to all INTERNAL_PEERs. It can be used for (all items apply):
- a) address ranges/prefixes advertisements to all MASC children and local domain's MAASs;
- b) injection into G-RIB;
- c) further expansion by the address allocation algorithm (see Appendix A);
11.7. WITHDRAW Message Processing 🦢
11.7.1. WITHDRAW by CHILD
If the WITHDRAW can't be associated with any of the child domain's PREFIX_IN_USE (i.e. no child's PREFIX_IN_USE covers the WITHDRAW's range), or if the WITHDRAW doesn't match any of the child domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there's no child's claim with the same Address, Mask and Timestamp), the message gets dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix> must be sent back, and no further actions should be taken. Otherwise, propagate it to all INTERNAL_PEERs and children 🎉
11.7.2. WITHDRAW by SIBLING 💅
Okay so bestie, if a WITHDRAW can't be linked to any of the siblings' PREFIX_IN_USE (meaning no sibling's PREFIX_IN_USE covers the WITHDRAW's range), or it doesn't match any of the sibling domain's NEW_CLAIM or CLAIM_TO_EXPAND (meaning there's no sibling claim with the same Address, Mask and Timestamp), it's getting dropped 🙅♀️ A NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix> MUST be sent back, and no further actions SHOULD be taken. Otherwise, it gets passed along to all INTERNAL_PEERs, all MASC nodes from the same parent MASC domain, and all known siblings with the same parent domain ✨
11.7.3. WITHDRAW by INTERNAL 🫶
Same energy here, but with more checks 🧐 If the WITHDRAW can't be linked to any of the local domain's PREFIX_IN_USE or PREFIX_MANAGED (no local prefix covers the WITHDRAW's range), or it doesn't match any of the local domain's NEW_CLAIM or CLAIM_TO_EXPAND (no local claim with the same Address, Mask and Timestamp), the message is dropped. A NOTIFICATION of <UPDATE Message Error, No Appropriate Internal Prefix> MUST be sent back, and no further actions SHOULD be taken.
Otherwise, it propagates to all INTERNAL_PEERs, all MASC nodes of the corresponding parent domain of that prefix, all known siblings with that parent domain, and all children. If the WITHDRAW can be linked to some of the local domain's PREFIX_IN_USE or PREFIX_MANAGED, stop advertising the WITHDRAW range to the MAASs and withdraw that range from the G-RIB database.
Now the special case 🦋 When there's an indication that the WITHDRAW was originated by the local domain because of a clash, the range in the WITHDRAW is a subrange of the local PREFIX_MANAGED, and the Claim Holdtime of the WITHDRAW is shorter than the Claim Holdtime of PREFIX_MANAGED, the WITHDRAW's range SHOULD NOT be withdrawn from the G-RIB. And if the WITHDRAW matches a local domain's NEW_CLAIM or CLAIM_TO_EXPAND, cancel that matching claim's Claim-Timer ⏰
11.7.4. WITHDRAW by PARENT 👑
If the WITHDRAW can't be linked to any parent domain, a NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix> MUST be sent back, and no further actions SHOULD be taken.
Otherwise, it goes out to all INTERNAL_PEERs and all known siblings with the same parent domain. Also, you originate a WITHDRAW message for each overlap between a locally owned PREFIX_MANAGED/PREFIX_IN_USE and the received WITHDRAW 🌸 The locally originated WITHDRAW's Claim Holdtime SHOULD be at least equal to the Claim Holdtime in the WITHDRAW received from the parent, and the Origin Node ID SHOULD be the same as the particular PREFIX_MANAGED/PREFIX_IN_USE.
11.8. UPDATE Message Ordering 🍓
Okay, so to keep things consistent and make implementations easier to sanity check 🧠 when more than one UPDATE needs to go to a peer (for example, right after a connection is (re)established), some UPDATEs MUST be sent before others.
These rules always apply:
PREFIX_IN_USEMUST always be sent BEFORECLAIM_TO_EXPAND,NEW_CLAIM, and WITHDRAW by the same MASC domain- WITHDRAW MUST always be sent AFTER
PREFIX_IN_USE,CLAIM_TO_EXPAND,NEW_CLAIM, andPREFIX_MANAGEDby the same MASC domain
Any further ordering is defined below, based on the roles of the sender and the receiver 💖
11.8.1. Parent to Child 🧚
Messages go out in this order:
- Parent's
PREFIX_MANAGEDand WITHDRAWs. - All children's
PREFIX_IN_USE,CLAIM_TO_EXPAND, andNEW_CLAIMs. CLAIMs from third-party children that are just hints for more space (address = 0) SHOULD NOT be propagated. If they are propagated, the child SHOULD drop them. - Parent-initiated
CLAIM_DENIEDand child-initiated WITHDRAWs. ACLAIM_DENIEDabout third-party children's claims or hints with address = 0 SHOULD NOT be propagated. If it is propagated, the child SHOULD drop it.
11.8.2. Child to Parent 🎀
Messages go out in this order:
- Parent's
PREFIX_MANAGEDand WITHDRAWs. - All
PREFIX_IN_USE,CLAIM_TO_EXPAND, andNEW_CLAIMs from that parent's space, initiated by that child and all of its siblings. - Parent-initiated
CLAIM_DENIED, and all WITHDRAWs that can be linked to that parent's space and are initiated by the local domain or by all known siblings with that parent.
11.8.3. Sibling to Sibling 🌈
Messages go out in this order:
- All common parent's
PREFIX_MANAGEDand WITHDRAWs. PREFIX_IN_USE,CLAIM_TO_EXPAND, andNEW_CLAIMs, initiated by siblings.CLAIM_DENIEDs initiated by the common parent, and WITHDRAWs initiated by the local domain and all known siblings with that parent.
11.8.4. Internal to Internal 💜
Messages go out in this order:
- All parents'
PREFIX_MANAGEDand WITHDRAWs. - The local domain's and all siblings'
PREFIX_IN_USE,CLAIM_TO_EXPAND, andNEW_CLAIMs. CLAIMs from siblings that are just hints for more space (address = 0) SHOULD NOT be propagated. If they are propagated, the recipient SHOULD drop them. CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by the local domain and all known siblings.- All children's
PREFIX_IN_USE,CLAIM_TO_EXPAND, andNEW_CLAIMs. - All
CLAIM_DENIEDs initiated by the local domain about children's claims, and all WITHDRAWs initiated by children.
12. Operational Considerations 🌟
12.1. Bootup Operations ⚡
To learn about its parent domains' IDs and prefixes, a MASC node SHOULD try to establish connections to its PARENT nodes before it starts a connection to a SIBLING node. To avoid learning about its own PREFIX_MANAGED from its children or siblings, a MASC node SHOULD try to establish connections to its PARENT nodes and INTERNAL_PEER nodes before it starts a connection to a CHILD or SIBLING node 🙈
12.2. Leaf and Non-leaf MASC Domain Operation 🌳
A non-leaf MASC domain (that is, a domain that has children domains) SHOULD advertise its PREFIX_MANAGED addresses to its children, and SHOULD claim the sub-ranges from that space that would be advertised to the internal MAASs (the claim wait time SHOULD be equal to [WAITING_PERIOD]). A MASC node in a non-leaf MASC domain SHOULD perform dual functions, acting as a child of itself when it comes to claiming and managing the sub-ranges for local usage 🙌
A leaf MASC domain SHOULD advertise all PREFIX_MANAGED addresses to its MAASs without explicitly claiming them for internal usage. A MASC node can assume it belongs to a leaf domain if it simply doesn't have any UPDATEs from child domains. If an UPDATE from a child is received, the domain MUST switch from "leaf" to "non-leaf" mode, and if it needs more addresses for internal usage, it MUST claim them from that domain's PREFIX_MANAGED. After the last UPDATE originated by a child expires, the domain can switch back to "leaf" mode 🍃
12.3. Clock Skew Workaround 🕰️
Each UPDATE has a Claim Timestamp field that's set to the absolute time of the MASC node that originated that UPDATE. The timestamp does two jobs: it resolves collisions, and it defines how long an UPDATE SHOULD be kept in the local cache of other MASC nodes. Clock skew could lead to unfair collision decisions, where claims from nodes with clocks behind real time always win. But because collisions are presumably rare, this won't be a big deal 🤷♀️ Skew can also cause an UPDATE to expire earlier than it really should, so a node might assume too early that the expired UPDATE or prefix is free for allocation 😬 To make up for clock skew, an UPDATE message SHOULD be kept longer than the time specified in the Claim Holdtime. For example, keeping UPDATEs for an extra 24 hours compensates for clock skew of up to 24 hours ⏳
12.4. Clash Resolving Mechanism ⚔️
If a MASC node receives a PREFIX_IN_USE claim originated by a sibling and that claim overlaps with some of the local prefixes, the clash MUST be resolved. Two MASC domains SHOULD NOT manage overlapping address ranges, unless the domains have an ancestor-descendant (for example, parent-child) relationship in the MASC hierarchy. Also, two MASC domains SHOULD NOT have locally-allocated overlapping address ranges. The clashed address ranges SHOULD NOT be advertised to the MAASs and allocated to multicast applications or sessions. If a clashed address has been allocated to an application, the application SHOULD be informed to stop using that address and switch to a new one 🚫
The G-RIB database MUST be consistent, so it has no ambiguous entries. "Ambiguous G-RIB entries" are entries that might make the multicast routing protocol loop or lose connectivity 😱 In MASC, the WITHDRAW message is what solves this problem. When a clashing PREFIX_IN_USE comes in, it's compared (using the function described in Section 5.1.1) against all prefixes allocated to the local domain. If the local PREFIX_IN_USE wins, no further actions are taken. If the local PREFIX_IN_USE loses, the clashing address range MUST be withdrawn by initiating a WITHDRAW message. That message MUST have Role = INTERNAL. Its Origin Node ID and Origin Domain ID MUST be the same as the corresponding local PREFIX_IN_USE message, while its Claim Timestamp, Claim Lifetime, Claim Holdtime, Address and Mask MUST be the same as the received winning PREFIX_IN_USE. The initiated WITHDRAW message MUST be processed as described in Section 11.7 ✨
If a cached WITHDRAW times out and the local MASC domain owns an overlapping PREFIX_MANAGED or PREFIX_IN_USE, those overlapping prefix ranges can be injected back into the G-RIB database. Similarly, address ranges that weren't advertised to the local domain's MAASs because of the WITHDRAW can now be advertised again 🔄
On top of automatic clash resolving, a MASC implementation SHOULD support manual clash resolving. For example, after a clash is detected, the network administrator SHOULD be informed that a clash has occurred. The specific manual mechanisms are out of scope for this protocol 🧑💻
A MASC node MUST be configured to operate using either manual or automatic clash resolution mechanisms 🎛️
12.5. Changing Network Providers 🌍
If a MASC domain changes network providers so that the old provider can't be used to provide connectivity, any traffic for sessions that are in progress and use that MASC domain as the root of multicast distribution trees won't be able to reach that domain 😭
If the new network provider is willing to carry traffic for the old sessions rooted at the customer domain, then it MUST propagate the customer's old prefixes through the G-RIB. However, at least one MASC node in the customer domain MUST maintain a TCP connection to one of the old network provider's MASC nodes. That way, it can keep "defending" the customer's prefixes, and SHOULD continue doing so until the old prefixes' lifetimes expire 🛡️
If the new network provider isn't willing to propagate the old prefixes, then the customer SHOULD remove its prefixes from the G-RIB. If BGMP is in use, the old network provider's domain will automatically become the Root Domain for the customer's old groups, since there's no more specific group route. MASC nodes in the customer domain MAY still connect with the old provider's MASC nodes to defend their allocation 🦋
12.6. Debugging 🐞
12.6.1. Prefix-to-Domain Lookup 🔍
okay so if you want to know which BGMP/MASC root domain owns a group address, just use mtrace [MTRACE] on a group address picked from that prefix. ✨
12.6.2. Domain-to-Prefix Lookup 🗺️
bestie, there are a few ways to figure out what address space a MASC domain got. you can directly ask one of the MASC servers inside that domain, or you can peek at the state in its parents, siblings, or children, or check out the G-RIB info that domain originated. 💅 the first option gives you the most detailed info, no cap. finding the address of one of the MASC nodes inside a domain is outside the scope of MASC, so that one's not on us 🙈
13. MASC Storage 💾
so MASC is usually run by border routers, and those in general don't have stable storage 😭 which is a whole thing. in this case, MASC must use the Layer 2 protocol/mechanism (e.g., ([AAP])) as described in [MALLOC] to store the important info (the prefixes the local domain allocated) in the domain's MAASs, who should have stable storage. 🫶 if the MASC speaker does have local storage, it should use that instead of the Layer 2 protocol/mechanism. and claims that are still in progress don't have to be saved with the Layer 2 protocol/mechanism. main character energy for real 🌸
14. Security Considerations 🛡️
okay this part is SERIOUS, bestie 😭 IPsec [IPSEC] can be used to address security concerns between two MASC peering nodes. however, UPDATE messages are store-and-forward, so if a non-trustworthy MASC node can connect to some point in the MASC topology, that node can undetectably inject malicious UPDATEs that may mess with the normal operation of other MASC nodes. 💀 to deal with this, each MASC node should allow peering only with trustworthy nodes. no bad vibes allowed 🚫
after a reboot, a MASC node/domain can restore its state from its neighbors (internal peers, parents, siblings, children) 🔄 typically, the state received from a parent or internal peer will be trustworthy, but a node may choose to drop its own UPDATEs that were received through a sibling or a child. that's a valid choice, iykyk 🦋
a misbehaving node may try a Denial of Service attack by sending a large number of colliding messages that would stop any of its siblings from allocating more addresses. 😤 a single mis-behaving node can easily be spotted by all of its siblings, and then all of its UPDATEs can be ignored. the multiple-origin-address version of this attack can be prevented if a third-party UPDATE (e.g. from a non-directly connected sibling) is accepted only when it's sent via the common parent domain. and the MASC nodes in the parent domain accept children UPDATEs only if they come via an internal peer, or come directly from a child node that is the same as the Origin Node ID. 👑 very strict, very iconic.
15. IANA Considerations 📋
this document defines several number spaces: MASC message types, MASC OPEN message optional parameters types, MASC UPDATE message attribute types, MASC UPDATE message optional parameters types, and MASC NOTIFICATION message error codes and subcodes. 🌈 for all of these, certain values are defined in this spec. new values may only be defined by IETF Consensus, as described in [IANA-CONSIDERATIONS]. basically that means they get defined by RFCs approved by the IESG. ✨
16. Acknowledgments 🫶
the authors would like to thank the participants of the IETF for their help with this protocol. so sweet 🥹💖
17. APPENDIX A: Sample Algorithms 🧮
DISCLAIMER: this section describes some preliminary suggestions by various people for algorithms which could be used with MASC. it's not finalized, so don't treat it like gospel 🙈
17.1. Claim Size and Prefix Selection Algorithm 🎯
this section covers the algorithms a MASC node uses (on behalf of a MASC domain) to satisfy demand for multicast addresses. the allocated addresses should be aggregatable, the address utilization should be reasonably high, and the allocation latency to the MAASs should be shorter than [WAITING_PERIOD] whenever possible. goals, goals, goals 💅
17.1.1. Prefix Expansion 🧩
for ease of implementation and troubleshooting, MASC should use contiguous masks to specify the address ranges, i.e. prefixes. (research says sufficiently good results can be achieved using contiguous masks only ✨) the chosen prefixes should be as expandable as possible. the method for picking the children's sub-prefixes from the parent's prefix is the so-called Reverse Bit Ordering (idea by Dave Thaler; inspired by Kampai [KAMPAI]). 🦋 for example, if the parent's prefix width is four bits, the addresses of the sub-prefixes get picked in this order:
Parent: xxxx
Child A: 0000
Child B: 1000
Child C: 0100
Child D: 1100if some of the children need to expand their sub-prefix, they try to double the corresponding sub-prefix starting from the right:
Child A: 000x
Child A: 00xx
Child D: 110x
Child D: 11xxand so on 🌀
however, because the address ordering is super strict, to reduce the probability of collision, when a new sub-prefix has to be chosen, the choice should be random among all candidates with the same potential for expandability. for example, if the free sub-prefixes are 01xx, 10xx, 110x, then the new prefix to claim should be chosen with a 50% probability for 01xx and 50% for 10xx, for example. 🎲 randomness is the move here
17.1.2. Reducing Allocation Latency ⏩
to reduce allocation latency, a MASC node uses pre-allocation. it constantly monitors the demand for addresses from its children (or MAASs), and predicts what the address usage will be after [WAITING_PERIOD]. only if the available addresses will be used up within [WAITING_PERIOD] does a MASC node claim more addresses in advance. 🔮 predicting the future, but make it networking
17.1.3. Address Space Utilization 📊
because every prefix size is a power of two, if a node tries to allocate just a single prefix, the utilization at that node (i.e. at that node's domain) can be as low as 50%. 😬 to improve utilization, a MASC node can have more than one prefix allocated at a time (typically, each with a different size). by using pre-allocation and allocating several prefixes of different sizes (see below), a MASC node should try to keep its address utilization in the range 70-90%. ✨ sweet spot unlocked
17.1.4. Prefix Selection After Increase of Demand 📈
to reduce allocation latency even more by lowering the probability of collision, and to improve the aggregability of the allocated addresses, a MASC node carefully chooses the prefixes to claim. the first prefix is chosen at random among all reasonably expandable candidates. if a node chooses to allocate another, smaller prefix, then, instead of doubling the size of the first one (which might drop the address utilization a lot), a second "neighbor" prefix is chosen. 👯 for example, if prefix 224.0/16 is already allocated and the MASC domain needs 256 more addresses, the second prefix to claim will be 224.1.0/24. if the domain needs even more addresses, the second prefix will eventually grow to 224.1/16, and then both prefixes can be automatically aggregated into 224.0/15. 🧠 only if 224.0.1/24 could not be allocated will a MASC node choose another prefix (eventually random among the unused prefixes).
if the number of allocated prefixes goes above some threshold, and none of them can be extended when more addresses are needed, then, to reduce the amount of state, a MASC node should claim a new larger prefix and should stop re-claiming the older non-expandable prefixes. 🧹 research results show that up to three prefixes per MASC domain is a reasonable threshold, so the address utilization can be in the range 70-90%, and at the same time the prefix flux will be reasonably low. the math is mathing 🔥
17.1.5. Prefix Selection After Decrease of Demand 📉
if demand for addresses decreases, such that its address space is under-utilized, a MASC node implicitly returns the unused prefixes after their lifetimes expire, or re-claims some smaller sub-prefixes. 🍂 for example, if prefix 224.0/15 is 50% used by the MAASs and/or children MASC domains, and the overall utilization is such that approximately 2^16 (64K) addresses should be returned, a MASC node should stop reclaiming 224.0/15 and should start reclaiming either 224.0/16 or 224.1/16 (whichever sub-prefix has higher utilization). 🧺 downsizing, but make it aesthetic
17.1.6. Lifetime Extension Algorithm ⏳
if demand for addresses did not decrease, then a MASC node re-claims the prefixes it has allocated before their lifetime expires. each prefix (or sub-prefix, if demand has decreased) should be re-claimed every 48 hours. 🔁 renewal season, periodt 💜
18. APPENDIX B: Strawman Deployment 🚀
at the moment of writing, 225.0.0.0-225.255.255.255 is temporarily allocated to MALLOC. 🧪 presumably this block of addresses will be used for experimental deployment and testing.
if MASC were widely deployed on the Internet, we might expect numbers similar to the following:
- Initially will have approximately 128 Top-Level Domains 🌍
- Assume initially approximately 8192 level-2 MASC domains; on average, a TLD will have approximately 64 children domains. 👶
- MASC managed global addresses: 🌐
The following (large) ranges are not allocated yet (2^N represents the size of the contiguous mask prefixes):
225.0.0.0 - 231.255.255.255 = 2^26 + 2^25 + 2^24
234.0.0.0 - 238.255.255.255 = 2^25 + 2^25 + 2^24
---------------------------
Total: 12*2^24 addressesinitially, the range 228.0.0.0 - 231.255.255.255 (4*2^24 = 2^26 = 64M) could be used by MASC as the global address pool. the rest (8*2^24) should be reserved. part of it could be added later to MASC, or it can be used to enlarge the pool of administratively scoped addresses (currently 239.X.X.X), or the pool for static allocation (233.X.X.X). 🤔
- If the multicast addresses are evenly distributed, each TLD would have a maximum of 2^19 (512K) addresses, while each level-2 MASC domain would have 8192 addresses. ⚖️
- Initial claim size: 256 addresses/MASC domain 🐣
- Could use soft and hard thresholds to specify the maximum amount of claimed+allocated addresses per domain. for example, trigger a warning message if claimed+allocated addresses by a domain is >= 1.0*average_assumed_per_domain (a strawman default soft threshold): 🚨
- if a TLD claim+allocation >= 512K
- if a second level MASC domain claim+allocation >= 8K
the hard threshold (for example, 2.0*average_assumed_per_domain) can be enforced by sending an explicit DENIED message. 🛑
the TLD thresholds (with regard to the claims by the second level MASC domains) are a private matter and a part of the particular TLD policy: the thresholds could be per customer, and the warnings to the administrators could be a signal that it's time to change the policy. 🔐
- Initial claim lifetime is of the order of 30 days. prefix lifetime is periodically (every 48 hours) reclaimed/extended, unless the prefix is under-utilized (see APPENDIX A). because allocation is demand-driven, the allocated prefix lifetime will be automatically extended if the MAASs need a longer prefix lifetime (e.g. 3-6 months). ⏰
- A level-2 MASC domain could have children (i.e. level-3) MASC domains. 🌳
- If a level-2 or level-3 MASC domain uses less than 128 addresses, a Layer 2 protocol/mechanism (e.g. AAP) should be run among that domain and its parent MASC domain. 🧃
19. Authors' Addresses ✨
okay bestie, here are the people who wrote this 🫶 the whole crew is from USC/ISI, with one from ACIRI and one from Microsoft 💅
Pavlin Radoslavov
Computer Science Department
University of Southern California/ISI
Los Angeles, CA 90089
USA
EMail: pavlin@catarina.usc.edu
Deborah Estrin
Computer Science Department
University of Southern California/ISI
Los Angeles, CA 90089
USA
EMail: estrin@isi.edu
Ramesh Govindan
University of Southern California/ISI
4676 Admiralty Way
Marina Del Rey, CA 90292
USA
EMail: govindan@isi.edu
Mark Handley
AT&T Center for Internet Research at ISCI (ACIRI)
1947 Center St., Suite 600
Berkeley, CA 94704
USA
EMail: mjh@aciri.org
Satish Kumar
Computer Science Department
University of Southern California/ISI
Los Angeles, CA 90089
USA
EMail: kkumar@usc.edu
David Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
EMail: dthaler@microsoft.com20. References 📚
these are all the docs this one leans on, so you can go read the receipts 🤓 every single entry is listed below, exactly as written
[AAP] Handley, M. and S. Hanna, "Multicast Address
Allocation Protocol (AAP)", Work in Progress.
[API] Finlayson, R., "An Abstract API for Multicast
Address Allocation", RFC 2771, February 2000.
[BGMP] Thaler, D., Estrin, D. and D. Meyer, "Border
Gateway Multicast Protocol (BGMP): Protocol
Specification", Work in Progress.
[BGP] Rekhter, Y. and T. Li, "A Border Gateway
Protocol 4 (BGP-4)", RFC 1771, March 1995.
[CIDR] Rekhter, Y. and C. Topolcic, "Exchanging
Routing Information Across Provider Boundaries
in the CIDR Environment", RFC 1520, September
1993.
[IANA] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[IPSEC] Kent, S. and R. Atkinson, "Security
Architecture for the Internet Protocol", RFC
2401, November 1998.
[KAMPAI] Tsuchiya, P., "Efficient and Flexible
Hierarchical Address Assignment", INET92, June
1992, pp. 441--450.
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast
Address Dynamic Client Allocation Protocol
(MADCAP)", RFC 2730, December 1999.
[MALLOC] Thaler, D., Handley, M. and D. Estrin, "The
Internet Multicast Address Allocation
Architecture", RFC 2908, September 2000.
[MBGP] Bates, T., Chandra, R., Katz, D. and Y.
Rekhter, "Multiprotocol Extensions for BGP-4",
RFC 2283, September 1997.
[MTRACE] Fenner, W., and S. Casner, "A `traceroute'
facility for IP Multicast", Work in Progress.
[MZAP] Handley, M, Thaler, D. and R. Kermode
"Multicast-Scope Zone Announcement Protocol
(MZAP)", RFC 2776, February 2000.
[RFC1112] Deering, S., "Host Extensions for IP
Multicasting", STD 5, RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 2373, July 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[SCOPE] Meyer, D., "Administratively Scoped IP
Multicast", RFC 2365, July 1998.21. Full Copyright Statement ⚖️
okay this part is the legal stuff, but I'm keeping every clause so nothing gets lost 🎀
The Internet Society owns the copyright here, and it's (C) The Internet Society (2000), all rights reserved 💜
Anyone can copy and share this document and translations of it, and people can make derivative works that comment on or explain it or help with building it. Those can be made, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the copyright notice and this paragraph stay on every copy and derivative work 🌸
However, this document itself may not be modified in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's being translated into languages other than English 🧚
The permissions above are perpetual, and the Internet Society or its successors or assigns will not revoke them 🦋
This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc2909 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms