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.
ISO Plain Language
On this page
§1What This Document Assigns
This document defines the initial assignment of IPv6 multicast addresses. It is based on the IP Version 6 Addressing Architecture and on the current IPv4 multicast address assignments, and it adapts the IPv4 assignments that are relevant to IPv6. IPv4 assignments that were not relevant were not converted into IPv6 assignments, and comments are solicited on that conversion. All other IPv6 multicast addresses are reserved.
The memo points readers to two other documents. Sections 2 and 3 specify the reserved and preassigned IPv6 multicast addresses, while the Addressing Architecture defines the rules for assigning new IPv6 multicast addresses. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are used as described in RFC 2119.
The list is built by copying the IPv4 multicast registry and keeping the entries that make sense for IPv6. The rest of the address space is left free for later.
§2Fixed Scope Multicast Addresses
These are permanently assigned multicast addresses that are valid over a specified scope value. The first group is the node-local scope, where the group is confined to a single node: FF01:0:0:0:0:0:0:1 is the All Nodes Address and FF01:0:0:0:0:0:0:2 is the All Routers Address.
The link-local scope covers the addresses that matter only on one link. The list holds the All Nodes Address at FF02:0:0:0:0:0:0:1 and the All Routers Address at FF02:0:0:0:0:0:0:2, with FF02:0:0:0:0:0:0:3 left unassigned. Then come the addresses used by routing and management protocols: DVMRP Routers at FF02:0:0:0:0:0:0:4, OSPFIGP at FF02:0:0:0:0:0:0:5, OSPFIGP Designated Routers at FF02:0:0:0:0:0:0:6, ST Routers at FF02:0:0:0:0:0:0:7, ST Hosts at FF02:0:0:0:0:0:0:8, RIP Routers at FF02:0:0:0:0:0:0:9, EIGRP Routers at FF02:0:0:0:0:0:0:A, Mobile-Agents at FF02:0:0:0:0:0:0:B, All PIM Routers at FF02:0:0:0:0:0:0:D and RSVP-ENCAPSULATION at FF02:0:0:0:0:0:0:E. There are also the Link Name address at FF02:0:0:0:0:0:1:1 and All-dhcp-agents at FF02:0:0:0:0:0:1:2. The last entry of this scope is the Solicited-Node Address, FF02:0:0:0:0:0:1:FFXX:XXXX.
The site-local scope holds the All Routers Address at FF05:0:0:0:0:0:0:2, All-dhcp-servers at FF05:0:0:0:0:0:1:3, All-dhcp-relays at FF05:0:0:0:0:0:1:4 and Service Location at FF05:0:0:0:0:0:1:1000.
Some groups only make sense inside one machine, some only on one cable, and some inside one site. The memo gives each of those its own block of addresses, so a router on a link never sees traffic meant for a whole site.
- IPv6 multicast FF in the first two bits
- 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 OSPFIGP
- FF02::9 RIP Routers
- FF02::B Mobile-Agents
- FF02::D All PIM Routers
- FF02::E RSVP-Encapsulation
- FF02::1:2 All-dhcp-agents
- FF02::1:FFXX:XXXX Solicited-Node
- Site-local FF05::/16
- FF05::2 All Routers
- FF05::1:3 All-dhcp-servers
- FF05::1:4 All-dhcp-relays
- FF05::1:1000 Service Location
- Any scope FF0X::/8, X for any legal scope value
- FF0X::0 Reserved Multicast
- FF0X::101 Network Time Protocol
- FF0X::114 Any private experiment
- FF0X::2:0000-2:7FFD Multimedia Conference Calls
- FF0X::2:7FFE SAPv1 Announcements
- FF0X::2:8000-2:FFFF SAP Dynamic Assignments
- Node-local FF01::/16
§3All-Scope Multicast Addresses
The second family of permanently assigned addresses is valid over all scope ranges. The memo shows this with an X in the scope field of the address, meaning any legal scope value, so the addresses are written as FF0X:0:0:0:0:0:0:0 and so on.
One rule matters for anyone using these groups: as defined in the Addressing Architecture, IPv6 multicast addresses that differ only in scope represent different groups, and nodes must join each group individually. The same service is therefore a different group at each scope.
The registry itself begins with the Reserved Multicast Address at FF0X:0:0:0:0:0:0:0 and then lists services carried over from IPv4: the VMTP Managers Group at FF0X:0:0:0:0:0:0:100, the Network Time Protocol at FF0X:0:0:0:0:0:0:101, SGI-Dogfight at 102, Rwhod at 103, VNP at 104, Artificial Horizons - Aviator at 105, NSS - Name Service Server at 106, AUDIONEWS - Audio News Multicast at 107, SUN NIS+ Information Service at 108, MTP Multicast Transport Protocol at 109, the IETF audio and video groups from 10A to 10F, MUSIC-SERVICE at 110, the SEANET telemetry and image groups at 111 and 112, MLOADD at 113, any private experiment at 114, DVMRP on MOSPF at 115, SVRLOC at 116, XINGTV at 117, microsoft-ds at 118, the nbc-pro and nbc-pfn groups at 119 and 11A, the lmsc-calren groups from 11B to 11E, ampr-info at 11F, mtrace at 120, the RSVP-encap groups at 121 and 122, SVRLOC-DA at 123, rln-server at 124, proshare-mc at 125, dantz at 126, the cisco-rp groups at 127 and 128, gatekeeper at 129, iberiagames at 12A, the unofficial BSD rwho group at 201 and SUN RPC PMAPPROC_CALLIT at 202.
The list finishes with ranges rather than single addresses. Multimedia Conference Calls run from FF0X:0:0:0:0:0:2:0000 to FF0X:0:0:0:0:0:2:7FFD, SAPv1 Announcements sit at FF0X:0:0:0:0:0:2:7FFE, SAPv0 Announcements, marked deprecated, at FF0X:0:0:0:0:0:2:7FFF, and SAP Dynamic Assignments run from FF0X:0:0:0:0:0:2:8000 to FF0X:0:0:0:0:0:2:FFFF. Every entry in the list carries the name of the person or document behind it.
These groups work at any size, from one machine to the whole Internet. A group that is used at two different sizes is still two different groups, so a host has to join each one it wants.
- FF01::1All Nodes — Node-local scope.
- FF02::1All Nodes — Link-local scope.
- FF02::2All Routers — Link-local scope.
- FF02::5OSPFIGP — The OSPF routing protocol on a link.
- FF02::9RIP Routers — The RIPng routing protocol on a link.
- FF02::DAll PIM Routers — Multicast routing protocol, PIM.
- FF02::ERSVP-Encapsulation — Resource reservation encapsulation.
- FF02::1:2All-dhcp-agents — The DHCPv6 agents on a link.
- FF05::2All Routers — Site-local scope.
- FF05::1:1000Service Location — The Service Location Protocol, site-local.
- FF0X::101Network Time Protocol — Valid at any scope.
- FF0X::114Any private experiment — Valid at any scope.
- FF0X::2:7FFESAPv1 Announcements — Valid at any scope.
- FF0X::2:7FFFSAPv0 Announcements — Valid at any scope, marked deprecated.
§7Security Considerations
The memo says it defines the initial assignment of IPv6 multicast addresses, and that as such it does not directly impact the security of the Internet infrastructure or its applications.
Assigning numbers does not make anything more or less secure, and the memo says so.