Dynamic Internet Multicast Tunneling
draft-zzhang-mboned-dynamic-internet-mcast-tunnel-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhaohui (Jeffrey) Zhang , Lenny Giuliano , Brad Tarno , Chris Lenart | ||
| Last updated | 2026-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zzhang-mboned-dynamic-internet-mcast-tunnel-00
mboned Z. Zhang
Internet-Draft L. Giuliano
Intended status: Standards Track HPE
Expires: 3 September 2026 B. Tarno
Disney
C. Lenart
Verizon
2 March 2026
Dynamic Internet Multicast Tunneling
draft-zzhang-mboned-dynamic-internet-mcast-tunnel-00
Abstract
This document specifies a mechanism to facilitate widespread
multicast connectivity over the Global Internet via dynamic
tunneling, enabling many different multicast islands to be connected
by tunnels between both PIM routers and AMT gateways/relays.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 September 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 3 September 2026 [Page 1]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Upstream Multicast Hop Extended Community (UMH EC) . . . 6
3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6
4. Operational Considerations . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
IP Multicast requires every Layer 3 hop between source and receivers
to be multicast-enabled. This requirement has always been a
significant barrier to deployment of multicast over the Global
Internet as it essentially requires enabling a multicast routing
protocol on every interface on every router and firewall between all
hosts to achieve ubiquitous availability.
To overcome this hurdle, network overlays (or tunnels) have been used
to connect multicast-enabled routers/hosts that are separated by
unicast-only parts of the network. For example, the original
Multicast Backbone (MBONE) was constructed in the 1990s as a network
of multicast-enabled devices connected together by GRE tunnels across
the Internet. But these GRE tunnels were onerous to manage as they
require static configuration and coordination on both ends, plus
unicast routing protocols like BGP, ISIS and OSPF to be run through
the tunnels so that Reverse-Path Forwarding (RPF) would operate
properly. Subsequent efforts in the early 2000s focused on native
multicast deployment across the Internet, but these efforts
inevitably fell short of global ubiquity.
Zhang, et al. Expires 3 September 2026 [Page 2]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
Automatic Multicast Tunneling (AMT) [RFC7450] was later created as a
dynamic tunneling mechanism to overcome the operational shortcomings
of static tunneling protocols like GRE. AMT was initially motivated
to solve the "last-mile" problem, where receivers on unicast-only
networks (AMT gateways) could dynamically build tunnels to devices at
the edge of multicast-enabled parts of the network (AMT Relays) and
receive multicast content without any dependencies on their local
service provider. AMT and SSM combined together to form TreeDN
[RFC9706], a tree-based CDN architecture that addressed the
operational challenges of multicast over the Global Internet. TreeDN
used SSM as a simplified deployment option for efficiently delivering
multicast content from the source to the border of the multicast-
enabled domain, with AMT providing availability in the "last-mile" by
delivering this content to receivers on unicast-only networks.
Over time, there has been a growing interest in using AMT in the
"middle-mile" to connect multicast "islands" that are separated by
unicast-only transit networks. Strictly speaking, AMT has always had
the ability to build router-router tunnels, in addition to router-
host tunnels. But because no unicast-routing protocols can run
through the AMT tunnels (IGMP is the only control plane protocol that
can run through an AMT tunnel), determining source reachability (RPF)
is a problem when there are potentially many different AMT relays to
choose from, with no obvious way for a transit router acting as AMT
Gateway to know which AMT relay has multicast connectivity to a
particular source. DRIAD [RFC8777] was proposed to address the AMT
Relay discovery problem, but this solution has dependencies on the
receiver’s local service provider- essentially assuming the "last-
mile" supports multicast (and DRIAD). Further, DRIAD is more
suitable for hosts, not core routers, acting as AMT GWs.
In addition, for the multicast routers running PIM-SSM [RFC7761] over
the tunnels between them, it is desired to make the tunnel management
automatic, and remove the need for exchanging RPF routes over the
tunnels.
This document specifies a mechanism for extending the TreeDN
architecture to facilitate widespread multicast connectivity over the
Global Internet via dynamic tunneling in the "middle-mile", enabling
many different multicast islands to be connected by tunnels between
both PIM routers and AMT gateways/relays.
This solution provides the benefits of dynamically created tunnels
(i.e., no manual configuration on the tunnel endpoints, as was needed
with GRE) while providing reachability info regarding which sources
could be reached behind which routers/relays.
Zhang, et al. Expires 3 September 2026 [Page 3]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
2. Mode of Operation
Consider the following topology with five ASes:
GWs | |
||| | |
src ||| | GWs | GWs
| RL1+ | ||| | |||
| PIM2 | ||| | |||
PIM1 | PIM7+RL3 | GW2+RL4
| |
PIM3+ | | ASBR5
AS100 ASBR1 | | AS400
-----------------| PIM6+ ASBR4 |-----------------
AS200 PIM4+ | ASBR3 | AS500
ASBR2 | | ASBR6
| PIM8 |
PIM5+ | |
GW1+RL2 | | GW3+ RL5+
||| | | PIM9 PIM10
||| | | |||
GWs | | |||
| AS300 | GWs
GW: AMT Gateway RL: AMT Relay
* All devices with + in the title are single routers serving
multiple functions. So PIM5+GW1+RL2 is a PIM router that also
functions as both AMT GW and AMT Relay.
* The source is connected to router PIM1 in AS100. There are
several local receivers connected as AMT GWs off RL1+PIM2, which
is a PIM neighbor of PIM1.
* In AS200, PIM4+ASBR2 is a PIM neighbor of PIM3+ASBR1 in AS100.
There are several local receivers connected as AMT GWs to
PIM5+GW1+RL2, which runs both PIM and AMT GW (it could receive
traffic from either PIM4+ASBR2 natively or from RL1-PIM2 via AMT
or from both).
* In AS300, PIM6+ASBR3 runs PIM but ASBR4 does not. PIM7+RL3 has
receivers connected as AMT GWs.
* Neither ASBR5 nor ASBR6 runs PIM. In AS400, GW2+RL4, has several
local receivers connected as AMT GWs, and joins upstream as an AMT
GW connected to PIM7+RL3 in AS300. GW2+RL4 serves as an IGMP
proxy since it sends IGMP reports upstream based on the IGMP
reports/PIM joins it receives from hosts/routers downstream.
Zhang, et al. Expires 3 September 2026 [Page 4]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
* In AS500, GW3+PIM9 receives traffic from either PIM7+RL3 via AMT
(PIM->IGMP proxy) or from PIM8 via a dynamic PIM tunnel.
RL5+PIM10 receives traffic from GW3+PIM9, and forwards that
traffic to local receivers connected as AMT GWs.
When PIM3+ASBR1 advertises the route for the source to PIM4+ASBR2 and
PIM6+ASBR3, it includes an Upstream Multicast Hop (UMH) Extended
Community (EC) that encodes RL1+PIM2’s address as an AMT relay, so
that downstream routers know that RL1+PIM2 can be used as the AMT
relay for multicast traffic from the source prefix.
Suppose PIM4+ASBR2 re-advertises the source's BGP route to
PIM5+GW1+RL2 with the EC attached. When PIM5+GW1+RL2 receives IGMP
joins from its own downstream AMT GWs, it does the RPF lookup and
finds the route with the UMH EC specifying the RL1+PIM2 as the AMT
relay. The route also resolves to the next hop router PIM4+ASBR2, so
PIM5+GW1+RL2 can choose to pull traffic either via PIM from
PIM4+ASBR2, or via AMT from RL1+PIM2. In the latter case,
PIM5+GW1+RL2 is an AMT GW of RL1+PIM2.
When PIM7+RL3 in AS300 receives IGMP joins from its own downstream
AMT GWs, since it is not an AMT GW-capable router, it can only
receive traffic natively from PIM6+ASBR3.
Notice that ASBR4/5/6 do not run PIM in this example. Suppose that
when ASBR4 re-advertises the route for the source to ASBR5/6, it
keeps the UMH EC unchanged or changes it to encode PIM7+RL3's
address, and add another UMH EC that encodes PIM8's address as a PIM
router.
Suppose ASBR5/6 re-advertises the route to GW2+RL4 and RL5+PIM10,
respectively, keeping the UMH EC. GW2+RL4 will serve as IGMP proxy
to PIM7+RL3 via AMT, while RL5+PIM10 sends a PIM join toward
GW3+PIM9. Either RL5+PIM10 or GW3+PIM9 may directly send PIM joins
to PIM8 over a dynamic tunnel, using the PIM-lite mode [RFC9739]
where a PIM adjacency is not required.
There are a few key points to note here:
* A router that receives IGMP joins (via AMT or natively) or PIM
joins needs to either have a direct upstream PIM neighbor toward
the source/ UMH, or be able to establish an AMT or PIM tunnel to a
remote UMH.
* The remote UMHs for a multicast source may be learned from the UMH
EC attached to the BGP routes, may be provisioned locally, or may
be learned from the PIM RPF Vector attribute [RFC5496] in PIM
joins from the downstream.
Zhang, et al. Expires 3 September 2026 [Page 5]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
3. Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3.1. Upstream Multicast Hop Extended Community (UMH EC)
The UMH EC is an IPv4 Address Specific Extended Community with a sub-
type TBD1 (Section 6) to be assigned by IANA, or an IPv6 Address
Specific Extended Community with a type TBD2 (Section 6) to be
assigned by IANA.
The Global Admin Field of the EC encodes the address of the UMH. The
lower 4-bit of the Local Admin Field encodes the type of the UMH.
The next 4-bit encodes the preference of the UMH, and the remaining
upper 8-bit of the Local Admin Field is reserved and MUST be set to 0
when sending and MUST be ignored when receiving.
3.2. Procedures
When an ASBR advertises routes to its internal/external peers, it MAY
keep the existing UMH ECs unchanged, or remove some/all of them, and/
or add its own UMH ECs based local policies. The added UMH ECs MUST
be for PIM routers or AMT relays in the ASBR's own AS that accept
joins from AMT GWs or PIM routers over tunnels. When multiple UMH
ECs are added, the preference bits SHOULD be set to indicate the
preference. The higher the number, the higher preference.
A PIM router or AMT Relay may learn remote UMHs by receiving BGP
routes with the UMH ECs or from local provisioning. It may choose to
send PIM/IGMP joins over a tunnel to a remote UMH, or tunnels to more
UMHs for redundancy purposes as specified in [RFC7431] for Multicast
Only Fast ReRoute (MoFRR), or to an immediate upstream PIM router
based on RPF lookup and local policies. In the latter case, PIM RPF
Vector [RFC5496] may be used so that routers along the path only need
to do a RPF check toward the remote UMH instead of the source, so
that they do not need to learn the routes to the source.
When there are multiple UMH ECs in the route to the source, the
preference order SHOULD be determined as follows:
* If the route to a UMH address has the shortest AS_PATH, the UMH is
most preferred.
Zhang, et al. Expires 3 September 2026 [Page 6]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
* For UMHes whose routes have the same length of AS_PATH, the one
with the higher preference value in the UMH EC is preferred.
With the same AS_PATH length and preference, it does not matter which
UMH is preferred. Local policy MAY also override the preference, and
the ultimate choice only has local significance.
When AMT tunnels to the upstream are used, it behaves as an AMT GW
(in addition to PIM router or AMT relay), and IGMP proxy (from
downstream IGMP or PIM joins) procedures are followed, including the
procedures in [I-D.ietf-pim-multipath-igmpmldproxy].
While AMT defines handshake procedures for the tunnel establishment,
there are no specified procedures to establish the tunnels between
remote PIM neighbors, which operate in PIM-lite mode [RFC9739]
between them. A downstream PIM router can use any mechanism to
tunnel PIM joins to an upstream PIM router - UDP, GRE, MPLS, or BIER
[I-D.ietf-bier-pim-signaling]. The upstream PIM router can use any
mechanism to tunnel multicast data to remote downstream neighbors.
The only requirement is that downstream routers MUST be able to
associate incoming tunneled multicast data with logical interfaces
for RPF purposes. The PIM joins sent over the tunnel may carry a PIM
Join Attribute [RFC5384] to indicate the desired tunnel, which may
also help the downstream router associating the incoming traffic with
the logical interface. Details will be specified in a future
revision of this document.
4. Operational Considerations
The announcement of UMHs via BGP is like dynamic unicast routing and
the provisioning of UMHs on a router is like static unicast routing.
Care must be taken that the dynamic and static routing are consistent
to prevent multicast routing loops.
An operator should be cautious when its ASBRs add the UMH ECs when
re-advertising routes externally, because the announced UMHs may
attract many external AMT/PIM joins. AMT has security measures for
access control and protection against resource exhaustion, and many
PIM implementations also have policies to allow/deny joins for access
control. It is a reasonable practice to accept remote PIM/IGMP joins
from only neighboring or specifically allowed ASes, and with
additional fine grain control by policies.
Zhang, et al. Expires 3 September 2026 [Page 7]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
5. Security Considerations
Routers that originate or change the UMH EC MUST ensure that the UMHs
have multicast connectivity to the multicast source, whether natively
or through tunnels. Rogue routers, or those with no multicast
connectivity to the source, could create multicast blackholes by
advertising multicast reachability to the source via the UMH EC.
That said, this risk is not much different than what can occur with
any other reachability information that BGP advertises (eg, unicast
routing).
6. IANA Considerations
This document requests IANA to assign an Extended Community sub-type
of value TBD1 for Upstream Multicast Hop from the Transitive IPv4-
Address-Specific Extended Community Sub-Types registry.
This document requests IANA to assign an IPv6-Address-Specific
Extended Community type of value TBD2 from the Transitive IPv6-
Address-Specific Extended Community Types registry.
This document requests IANA to create a Upstream Multicast Hop Types
registry with the following initial allocations:
Value Description Reference
===== =========== =========
0 Reserved This Document
1 PIM This Document
2 AMT Relay This Document
3-15 Unallocated This Document
The registration procedure is "Specification Required".
7. Acknowledgments
The solution described in this document was inspired by earlier
discussions with the following people about the desire for using AMT
in the "middle mile": Jake Holland, Erik Herz, Guillaume Bichot, Omar
Ramadan and Marc Fiuczynski.
8. References
8.1. Normative References
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
Zhang, et al. Expires 3 September 2026 [Page 8]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9739] Bidgoli, H., Ed., Venaas, S., Mishra, M., Zhang, Z., and
M. McBride, "Protocol Independent Multicast Light (PIM
Light)", RFC 9739, DOI 10.17487/RFC9739, March 2025,
<https://www.rfc-editor.org/info/rfc9739>.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008,
<https://www.rfc-editor.org/info/rfc5384>.
8.2. Informative References
[RFC9706] Giuliano, L., Lenart, C., and R. Adam, "TreeDN: Tree-Based
Content Delivery Network (CDN) for Live Streaming to Mass
Audiences", RFC 9706, DOI 10.17487/RFC9706, January 2025,
<https://www.rfc-editor.org/info/rfc9706>.
[RFC8777] Holland, J., "DNS Reverse IP Automatic Multicast Tunneling
(AMT) Discovery", RFC 8777, DOI 10.17487/RFC8777, April
2020, <https://www.rfc-editor.org/info/rfc8777>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
Zhang, et al. Expires 3 September 2026 [Page 9]
Internet-Draft Dynamic Internet Nulticast Tunneling March 2026
[I-D.ietf-pim-multipath-igmpmldproxy]
Asaeda, H. and L. M. Contreras, "Multipath Support for
IGMP/MLD Proxy", Work in Progress, Internet-Draft, draft-
ietf-pim-multipath-igmpmldproxy-03, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-
multipath-igmpmldproxy-03>.
[I-D.ietf-bier-pim-signaling]
Bidgoli, H., Xu, F., Kotalwar, J., Wijnands, I., Mishra,
M. P., and Z. J. Zhang, "PIM Signaling Through BIER Core",
Work in Progress, Internet-Draft, draft-ietf-bier-pim-
signaling-13, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
pim-signaling-13>.
Authors' Addresses
Zhaohui Zhang
HPE
Email: zhaohui.zhang@hpe.com
Lenny Giuliano
HPE
Email: leonard.giuliano@hpe.com
Brad Tarno
Disney
Email: brad.tarno@disney.com
Christopher Lenart
Verizon
Email: chris.lenart@verizon.com
Zhang, et al. Expires 3 September 2026 [Page 10]