IPv6 Multicast Address Assignments
The registry of reserved IPv6 multicast group addresses and their purposes.
Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, <https://www.rfc-editor.org/info/rfc2375>.
@misc{rfc2375,
series = {Request for Comments},
number = 2375,
howpublished = {RFC 2375},
publisher = {RFC Editor},
doi = {10.17487/RFC2375},
url = {https://www.rfc-editor.org/info/rfc2375},
author = {R. Hinden and S. Deering},
title = {{IPv6 Multicast Address Assignments}},
pagetotal = 8,
year = 1998,
month = jul,
} RFC text
Contents
Network Working Group R. Hinden
Request for Comments: 2375 Ipsilon Networks
Category: Informational S. Deering
Cisco
July 1998
IPv6 Multicast Address Assignments
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1.0 Introduction
This document defines the initial assignment of IPv6 multicast
addresses. It is based on the "IP Version 6 Addressing Architecture"
[ADDARCH] and current IPv4 multicast address assignment found in
<ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
It adapts the IPv4 assignments that are relevant to IPv6 assignments.
IPv4 assignments that were not relevant were not converted into IPv6
assignments. Comments are solicited on this conversion.
All other IPv6 multicast addresses are reserved.
Sections 2 and 3 specify reserved and preassigned IPv6 multicast
addresses.
[ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
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. Fixed Scope Multicast Addresses
These permanently assigned multicast addresses are valid over a
specified scope value.
2.1 Node-Local Scope
FF01:0:0:0:0:0:0:1 All Nodes Address [ADDARCH]
FF01:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
2.2 Link-Local Scope
FF02:0:0:0:0:0:0:1 All Nodes Address [ADDARCH]
FF02:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
FF02:0:0:0:0:0:0:3 Unassigned [JBP]
FF02:0:0:0:0:0:0:4 DVMRP Routers [RFC1075,JBP]
FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy]
FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy]
FF02:0:0:0:0:0:0:7 ST Routers [RFC1190,KS14]
FF02:0:0:0:0:0:0:8 ST Hosts [RFC1190,KS14]
FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080]
FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci]
FF02:0:0:0:0:0:0:B Mobile-Agents [Bill Simpson]
FF02:0:0:0:0:0:0:D All PIM Routers [Farinacci]
FF02:0:0:0:0:0:0:E RSVP-ENCAPSULATION [Braden]
FF02:0:0:0:0:0:1:1 Link Name [Harrington]
FF02:0:0:0:0:0:1:2 All-dhcp-agents [Bound,Perkins]
FF02:0:0:0:0:1:FFXX:XXXX Solicited-Node Address [ADDARCH]
2.3 Site-Local Scope
FF05:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
FF05:0:0:0:0:0:1:3 All-dhcp-servers [Bound,Perkins]
FF05:0:0:0:0:0:1:4 All-dhcp-relays [Bound,Perkins]
FF05:0:0:0:0:0:1:1000 Service Location [RFC2165]
-FF05:0:0:0:0:0:1:13FF
3.0 All Scope Multicast Addresses
These permanently assigned multicast addresses are valid over all
scope ranges. This is shown by an "X" in the scope field of the
address that means any legal scope value.
Note that, as defined in [ADDARCH], IPv6 multicast addresses which
are only different in scope represent different groups. Nodes must
join each group individually.
The IPv6 multicast addresses with variable scope are as follows:
FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [ADDARCH]
FF0X:0:0:0:0:0:0:100 VMTP Managers Group [RFC1045,DRC3]
FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1]
FF0X:0:0:0:0:0:0:102 SGI-Dogfight [AXC]
FF0X:0:0:0:0:0:0:103 Rwhod [SXD]
FF0X:0:0:0:0:0:0:104 VNP [DRC3]
FF0X:0:0:0:0:0:0:105 Artificial Horizons - Aviator [BXF]
FF0X:0:0:0:0:0:0:106 NSS - Name Service Server [BXS2]
FF0X:0:0:0:0:0:0:107 AUDIONEWS - Audio News Multicast [MXF2]
FF0X:0:0:0:0:0:0:108 SUN NIS+ Information Service [CXM3]
FF0X:0:0:0:0:0:0:109 MTP Multicast Transport Protocol [SXA]
FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3]
FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3]
FF0X:0:0:0:0:0:0:110 MUSIC-SERVICE [Guido van Rossum]
FF0X:0:0:0:0:0:0:111 SEANET-TELEMETRY [Andrew Maffei]
FF0X:0:0:0:0:0:0:112 SEANET-IMAGE [Andrew Maffei]
FF0X:0:0:0:0:0:0:113 MLOADD [Braden]
FF0X:0:0:0:0:0:0:114 any private experiment [JBP]
FF0X:0:0:0:0:0:0:115 DVMRP on MOSPF [Moy]
FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades]
FF0X:0:0:0:0:0:0:117 XINGTV <hgxing@aol.com>
FF0X:0:0:0:0:0:0:118 microsoft-ds <arnoldm@microsoft.com>
FF0X:0:0:0:0:0:0:119 nbc-pro <bloomer@birch.crd.ge.com>
FF0X:0:0:0:0:0:0:11A nbc-pfn <bloomer@birch.crd.ge.com>
FF0X:0:0:0:0:0:0:11B lmsc-calren-1 [Uang]
FF0X:0:0:0:0:0:0:11C lmsc-calren-2 [Uang]
FF0X:0:0:0:0:0:0:11D lmsc-calren-3 [Uang]
FF0X:0:0:0:0:0:0:11E lmsc-calren-4 [Uang]
FF0X:0:0:0:0:0:0:11F ampr-info [Janssen]
FF0X:0:0:0:0:0:0:120 mtrace [Casner]
FF0X:0:0:0:0:0:0:121 RSVP-encap-1 [Braden]
FF0X:0:0:0:0:0:0:122 RSVP-encap-2 [Braden]
FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades]
FF0X:0:0:0:0:0:0:124 rln-server [Kean]
FF0X:0:0:0:0:0:0:125 proshare-mc [Lewis]
FF0X:0:0:0:0:0:0:126 dantz [Yackle]
FF0X:0:0:0:0:0:0:127 cisco-rp-announce [Farinacci]
FF0X:0:0:0:0:0:0:128 cisco-rp-discovery [Farinacci]
FF0X:0:0:0:0:0:0:129 gatekeeper [Toga]
FF0X:0:0:0:0:0:0:12A iberiagames [Marocho]
FF0X:0:0:0:0:0:0:201 "rwho" Group (BSD) (unofficial) [JBP]
FF0X:0:0:0:0:0:0:202 SUN RPC PMAPPROC_CALLIT [BXE1]
FF0X:0:0:0:0:0:2:0000
-FF0X:0:0:0:0:0:2:7FFD Multimedia Conference Calls [SC3]
FF0X:0:0:0:0:0:2:7FFE SAPv1 Announcements [SC3]
FF0X:0:0:0:0:0:2:7FFF SAPv0 Announcements (deprecated) [SC3]
FF0X:0:0:0:0:0:2:8000
-FF0X:0:0:0:0:0:2:FFFF SAP Dynamic Assignments [SC3]
5.0 References
[ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Work in Progress.
[RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
Specification", RFC 1045, February 1988.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, November
1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, Stanford University, August 1989.
[RFC1119] Mills, D., "Network Time Protocol (Version 1),
Specification and Implementation", STD 12, RFC 1119, July
1988.
[RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
[RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
"Service Location Protocol", RFC 2165 June 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
6. People
<arnoldm@microsoft.com>
[AXC] Andrew Cherenson <arc@SGI.COM>
[Braden] Bob Braden, <braden@isi.edu>, April 1996.
[Bob Brenner]
[Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
<bloomer@birch.crd.ge.com>
[Bound] Jim Bound <bound@zk3.dec.com>
[BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
[BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
[BXS2] Bill Schilit <schilit@parc.xerox.com>
[Casner] Steve Casner, <casner@isi.edu>, January 1995.
[CXM3] Chuck McManis <cmcmanis@sun.com>
[Tim Clark]
[DLM1] David Mills <Mills@HUEY.UDEL.EDU>
[DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
[DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
[Farinacci] Dino Farinacci, <dino@cisco.com>
[GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
[Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
<hgxing@aol.com>
[IANA] IANA <iana@iana.org>
[Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
[JBP] Jon Postel <postel@isi.edu>
[JXM1] Jim Miner <miner@star.com>
[Kean] Brian Kean, <bkean@dca.com>, August 1995.
[KS14] <mystery contact>
[Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
[Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
[Malamud] Carl Malamud, <carl@radio.com>, January 1996.
[Andrew Maffei]
[Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
[Moy] John Moy <jmoy@casc.com>
[MXF2] Martin Forssen <maf@dtek.chalmers.se>
[Perkins] Charlie Perkins, <cperkins@corp.sun.com>
[Guido van Rossum]
[SC3] Steve Casner <casner@isi.edu>
[Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
[Joel Snyder]
[SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
[SXD] Steve Deering <deering@PARC.XEROX.COM>
[tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
[Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
[Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
[Veizades] John Veizades, <veizades@tgv.com>, May 1995.
[Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
7.0 Security Considerations
This document defines the initial assignment of IPv6 multicast
addresses. As such it does not directly impact the security of the
Internet infrastructure or its applications.
8.0 Authors' Addresses
Robert M. Hinden
Ipsilon Networks, Inc.
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: +1 415 990 2004
EMail: hinden@ipsilon.com
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527-8213
EMail: deering@cisco.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
AI ELI5
On this page
§1Multicast Addresses in IPv6
Multicast in IP networks allows a sender to transmit one packet to many receivers simultaneously. Instead of sending separate unicast packets to each recipient, a sender addresses a single multicast group address. Routers forward that packet to all networks with at least one listener on that group. Receivers signal their interest using a group membership protocol (IGMP for IPv4, MLD for IPv6).
Multicast is useful for broadcast-like services: all routers on a link need to hear OSPF routing updates, all DHCP clients need to discover DHCP servers, all nodes in a multimedia conference need each other's video streams. Without multicast, the sender would have to send individual copies to each recipient, wasting bandwidth.
IPv6 multicast addresses are allocated from a reserved portion of the address space. The first octet (FF in hex) identifies an address as multicast. Within the multicast space, addresses are allocated hierarchically: some are permanently reserved for specific protocols, others are allocated dynamically to applications, and some ranges are left unassigned for future use.
Multicast is like shouting in a stadium so everyone interested hears you at once, instead of calling each person individually. IPv6 sets aside special addresses that mean "all routers" or "all DHCP servers" so devices can find them without asking.
§2Scope Boundaries and Allocation Strategy
IPv6 multicast addresses include a scope field that limits how far the packet travels. Node-local scope means the packet does not leave the sending computer. Link-local scope means the packet reaches only the local Ethernet segment (or wireless LAN); routers do not forward it further. Site-local scope reaches all computers within a site (organization), but not beyond to the internet. Global scope allows packets to be routed across the entire internet.
The allocation strategy preserves interoperability. Link-local addresses (FF02::/16) are reserved for protocols that must work automatically without manual configuration: all nodes on a link need to receive Router Advertisements, DHCP server discovery, and OSPF updates. Well-known addresses like FF02::1 (all nodes) and FF02::2 (all routers) are fixed. Specific link-local groups are assigned to protocols: FF02::5 for OSPF routers, FF02::9 for RIP routers, FF02::D for PIM routers.
Global multicast addresses (FF0X::/16 with variable scope) allow applications to operate across the internet. Some are permanently assigned to services like NTP (FF0X::101) and multimedia conferences (FF0X:0:0:0:0:0:2:0000 through FF0X:0:0:0:0:0:2:7FFF). Others are left unassigned for dynamic allocation or experimental use.
Some multicast addresses only work on your local network (link-local), some work within your organization (site-local), and some work globally across the internet. The registry reserves certain addresses for each protocol so they don't collide.
- IPv6 Multicast (FF00::/8)
- Node-Local (FF01::/16)
- FF01::1 All Nodes
- FF01::2 All Routers
- Link-Local (FF02::/16)
- FF02::1 All Nodes
- FF02::2 All Routers
- FF02::5 OSPF Routers
- FF02::9 RIP Routers
- Site-Local (FF05::/16)
- FF05::2 All Routers
- FF05::1:3 DHCP Servers
- Global (FF0X::/16, variable scope)
- FF0X::101 NTP
- FF0X::2:0-7FFF Multimedia Conferences
- FF0X::2:7FFE SAP Announcements
- Node-Local (FF01::/16)
§3The Address Registry
The RFC documents the initial assignments across multiple scope levels. Link-local scope (FF02::/16) allocates addresses for automatic protocols. FF02::1 and FF02::2 are all-nodes and all-routers addresses required by IPv6. Routing protocols each get a reserved address: OSPFIGP uses FF02::5 and FF02::6, RIPng uses FF02::9, EIGRP uses FF02::A. Service discovery protocols like Service Location (SLP) are assigned to FF05::116 (site-local).
Global multicast addresses include assignments to well-known services. NTP (Network Time Protocol) uses FF0X::101. Multimedia conference calls use a large range (FF0X:0:0:0:0:0:2:0000 through FF0X:0:0:0:0:0:2:7FFF). Session Announcement Protocol (SAP) announcements use FF0X:0:0:0:0:0:2:7FFE and FF0X:0:0:0:0:0:2:7FFF.
The document notes that IPv4 multicast conventions have been adapted where relevant; IPv4 assignments that do not apply to IPv6 (such as some legacy protocols) are omitted. The registry is structured to allow for future expansion: undefined ranges are reserved rather than assigned, permitting IANA to allocate them for new services without revising this document.
The registry is a phone book. FF02::5 is OSPF routers' number. FF02::101 is NTP's number. When a router boots, it sends to FF02::2 and says "I'm here, give me a routing update". No coordination needed because everyone uses the same numbers.
§4Compatibility and Future Allocation
The RFC is based on the IPv6 Addressing Architecture (RFC 2373) and adapted from IPv4 multicast address assignments in the IANA registry. The goal is to ensure that IPv6 multicast implementations can be compatible with existing IPv4 deployments where the protocols are the same. For example, both IPv4 and IPv6 OSPF use their respective multicast addresses, so a dual-stack router (supporting both IPv4 and IPv6) can participate in multicast on each address family.
One key principle: addresses that differ only in scope represent different groups. FF01::1 (all nodes, node-local scope) is a different multicast group from FF02::1 (all nodes, link-local scope), even though both carry the same logical meaning. A node that wants to join both must join each address separately.
The RFC does not prescribe the mechanism for allocating unassigned ranges; it defers to IANA procedures and to the IPv6 Addressing Architecture for rules on how new addresses should be assigned. This forward-looking approach allows the registry to grow as IPv6 and new multicast applications evolve.
The registry is designed so IPv6 multicast works like IPv4 multicast where they overlap. Both support OSPF routers at their respective multicast addresses. When new services need addresses, IANA can assign them without breaking this document.