RFC 2776

Multicast-Scope Zone Announcement Protocol (MZAP)

📅 published February 2000, from ietf

RFC 2776: Multicast-Scope Zone Announcement Protocol (MZAP) 💖

Okay bestie, this is RFC 2776, the Multicast-Scope Zone Announcement Protocol (MZAP) ✨. It came out in February 2000 from the Network Working Group and sits on the Standards Track 🎀, so it's an actual internet standard, not just vibes. The authors are M. Handley from ACIRI, D. Thaler from Microsoft, and R. Kermode from Motorola 🫶. It doesn't say it obsoletes or updates anything, so I'm not going to guess 🙈.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌸

This doc defines a protocol called the Multicast-Scope Zone Announcement Protocol (MZAP), and its whole job is discovering the multicast administrative scope zones that are relevant at a particular location 🔍. It also gives you mechanisms for spotting common misconfigurations of administrative scope zones. Main character energy for network debugging 💅.

Table of Contents 🗂️

   1 Introduction ................................................  2
   2 Terminology .................................................  4
   3 Overview ....................................................  5
   3.1 Scope Nesting .............................................  6
   3.2 Other Messages ............................................  7
   3.3 Zone IDs ..................................................  7
   4 Detecting Router Misconfigurations ..........................  8
   4.1 Detecting non-convex scope zones ..........................  8
   4.2 Detecting leaky boundaries for non-local scopes ...........  9
   4.3 Detecting a leaky Local Scope zone ........................ 10
   4.4 Detecting conflicting scope zones ......................... 10
   5 Packet Formats .............................................. 11
   5.1 Zone Announcement Message ................................. 14
   5.2 Zone Limit Exceeded (ZLE) ................................. 15
   5.3 Zone Convexity Message .................................... 15
   5.4 Not-Inside Message ........................................ 16
   6 Message Processing Rules .................................... 17
   6.1 Internal entities listening to MZAP messages .............. 17
   6.2 Sending ZAMs .............................................. 18
   6.3 Receiving ZAMs ............................................ 18
   6.4 Sending ZLEs .............................................. 20
   6.5 Receiving ZLEs ............................................ 20
   6.6 Sending ZCMs .............................................. 21
   6.7 Receiving ZCMs ............................................ 21
   6.8 Sending NIMs .............................................. 21
   6.9 Receiving NIMs ............................................ 22
   7 Constants ................................................... 22
   8 Security Considerations ..................................... 23
   9 Acknowledgements ............................................ 24
   10 References ................................................. 25
   11 Authors' Addresses ......................................... 26
   12 Full Copyright Statement ................................... 27

1. Introduction ✨

Okay so administratively-scoped IP multicast, which is defined in RFC 2365 [1], lets you address packets to a specific range of multicast addresses (for IPv4, that's something like 239.0.0.0 to 239.255.255.255 🌈). Those packets won't cross configured administrative boundaries 🚧. The addresses can also be assigned locally, so they aren't required to be unique across administrative boundaries. That's address reuse, and it means infrastructure stuff like address allocation, session advertisement, and service location can use well-known addresses that are guaranteed to mean something inside every organization 🫶.

The range of administratively-scoped addresses can be split up by administrators, so you can have multiple levels of administrative boundaries running at the same time 🧚. That's why a "multicast scope" is defined as a particular range of addresses that has been given some topological meaning.

To make this work, a router sitting at an administrative boundary gets configured with one or more per-interface filters, called "multicast scope boundaries" 🔐. Having one of these on an interface means it will not forward packets matching a configured range of multicast addresses in either direction on that interface.

A specific area of the network topology that's inside a boundary for a given scope is known as a "multicast scope zone" 🦋. Since the same ranges can be reused in disjoint areas of the network, there can be lots of "multicast scope zones" for any given multicast scope. A scope zone can have zero or more textual names (in different languages) for the scope, just so humans can read it. For example, if the range 239.192/14 were assigned to span an entire corporate network, it might be given (internally) the name "BigCo Private Scope" 💼.

Administrative scope zones can be any size. A particular host can be inside many administrative scope zones of various sizes, one for each different scope (meaning non-overlapping ranges of addresses). The only rule is that scope zones which intersect topologically must not intersect in address range 🚦.

Applications and services care about different things about the scopes they live in:

  • Applications that let users pick which scope to operate in (like when creating a new session, whether it stays on a corporate intranet or goes out over the public Internet) care about the textual names, because those are what users understand 💬.
  • Services that use "relative" multicast addresses (as defined in [1]) in every scope care about the range of addresses used by each scope, so they can apply a constant offset and work out which address to use in each scope 🧮.
  • Address allocators care about the address range, and whether they're allowed to allocate addresses across the entire range or not 📒.
  • Some applications and services are also interested in how scopes nest inside each other. For example, nesting info can be used for "expanding-scope" searches, which work in a similar but better-behaved way to the well-known expanding ring search (where the TTL of a query keeps going up until a replier is found) 🔎. Studies have also shown that nested scopes can be useful for localizing multicast repair traffic [8] 🩹.

Two barriers make administrative scoping hard to deploy and use right now:

  • Applications have no way to dynamically discover info on the scopes that are relevant to them. That makes administrative scope zones hard to use, which lowers the incentive to deploy them 😩.
  • Misconfiguration is super easy 💀. It's hard to detect scope zones that aren't convex (the shortest path between two nodes inside the zone passes outside the zone), that leak (one or more boundary routers weren't configured correctly), or that intersect in both area and address range.

This document tackles both of these barriers 💪. It defines the Multicast Scope Zone Announcement Protocol (MZAP), which lets an entity learn which scope zones it's inside. Servers usually cache the info they learn from MZAP, and can then hand it to applications quickly when asked, using other means like MADCAP [9] 🚀. MZAP also gives diagnostic info to the boundary routers themselves, so misconfigured scope zones can be detected 🕵️‍♀️.

2. Terminology 🎀

The "Local Scope" is defined in RFC 2365 [1]. It's the smallest administrative scope that's bigger than link-local, and its address range is 239.255.0.0 to 239.255.255.255 inclusive (for IPv4), or FF03::/16 (for IPv6) 🌈. RFC 2365 specifies:

"239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own Local Scope. This implies that any scope boundary is also a boundary for the Local Scope."

A multicast scope Zone Boundary Router (ZBR) is a router that has a boundary configured for a particular multicast scope on one or more of its interfaces 🧱. Any interface configured with a boundary for any administrative scope zone MUST also have a boundary for the Local Scope zone, as described above. No skipping that step, bestie 🙅‍♀️.

Routers like this SHOULD be configured so the router itself is inside the scope zone. Figure 1(a) shows this, where router A is inside the scope zone and has the boundary configuration ✅.

          ............                     ................
         .            .   +B+-->          .                *B+-->
        .              . /               .                / .
       .                *               .                +   .
       .          <---+A*---+C+->       .          <---+A+---*C+->
       .              + .               .              +     .
       .             /  .               .             /      .
        . zone X  <--  .                 . zone X  <--      .
         ..............                   ..................

        A,B,C - routers    * - boundary interface    + - interface

       (a) Correct zone boundary         (b) Incorrect zone boundary

          Figure 1: Administrative scope zone boundary placement

It's possible for the first router outside the scope zone to be configured with the boundary, like in Figure 1(b), where routers B and C are outside the zone and have the boundary configuration, while A doesn't. But this is NOT RECOMMENDED 🙅‍♀️. This rule doesn't apply to Local Scope boundaries, but it does apply to all the other boundary routers.

We next define the term "Zone ID" 🆔. It means the lowest IP address used by any ZBR for a particular zone when it's sourcing MZAP messages into that scope zone. This IP address, combined with the first multicast address in the scope range, is what uniquely identifies the scope zone. Each ZBR listens for messages from other ZBRs for the same boundary, and can work out the Zone ID from the source addresses it sees. The Zone ID can change over time as ZBRs come up and go down 🔄.

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 [2] 📖.

Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in section 7 🧾.

3. Overview ✨

okay so bestie, when a ZBR (zone border router) is set up correctly, it can figure out which side of the boundary is inside the scope zone and which side is outside it 🧠🦋

That ZBR then sends out periodic Zone Announcement Messages (ZAMs) 📣 for every zone it's set up to guard as a boundary into that scope zone. Each ZAM carries the scope zone's address range, its Zone ID, and its textual names 💖 The messages get multicast to the well-known address [MZAP-LOCAL-GROUP] in the Local Scope 🌸 and they get relayed across Local Scope boundaries into every Local Scope zone inside the scope zone the ZAM is talking about. Check out Figure 2 below, it's giving flooding energy 🌊✨

 ###########################
 # Zone1      =      Zone2 #    ##### = large scope zone boundary
 *E-----+--->A*-----+-x    #
 #      |     =     v      #    ===== = Local Scope boundaries
 #      |     ======*===*==#
 #      |     =     B   F  #    ----> = path of ZAM originated by E
G*<-----+--->C*->   |   ^  #
 #      v     =   <-+---+  #    ABCDE = ZBRs
 #      D     =      Zone3 #
 #######*###################        * = boundary interface

               Figure 2: ZAM Flooding Example

The best part? Any entity can listen on that single well-known group address and learn about every scope it lives in 🎀👑

3.1. Scope Nesting

MZAP also lets you discover how scope zones nest inside each other 🪆 Two zones count as nested if one is made up of a subset of the routers in the other. See Figure 3 for the vibes 💅

  +-----------+       +-----------+      +-------------+
  | Zone 1    |       | Zone 3    |      | Zone 5      |
  |   +------+|       |    +------+      |    .........|..
  |   |Zone 2||       |    |Zone 4|      |    : Zone 6 | :
  |   +--A---+|       |    C      |      |    D        | :
  +-----------+       +----+--B---+      +--------E----+ :
                                               :..........:

  (a) "Contained"    (b) "Common Border"  (c) "Overlap"
       Zone 2 nests       Zone 4 nests         Zones 5 and 6
       inside Zone 1      inside Zone 3        do not nest

                  Figure 3: Zone nesting examples

Here's the tea 🫖 A ZBR can't independently tell whether one zone is nested inside another. What it can tell is that one zone does not nest inside another 🙈 Using Figure 3 as the example:

  • ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2 from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it then knows that zone 1 does not nest within zone 2, but it cannot, however, determine whether zone 2 nests within zone 1.
  • ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine if one is nested inside the other. However, ZBR C can determine that zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3, since it is a ZBR for zone 4 but not zone 3.
  • ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5. Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for zone 6.

So ZBRs can prove that a zone does not nest inside another, but they can't prove that it does 😭 That means nesting has to be figured out in a distributed way 🌈 This happens through Not-Inside Messages (NIMs), which say that a zone X is not inside a zone Y. These go to the well-known [MZAP-LOCAL-GROUP], so the same entities that listen for ZAM messages (like MADCAP servers) see them too 👀 Those entities can work out the nesting relationship between two scopes once there's been a sustained absence of any evidence to the contrary 🧚

3.2. Other Messages

There are two other message types, Zone Convexity Messages (ZCMs) and Zone Limit Exceeded (ZLE) messages 🍓 Only routers use them, and they let routers compare configs for consistency and catch misconfigurations 🔍 These go to MZAP's relative address within the scope range of the scope zone they're about, so usually only routers ever see them, not everybody 🙈 How they catch specific misconfigurations gets covered in the next section.

Packet formats for all messages are described in Section 5 📦

3.3. Zone IDs

When a boundary router first starts up, it picks its lowest IP address that it considers to be inside a given zone, and that's routable everywhere within the zone (so, not a link-local address, bestie) 💜 It uses that as the Zone ID for the zone. Then it schedules ZCM (and ZAM) messages to go out in the future, because it does not send them right away ⏰

When a ZCM comes in for the given scope, the sender gets added to the local list of ZBRs for that scope (and the router adds itself too 💅), and the Zone ID gets updated to the lowest IP address in the list ✨ Entries in the list eventually time out if no more messages arrive from that ZBR. So the Zone ID converges to the lowest address of any active ZBR for the scope 🦋

Note that the sender of ZAM messages MUST NOT be used in this way 🚫 This matters because the procedure for detecting a leaky Local scope, described in Section 4.3 below, relies on two disjoint zones for the same scope range having different Zone IDs 💀 If ZAMs were used to compute Zone IDs, then ZAMs leaking across a Local Scope boundary would make the two zones converge to the same Zone ID. Total mess, no thanks 🙅‍♀️

4. Detecting Router Misconfigurations 🔎

In this section we go over how to detect the various error conditions 🕵️‍♀️ If any error is detected, the router should attempt to alert a network administrator to the nature of the misconfiguration. How to do that is outside the scope of MZAP, so that's a different vibe 🌸

4.1. Detecting non-convex scope zones

Zone Convexity Messages (ZCMs) are how routers catch non-convex administrative scope zones, which is one possible misconfiguration 🙃 Non-convex scope zones can cause real problems for applications, because a receiver might never see administratively-scoped packets from a sender in the same scope zone. The packets traveling between them can get dropped at the boundary 😭

In the example in Figure 4, the path between B and D goes outside the scope (through A and E) 🗺️ Router B and Router C each send ZCMs within a given scope zone where they each have a boundary, and each one reports the other boundary routers of the zone it has heard from 💌 In Figure 4, Router D can't see Router B's messages, but it can see C's report of B, so it can conclude the zone is not convex 🧠

 #####*####========
 #    B   #       =         ##### = non-convex scope boundary
 #    |->A*       =
 #    |   #       =         ===== = other scope boundaries
 #    |   ####*####
 #    |       E   #         ----> = path of B's ZCM
 #    v          D*
 #    C           #             * = boundary interface
 #####*############

             Figure 4: Non-convexity detection

Non-convex scope zones can be detected in three ways 🎀

  1. If a ZBR is listed in ZCMs received, but the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone,
  2. If a ZBR is listed in ZCMs received, but no ZCM is received from that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4, or
  3. ZAM messages can also be used in a manner similar to that for ZCMs in (1) above, as follows: if a ZAM is received from a ZBR on an interface inside a given scope zone, and the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone.

Zone Convexity Messages MAY also be sent and received by correctly configured ordinary hosts within a scope region 🙌 That can be a handy diagnostic tool, and it doesn't need privileged access 🔑

4.2. Detecting leaky boundaries for non-local scopes

A "leaky" boundary is one that logically has a "hole" 🕳️ That happens when some router doesn't have a boundary applied on an interface where one ought to exist. So the boundary doesn't completely surround a piece of the network, and scoped data ends up leaking outside 💦

Leaky scope boundaries can be detected in two ways 🔍

  1. If it receives ZAMs originating inside the scope boundary on an interface that points outside the zone boundary. Such a ZAM message must have escaped the zone through a leak, and flooded back around behind the boundary. This is illustrated in Figure 5.
 =============#####*########
 = Zone1      #    A Zone2 #       C   = misconfigured router
 =      +---->*E   v       #
 =      |     #    B       #     ##### = leaky scope boundary
 =======*=====#====*=======#
 =      D     #    |       #     ===== = other scope boundaries
 =      ^-----*C<--+       #
 = Zone4      #      Zone3 #     ----> = path of ZAMs
 =============##############

                 Figure 5: ZAM Leaking
  1. If a Zone Length Exceeded (ZLE) message is received. The ZAM packet also contains a Zones Traveled Limit 🧳 If the number of Local Scope zones traversed becomes equal to the Zones Traveled Limit, a ZLE message is generated (the suppression mechanism for preventing implosion is described later in the Processing Rules section 🙏). ZLEs catch leaks where packets don't come back to another part of the same scope zone, and instead reach other Local Scope zones far away from the ZAM originator 🌍

In either case, the misconfigured router will be either the message origin, or one of the routers in the ZBR path list included in the message received. It could also be a router on the path between two such ZBRs that ought to have been a ZBR itself 🕵️‍♀️

4.3. Detecting a leaky Local Scope zone

A Local Scope is leaky if a router has an administrative scope boundary on some interface, but doesn't have a Local Scope boundary on that interface as specified in RFC 2365 🫣 You can detect this with the following method:

  • If a ZAM for a given scope is received by a ZBR that is a boundary for that scope, it compares the Origin's Scope Zone ID in the ZAM with its own Zone ID for the given scope. If the two do not match, this is evidence of a misconfiguration. Since a temporary mismatch may result immediately after a recent change in the reachability of the lowest-addressed ZBR, misconfiguration should be assumed only if the mismatch is persistent ⏳

The exact location of the problem can be found by doing an mtrace [5] from the router detecting the problem, back to the ZAM origin, for any group within the address range identified by the ZAM 🗺️ The router at fault will be the one reporting that a boundary was reached 🚨

4.4. Detecting conflicting scope zones ✨

okay so conflicts can be spotted with this check 🔍

  • If a ZBR receives a ZAM for a given scope, and the included start and end addresses overlap with, but are not identical to, the start and end addresses of a locally-configured scope.

scope names can conflict too, and you catch those with this one 🎀

  • If a ZBR is configured with a textual name for a given scope and language, and it receives a ZAM or ZCM with a name for the same scope and language, but the scope names do not match.

Detecting either type of conflict above means something's off. Either the local router or the router that sent the message is misconfigured 😭 Configuration tools SHOULD strip white space from the beginning and end of each name to avoid accidental misconfiguration 🫶

5. Packet Formats 💅

All MZAP messages are sent over UDP, with a destination port of [MZAP-PORT] and an IPv4 TTL or IPv6 Hop Limit of 255 🦋

When a ZBR sends an MZAP message about a given scope zone, it MUST use a source address that will have significance everywhere within that scope zone. For example, link-local addresses MUST NOT be used 🙈

the common MZAP message header (it sits right after the UDP header) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |B|    PTYPE    |Address Family |   NameCount   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Message Origin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Zone ID Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Zone Start Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Zone End Address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length)                         |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     . . .                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  . . .        | Encoded Zone Name-N (variable length)         |
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     Padding (if needed)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version: The version defined in this document is version 0. 🌸

"Big" scope bit (B): If clear, it means the addresses in the scoped range can't be subdivided, and address allocators are allowed to use the whole range. If set, allocators should not use the entire range, and should instead learn an appropriate sub-range through another mechanism (e.g., AAP [7]) 🧚

Packet Type (PTYPE): the packet types defined in this document are 🍓

   0: Zone Announcement Message (ZAM)
   1: Zone Limit Exceeded (ZLE)
   2: Zone Convexity Message (ZCM)
   3: Not-Inside Message (NIM)

Address Family: this is the IANA-assigned address family number [10,11] that tells you which address family all the addresses in the packet belong to. The families defined for IP are 🌈

   1: IPv4
   2: IPv6

Name Count: the number of encoded zone name blocks in this packet. The count may be zero 💜

Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) this is the start address for the scope zone boundary. For example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then Zone Start Address is 239.1.0.0 ✨

Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) this is the ending address for the scope zone boundary. For example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then Zone End Address is 239.1.0.255 ✨

Message Origin: 32 bits (IPv4) or 128 bits (IPv6) this is the IP address of the interface that originated the message 🦋

Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) this is the lowest IP address of a boundary router that has been observed in the zone that originated the message. Together with Zone Start Address and Zone End Address, it forms a unique ID for the zone. Note that this ID is usually different from the ID of the Local Scope zone in which the origin resides 🔥

Encoded Zone Name:

   +--------------------+
   |D| Reserved (7 bits)|
   +--------------------+
   | LangLen (1 byte)   |
   +--------------------+-----------+
   | Language Tag (variable size)   |
   +--------------------+-----------+
   | NameLen (1 byte)   |
   +--------------------+-----------+
   | Zone Name (variable size)      |
   +--------------------------------+

the first byte holds flags, and only the high bit is defined. The other bits are reserved (sent as 0, ignored on receipt) 🎀

"Default Language" (D) bit: if set, it's a preference that the name in the following language should be used when no name is available in a desired language 💖

Language tag length (LangLen): 1 byte the length, in bytes, of the language tag 🌸

Language Tag: (variable size) the language tag (like "en-US") that says what language the zone name is in. Language tags are described in [6] 🌍

Name Len: the length, in bytes, of the Zone Name field. The length MUST NOT be zero 🚫

Zone Name: multiple of 8 bits the Zone Name is an ISO 10646 character string in UTF-8 encoding [4] that gives the name of the scope zone (eg: "ISI-West Site"). It should be relatively short and MUST be less than 256 bytes in length. White space SHOULD be stripped from the beginning and end of each name before encoding, so you don't get accidental conflicts 🫶

Padding (if needed): the end of the MZAP header gets padded with null bytes until it's 4-byte aligned 🧸

5.1. Zone Announcement Message 📣

A Zone Announcement Message has PTYPE=0. A ZBR periodically sends one for each scope it is a boundary for, EXCEPT for:

  • the Local Scope
  • the Link-local scope

this is what the format looks like 👀

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ZT       |     ZTL       |           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address N                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the fields work like this 🧩

Zones Traveled (ZT): 8 bits the number of Local Zone IDs contained in this message path 🛤️

Zones Traveled Limit (ZTL): 8 bits the limit on how many local zones the packet can traverse before it MUST be dropped. A value of 0 means there's no limit 🚦

Hold Time: the time, in seconds, after which the receiver should assume the scope no longer exists, if no subsequent ZAM is received. This should be set to [ZAM-HOLDTIME] ⏳

Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) the zone path is a list of the Local Zone ID Addresses (the Zone ID Address of a local zone) that the ZAM has passed through, plus the IP addresses of the routers that forwarded the packet. The origin router fills in the "Local Zone ID Address 0" field when it sends the ZAM. Every Local Scope router that forwards the ZAM across a Local Scope boundary MUST add the Local Zone ID Address of the local zone that the packet of the zone into which the message is being forwarded, and its own IP address, to the end of this list, and increment ZT accordingly. The zone path is empty which the ZAM is first sent 🌟

5.2. Zone Limit Exceeded (ZLE) 🚨

the format of a ZLE 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ZT       |     ZTL       |         Hold Time             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address N                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

all fields are copied from the ZAM, except PTYPE, which gets set to one. 🦄🫶

5.3. Zone Convexity Message ✨

okay so a Zone Announcement Message has PTYPE=2 🎀 (yes, the spec says that, and yes, we're keeping it!). A ZBR sends one of these periodically for each scope it's a boundary for, except the Link-local scope. ZCM's ARE sent in the Local Scope 🦋

Unlike ZAMs, which go to the [MZAP-LOCAL-GROUP], Zone Convexity Messages go to the [ZCM-RELATIVE-GROUP] inside the scope zone itself 💜 Here's the layout:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               MZAP Header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ZNUM      |  unused       |           Hold Time           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ZBR Address 1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ZBR Address N                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields, bestie 🫶

  • Number of ZBR addresses (ZNUM): 8 bits 🌸 This is how many ZBR Addresses are in the message.
  • Hold Time ⏳ The time, in seconds, after which the receiver should assume the sender is no longer reachable, if no later ZCM shows up. This should be set to [ZCM-HOLDTIME].
  • ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) 🌈 These are the addresses of the other ZBRs that the Message Origin ZBR has been hearing ZCMs from, as long as their hold time hasn't run out. The router should include every such address that fits in the packet. If they don't all fit, it prefers the ones it hasn't included recently. Rotation is everything 🔁

5.4. Not-Inside Message 🧚

A Not-Inside Message (NIM) has PTYPE=3, and a ZBR sends it periodically when it knows that a scope X does not nest within another scope Y ("X not inside Y") 💅

Here's what it looks like:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               MZAP Header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Not-Inside Zone Start Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields:

  • MZAP Header 🎀 These fields identify scope X. The Name Count may be 0.
  • Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) 🍓 This is the start address for scope Y.

6. Message Processing Rules 👑

6.1. Internal entities listening to MZAP messages 👂

Any host or app can join the [MZAP-LOCAL-GROUP] to listen for Zone Announcement Messages, so it can build a list of the scope zones that matter locally, and for Not-Inside Messages if it wants to learn nesting info 🧠 Listening directly is not the recommended way for regular apps to find this stuff, though 🙈 Normally they'll query a local Multicast Address Allocation Server (MAAS) [3], which listens to ZAMs and NIMs to keep scope info up to date, and clients can ask it using MADCAP messages 💌

An entity (including a MAAS) that doesn't have any of this info can only assume it's inside the Global Scope and the Local Scope. Both have well-known address ranges defined in [1] 🌍

An internal entity (like a MAAS) that gets a ZAM will parse the info that's relevant to it, like the address range and the names. An address allocator that receives this info MUST also use the "B" bit to decide whether it can add the address range to the set it may allocate from. Specifically, it may add the range only if the bit is zero 🚦 Even if the bit is zero, a MAAS SHOULD still store the range info, so clients using relative addresses can still get the ranges by asking the MAAS 🫶

An internal entity (like a MAAS) should assume that X nests within Y if:

  • a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] seconds ago, AND
  • b) it hasn't heard a NIM saying "X not inside Y" for at least [NIM-HOLDTIME] seconds 💖

6.2. Sending ZAMs 📣

Each ZBR should send a Zone Announcement Message for each scope zone it's a boundary for, every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-INTERVAL] each time, to avoid message synchronisation 🌀

The ZAM also carries a Zones Traveled Limit (ZTL) 🚧 If the number of Local Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the packet gets dropped. The ZTL field is set when the packet is first sent and defaults to 32, but a network admin can set it lower if they know how big the zone is 🍓

6.3. Receiving ZAMs 📥

When a ZBR gets a ZAM for some scope zone X, it follows these rules 💅

If the local ZBR does NOT have any configuration for scope X:

  • (1) Check whether the included start and end addresses overlap with, but aren't identical to, the start and end addresses of any locally-configured scope Y. If so, signal an address range conflict to a local admin 🚨
  • (2) Create a local "X not inside" state entry, if one doesn't already exist. The ZBR then restarts the entry's timer at [ZAM-HOLDTIME]. This state means the ZBR knows X doesn't nest inside any scope it's a boundary for 🧩 If the timer runs out (no more ZAMs for X heard for [ZAM-HOLDTIME]), the entry gets deleted 🗑️

If the local ZBR does have configuration for scope X:

  • (1) If the ZAM came from OUTSIDE the scope (meaning it was received over a boundary interface for scope X):
    • a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone ID, signal a leaky scope misconfiguration 🫣
    • b) Drop the ZAM and do no further processing below. For example, router G in Figure 2 won't forward the ZAM. This rule is mainly a safety measure, since putting G where it is in Figure 2 isn't a recommended setup, as discussed earlier 🙅‍♀️
  • 2) If the ZAM came from INSIDE the scope:
    • a) If the next-hop interface (according to the multicast RIB) toward the Origin is outside the scope zone, signal a non-convexity problem 🌵
    • b) If the Origin's Scope Zone ID in the ZAM doesn't match the Scope Zone ID kept by the local ZBR, and this mismatch keeps happening, signal a possible leaky scope warning ⚠️
    • c) For each textual name in the ZAM, check whether a name for the same scope and language is locally configured. If it is, but the scope names don't match, signal a scope name conflict to a local admin 🙃
    • d) If the ZAM was received on an interface that is NOT a Local Scope boundary, and the last Local Zone ID Address in the path list is 0, the ZBR fills in the Local Zone ID Address of the local zone the ZAM came from 🧃

If a ZAM for the same scope (identified by the origin Zone ID and first multicast address) was received in the last [ZAM-DUP-TIME] seconds, the ZAM gets discarded. Otherwise, the ZAM is cached for at least [ZAM-DUP-TIME] seconds. For example, when router C in Figure 2 gets the ZAM via B, it won't forward it, because it just forwarded the ZAM from E 🔁

The Zones Travelled count in the message then gets incremented. If the updated count is equal to or greater than the ZTL field, schedule a ZLE to be sent (as described in the next subsection) and do no further processing below 🛑

If the Zone ID of the Local Scope zone the ZBR is in isn't already in the ZAM's path list, the ZAM is immediately re-originated within the Local Scope zone. Before doing so, it adds its own address and the Zone ID of the Local Scope zone the message is being forwarded into to the path list 🛤️ A ZBR that gets a ZAM with a non-null path list MUST NOT forward that ZAM back into a Local Scope zone that's contained in the path list. For example, in Figure 2, router F didn't get the ZAM via A (packet loss, oof 😭), so it won't forward the ZAM from B back into Zone 2, since the path list is { (E,1), (A,2), (B,3) } and Zone 2 is already in there 🌸

The ZBR also re-originates the ZAM out each interface with a Local Scope boundary. The exceptions: it isn't sent back out the interface it came in on, and it isn't sent into any local scope zone whose ID is known and already in the path list 🚫 In each re-originated ZAM, the ZBR adds its own IP address to the path list, plus the Zone ID Address of the Local Scope Zone the ZAM is being sent into, or 0 if that ID is unknown. (For example, if the other end of a point-to-point link also has a boundary on the interface, then the link has no Local Scope Zone ID 🔗)

6.4. Sending ZLEs 🚨

A ZLE is sent by a local-zone boundary router that would have exceeded the Zone Traveled Limit if it had forwarded a ZAM packet 😱 To avoid ZLE implosion, ZLEs are multicast with a random delay and suppressed by other ZLEs 🌊 A ZLE only gets scheduled if at least [ZLE-MIN-INTERVAL] seconds have passed since the router last sent a ZLE to any destination ⏱️ To schedule one, the router sets a random delay timer within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any arrive before the timer expires, the timer is cleared and the ZLE isn't sent. If the timer does expire, the router sends a ZLE to the [MZAP-RELATIVE-GROUP] within the indicated scope 📬

Here's how the random delay (T) gets picked:

  Choose a random value X from the uniform random interval [0:1]
  Let C = 256
  Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)

This equation gives an exponential random distribution, which makes sure close to one ZBR responds 🎯 A purely uniform distribution would start having scaling problems as the number of ZBRs goes up 📈 ZLEs only get suppressed if a duplicate ZLE arrives before the chosen time. So two routers choosing delays that differ by less than the propagation delay between them will both send messages, eating up extra bandwidth 💸 That's why it's desirable to have as few routers as possible choosing a delay close to the lowest one, and an exponential distribution is perfect for that 💅

A router SHOULD NOT send more than one Zone Limit Exceeded message every [ZLE-MIN-INTERVAL], regardless of destination ⏳

6.5. Receiving ZLEs 📨

When a router gets a ZLE, it does the following 🧁

  • (1) If the router has a duplicate ZLE message scheduled to be sent, it unschedules its own message so another one won't be sent 🙌
  • (2) If the ZLE has the router's own address in the Origin field, it signals a leaky scope misconfiguration 🫣

6.6. Sending ZCMs

Okay bestie, so each ZBR should send a Zone Convexity Message (ZCM) for every scope zone it's a boundary for, every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM-INTERVAL] each time 🫶 That jitter is there so everyone doesn't send at the exact same moment and cause message synchronisation drama 💅

ZCMs go to the [ZCM-RELATIVE-GROUP] in the scoped range itself. For example, if the scope range is 239.1.0.0 to 239.1.0.255, these messages should be sent to 239.1.0.252 🦋 They're not Locally-Scoped packets, so they just get multicast across the scope zone itself. No path needs to be built up and intermediate Local Scope ZBRs don't need to do anything special, which is so efficient, I'm obsessed 😭✨

6.7. Receiving ZCMs

When a ZCM comes in for a given scope X, on an interface that's inside the scope, here's what happens 🌸

  1. The Origin gets added to the local list of ZBRs (including itself) for that scope, and the Zone ID gets updated to the lowest IP address in the list. The new entry is scheduled to time out after [ZCM-HOLDTIME] if no further messages arrive from that ZBR. This way the Zone ID converges to the lowest address of any active ZBR for the scope, and that's giving stability 👑
  2. If a ZBR is listed in the ZCMs received, but the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone, or if no ZCM has been received from that ZBR for [ZCM-HOLDTIME] seconds (like in the example in Figure 4), then signal a non-convexity problem. Basically the zone has a weird shape and someone needs to know 🙈
  3. For each textual name in the ZCM, check whether a name for the same scope and language is locally configured. If so, but the scope names don't match, signal a scope name conflict to a local administrator. Name drama, not cute 💀

6.8. Sending NIMs

Periodically, for each scope zone Y that it's a boundary for, a router originates a Not-Inside Message (NIM) for each "X not inside" entry it created when receiving ZAMs 🧚 Just like a ZAM, this message is multicast to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y.

Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL] seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization. Same jitter energy as before, periodt 🎀

6.9. Receiving NIMs

When a ZBR receives a NIM saying that "X is not inside Y", it gets forwarded, unmodified, in a similar way to ZAMs. But there are some extra checks, bestie 👀

  1. If the NIM was received on an interface with a boundary for either X or Y, the NIM is discarded.
  2. Unlike ZAMs, if the NIM was not received on the interface towards the message origin (according to the Multicast RIB), the NIM is discarded. Unlike ZAMs, this one is picky 💅
  3. If a NIM for the same X and Y (each identified by its first multicast address) was received in the last [ZAM-DUP-TIME] seconds, the NIM is not forwarded. No double-posting, we don't do that here 🙅‍♀️
  4. Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.
  5. The ZBR then re-originates the NIM (i.e., with the original UDP payload) into each local scope zone it has interfaces in, except that it's not sent back into the local scope zone it came from, and it's not sent out any interface with a boundary for either X or Y. Main character energy for the NIM, honestly 🌈

7. Constants 🎀

Here are all the constants, babe. Keep these handy, they're literally the numbers everything runs on 🍓

  • [MZAP-PORT]: The well-known UDP port that all MZAP messages are sent to. Value: 2106.
  • [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope that ZAMs are sent to. All Multicast Address Allocation servers and Zone Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4.
  • [ZCM-RELATIVE-GROUP]: The relative group in each scope zone that ZCMs are sent to. A Zone Boundary Router listens to the relative group in each scope it's a boundary for. Value: (last IP address in scope range) - 3. For example, in the Local Scope, the relative group is the same as the [MZAP-LOCAL-GROUP] address. Same address, different name, very cute 🦋
  • [ZAM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Announcement Messages. Default value: 600 seconds (10 minutes).
  • [ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 minutes).
  • [ZAM-DUP-TIME]: The time interval after forwarding a ZAM during which ZAMs for the same scope will not be forwarded. Default value: 30 seconds.
  • [ZCM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Convexity Messages. Default value: 600 seconds (10 minutes).
  • [ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 minutes).
  • [ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random delay before sending a ZLE message. Default value: 300 seconds (5 minutes). Random delay, random vibes 🌸
  • [ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, regardless of destination. Default value: 300 seconds (5 minutes).
  • [NIM-INTERVAL]: The interval at which a Zone Boundary Router originates Not-Inside Messages. Default value: 1800 seconds (30 minutes).
  • [NIM-HOLDTIME]: The holdtime to include the state within a NIM. This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91 minutes). 91 minutes, that's a whole vibe ✨

8. Security Considerations 🔐

Okay, this section is serious, so I'm keeping all of it 😭 Unauthorized reading of MZAP messages is relatively innocuous, so encryption is generally not an issue. But accepting unauthenticated MZAP messages can be problematic. Authentication of MZAP messages can be provided by using the IPsec Authentication Header (AH) [12].

For ZCMs and ZLEs, an attacker can cause false logging of convexity and leakage problems. It's likely that would be purely an annoyance and not cause any significant problem. (Such messages could be authenticated, but since they may be sent within large scopes, the receiver may not be able to authenticate a non-malicious sender.)

ZAMs and NIMs, on the other hand, are sent within the Local Scope, where assuming a security relationship between senders and receivers is more practical 🫶

For NIMs, accepting unauthenticated messages can cause the false cancellation of nesting relationships. This would cause a section of the hierarchy of zones to flatten. Such a flattening would lessen the efficiency benefits afforded by the hierarchy, but it wouldn't make it unusable. Less efficient, not broken 🥲

Accepting unauthenticated ZAM messages, however, could cause applications to believe that a scope zone exists when it doesn't. If these were believed, applications might choose to use this non-existent administrative scope for their uses. Such applications would be able to communicate successfully, but they'd be unaware that their traffic may be traveling further than they expected. 😱 As a result, any application accepting unauthenticated ZAMs MUST only take scope names as a guideline, and SHOULD assume that their traffic sent to non-local scope zones might travel anywhere. The confidentiality of such traffic CANNOT be assumed from the fact that it was sent to a scoped address that was discovered using MZAP.

ZAMs are also used to inform Multicast Address Allocation Servers (MAASs) of names and address ranges of scopes. Accepting unauthenticated ZAMs could result in false names being presented to users, and in wrong addresses being allocated to users. Bestie, this is the part where we protect the vibes 🛡️

To counter this, MAASs authenticate ZAMs as follows:

  1. A ZBR signs all ZAMs it originates (using an AH).
  2. A ZBR signs a ZAM it relays if and only if it can authenticate the previous sender. A ZBR MUST still forward un-authenticated ZAMs (to provide leak detection), but should propagate an authenticated ZAM even if an un-authenticated one was received within the last [ZAM-DUP-TIME] seconds.
  3. A MAAS SHOULD be configured with the public key of the local zone in which it resides. A MAAS thus configured SHOULD ignore an unauthenticated ZAM if an authenticated one for the same scope has been received, and MAY ignore all unauthenticated ZAMs. Choose your own ZAM-ignoring adventure 🧚

9. Acknowledgements 💜

This document is a product of the MBone Deployment Working Group, whose members provided many helpful comments and suggestions. Van Jacobson provided some of the original ideas that led to this protocol. The Multicast Address Allocation Working Group also provided useful feedback regarding scope names and interactions with applications. Shoutout to all of them, they're iconic 👑

10. References 📚

  • [1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", Work in Progress.
  • [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
  • [5] Fenner, W. and S. Casner, "A `traceroute' facility for IP Multicast", Work in Progress.
  • [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
  • [7] Handley, M. and S. Hanna. "Multicast Address Allocation Protocol (AAP)", Work in Progress.
  • [8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998, Vancouver, Canada.
  • [9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
  • [10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
  • [11] IANA, "Address Family Numbers", http://www.isi.edu/in-notes/iana/assignments/address-family-numbers
  • [12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

11. Authors' Addresses 🖊️

Mark Handley

Mark Handley
AT&T Center for Internet Research at ICSI
1947 Center St, Suite 600
Berkely, CA 94704
USA

EMail: mjh@aciri.org

David Thaler

David Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
USA

EMail: dthaler@microsoft.com

Roger Kermode

Roger Kermode
Motorola Australian Research Centre
12 Lord St,
Botany, NSW 2019
Australia

EMail: Roger.Kermode@motorola.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is 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. Thank you, Internet Society, you're the real MVP 💖

📦 where this page comes from