RFC 6308

Overview of the Internet Multicast Addressing Architecture

📅 published June 2011, from ietf

RFC 6308 🎀 Request for Comments: 6308 💖

Author: P. Savola, CSC/FUNET 🌸 Date: June 2011 📅 Category: Informational 📚 ISSN: 2070-1721 ✨ Obsoletes: 2908 💅

Okay bestie, this one's the big picture on IP multicast addressing. It's an informational doc, so it's not a Standards Track spec, but it's still super useful. It basically says "we need to fix the confusing docs" and then explains how multicast addresses actually get handed out. It obsoletes RFC 2908 🦋

Overview of the Internet Multicast Addressing Architecture 🧚

Abstract ✨

Okay so, nobody had up-to-date docs on how IP multicast addresses get allocated and assigned, and it was a whole mess 😭 This memo fixes that by describing the allocation and assignment techniques and mechanisms that are being used right now (as of when it was written) 💜

Status of This Memo 📝

This document is not an Internet Standards Track specification, so it's just published for information 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 🫶

For the latest status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6308 🔗

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💅

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Terminology: Allocation or Assignment ......................3
   2. Multicast Address Allocation ....................................3
      2.1. Derived Allocation .........................................3
           2.1.1. GLOP Allocation .....................................4
           2.1.2. Unicast-Prefix-Based Allocation .....................4
      2.2. Administratively Scoped Allocation .........................5
      2.3. Static IANA Allocation .....................................6
      2.4. Dynamic Allocation .........................................6
   3. Multicast Address Assignment ....................................6
      3.1. Derived Assignment .........................................6
      3.2. SSM Assignment inside the Node .............................7
      3.3. Manually Configured Assignment .............................7
      3.4. Static IANA Assignment .....................................7
           3.4.1. Global IANA Assignment ..............................7
           3.4.2. Scope-Relative IANA Assignment ......................8
      3.5. Dynamic Assignments ........................................8
   4. Summary and Future Directions ...................................9
      4.1. Prefix Allocation ..........................................9
      4.2. Address Assignment ........................................10
      4.3. Future Actions ............................................11
   5. Acknowledgements ...............................................11
   6. IANA Considerations ............................................11
   7. Security Considerations ........................................11
   8. References .....................................................12
      8.1. Normative References ......................................12
      8.2. Informative References ....................................13

1. Introduction 🌟

Okay so, good, up-to-date IP multicast docs are basically nonexistent 💀 This is especially bad for multicast address allocations (to networks and sites) and assignments (to hosts and applications). It's made worse by confusing or misleading documentation on the subject [RFC2908], so people who want to learn how multicast addressing works just don't get a clear picture of what's going on 😭

The goal here is to give a quick overview of multicast addressing and allocation techniques. The term "addressing architecture" is used to loosely refer to the set of addressing mechanisms and methods 🦋

It's important to note that Source-Specific Multicast (SSM) [RFC4607] doesn't have these addressing problems, because SSM group addresses only have local significance. So this document focuses on the Any Source Multicast (ASM) model 💜

This memo obsoletes and re-classifies RFC 2908 to Historic, and it also re-classifies RFCs 2776 and 2909 to Historic 🧚

1.1. Terminology: Allocation or Assignment 🏷️

Almost all multicast docs, and plenty of other RFCs (like DHCPv4 [RFC2131] and DHCPv6 [RFC3315]), have used "address allocation" and "address assignment" interchangeably. But the operator and address management communities use these terms for two conceptually different processes, so it's giving confusion 🙃

In unicast operations, address allocations are about leasing a large block of addresses from the Internet Assigned Numbers Authority (IANA) to a Regional Internet Registry (RIR), or from an RIR to a Local Internet Registry (LIR), possibly through a National Internet Registry (NIR). Address assignments are the leases of smaller address blocks, or even single addresses, to end-user sites or end-users themselves ✨

So in this memo, we're separating the two functions. "Allocation" describes how network operators get larger blocks of addresses, and "assignment" describes how applications, nodes, or sets of nodes get a multicast address for their own use 💅

2. Multicast Address Allocation 🦢

Multicast address allocation is about how a network operator might get a larger block of addresses, and there are a number of ways to do it, as described below 🌈

Heads up that these are all only relevant to ASM. SSM doesn't need any address block allocation, because its group address only has local significance. (We do talk about address assignment inside the node in Section 3.2, though 🫶)

2.1. Derived Allocation 🧮

Derived allocations take the unicast prefix or some other network property (for example, an autonomous system (AS) number) and use it to work out unique multicast address allocations 💖

2.1.1. GLOP Allocation 🌍

GLOP address allocation [RFC3180] puts the 16-bit public AS number in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each AS number can get a /24 worth of multicast addresses. This is totally fine for multicast testing or small-scale use, but it might not be enough in every case for heavy multicast use 🍓

A minor operational debugging issue is that, when the AS number is greater than 255, the connection between the AS and the prefix isn't obvious from the prefix itself. You have to calculate it (for example, as described in [RFC3180], AS 5662 maps to 233.22.30.0/24). A usage issue is that GLOP addresses aren't tied to any prefix, but to routing domains, so they can't be used or calculated automatically 🙈

GLOP mapping is not available with 4-byte AS numbers [RFC4893]. Unicast-prefix-based allocation or an IANA allocation from "AD-HOC Block III" (the previous so-called "EGLOP" (Extended GLOP) block) could be used instead, as needed. 💀

The GLOP allocation algorithm hasn't been defined for IPv6 multicast, because the unicast-prefix-based allocation (described below) meets the same need in a simpler way ✨

2.1.2. Unicast-Prefix-Based Allocation 🪄

RFC 3306 [RFC3306] describes a mechanism that embeds up to 64 high-order bits of an IPv6 unicast address into the prefix part of the IPv6 multicast address. That leaves at least 32 bits of group-id space available after the prefix mapping 🦋

There's a similar IPv4 mapping described in [RFC6034], but it only gives a limited number of addresses (for example, 1 per IPv4 /24 block) 🥲

The IPv6 unicast-prefix-based allocations are an extremely useful way to let each network operator, even each subnet, get multicast addresses easily through a simple computation 🔥 Also, since the IPv6 multicast header includes the scope value [RFC4291], multicast groups of smaller scope can use the same mapping too 💜

The IPv6 Embedded Rendezvous Point (RP) technique [RFC3956], used with Protocol Independent Multicast - Sparse Mode (PIM-SM), takes unicast-prefix-based allocations even further by embedding the unicast prefix and interface identifier of the PIM-SM RP in the prefix. This gives the routing systems all the info they need to run the group in either inter- or intra-domain operation 👑 One difference from RFC 3306, though, is that hosts can't calculate their "multicast prefix" automatically (because the prefix depends on the decisions of the operator setting up the RP). So they instead require an assignment method 🙃

All the IPv6 unicast-prefix-based allocation techniques provide a sufficient amount of multicast address space for network operators 🌸

2.2. Administratively Scoped Allocation 🚧

Administratively scoped multicast address allocation [RFC2365] comes in two flavours: under 239.0.0.0/8 in IPv4, or through 4-bit encoding in the IPv6 multicast address prefix [RFC4291] 🎀

Since IPv6 administratively scoped allocations can be handled with unicast-prefix-based multicast addressing (as described in Section 2.1.2), we'll only talk about IPv4 in this section 💅

The IPv4 administratively scoped prefix 239.0.0.0/8 is further divided into Local Scope (239.255.0.0/16) and Organization Local Scope (239.192.0.0/14). Other parts of the administrative scopes are either reserved for expansion or undefined [RFC2365]. However, RFC 2365 is ambiguous about whether enterprises or the IETF are allowed to expand that space 🤔

If you're operating under a single administration, you can easily use scoped multicast addresses for your internal groups ✨ Groups that need to be shared between multiple routing domains (even if they aren't propagated through the Internet) are more of a problem. They typically need a global multicast address assignment, because their scope is undefined 🫶

There are a ton of multicast applications (like "Norton Ghost") that are restricted either to a link or a site, and it's extremely undesirable to propagate them any further, beyond the link or the site 😭 A lot of these applications have been given a static IANA address assignment, or have hijacked one. Since assignments to locally used applications come from the same range as global applications, implementing proper propagation limiting is challenging 🥲 Filtering would be easier if a separate, identifiable range were used for such assignments in the future. That's an area for further future work 🔮

There has also been work on a protocol to automatically discover multicast scope zones [RFC2776], but it has never been widely implemented or deployed 💀

2.3. Static IANA Allocation 🎀

okay so in some rare cases, organizations have managed to snag static multicast address allocations (up to 256 addresses) straight from IANA 😭. Usually these were meant as a block of static assignments for multicast applications, as described in Section 3.4.1. If there's another way to get addresses, that approach is preferable 💅.

Especially for operators that only have a 32-bit AS number and need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the previous so-called "EGLOP" block) is an option [RFC5771] 🦋.

2.4. Dynamic Allocation 🧚

bestie, this one's a whole saga ✨. RFC 2908 [RFC2908] proposed three different layers of multicast address allocation and assignment, where layer 3 (inter-domain allocation) and layer 2 (intra-domain allocation) could be applicable here. The Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an example of the former, and the Multicast Address Allocation Protocol (AAP) [MALLOC-AAP] (abandoned in 2000 due to lack of interest and technical problems) is an example of the latter 🥀.

Both of the proposed allocation protocols were quite complex, and they have never been deployed or seriously implemented 💀.

It can be concluded that dynamic multicast address allocation protocols provide no benefit beyond GLOP/unicast-prefix-based mechanisms, and they have been abandoned 🙈.

3. Multicast Address Assignment 🌸

okay now we're on assignment, which is the "who gets which address" part 👑. There are a number of possible ways for an application, node, or set of nodes to learn a multicast address, as described below.

Any IPv6 address assignment method should be aware of the guidelines for the assignment of group-IDs for IPv6 multicast addresses [RFC3307] 📝.

3.1. Derived Assignment 🍓

there are way fewer options for derived address assignment compared to derived allocation, ngl 😩. Derived multicast assignment has only been specified for IPv6 link-scoped multicast [RFC4489], where the EUI64 is embedded in the multicast address. This gives a node its own unique multicast addresses for link-local ASM communications ✨.

3.2. SSM Assignment inside the Node 💜

while SSM multicast addresses only have local (to the node) significance, there's still a minor issue: how do you assign addresses between the applications running on the same IP address? 🤔

This isn't really considered a problem, because the addresses for these applications are typically selected manually or statically. But if it's done using an Application Programming Interface (API), the API could check that the addresses don't conflict before assigning one 🫶.

3.3. Manually Configured Assignment 🌷

with manually configured assignment, a network operator who has a multicast address prefix assigns the multicast group addresses to the requesting nodes using a manual process 📞.

Typically, the user or administrator who wants to use a multicast address for a particular application asks the network operator for one by phone, email, or similar means. The network operator then gives the user a multicast address. After that, the user or administrator of the node or application manually configures the application to use the assigned address 💌.

This is a relatively simple process. It has been sufficient for certain applications that need manual configuration anyway, or that cannot or do not want to justify a static IANA assignment 🙌. Manual assignment works when the number of participants in a group is small, since each participant has to be manually configured 🐣.

This is the most commonly used technique when the multicast application does not have a static IANA assignment 🏆.

3.4. Static IANA Assignment 🪄

in contrast to manually configured assignment, static IANA assignment means getting an assignment for the particular application directly from IANA. There are two main forms of IANA assignment: global and scope-relative. Guidelines for IANA are described in [RFC5771] 📚.

3.4.1. Global IANA Assignment 🌍

globally unique address assignment is seen as lucrative 💰, because it's the simplest approach for application developers. They can hard-code the multicast address. Hard-coding requires no lease of the usable multicast address, and the client applications don't need to perform any kind of service discovery (but they depend on hard-coded addresses). However, there's an architectural scaling problem with this approach, because it encourages a "land-grab" of the limited multicast address space 😤.

3.4.2. Scope-Relative IANA Assignment 🦄

IANA also assigns numbers as an integer offset from the highest address in each IPv4 administrative scope, as described in [RFC2365] 🧮. For example, the SLPv2 discovery scope-relative offset is "2". So the SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is "239.255.255.253", and within the IPv4 Organization Local-Scope (239.192.0.0/14), it is "239.195.255.253". And so on 🫠.

Similar scope-relative assignments also exist with IPv6 [RFC2375]. IPv6 multicast addresses have much more flexible scoping, so scope-relative assignments are also applicable to global scopes. The assignment policies are described in [RFC3307] 🌈.

3.5. Dynamic Assignments 💫

Layer 1 as defined in RFC 2908 [RFC2908] described dynamic assignment from Multicast Address Allocation Servers (MAAS) to applications and nodes, with the Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] as an example. Since then, other mechanisms have also been proposed (e.g., DHCPv6 assignment [MCAST-DHCPv6]), but these have not gained traction 😢.

It would be rather straightforward to deploy a dynamic assignment protocol that leases group addresses based on a multicast prefix to applications that want to use multicast. However, only a few have implemented MADCAP (i.e., it is not significantly deployed). It is not clear whether the sparse deployment is due to a lack of need for the protocol. Moreover, it is not clear how widely the APIs for communication between the multicast application and the MADCAP client operating at the host have been implemented [RFC2771] 🤷‍♀️.

An entirely different approach is the Session Announcement Protocol (SAP) [RFC2974] 📣. In addition to advertising global multicast sessions, the protocol also has associated ranges of addresses for both IPv4 and IPv6 that SAP-aware applications can use to create new groups and new group addresses. Creating a session (and obtaining an address) is a rather tedious process, which is why it isn't done all that often 🥱. It's also worth noting that the IPv6 SAP address is unroutable in the inter-domain multicast 🚫.

Conclusions about dynamic assignment protocols are that:

  1. multicast is not significantly attractive in the first place,
  2. most applications have a static IANA assignment and thus require no dynamic or manual assignment,
  3. those applications that cannot be easily satisfied with IANA or manual assignment (i.e., where dynamic assignment would be desirable) are rather marginal, or
  4. there are other reasons why dynamic assignments are not seen as a useful approach (for example, issues related to service discovery/rendezvous) 🫣.

In consequence, more work on rendezvous/service discovery would be needed to make dynamic assignments more useful 🔮.

4. Summary and Future Directions 🏁

this section sums up everything we've been talking about in this memo, and it also drops some potential future directions 👀✨.

4.1. Prefix Allocation 🎂

here's the summary of prefix allocation methods for ASM, shown in Figure 1 📊.

    +-------+--------------------------------+--------+--------+
    | Sect. | Prefix allocation method       | IPv4   | IPv6   |
    +-------+--------------------------------+--------+--------+
    | 2.1.1 | Derived: GLOP                  |  Yes   | NoNeed*|
    | 2.1.2 | Derived: Unicast-prefix-based  |   No   |  Yes   |
    |  2.2  | Administratively scoped        |  Yes   | NoNeed*|
    |  2.3  | Static IANA allocation         |  Yes** |   No   |
    |  2.4  | Dynamic allocation protocols   |   No   |   No   |
    +-------+--------------------------------+--------+--------+
    *  = the need satisfied by IPv6 unicast-prefix-based allocation
    ** = mainly using the AD-HOC block III (formerly called "EGLOP")

                             Figure 1
  • Only ASM is affected by the assignment/allocation issues 🎯.
  • With IPv4, GLOP allocations provide a sufficient IPv4 multicast allocation mechanism for those that have a 16-bit AS number. IPv4 unicast-prefix-based allocation offers some addresses. IANA is also allocating from the AD-HOC block III (formerly called "EGLOP"), especially with 32-bit AS number holders in mind. Administratively scoped allocations provide the opportunity for internal IPv4 allocations 🧁.
  • With IPv6, unicast-prefix-based addresses and the derivatives provide a good allocation strategy, and this also works for scoped multicast addresses 💖.
  • Dynamic allocations are too complex and unnecessary a mechanism 🙅‍♀️.

4.2. Address Assignment 🎀

here's the summary of address assignment methods, shown in Figure 2 🦋.

     +--------+--------------------------------+----------+----------+
     | Sect.  | Address assignment method      | IPv4     | IPv6     |
     +--------+--------------------------------+----------+----------+
     |  3.1   | Derived: link-scope addresses  |  No      |   Yes    |
     |  3.2   | SSM (inside the node)          |  Yes     |   Yes    |
     |  3.3   | Manual assignment              |  Yes     |   Yes    |
     |  3.4.1 | Global IANA/RIR assignment     |LastResort|LastResort|
     |  3.4.2 | Scope-relative IANA assignment |  Yes     |   Yes    |
     |  3.5   | Dynamic assignment protocols   |  Yes     |   Yes    |
     +--------+--------------------------------+----------+----------+

                                 Figure 2
  • Manually configured assignment is typical today, and it works to a sufficient degree at smaller scale 🌱.
  • Global IANA assignment has been done extensively in the past. Scope-relative IANA assignment is acceptable, but the size of the pool is not very high. Inter-domain routing of IPv6 IANA-assigned prefixes is likely going to be challenging, and as a result that approach is not very appealing 😬.
  • Dynamic assignment, e.g., MADCAP, has been implemented, but there is no wide deployment. Therefore, either there are other gaps in the multicast architecture, or there is no sufficient demand for it in the first place when manual and static IANA assignments are available. Assignments using SAP also exist but are not common, and global SAP assignment is infeasible with IPv6 🥲.
  • Derived assignments are only applicable in a fringe case of link-scoped multicast 🪐.

4.3. Future Actions 🚀

  • Multicast address discovery/"rendezvous" needs to be analyzed at more length, and an adequate solution provided. See [ADDRDISC-PROB] and [MSA-REQ] for more information 🔍.
  • The IETF should consider whether to specify more ranges of the IPv4 administratively scoped address space for static allocation for applications that should not be routed over the Internet (such as backup software, etc. -- so that these wouldn't need to use global addresses, which should never leak in any case) 🧐.
  • The IETF should consider its static IANA allocations policy, e.g., "locking it down" to a stricter policy (like "IETF Consensus") and looking at developing the discovery/rendezvous functions, if necessary 🔒.

5. Acknowledgements 🫶

Okay bestie, the big shoutout goes to Kaarle Ritvanen [RITVANEN]. Tutoring a couple of multicast papers, including the latest one by Kaarle, is what convinced the author that the multicast address assignment and allocation docs needed an update. Iconic origin story 😭✨

Multicast address allocations and assignments also got discussed at the MBONED WG session at IETF 59 [MBONED-IETF59]. Very main character moment for the topic 💜

Dave Thaler, James Lingard, and Beau Williamson gave really useful feedback on the preliminary version of this memo 🙌 Myung-Ki Shin, Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred Hoenes also suggested improvements. Y'all are the real MVPs 👑🦋

6. IANA Considerations 🎀

Okay so the IANA considerations in Sections 4.1.1 and 4.1.2 of [RFC2908] got obsoleted and are now Historic, and they were never actually implemented in the IANA registry. Not the vibe, but that's the tea 🍓💅

7. Security Considerations 🔥

Bestie, this part is short but it's giving real talk. This memo only describes different approaches to allocating and assigning multicast addresses, and this has no security considerations. The security analysis of the mentioned protocols is out of scope of this memo, so don't look for it here 🙈

BUT. Obviously, the dynamic assignment protocols in particular are inherently vulnerable to resource exhaustion attacks, as discussed, e.g., in [RFC2730]. Yikes, that's a whole plot twist 💀 Dynamic assignment is powerful, but it can be drained, so keep your guard up 😤✨

8. References 📚

8.1. Normative References

Here are the normative references, the ones you absolutely need to read. Full list, no skipping 💖

[RFC2365]   Meyer, D., "Administratively Scoped IP Multicast",
            BCP 23, RFC 2365, July 1998.

[RFC3180]   Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
            BCP 53, RFC 3180, September 2001.

[RFC3306]   Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
            Multicast Addresses", RFC 3306, August 2002.

[RFC3307]   Haberman, B., "Allocation Guidelines for IPv6 Multicast
            Addresses", RFC 3307, August 2002.

[RFC3956]   Savola, P. and B. Haberman, "Embedding the Rendezvous
            Point (RP) Address in an IPv6 Multicast Address",
            RFC 3956, November 2004.

[RFC4291]   Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 4291, February 2006.

[RFC4489]   Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
            Generating Link-Scoped IPv6 Multicast Addresses",
            RFC 4489, April 2006.

[RFC4607]   Holbrook, H. and B. Cain, "Source-Specific Multicast for
            IP", RFC 4607, August 2006.

[RFC5771]   Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines
            for IPv4 Multicast Address Assignments", BCP 51,
            RFC 5771, March 2010.

[RFC6034]   Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
            Addresses", RFC 6034, October 2010.

8.2. Informative References

These ones are the extra-credit reading, bestie 🧚 Some are still Work in Progress, so they might change.

[ADDRDISC-PROB]
            Savola, P., "Lightweight Multicast Address Discovery
            Problem Space", Work in Progress, March 2006.

[MALLOC-AAP]
            Handley, M. and S. Hanna, "Multicast Address Allocation
            Protocol (AAP)", Work in Progress, June 2000.

[MBONED-IETF59]
            "MBONED WG session at IETF59",
            <http://www.ietf.org/proceedings/04mar/172.htm>.

[MCAST-DHCPv6]
            Durand, J., "IPv6 multicast address assignment with
            DHCPv6", Work in Progress, February 2005.

[MSA-REQ]   Asaeda, H. and V. Roca, "Requirements for IP Multicast
            Session Announcement", Work in Progress, March 2010.

[RFC2131]   Droms, R., "Dynamic Host Configuration Protocol",
            RFC 2131, March 1997.

[RFC2375]   Hinden, R. and S. Deering, "IPv6 Multicast Address
            Assignments", RFC 2375, July 1998.

[RFC2730]   Hanna, S., Patel, B., and M. Shah, "Multicast Address
            Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
            December 1999.

[RFC2771]   Finlayson, R., "An Abstract API for Multicast Address
            Allocation", RFC 2771, February 2000.

[RFC2776]   Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
            Zone Announcement Protocol (MZAP)", RFC 2776, February
            2000.

[RFC2908]   Thaler, D., Handley, M., and D. Estrin, "The Internet
            Multicast Address Allocation Architecture", RFC 2908,
            September 2000.

[RFC2909]   Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
            Kumar, S., and D. Thaler, "The Multicast Address-Set
            Claim (MASC) Protocol", RFC 2909, September 2000.

[RFC2974]   Handley, M., Perkins, C., and E. Whelan, "Session
            Announcement Protocol", RFC 2974, October 2000.

[RFC3315]   Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
            C., and M. Carney, "Dynamic Host Configuration Protocol
            for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC4893]   Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
            Number Space", RFC 4893, May 2007.

[RITVANEN]  Ritvanen, K., "Multicast Routing and Addressing", HUT
            Report, Seminar on Internetworking, May 2004,
            <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.

Author's Address 🌸

Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland

EMail: psavola@funet.fi
📦 where this page comes from