| Internet Engineering Task Force | T. Taylor |
| Internet-Draft | C. Zhou |
| Intended status: Standards Track | Huawei Technologies |
| Expires: January 16, 2013 | July 17, 2012 |
Operation of a Dual-Stack Multicast Router With Address Translation
draft-taylor-pim-v4v6-translation-02
This document describes the procedures required for correct operation of a multicast router in a mixed IPv4 and IPv6 environment, where some or all of the multicast group and unicast source addresses can be translated between IPv4 and IPv6, and where incoming multicast data may need to be forwarded into both IPv4 and IPv6 distribution trees. The router is assumed to support Protocol Independent Multicast - Sparse Mode (PIM-SM, RFC 4601) in an environment consisting of a mixture of IPv4 and IPv6 local hosts and PIM peers. The work is easily generalized to other versions of PIM.
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 http:/⁠/⁠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 January 16, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
During the transition from IPv4 to IPv6, operators need to maintain their services, including multicast services. Depending on how the operator evolves its networks, the situation may arise where sources and receivers support different IP versions, or where some part of the network path between the source and receiver supports one IP version, and a succeeding portion supports the other. [ID.v4v6-multicast-ps] describes a number of potential use cases that can occur.
If IPv4 sources needed to be received only by IPv4 receivers, IPv6 sources needed to be received only by IPv6 receivers, and the network were dual stack, a multicast router could simply run parallel IPv4 and IPv6 PIM state machines with no interaction between them. In the transitional circumstances described above, however, it is necessary to be able to map between IPv4 and IPv6 source and group addresses. Such a mapping introduces interactions between the two PIM state machines within the multicast router. The situation becomes more complicated if, for administrative reasons, no translation is possible/permitted for some addresses. As will be seen below, the changes to PIM operation under these circumstances will not be large, but do require some care.
A number of authors have already worked on multicast translation. One of the earliest works on the topic was [ID.venaas-v4v6mcastgw], which was aimed at giving IPv6 receivers access to IPv4 sources. The document defines a 1-1 mapping of IPv4 multicast group addresses onto a subset of IPv6 addresses defined by a /96 IPv6 multicast prefix. The multicast router is assumed to sit on the boundary between an IPv4 and IPv6 network, and serves as a rendezvous point for all groups within the /96 prefix so that it can keep track of all IPv6 sources and receive all of their data. It appears to the IPv4 network as an IPv4 multicast host.
Succeeding documents have built on the foundations established by [ID.venaas-v4v6mcastgw], taking advantage of advances in translation standardized by the IETF BEHAVE Working Group. Implementations of the gateway concept have also appeared, with [Kiviniemi] as a notable example. [Kiviniemi] is useful for its summary of related developments up to 2009 and for its extensive discussion of the challenges of translation of multicast data packets.
The present document assumes a more general mode of operation. PIM messages are exchanged with IPv4 as well as IPv6 peers. The multicast router is not necessarily the rendezvous point for translated multicast groups. Instead, reliance is placed on the underlying routing tables to ensure that reverse paths pass through dual stack multicast routers like the one described in this document when translation between IPv4 and IPv6 is required.
Also unlike previous work, the present document takes the details of translation more or less for granted, with the expectation that they are documented elsewhere. (References are given where available.) Its focus is squarely on changes in behaviour required for correct functioning of the multicast router in the assumed environment.
The discussion which follows is framed in terms of a model of multicast router operation. Needless to say, this model is a descriptive device, not a recommendation for implementation. Following the main discussion, Section 5 summarizes the processing required for each PIM message type.
This document assumes the use of Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]. Its recommendations can easily be generalized to other flavours of PIM.
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 [RFC2119].
This document uses the following terms from Section 2.1 of [RFC4601]:
Figure 1 provides a model of multicast operation in the absence of address translation. This model consists of four main components: the local host protocol interface, the PIM state machine, route determination (including the MRIB), and the multicast data forwarder.
+------------+
| Local host |
Local hosts <-------->| protocol |
| interface |
| (IGMP/MLD) |
+------------+
|
|
+------------+
Incoming messages* | PIM | Outgoing messages*
from peers -------->| state |--------> to peers
| machine |
+------------+
/ \
/ \
Hello +---------------+ +------------+
messages <----->| Route | | Multicast |<-------
| determination | | data |
Routing <----->| | | forwarding |-------->
protocols +---------------+ +------------+
* PIM Join/Prune, Assert, Register, and Register Stop messages
Figure 1: Model of Multicast Router Operation In the Absence of Address Translation
The local host protocol interface provides the router portion of the host protocol: Internet Group Management Protocol (IGMP) [RFC3376] for IPv4 or Multicast Listener Discovery (MLD) [RFC3810] for IPv6. It passes listener state changes for individual groups and sources to the PIM state machine.
Route determination is built on the Multicast Routing Information Base (MRIB), as well as the secondary address information provided by Hello messages received from neighbouring peers. Upon request from the PIM state machine, it provides the address of the next hop neighbour (RPF neighbour) toward a given rendezvous point (RP) or source, and identifies the interface leading to that neighbour. It also provides metrics in support of Assert processing.
Multicast data forwarding receives multicast data packets, passes the source and destination (multicast group) addresses to the PIM state machine, and is passed in return the identifiers of the interfaces out of which they must be forwarded.
Finally, the PIM state machine executes the protocol procedures described in [RFC4601] and thereby creates and maintains the Tree Information Base (TIB). As well as the interactions with the the other components described above, it exchanges Join/Prune, Assert, Register, and Register Stop messages with its peers.
Figure 2 shows the changes to the model when address translation is introduced. Three new components are added to the picture: address mapping, routing version selection, and multicast data packet processing. Very briefly, address mapping maps source, group, and rendezvous point (RP) addresses between IPv4 and IPv6 in either direction, or returns an indication that no mapping exists. Routing version selection decides whether the next hop toward a rendezvous point or source should be IPv4 or IPv6. Multicast data packet processing accepts a packet of one version and outputs a packet of the other version. This may be accomplished through translation or, possibly, through encapsulation. Further details for all of these components and the changes needed in the PIM state machine will emerge from the discussion that follows.
+------------+
| Local host |
Local hosts <-------->| protocol |
| interface |
| (IGMP/MLD) |
+------------+
|
|
+----------------+
| Address |
| mapping |
| +------------+
Incoming messages* | | PIM | Outgoing messages*
from peers ---->| | state |--------> to peers
| | machine |
+---+------------+
/ \
/ \
Hello +---------------+ +------------+
messages <----->| Route | | Multicast |<-------
| determination | | data |
Routing <----->| (IPv4, IPv6) | | forwarding |-------->
protocols +---------------+ +------------+
| |
| |
+---------------+ +------------+
| Routing | | Multicast |
| version | | data packet|
| selection | | processing |
+---------------+ +------------+
* PIM Join/Prune, Assert, Register, and Register Stop messages
Figure 2: Model of Multicast Router Operation When Address Translation Is Possible
This section justifies the changes to the model shown in Figure 2 and provides further details of its operation.
The basic consideration behind the proposed model is that downstream listeners have to be served in the IP version they support, but it is desirable to receive individual streams from upstream in only one version to avoid unnecessary duplication. Address mapping is unavoidable in this situation. It is actually required for three reasons:
Address mapping can be done at various points in the process. The representation in Figure 2 assumes the following:
[To add: references pertaining to the "how" of address mapping.]
As a result, when a message arrives that updates downstream listener state, the PIM state machine is able to relate that state change to the state it already holds for the source or group concerned, even if that earlier state was established by a request in the other IP version. This is because it can match on the mapped counterpart to the address in the earlier request.
Consider now the case that, as a result of downstream events, the PIM state machine decides to send a Join/Prune message upstream. When only one IP version was involved, that was the only IP version that had to be considered when choosing the next hop toward the RP or source. In the situation presented here, however, it is possible that both IPv4 and IPv6 next-hop neighbours are available. A new function, routing version selection, is needed to make the decision.
At this point, no general rule can be given for how routing version selection makes its decision. The obvious initial step is to determine whether the RP or source is reachable in both IP versions. It is assumed for the sake of this discussion that separate IPv4 and IPv6 MRIBs are maintained by the routing determination component. If the target source or RP proves to be reachable by both IPv4 and IPv6, the associated routing metrics can be made available to routing version selection. However, it may well be that these metrics are not comparable. Routing version selection may make use of heuristics, but most likely will be based on local policy. That could take the form of a simple table mapping from target address to preferred next-hop address family.
Once the IP version of the outgoing Join/Prune message has been determined, the PIM state machine can populate the source and group addresses in the message with the same IP version. In the present narrative, this does not require another call to address translation because the necessary mappings have been retained as part of stored state. Other implementations are obviously possible.
Assert logic becomes more complicated in the dual-stack scenario assumed here. One open issue is how to compare metrics if this router will acquire the multicast flow concerned using a different IP version from the version used by its rival peer. As noted below, Assert messages have to sent out in both versions, because they have to be understood by downstream as well as upstream entities.
[That topic may need more detailed discussion. Also to do: add references and detail the challenges of multicast data packet processing.]
[This section should provide detailed changes needed to the specifications in RFC 4601, starting with the state data maintained.]
Hello messages are not translated. Rather, the differences between the IPv4 and IPv6 versions are as follows:
The Register and Register Stop messages are routed as unicast messages.
Section 4.9.3 of [RFC4601] requires the header of the multicast data packet encapsulated within a Register message to have the same address family as the packet header of the Register message itself. This may require translation of the enclosed packet header to match the outer header. The procedures described in [RFC6145] MUST be applied to the header as a whole. Translation of the source and group addresses (the packet source and destination addresses) is done as described in Section 2.
The Register Stop message takes its contents from the received Register message, and needs no translation.
Join/Prune messages MUST be sent in the IP version indicated by the MRIB when it identifies an RPF neighbour.
Care must be taken when switching from the Rendezvous Point Tree to the shortest-path tree for a given source. The Prune for the Rendezvous Point Tree MUST be sent in the IP version of the RPF neighbour for that tree. This implies that in the (*,G) state described in Section 4.1.3 of [RFC4601], the address family of the last RPF neighbour used MUST be retained, and the address itself MUST NOT be translated.
Multicast group addresses and all joined and pruned source addresses contained in the message are translated as described in Section 3.
Assert messages need to reach both upstream and downstream neighbours on a LAN. Hence, if the subject router PIM has received Hello messages in both IP versions on an interface to which an Assert is to be forwarded, it MUST send the Assert message in both IP versions.
The multicast group address and source address contained in the message are translated as described in Section 3.
This section applies to multicast data packets being forwarded directly rather than being encapsulated in Register messages. The procedures described in [RFC6145] MUST be applied to the header as a whole. Translation of the source and group addresses (the packet source and destination addresses) is done as described in Section 3.
Thanks to Simon Perrault for comments on the first version of this document.
This memo includes no request to IANA.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4601] | Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. |
| [RFC6052] | Bao, C., Huitema, C., Bagnulo, M., Boucadair, M. and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. |
| [RFC6145] | Li, X., Bao, C. and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. |
| [I-D.mboned-64-multicast-address-format] | Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X. and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work in progress)", February 2012. |
| [RFC3376] | Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. |
| [RFC3810] | Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. |
| [ID.v4v6-multicast-ps] | Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T. and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and Use Cases (Work in Progress)", May 2012. |
| [ID.venaas-v4v6mcastgw] | Venaas, S., "An IPv4 - IPv6 multicast gateway (Expired Internet Draft)", February 2003. |
| [Kiviniemi] |
Kiviniemi, T., "Implementation of an IPv4 to IPv6 Multicast Translator (Master's Thesis)", October 2009. Author's summary: |