RFC 5058
Explicit Multicast (Xcast) Concepts and Options
RFC 5058: Explicit Multicast (Xcast) Concepts and Options 🎀
okay bestie, this one is from November 2007 and it's an Experimental doc from the Network Working Group 🦋 The authors are R. Boivie (IBM), N. Feldman (IBM), Y. Imai (WIDE / Fujitsu), W. Livens (ESCAUX), and D. Ooms (OneSparrow). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Status of This Memo 📜
This memo defines an Experimental Protocol for the Internet community, so it's not an Internet standard of any kind 🌸 They're basically asking everyone to talk about it and suggest improvements 🫶 Distribution of this memo is unlimited, so share away! 💖
IESG Note 🙈
ngl this part is kind of a disclaimer 😭 This RFC is not a candidate for any level of Internet Standard. The IETF doesn't claim to know whether this RFC is fit for any purpose. In particular, the decision to publish it wasn't based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor picked to publish it at their own discretion. If you're thinking about implementing or deploying it, be careful and do your homework first ⚠️ The note also points you to RFC 3932 for more info.
Abstract ✨
okay so traditional IP multicast ([RFC 1112]) is great for really huge multicast groups, but it gets shaky when there's a massive number of different multicast groups 💀 This doc introduces Xcast (Explicit Multi-unicast), a brand new multicast scheme with complementary scaling properties 🧚 Xcast is built for a very large number of small multicast sessions 💜 The trick is that it puts the list of destinations right inside the data packets, instead of using a multicast group address 🍓 It's giving clever, honestly 👑
This document talks through Xcast concepts and options across several areas. It is not a complete technical specification 🎀
Table of Contents 📚
1. Introduction ....................................................3
2. Xcast Overview ..................................................4
3. The Cost of the Traditional IP Multicast Schemes ................6
4. Motivation ......................................................9
5. Application ....................................................11
6. Xcast Flexibility ..............................................12
7. Xcast Control Plane Options ....................................13
7.1. SIP Control Plane for Xcast ...............................14
7.2. Receiver-Initiated Join for Xcast .........................14
8. Optional Information ...........................................15
8.1. List of Ports .............................................15
8.2. List of DSCPs .............................................15
8.3. Channel Identifier ........................................15
9. Possible Xcast Packet Encoding .................................16
9.1. General ...................................................16
9.2. IPv4 ......................................................17
9.2.1. IPv4 Header ........................................17
9.2.2. Xcast4 Header ......................................17
9.3. IPv6 ......................................................20
9.3.1. IPv6 Header ........................................20
9.3.2. Xcast6 Header ......................................20
9.3.2.1. Routing Extension Header ..................21
9.3.2.2. Destination Extension Header ..............21
10. Impact on Upper-Layer Protocols ...............................22
10.1. Checksum Calculation in Transport-Layer Headers ..........22
10.2. IPsec ....................................................22
11. Gradual Deployment ............................................23
11.1. Tunneling ................................................23
11.2. Premature X2U ............................................25
11.3. Semi-Permeable Tunneling (IPv6 Only) .....................25
11.4. Special Case: Deployment without Network Support .........26
11.5. Using a Small Number of Xcast-Aware Routers to
Provide Xcast ............................................27
12. (Socket) API ..................................................28
13. Unresolved Issues .............................................28
13.1. The Format of the "List of Addresses" ....................28
13.2. The size of Channel Identifier ...........................28
13.3. Incremental Deployment ...................................28
13.4. DSCP usage ...............................................29
13.5. Traversing a Firewall or NAT Products ....................29
13.6. The Size of BITMAP .......................................29
14. Security Considerations .......................................29
15. IANA Considerations ...........................................30
16. Informative References ........................................31
17. Contributors ..................................................331. Introduction ✨
okay so traditional IP multicast schemes [1112] are amazing for really huge multicast groups, but they start to struggle when there's a massive number of distinct multicast groups 😭 This doc describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties. Xcast is made for supporting a very large number of small multicast sessions 🦋 It does this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address 💅 Like the Abstract said, this doc covers Xcast concepts and options in several areas, but it isn't a complete technical spec 🌸
Multicast is the ability to send data to a group of destinations efficiently, and it's getting more and more important for things like IP telephony and video-conferencing 📞✨
There are two kinds of multicast that seem to matter 🎀 The first is a broadcast-like multicast that sends data to a very large number of destinations. The second is a "narrowcast" multicast that sends data to a fairly small group [BOIV]. An example of the first is multicasting audio and video of a presentation to all employees on a corporate intranet 🏢 An example of the second is a videoconference with three or four people 🫶 For reasons explained below, it seems smart to use different mechanisms for these two cases 🧠 The Reliable Multicast Transport working group said it best: "it is believed that a 'one size fits all' protocol will be unable to meet the requirements of all applications" [RMT]. The 1998 IAB Routing Workshop [2902] also landed on the same conclusion: "For example, providing for many groups of small conferences (a small number of widely dispersed people) with global topological scope scales badly given the current multicast model". Iconic agreement 👑
Today's multicast schemes can be used to minimize bandwidth consumption 📉 Explicit Multi-Unicast (Xcast) can also minimize bandwidth consumption for "small groups" 🌈 But Xcast has an extra perk too! It gets rid of the per-session signaling and per-session state information that traditional IP multicast schemes need, and that's what lets Xcast support very large numbers of multicast sessions 🤯 This scalability matters because it enables big classes of applications like IP telephony, videoconferencing, collaborative applications, networked games, etc., where there are usually very large numbers of small multicast groups 🎮💜
Here's the wild part 😳 The idea for Xcast has been around for a while, even though the three groups that independently reinvented it in the late 1990's didn't know that at the time 🕰️ In fact, the very first proposal of the multicast concept in the Internet community was Lorenzo Aguilar's 1984 SIGCOMM paper [AGUI], which proposed using an explicit list of destinations (more on that below). Around the same time, David Cheriton and Stephen Deering developed Host Group Multicast in 1985 [CHER] 🧚
The Internet community compared the two proposals and concluded that one mechanism was better than multiple mechanisms 🙌 Plus, since Aguilar's proposal seemed to have serious scaling problems, the Host Group model got adopted 😬
But for reasons explained below, we think it makes sense to use different mechanisms for the two kinds of multicast we talked about above 💖 Host Group multicast may have been enough for the Internet of 1985, but we believe Xcast can be an important complement to Host Group multicast for the Internet of the 21st century 🌍✨
More parts are coming, so stay tuned, bestie! 💜
2. Xcast Overview ✨
okay so first, the words we're using 💅 In Xcast we say multicast session instead of "multicast group," because "group" is so tied to multicast group addresses in traditional IP multicast 🙈
- Session: in Xcast, the term 'multicast session' will be used instead of 'multicast group' to avoid the strong association of multicast groups with multicast group addresses in traditional IP multicast.
- Channel: in a session with multiple senders (e.g., a video conference), the flow sourced by one sender will be called a channel. So, a session can contain one or more channels.
bestie, in the Host Group Model the packet carries a multicast address as a logical identifier of all the group members 🎀 In Xcast it's different: the source node keeps track of the destinations in the multicast channel it wants to send packets to 🧚
so the source encodes the list of destinations in the Xcast header, then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast header to each of the next hops. it's giving a chain of little helpers 💖
when there is only one destination left, the Xcast packet can be converted into a normal unicast packet, which can be unicasted along the remainder of the route. this is called X2U (Xcast to Unicast) 🦋
let's do an example, because I'm obsessed with this diagram ✨ suppose that A is trying to get packets distributed to B, C, and D in Figure 1 below:
R4 ---- B
/
/
A----- R1 ---- R2 ---- R3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- R7
\
\
R9 ---- DFigure 1 🌸
this is how it goes 💜 A sends an Xcast packet with the list of destinations in its Xcast header to the first router, R1.
the Xcast header is slightly different for IPv4 and IPv6 [2460], so we won't reveal any details on the encoding of the Xcast header in this section (see Section 9). ignoring the details for now, the packet that A sends to R1 looks like this:
[ src = A | dest = B C D | payload ]when R1 gets this packet, it has to properly process the Xcast header. here's what a router does with one of these Xcast packets 👑
- Perform a route table lookup to determine the next hop for each of the destinations listed in the packet.
- Partition the set of destinations based on their next hops.
- Replicate the packet so that there's one copy of the packet for each of the next hops found in the previous steps.
- Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop.
- Send the modified copies of the packet on to the next hops.
- Optimization: If there is only one destination for a particular next hop, the packet can be sent as a standard unicast packet to the destination (X2U).
so in the example above, R1 sends a single packet on to R2 with a destination list of < B C D >, and R2 sends a single packet to R3 with the same destination list 🫶
when R3 receives the packet, by the algorithm above it sends one copy of the packet to next hop R5 with an Xcast list of < C D >, and one ordinary unicast packet addressed to < B > to R4. R4 receives a standard unicast packet and forwards it on to < B >. R5 forwards the Xcast packet it receives on to R6, which passes it on to R7. when the packet reaches R7, R7 transmits ordinary unicast packets addressed to < C > and < D >, respectively. R8 and R9 receive standard unicast packets, and forward them on to < C > and < D >, respectively. it's literally a whole relay race 🏃♀️💨
it's really important that the Xcast packet sent to a given next hop only includes destinations for which that next hop is the next hop listed in the route table. like, if the list of destinations in the packet sent to R4 also had included C and D, R4 would send duplicate packets. not it 💀
and note that when routing topology changes, the routing for an Xcast channel automatically adapts to the new topology, since the path an Xcast packet takes to a given destination always follows the ordinary, unicast routing for that destination 🌈
3. The Cost of the Traditional IP Multicast Schemes 💅
okay so traditional IP multicast schemes [DEER, DEE2, FARI] were designed to handle very large multicast groups 😭 they work well if you're trying to distribute broadcast-like channels all around the world, but they have scalability problems when there is a very large number of groups.
the traditional IP multicast model is determined by two components: the Host Group model [DEER] and a Multicast Routing Protocol. both components make multicast very different from unicast 🦋
in the Host Group model, a group of hosts is identified by a multicast group address, which is used both for subscriptions and forwarding. this model has two main costs:
- Multicast address allocation: The creator of a multicast group must allocate a multicast address that is unique in its scope (scope will often be global). This issue is being addressed by the MALLOC working group, which is proposing a set of Multicast Address Allocation Servers (MAAS) and three protocols (Multicast Address Set Claim (MASC), Address Allocation Protocol (AAP), Multicast Address Dynamic Client Allocation Protocol (MADCAP)).
- Destination unawareness: When a multicast packet arrives in a router, the router can determine the next hops for the packet, but knows nothing about the ultimate destinations of the packet, nor about how many times the packet will be duplicated later on in the network. This complicates the security, accounting and policy functions. 🙈
in addition to the Host Group model, a routing algorithm is required to maintain the member state and the delivery tree. this can be done using a (truncated) broadcast algorithm or a multicast algorithm [DEER]. since the former consumes too much bandwidth by unnecessarily forwarding packets to some routers, only the multicast algorithms are considered. these multicast routing protocols have the following costs:
- Connection state: The multicast routing protocols exchange messages that create state for each (source, multicast group) in all the routers that are part of the point-to-multipoint tree. This can be viewed as "per flow" signaling that creates multicast connection state, possibly yielding huge multicast forwarding tables. Some of these schemes even disseminate this multicast routing information to places where it isn't necessarily needed [1075]. Other schemes try to limit the amount of multicast routing information that needs to be disseminated, processed, and stored throughout the network. These schemes (e.g., [2201]) use a "shared distribution tree" that is shared by all the members of a multicast group, and they try to limit the distribution of multicast routing information to just those nodes that "really need it". But these schemes also have problems. Because of the shared tree, they use less than optimal paths in routing packets to their destinations, and they tend to concentrate traffic in small portions of a network. And these schemes still involve lots of "per flow" signaling and "per flow" state. 😮💨
- Source advertisement mechanism: Multicast routing protocols provide a mechanism by which members get 'connected' to the sources for a certain group without knowing the sources themselves. In sparse-mode protocols [2201, DEE2], this is achieved by having a core node, which needs to be advertised in the complete domain. On the other hand, in dense-mode protocols [1075] this is achieved by a "flood and prune" mechanism. Both approaches raise additional scalability issues.
- Inter-domain routing: Multicast routing protocols that rely on a core node [2201, DEE2] additionally need an inter-domain multicast routing protocol (e.g., [FARI]).
the cost of multicast address allocation, destination unawareness and the above scalability issues led people to search for other multicast schemes 🔍 Source-Specific Multicast (SSM) [4607] fixes some of the above drawbacks: in SSM, a host joins a specific source, so the channel is identified by the couple (source address, multicast address). this avoids multicast address allocation, as well as the need for an inter-domain routing protocol. the source advertisement is taken out of the multicast routing protocol and moved to an out-of-band mechanism (e.g., web page). iykyk 🧚
note that SSM still creates state and signaling per multicast channel in each on-tree node. Figure 2 depicts the above costs as a function of the number of members in the session or channel. all the costs have a hyperbolic behavior 📈
cost of the traditional
IP multicast model
per member
^
| costly| OK
| <-----|----->
| . |
| .. |
| ..|..
| | .........
| | ........
+--------------------------->
| number of members
v
alternative=XcastFigure 2 🎀
the traditional IP multicast model gets expensive for its members if the groups are small. small groups are typical for conferencing, gaming, and collaborative applications, and those are exactly the apps that are well-served by Xcast 💖
in practice, traditional IP multicast routing protocols impose limitations on the number of groups and the size of the network they're deployed in. for Xcast, these limitations do not exist ✨👑
4. Motivation ✨
Okay so Xcast is built on one of the biggest tenets of the Internet "philosophy" 🫶: move the complexity to the edges of the network and keep the middle simple 💅. That's the principle that guided IP and TCP, and it's literally why the Internet has been able to grow so big 🌈. One reason it scales so well is that the routers in the core deal with large Classless Inter-Domain Routing (CIDR) blocks instead of individual hosts or individual "connections" 🧚. Core routers don't need to track every TCP connection passing through them. The IETF's Diffserv work has the same vibe: routers shouldn't have to keep track of a huge number of individual Resource Reservation Protocol (RSVP) flows going through them 💜. The authors believe the core shouldn't have to track a bunch of individual multicast flows either 🔥.
Compared to traditional IP multicast, Xcast has these advantages (it's giving main character 👑):
- Routers do not have to maintain state per session (or per channel) [SOLA]. This makes Xcast super scalable in terms of how many sessions it can support, since the nodes in the network don't need to disseminate or store any multicast routing information for these sessions ✨.
- No multicast address allocation required 🎀.
- No need for multicast routing protocols (neither intra- nor inter-domain). Xcast packets always take the "right" path as determined by the ordinary unicast routing protocols 🦋.
- No core node, so no single point of failure 💖. Unlike the shared tree schemes, Xcast minimizes network latency and maximizes network "efficiency" 💅.
- Symmetric paths are not required 🌸. Traditional IP multicast routing protocols create non-shortest-path trees if paths are not symmetric. (A path between two nodes A and B is symmetric if the path is both the shortest path from A to B as well as the shortest path from B to A.) It is expected that an increasing number of paths in the Internet will be asymmetric in the future as a result of traffic engineering and policy routing, so the traditional IP multicast schemes will result in an increasing amount of suboptimal routing 😭.
- Automatic reaction to unicast reroutes ⚡. Xcast will react immediately to unicast route changes. In traditional IP multicast routing protocols, a communication between the unicast and the multicast routing protocol needs to be established. In many implementations, this is on a polling basis, which means a slower reaction to, e.g., link failures. It may also take some time for traditional IP multicast routing protocols to fix things up if there is a large number of groups that need to be fixed 🙄.
- Easy security and accounting 🔐. In contrast with the Host Group Model, in Xcast all the sources know the members of the multicast channel. That gives the sources the means to, e.g., reject certain members or count the traffic going to certain members quite easily. Not only a source, but also a border router is able to determine how many times a packet will be duplicated in its domain. It also becomes easier to restrict the number of senders or the bandwidth per sender 💅.
- Heterogeneous receivers 🌈. Besides the list of destinations, the packet could (optionally) also contain a list of Diffserv Code Points (DSCPs). While traditional IP multicast protocols have to create separate groups for each service class, Xcast incorporates the possibility of having receivers with different service requirements within one multicast channel.
- Xcast packets can make use of traffic-engineered unicast paths 🛣️.
- Simple implementation of reliable protocols on top of Xcast, because Xcast can easily address a subset of the original list of destinations to do a retransmission 🔁.
- Flexibility (see Section 6) 🧠.
- Easy transition mechanisms (see Section 11) 🚪.
It should be noted that Xcast has a number of disadvantages as well (ngl, nothing is perfect bestie 🙈):
- Overhead. Each packet contains all remaining destinations. But the total amount of data is still much less than for unicast, since the payload is only sent once. A method to compress the list of destination addresses might be useful 📦.
- More complex header processing. Each destination in the packet needs a routing table lookup. So an Xcast packet with n destinations requires the same number of routing table lookups as n unicast headers. Additionally, a different header has to be constructed per next hop. Note however that:
- a) Since Xcast will typically be used for super-sparse sessions, there will be a limited number of branching points, compared to non-branching points. Only in a branching point do new headers need to be constructed ✨.
- b) The header construction can be reduced to a very simple operation: overwriting a bitmap 🍓.
- c) Among the non-branching points, a lot of them will contain only one destination. In these cases, normal unicast forwarding can be applied 🦋.
- d) By using a hierarchical encoding of the list of destinations in combination with the aggregation in the forwarding tables, the forwarding can be accelerated [OOMS] 🚀.
- e) When the packet enters a region of the network where link bandwidth is not an issue anymore, the packet can be transformed by a Premature X2U. Premature X2U (see Section 11.2) occurs when a router decides to transform the Xcast packet for one or more destinations into unicast packets. This avoids more complex processing downstream 💜.
- f) Other mechanisms to reduce the processing have been described in [IMAI] (tractable list) and [OOMS] (caching), but are not (yet) part of the Xcast specification 🧚.
- Xcast only works with a limited number of receivers 🙈.
5. Application 🎀
While Xcast is not suitable for multicast sessions with a large number of members, such as the broadcast of an IETF meeting, it does provide an important complement to existing multicast schemes, because it can support very large numbers of small sessions 💖. So Xcast enables important applications like IP telephony, videoconferencing, multi-player games, collaborative e-meetings, etc. The number of these sessions will become huge 🤯.
Some people may argue that it's not worthwhile to use multicast for sessions with a limited number of members, and that it's preferable to use unicast instead. But in certain cases, limited bandwidth in the "last mile" makes it important to have some form of multicast, as the following example illustrates 📡. Assume n residential users set up a video conference. Access technologies are typically asymmetric (e.g., xDSL, General Packet Radio Service (GPRS), or cable modem) 🌸. So a host with xDSL has no problem receiving n-1 basic 100 kb/s video channels, but the host is not able to send its own video data n-1 times at this rate 😭. Because of the limited and often asymmetric access capacity, some type of multicast is mandatory 🔥.
A simple but important application of Xcast lies in bridging the access link 🌉. The host sends the Xcast packet with the list of unicast addresses, and the first router performs a Premature X2U.
Since Xcast is not suitable for large groups, Xcast will not replace the traditional IP multicast model. But it does offer an alternative for multipoint-to-multipoint communications when there can be very large numbers of small sessions 👑.
6. Xcast Flexibility 🦋
The main goal of multicast is to avoid duplicate information flowing over the same link 🧠. By using traditional IP multicast instead of unicast, bandwidth consumption decreases while the state and signaling per session increases. Xcast has a cost of 0 in these two dimensions, but it does introduce a third dimension, corresponding to the header processing per packet 🌈. This three-dimensional space is depicted in Figure 3 🎀.
state&signaling
per session
in router
^
|
|
....
B | ....
. | ....
. | ....
. | ....
. +------------------..---> processing
. / .... C per packet
. / ..... in router
. / .....
. / .....
./ .....
/A....
/
/
link bandwidth
Figure 3One method of delivering identical information from a source to n destinations is to unicast the information n times (A in Figure 3) 📨. A second method, the traditional IP multicast model (B in Figure 3), sends the information only once to a multicast address. In Xcast, the information is sent only once, but the packet contains a list of destinations (point C) 💜.
The three points A, B, and C define a plane (indicated with dots in Figure 3): a plane of conservation of misery 😭. All three approaches have disadvantages. The link bandwidth is a scarce resource, especially in access networks. State&signaling/session encounters limitations when the number of sessions becomes large, and an increased processing/packet is cumbersome for high-link speeds 🙃.
One advantage of Xcast is that it allows a router to move within this plane of conservation of misery based upon its location in a network 🗺️. For example, in the core of the network, a cache could be used to move along the line from C to B without introducing any per-flow signaling 🧚. Another possibility, as suggested above, is to use Premature X2U to move along the line from C to A in an access network if there is an abundance of bandwidth in the backbone 🌟.
7. Xcast Control Plane Options ✨
okay so Xcast doesn't have a control plane!! 🙈 Traditional IP multicast comes with a whole squad of helpers: IGMP ([3376]), plus the intra- and inter-domain multicast routing protocols we already talked about. Xcast skips all of that. How a multicast session gets defined is an application-level choice, so apps aren't stuck with the IGMP model where hosts join a session 💅 Here are some vibes an app could go with:
- Some applications might want to use an IGMP-like receiver-join model.
- Other applications might want a model where a user calls the party or parties they want to talk to (kinda like how you'd set up a group call today with the buttons on your phone 📞).
- One might define a session based on the cells near a moving device, so you get a "smooth handoff" between cells as the device crosses cell boundaries 📶
- In some applications, the members of the session might be given as arguments on a command line 💻
- One might build an app that uses GPS to send video from a bank robbery to the three police cars closest to the bank 🚨 (very main character, lowkey iconic 🎬)
So the app developer isn't locked into IGMP's receiver-initiated joins 🦋 An Xcast sender can figure out the addresses of the channel's members in multiple ways.
Also, for voice and multimedia conferences over IP, a few control planes already exist, like SIP [3261] and H.323 [H323] 🎀
7.1. SIP Control Plane for Xcast
In SIP, a host takes the initiative to set up a session 🙌 With help from a SIP server, the session gets created. The session state lives in the hosts 🧚 Data delivery can happen a few ways: meshed unicast, bridged, or multicast. Heads up that setting up multicast delivery still requires a multicast protocol and communication with Multicast Address Allocation Servers (MAAS) 🫶
In "meshed unicast" (also called "multi-unicasting"), the app keeps track of everyone's unicast addresses and sends a unicast to each one 📬 For the reasons described in Section 3, multi-unicasting (instead of multicast) is the prevalent solution today. And honestly, it's a simple swap: you just replace the loop that sends a unicast to each participant with one single "xcast_send" that sends the data to everyone 🍓 So it's super easy to add Xcast to real conferencing apps. no cap 💖
Xcast and SIP both handle super-sparse multicast sessions 🌸 And it turns out Xcast (a very flexible data plane mechanism) fits nicely with SIP (a very flexible control plane protocol) 🫶 When an app decides to use Xcast forwarding, its interface to the SIP agent doesn't change at all: it can use the same SIP messages it would use for multi-unicasting. SIP could also be used with Xcast for the conferencing model from earlier, where a caller places a call to several parties 📞✨
7.2. Receiver-Initiated Join for Xcast
In the last section, we went over how to set up an Xcast session among well-known participants of a multi-party conference 💅 Sometimes, though, participants want to join a session without being invited 🚪 For example, the chairman of a video chat might want to leave the door open for newcomers 🌈 The IGMP-like receiver-initiated join model from earlier can be built by adding a server that hosts can talk to in order to join a conference 🧚✨
8. Optional Information ✨
8.1. List of Ports
Okay, an extension to SIP could be set up so that everyone in a session uses the same transport (UDP) port number 🙂 But in the general case, each participant can listen on a different port number 🦋 To cover that, the Xcast packet can optionally carry a list of port numbers 💜
If the list of port numbers is present, the destination port number in the transport-layer header will be set to zero. On X2U, the destination port number in the transport-layer header will be set to the port number that matches the destination of the unicast packet 🎯
8.2. List of DSCPs
The Xcast packet could (optionally) also carry a list of Diffserv Code Points (DSCPs) 🎀 Traditional IP multicast protocols have to make separate groups for each service class. Xcast, though? It lets receivers with different service requirements live together inside one channel 🫶
The DSCP in the IP header will be set to the most demanding DSCP in the list of DSCPs. That IP-header DSCP is what determines, e.g., the scheduler to use ⚡
If two destinations with the same next hop have 'non-mergeable' DSCPs, two Xcast packets will be created 🧩 "Non-mergeable" means you can't say one is more or less stringent than the other 💀
8.3. Channel Identifier
Optionally, a sender can add an extra number to the Xcast header: the Channel Identifier 🔢 If the source doesn't want to use this option, it must set the Channel Identifier to zero. If the Channel Identifier is non-zero, the pair (Source Address, Channel Identifier) must uniquely identify the channel. (This is basically the same vibe as the (S, G) pair in SSM 👑) This document doesn't give the Channel Identifier any other meaning beyond the one above.
This Channel Identifier could be useful for a few things:
- A key to a caching table [OOMS].
- "Harmonization" when used with Host Group Multicast (to be discussed in greater detail in another document) 🌸
- An identifier of the channel in error, flow control, etc., messages 🚨
- It gives an extra demultiplexing option (besides the port number) 🔀
- ...
The size of the channel identifier and its semantics are TBD. 🙈
9. Possible Xcast Packet Encoding ✨
9.1. General
The source address field of the IP header contains the address of the Xcast sender 💖 The destination address field carries the All-Xcast-Routers address (to be assigned link-local multicast address). This is a fixed value on purpose 🔒 Every Xcast router joins this multicast group. Here's why the destination field gets a fixed number:
- The destination address field is part of the IP pseudo header, and the pseudo header is covered by transport-layer checksums (e.g., the UDP checksum). So the fixed value avoids a (delta) recalculation of the checksum 🧮
- The IPsec Authentication Header (AH) [4302] covers the IP header destination address, which prevents any modification to that field 🛡️ Also, both AHs and Encapsulating Security Payloads (ESPs) cover the whole UDP packet (via authentication and/or encryption). So the UDP checksum can't be updated if the IP header destination address were to change 😭
- In Xcast for IPv6, the Routing Extension shall be used. This header extension is only checked by a router if the packet is destined to that router. This works because all Xcast routers are part of the All_Xcast_Routers group 🦋
- Normally, Xcast packets are only visible to Xcast routers. However, if a non-Xcast router receives an Xcast packet by accident (or by criminal intent), it won't send ICMP errors, since the Xcast packet carries a multicast address in the destination address field [1812] 👀
Note that some benefits only hold when the multicast address stays in the destination field until it reaches the end node (so they can't be combined with X2U) ⚠️
9.2. IPv4
[AGUI] and [1770] proposed (for a slightly different purpose) to carry multiple destinations in the IPv4 option. But because of the limited flexibility (the limited size of the header), Xcast will take a different approach 🌷 The list of destinations will be encoded in a separate header. The Xcast header for IPv4 (in short, Xcast4) would be carried between the IPv4 header and the transport-layer header:
[IPv4 header | Xcast4 | transport header | payload ]Also, since the Xcast header gets added to the data portion of the packet, if the sender wants to avoid IP fragmentation, it must take the size of the Xcast header into account 📏
9.2.1. IPv4 Header
The Xcast4 header is carried on top of an IP header 🎀 The IP header will carry the protocol number listed as usable for experimental purposes in RFC 4727 [4727]. See also Section 15 🧪 The source address field contains the address of the Xcast sender, and the destination address field carries the All_Xcast_Routers address 💜
9.2.2. Xcast4 Header ✨
okay so the Xcast4 header is shown in Figure 4 💖 It's split into two bits: a fixed part (the first 12 octets) and two variable-length parts that the fixed part tells you how big are 🎀
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|A|X|D|P|R| NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROT ID | LENGTH | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4Here's the breakdown, bestie 🧚
VERSION= Xcast version number. This document describes version 1 🌸A= Anonymity bit 🫣: if this bit is set, the destination addresses whose matching bit in the bitmap is zero must be overwritten by zero.X= Xcast bit 🔒: if this bit is set, a router must not reduce the Xcast packet to unicast packet(s). In other words, the packet has to stay an Xcast packet end-to-end. This bit can be useful when IPsec [4301] is applied. If this bit is cleared, a router should apply X2U when there's only one destination left in the Xcast packet. Sometimes a router could decide not to apply X2U to a packet with the Xcast bit cleared, e.g., when the router has no directly connected hosts and wants to skip the extra processing that X2U needs 🙈D= DSCP bit 🍓: if this bit is set, the packet will contain a DS byte for each destination.P= Port bit 🚪: if this bit is set, the packet will contain a port number for each destination.NBR_OF_DEST= the number of original destinations.CHECKSUM= a checksum on the Xcast header only 🧮. It gets verified and recomputed at each point where the Xcast header is processed. The checksum field is the 16-bit one's complement of the one's complement sum of all the bytes in the header. When computing the checksum, the value of the checksum field is zero. It's still unclear whether a checksum is needed at all (that's for further study 👀). Even if only one destination is wrong, it can still be useful to forward the packet to N-1 correct destinations and 1 incorrect destination.CHANNEL IDENTIFIER= 4-octet Channel Identifier (see Section 8.3) 🦋. Since it sits within the first 8 bytes of the header, it will be returned in ICMP messages.PROT ID= specifies the protocol of the following header.LENGTH= length of the Xcast header in 4-octet words 📏. This field puts an upper boundary on the number of destinations. This value is also determined by theNBR_OF_DESTfield and theDandPbits.RESV=R= Reserved 🫧. It must be zero on transmission and must be ignored on receipt.
The first variable part is the 'List of Addresses and DSCPs', and the second variable part is the 'List of Port Numbers'. Both are 4-octet aligned. The second variable part is only there if the P bit is set ✨
Figure 5 shows what the variable part looks like when the P bit is set and the D bit is cleared (in this example, N is odd) 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BITMAP |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 1 | Port 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5BITMAP= every destination gets its own bit in the bitmap, showing whether that destination is still valid on this branch of the tree 🌳. The first bit matches the first destination in the list. This field is 4-octet aligned (e.g., for 49 destinations you'd get a 64-bit bitmap). If Xcast is used together with IPsec, the bitmap has to be moved to a new, to-be-defined IPv4 option, because it can change en route 🔄- List of Destinations 📬: each address is 4 octets.
- List of Port Numbers 🔢: a list of 2-octet destination port number(s), where each port lines up with the destination address right before it.
9.3. IPv6 💜
The Xcast6 header encoding is similar to IPv4, except that the Xcast information gets stored in IPv6 extension headers 🧚♀️
[IPv6 header | Xcast6 | transport header | payload ]9.3.1. IPv6 Header 🌈
The IPv6 header will carry the NextHeader value 'Routing Extension'. The source address field contains the address of the Xcast sender, and the destination address field carries the All_Xcast_Routers address 📮
9.3.2. Xcast6 Header 🎀
The Xcast6 header is also made up of a fixed part and two variable parts. The fixed part and the first variable part are carried in a Routing Extension, and the second variable part is carried in a Destination Extension 🧩
9.3.2.1. Routing Extension Header 🛣️
The P bit of Xcast4 isn't present here, because it's implied by whether the Destination Extension is there or not (Figure 6) 💫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |RouteType=Xcast| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6HdrExtLen= the header length is expressed in 8-octets, so a maximum of 127 destinations can be listed (this is whyNBR_OF_DESTis 7 bits) 🔢RouteType= Xcast (see Section 15) 🏷️- The fourth octet is set to 0 🫙
R= Reserved 🫧CHANNEL IDENTIFIER= 16-octet Channel Identifier (see Section 8.3) 🦋
The other fields are defined in Section 9.2.2 💖
The 'List of Addresses and DSCPs' is 8-octet aligned. The size of the bitmap depends on the number of destinations and is a multiple of 64 bits 📐
9.3.2.2. Destination Extension Header 🎁
Optionally, the Destination Extension (Figure 7) can be there to specify the list of Port Numbers. The destination header is only evaluated by the destination node 🎯
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7For the Option Type for Ports, see Section 15 🔖. The first three bits must be 010, which tells you that the packet must be discarded if the option is unknown and that the option cannot be changed en-route ⛔
The number of Ports must be equal to the number of destinations specified in the Routing header 💯
10. Impact on Upper-Layer Protocols 🧠
Some fields in the Xcast header(s) can be modified as the packet travels along its delivery path 🛤️ That has an impact on:
10.1. Checksum Calculation in Transport-Layer Headers 🧮
In transport-layer headers, the target of the checksum calculation includes the IP pseudo header, transport header, and payload. IPv6 header extensions are not a target 🙅♀️
The transformation of an Xcast packet into a normal unicast packet, which is (premature) X2U, replaces the multicast address in the IP header destination field with the address of a final destination. If the Xcast header contains a Port List, the port number in the transport layer (which should be zero) also needs to be replaced by the port number that corresponds to the destination. That means these checksums need to be recalculated. The good news is it doesn't need a full recalculation, just a delta calculation 🥹 e.g., for IPv4:
Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp')Here, "'" marks the new values, "da" is the destination address, "dp" is the destination port, and "H" and "L" are the higher and lower 16 bits, respectively 🫶
10.2. IPsec 🔐
This is described in [PARI] 📖
11. Gradual Deployment 🚀
11.1. Tunneling ✨
okay so, the first way to get Xcast working in a network full of routers that have never heard of it is to set up "tunnels" between Xcast peers 🚇 (this is the MBone approach [MBONE]). bestie, this basically builds a virtual network sitting on top of the existing one [2003] 🫧. The Xcast routers swap and keep up-to-date Xcast routing info using any normal unicast routing protocol (RIP, OSPF, IS-IS, BGP, you name it) 💅. The Xcast routing table ends up being just a regular unicast routing table that lists the destinations with Xcast connectivity, plus their matching Xcast next hops. So packets can hop from Xcast router to Xcast router, or they can get "tunneled" right through the non-Xcast routers in the middle 🦋.
Let's say A wants to get packets to B, C, and D in Figure 8 🌸. The "X" routers are Xcast-capable and the "R" routers are not. Figure 9 shows the routing tables that come out of those Xcast tunnels:
R4 ---- B
/
/
A ----- X1 ---- R2 ---- X3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- X7
\
\
R9 ---- D
Figure 8X1 sets up a tunnel to Xcast peer X3 🔗. X3 sets up tunnels to Xcast peers X1 and X7. X7 sets up a tunnel to Xcast peer X3. Easy peasy 🧚
X1 routing table: X3 routing table: X7 routing table:
Dest | NextHop Dest | NextHop Dest | NextHop
------+---------- ------+--------- ------+---------
B | X3 A | X1 A | X3
C | X3 C | X7 B | X3
D | X3 D | X7
Figure 9So A sends an Xcast packet to its default Xcast router, X1, and the packet carries the list of destinations 💖. The packet on the link between X1 and X3 looks like Figure 10:
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| B,C,D |
| prot=UDP |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| outer IP |
| src=X1 |
| dst=X3 |
| prot=IP |
+----------+
Figure 10When X3 gets this packet, it does the following 🔍:
- It does a route table lookup in the Xcast routing table to find the Xcast next hop for each destination listed in the packet.
- If no Xcast next hop shows up, it replicates the packet and sends a standard unicast to that destination.
- For the destinations that DO have an Xcast next hop, it groups the destinations by their next hops.
- It replicates the packet so there's one copy for each Xcast next hop found in the steps above.
- It edits the destination list in each copy so the copy for a given next hop only has the destinations that should go through that next hop.
- It sends the edited copies on to their next hops.
- Optimization: if a particular Xcast next hop only has one destination, the packet gets sent as a standard unicast packet to that destination, since there's zero benefit to keeping it as an Xcast packet 🙅♀️.
So in our example, X1 sends one packet on to X3 with a destination list of < B C D > 📦. R2 receives it as a unicast packet addressed to X3 and forwards it on, totally unaware of Xcast 🤷♀️. When X3 gets it, the algorithm above has it send one copy to < B > as an ordinary unicast packet, and one copy to X7 with a destination list of < C D >. R4, R5, and R6 act like standard routers that have no clue what Xcast is. When X7 gets the packet, it parses it and sends ordinary unicast packets to < C > and < D >, one for each 🎀.
The route table updating is simple inside a single domain, but it gets way more complicated across domains 😵💫. So using tunneling in an inter-domain environment needs more thought first 🧐.
11.2. Premature X2U 🌈
If a router finds out that its downstream neighbor isn't Xcast capable, it can do a Premature X2U 💌. That means it sends a unicast packet for each destination in the Xcast header that has this neighbor as its next hop. So the duplication happens before the Xcast packet even reaches its real branching point 🌿.
How a router discovers a neighbor's Xcast capability is still for further study 🔮 (no final answer yet, bestie). People have floated a few ideas though: an extension to a routing protocol that advertises Xcast capabilities 📣, or sending periodic 'Xcast pings' to neighbors 🏓 (you send an Xcast packet that has your own address as a destination and check whether it comes back to you).
11.3. Semi-Permeable Tunneling (IPv6 Only) 🫧
This is a tunneling optimization because it doesn't need any manual tunnel configuration 🙌. You turn it on by adding a Hop-by-Hop Xcast6 header. An IPv6 packet can kick off extra processing in the on-route routers by using the IPv6 Hop-by-hop option 🚀.
The type of the Xcast6 Hop-by-hop option starts with '00', so routers that can't recognize Xcast6 just treat the Xcast6 datagram like a normal IPv6 datagram and forward it toward the destination in the IPv6 header 🛤️. That's the iconic part, fr fr 😭.
Packets will reach all the members as long as at least all the participating hosts have been upgraded 💯.
When the source A sends an Xcast packet using semi-permeable tunneling to destinations B, C, and D, it builds the packet in Figure 11 💖. One of the final destinations goes into the destination address field of the outer IP header.
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| Xcast |
|SP-tunnel |
|Hop-by-hop|
+----------+
| outer IP |
| src=A |
| dst=B |
| prot=IP |
+----------+
Figure 11Semi-permeable tunneling is a special kind of tunneling that lets the intermediate Xcast routers on a tunnel check the destinations and branch off whenever destinations have a different next hop 🌊.
Also, now that there's an Xcast IPv4 option, this technique could be used in IPv4 networks too 🎉.
11.4. Special Case: Deployment without Network Support 🫶
Here's a sneaky way to deploy Xcast by only upgrading the hosts 🧁. You use tunneling (see Sections 11.1 and 11.3) with one of the final destinations as the tunnel endpoint. Then the Xcast packet gets delivered to every destination once all the hosts are Xcast aware 👑. Both normal and semi-permeable tunneling can be used for this.
In the example above, if host B gets this packet, it notices the other destinations in the Xcast header 👀. B then creates a new Xcast packet and sends it to one of the remaining destinations 🏃♀️.
With Xcast6 and semi-permeable tunneling, you can add Xcast routers to the network without having to configure any tunnels 🪄.
But the downsides of this method are:
- every host in the session needs to be upgraded.
- the routing isn't optimal.
- anonymity issue: hosts can know who the other parties in the session are. That's not a big deal for conferencing, but it might be for other applications 🙈.
- the host has to do network functions itself, and it needs an upstream link with the same bandwidth as its downstream link 😩.
11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast in a Not-So-Small Network 🧚♀️
In this approach, an Xcast packet uses a special 32-bit unicast address in the destination field of the IP header 💜. In the simplest version, there might be just one Xcast-aware router in the whole network 🦄. That router acts like a "server" to the other routers, and it's configured so that its IP address (or one of its IP addresses) matches the "special" 32-bit address. So when Xcast clients send Xcast packets, the non-Xcast-aware routers route those packets to the Xcast-aware router, and that router can "explode" them (X2U) into the right set of unicast packets 💥. This lets clients anywhere in the network use Xcast to get past the limited bandwidth in the "first mile," and it only needs a minimum of one Xcast-aware router (i.e., 1) 🌟.
Another option is to put a few of these Xcast-aware routers at different points in the network and configure each one with the special 32-bit address 🗺️. That gives you redundancy, which gets rid of the single point of failure 🛡️. It also shortens the distance an Xcast packet has to travel to reach an Xcast-aware router, which cuts down on network latency ⚡. In this case the Xcast-aware routers look like one single server that's "multihomed" (meaning it's connected to the network in more than one place) 🏠. The non-Xcast-aware routers then use ordinary unicast routing to deliver packets addressed to this "multihomed virtual server" along the shortest available path 🛣️.
Note that delivering packets to any host in a group like this is also known as "anycast," and it's covered in more detail in RFCs [1546], [2526], and [3068] 📚. Note too that RFC 1546 says:
The important observation is that multiple routes to an anycast address appear to a router as multiple routes to a unicast destination, and the router can use standard algorithms to choose the best route.
12. (Socket) API 🔌✨
okay so in the most basic version of Xcast, the final destinations just receive an ordinary unicast UDP packet 🦋 which means hosts can receive an Xcast packet with a totally standard, unmodified TCP/IP stack. no kernel drama needed 💅
hosts can also send Xcast packets with a normal TCP/IP stack plus a small Xcast library that sends them on a raw socket. this has been used to build Xcast-based apps on both Unix and Windows platforms with zero kernel changes 🫶
another option is to tweak the sockets interface a bit. for example, you could add an xcast_sendto function that works like sendto but takes a list of destination addresses instead of the single address that sendto uses 💖
13. Unresolved Issues 🌸
ok, not everything is finished yet 🥺 more work is needed in a few areas.
13.1. The Format of the "List of Addresses" 📝
there are still details to pin down. for example, in the IPv4 case, the format of the DSCPs option still needs to be specified 🧐
13.2. The Size of Channel Identifier 🎀
the channel identifiers are sized differently for IPv4 and IPv6 in this document, which is a bit messy ngl. 32 bits might be enough for both IPv6 and IPv4 ✨
13.3. Incremental Deployment 🌈
this document talks about several ways to deploy Xcast gradually, including tunneling, premature X2U, and so on. more work is needed to figure out the best way to do incremental deployment inside a domain and across domains 🗺️ if tunneling is used, extra details need to be specified (like the tunneling format and how tunnels work in the inter-domain case).
13.4. DSCP Usage 🍓
DSCP usage needs some love 💕 DSCPs may have to be rewritten as packets cross inter-domain boundaries.
13.5. Traversing a Firewall or NAT Products 🧱
using a different, carried protocol type for IPv4 may cause trouble for some firewall and NAT products 😬
13.6. The Size of BITMAP 🧩
since this is designed for small groups, it might make sense to just mandate a fixed size for the bitmap. simple is iconic 👑
14. Security Considerations 🚨🔐
this part is serious, bestie, so read it carefully 🙈
the list of destinations in Xcast is provided by an application layer that manages group membership, plus authorization if authorization is wanted.
since a source holds the list of destinations and can change the list, it has more control over where its packets go than in traditional multicast. it can, for example, stop anonymous eavesdroppers from joining a multicast session 🕵️♀️
some forms of denial-of-service attack can use Xcast to make their "effect" bigger 💀 a smurf attack, for example, sends an ICMP Echo Request with the source address set to the address of the attack target, so the target receives the ICMP echo replies. with Xcast, the ICMP Echo Request could be sent to a list of destinations that makes every member of the list send an Echo Reply to the target. yikes 😭
traditional multicast has measures against this kind of attack. a router or host can be configured so that it won't reply to ICMP requests addressed to a multicast address. the Reverse Path Forwarding check in traditional multicast architectures also helps limit these attacks 🛡️ in Xcast, it can be hard for a host to notice that an ICMP request was addressed to multiple destinations, since by the time it reaches the host the packet may look like an ordinary unicast packet. on the other hand, a router can detect Xcast packets used to send ICMP requests to multiple destinations and can be configured to drop them 🙅♀️ also, since Xcast sends packets to a short list of destinations, the problem of attack packets going to multiple destinations is less of a problem than in traditional multicast. obviously, using IPsec for confidentiality and/or authentication can further lower the risk of this type of attack 🔒
the problem of secure group communications has been taken on by the Multicast Security (MSEC) working group, which has defined an architecture for securing IP-multicast-based group communications, see [3740]. lots of the ideas from the MSEC working group apply to Xcast-based group communications too: managing group membership, identifying and authenticating group members, protecting the confidentiality and integrity of multicast traffic, and managing and securely distributing and refreshing keys 🔑 and many of the same mechanisms seem to apply. one big difference between multicast and Xcast is that the Xcast header (or at least a bitmap in the Xcast header) needs to change as an Xcast packet travels from a source to a destination. this affects the use of IPsec and suggests that at least the Xcast header bitmap must be in a "mutable" field 🧐 a complete solution for securing Xcast-based group communications, addressing all the issues listed above, will be the subject of additional work and will be discussed in one or more additional documents. we expect this effort to build on the work already done in the msec working group ✨
15. IANA Considerations 📋
experimenting with the Xcast protocol requires protocol numbers maintained by IANA. for example, to implement XCAST6, implementations must agree on four protocol numbers:
(1) Multicast Address for All_Xcast_Routers
(2) Routing Type of IPv6 Routing Header
(3) Option Type of IPv6 Destination Option Header
(4) Option Type of IPv6 Hop-by-Hop Options Headera protocol implementer can temporarily experiment with Xcast by using the values set aside for experimental use in RFC [4727]. an implementer must verify that no other experiment uses the same values on the Xcast testbed at the same time 🧪
a future revision of the Xcast specification published on the standards track is required before IANA can assign permanent registry entries for Xcast. implementers should be aware that they will need to modify their implementations when those permanent allocations are made 🔄
16. Informative References 📚
[1546]Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.[2526]Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.[3068]Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.[1112]Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.[1075]Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.[1770]Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.[1812]Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.[2003]Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.[2201]Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.[2460]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.[2902]Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.[3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[3376]Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.[3740]Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.[4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.[4302]Kent, S., "IP Authentication Header", RFC 4302, December 2005.[4607]Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.[4727]Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.[AGUI]L. Aguilar, "Datagram Routing for Internet Multicasting", SIGCOMM '84, March 1984.[CHER]David R. Cheriton, Stephen E. Deering, "Host groups: a multicast extension for datagram internetworks", Proceedings of the ninth symposium on Data communications, p. 172-179, September 1985, Whistler Moutain, British Columbia, Canada.[BOIV]Boivie, R. and N. Feldman, "Small Group Multicast", Work in Progress, February 2001.[DEER]S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991.[DEE2]S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei, "The Pim Architecture for Wide-area Multicast Routing", ACM Transactions on Networks, April 1996.[FARI]Farinacci, D., et al., "Multicast Source Discovery Protocol", Work in Progress, June 1998.[H323]ITU-T Recommendation H.323 (2000), Packet-Based Multimedia Communications Systems.[IMAI]Imai, Y., "Multiple Destination option on IPv6 (MDO6)", Work in Progress, September 2000,[MBONE]Casner, S., "Frequently Asked Questions (FAQ) on the Multicast Backbone (MBONE)",<ftp://ftp.isi.edu/mbone/faq.txt>.[OOMS]Ooms, D., Livens, W., and O. Paridaens, "Connectionless Multicast", Work in Progress, April 2000.[PARI]Paridaens, O., Ooms, D., and B. Sales, "Security Framework for Explicit Multicast", Work in Progress, June 2002.[RMT]Reliable Multicast Transport Working Group web site,<http://www.ietf.org/html.charters/rmt-charter.html>, June 15, 1999.[SOLA]M. Sola, M. Ohta, T. Maeno, "Scalability of Internet Multicast Protocols", INET'98,<http://www.isoc.org/inet98/proceedings/6d/6d_3.htm>.
17. Contributors 🫶
Olivier Paridaens
Alcatel Network Strategy Group
Fr. Wellesplein 1, 2018
Antwerpen, Belgium
Phone: 32 3 2409320
EMail: Olivier.Paridaens@alcatel.be
Eiichi Muramoto
Matsushita Electric Industrial Co., Ltd.
4-12-4 Higashi-shinagawa, Shinagawa-ku
Tokyo 140-8587, Japan
Phone: +81-3-6710-2031
EMail: muramoto@xcast.jpAuthors' Addresses 💜
Rick Boivie
IBM T. J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
Phone: 914-784-3251
EMail: rhboivie@us.ibm.com
Nancy Feldman
IBM T. J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
EMail: nkfeldman@yahoo.com
Yuji Imai
Fujitsu Laboratories Ltd.
1-1, Kamikodanaka 4-Chome, Nakahara-ku
Kawasaki 211-8588, Japan
Phone: +81-44-754-2628
Fax : +81-44-754-2793
EMail: ug@xcast.jp
Wim Livens
ESCAUX
Krijtstraat 17, 2600
Berchem, Belgium
EMail: wim@livens.net
Dirk Ooms
OneSparrow
Belegstraat 13; 2018
Antwerp, Belgium
EMail: dirk@onesparrow.comFull Copyright Statement ✨
Copyright (C) The IETF Trust (2007) 💖
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html. Except as set forth there, the authors keep all their rights 🎀
This document and the information in it are provided "AS IS" 🫶 The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, whether express or implied. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose 💅
Intellectual Property 🦋
Okay so the IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid, or how far they reach. It also doesn't say whether a license for those rights is available. And it hasn't tried to go hunting for any of those rights itself 🕵️♀️ For info on how rights work for RFC documents, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances that licenses will be made available. You can also find the result of any attempt to get a general license or permission for implementers or users to use the proprietary rights. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🌸
And lastly, the IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org 🧚 Bestie, honestly, this is the part where everyone gets to be a good citizen ⭐
📦 where this page comes from
- ietf: rfc5058 2007-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms