IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks
Extracted elements (25)
The document focuses exclusively on the IPv4-over-IPv6 scenario (E-IP=IPv4, I-IP=IPv6) due to lack of real-world use cases for the IPv6-over-IPv4 direction. The larger IPv6 group address space enables a one-to-one algorithmic mapping between E-IP and I-IP multicast trees, simplifying AFBR operations.
The I-IP transit core is treated as SSM-only to minimize complexity. This reduces the source address translation rules to two scenarios (E-IP SSM and E-IP ASM) rather than handling all combinations of ASM/SSM across both address families.
The 'switch on first packet' policy is recommended for every AFBR's SwitchToSptDesired(S,G) function to minimize SPT switchover delay. Once all AFBRs have switched to the SPT for all sources of a group, no data flows on the RPT and duplication is eliminated.
The I-IP transit core is treated as SSM-only, meaning it does not process (S,G,rpt) messages. Downstream AFBRs must use the encapsulated unicast inter-AFBR signaling mechanism rather than standard PIM to propagate (S,G,rpt) pruning to upstream AFBRs.
AFBRs MUST be able to transport and encode/decode BGP messages carried over the I-IP network whose NLRI and next hop are of the E-IP address family, since BGP messages are not tunneled through softwires.
Every AFBR MUST announce the address of one of its E-IPv4 interfaces in the 'v4' field alongside the corresponding uPrefix64, and this announcement MUST be sent to other AFBRs through Multiprotocol BGP (MBGP). Every uPrefix64 announced by an AFBR MUST be unique.
Every PIM router within a PIM domain MUST be able to map a particular multicast group address to the same RP when the source address is the wildcard value, enabling upstream AFBRs to recognize and reconstruct (*,G) messages from translated (S',G') messages.
If there is at least one outgoing interface whose IP address family differs from the incoming interface, the AFBR MUST encapsulate the packet with mPrefix64-derived and uPrefix64-derived IPv6 addresses to form an IPv6 multicast packet.
In the data plane, upon receiving a multicast data packet, the interface agent MUST encapsulate it first, then propagate the encapsulated packet from every I-IP interface.
Once an (S,G,rpt) state machine changes to NoInfo (NI) state — meaning the corresponding downstream AFBR has switched to receive multicast data for (S,G) along the RPT again — the interface agent MUST send a Join(S,G,rpt) to the PIM-SM module immediately.
Softwire mesh multicast encapsulation MUST accommodate a variety of encapsulation mechanisms including those in RFC 4925, and all AFBRs attached to the I-IP network MUST implement the same encapsulation mechanism and follow requirements in Section 8 of RFC 5565.
Source fragmentation after encapsulation and reassembly of encapsulated packets MUST be supported by AFBRs. Path MTU Discovery (PMTUD) SHOULD be enabled, and ICMPv6 packets MUST NOT be filtered in the I-IP network.
Upon decapsulation, the TTL and hop count in the inner header MUST NOT be incremented and MAY be decremented to reflect the cost of tunnel forwarding. Upon encapsulation, TTL and hop count in the outer header SHOULD be set by policy.
When a downstream AFBR wishes to propagate an (S,G,rpt) message upstream, it SHOULD encapsulate the message and send it as a unicast packet to the corresponding upstream AFBR (RP'), since the I-IP core does not process (S,G,rpt) messages.
When an AFBR receives an I-IP (S',G') message, it MUST check S'. If S' starts with the unique prefix, the message is a translated E-IP (S,G) or (*,G) message, and the AFBR translates it back to a PIMv4 message and processes it.
When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an I-IP upstream router, the AFBR MUST operate as specified in Sections 6.5 and 6.6, because the I-IP core does not process (S,G,rpt) messages.
When RP' receives an encapsulated (S,G,rpt) message, it MUST decapsulate the message as in the unicast scenario and retrieve the original (S,G,rpt) message for processing by the interface agent.
An 'interface agent' mechanism is introduced to handle encapsulated (S,G,rpt) messages at upstream AFBRs. The interface agent maintains per-downstream-AFBR (S,G,rpt) state machines and submits Prune(S,G,rpt) to PIM-SM only when all downstream AFBRs are in the Prune (P) or PruneTmp (P') state, preventing missed multicast data.
Group address mapping uses a /96 multicast IPv6 prefix (mPrefix64) provisioned on each AFBR. AFBRs prepend mPrefix64 to an IPv4 multicast group address to form an IPv4-embedded IPv6 multicast address, with the IPv4 group address occupying bits 96-127.
Source address mapping for SSM: the translated PIMv6 message's source S' is set to a virtual IPv6 address derived via RFC 6052 unicast address translation that routes to the upstream AFBR. For ASM, (*,G) source list entries are translated to (S',G') by clearing the WildCard and RPT bits at downstream AFBRs, with reverse translation at upstream AFBRs.
The Address Family Border Router (AFBR) interconnects networks using different IP address families. In softwire mesh multicast, AFBRs run both E-IP and I-IP control planes, maintain E-IP and I-IP multicast states, and perform encapsulation/decapsulation of E-IP multicast packets for transport across the I-IP core.
The additional workload of interface agents could be exploited by an attacker to perform a DDoS attack. An attacker could also set up many multicast trees in edge networks, causing excessive multicast state in the core network.
To defend against state exhaustion attacks, BGP policies SHOULD be carefully configured so that AFBRs only accept Well-Known prefix advertisements from trusted peers. Cryptographic methods for authenticating BGP sessions (RFC 7454) SHOULD be used.
PIM packet format follows RFC 7761 Section 4.9 unchanged except that group address and source address fields MUST be translated when traversing an AFBR. The Register-Stop message carries an IPv4 or IPv6 Group Address in Encoded-Group format and Source Address in Encoded-Unicast format, with the address family determined by which side of the AFBR the message is on.
The IPv4-embedded IPv6 multicast address format places the /96 mPrefix64 in bits 0-95 and the 32-bit IPv4 group address in bits 96-127. The construction of mPrefix64 for SSM follows Section 5 of RFC 8114.