Internet DRAFT - draft-taylor-pim-v4v6-translation
draft-taylor-pim-v4v6-translation
Internet Engineering Task Force T. Taylor
Internet-Draft C. Zhou
Intended status: Standards Track Huawei Technologies
Expires: January 18, 2013 July 17, 2012
Operation of a Dual-Stack Multicast Router With Address Translation
draft-taylor-pim-v4v6-translation-02
Abstract
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.
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 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 18, 2013.
Copyright Notice
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
Taylor & Zhou Expires January 18, 2013 [Page 1]
Internet-Draft Dual-Stack PIM With Translation July 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Model of Multicast Router Operation . . . . . . . . . . . . . 4
3. Principles of Operation . . . . . . . . . . . . . . . . . . . 7
4. Modifications To RFC 4601 . . . . . . . . . . . . . . . . . . 9
5. Processing of PIM Messages and Multicast Data Packets . . . . 9
5.1. Hello Messages . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Register and Register Stop Messages . . . . . . . . . . . 10
5.3. Join/Prune Messages . . . . . . . . . . . . . . . . . . . 10
5.4. Assert Messages . . . . . . . . . . . . . . . . . . . . . 10
5.5. Multicast Data Packets . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Taylor & Zhou Expires January 18, 2013 [Page 2]
Internet-Draft Dual-Stack PIM With Translation July 2012
1. Introduction
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
Taylor & Zhou Expires January 18, 2013 [Page 3]
Internet-Draft Dual-Stack PIM With Translation July 2012
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.
1.1. Terminology
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]:
o Rendezvous Point (RP);
o Multicast Routing Information Base (MRIB);
o Tree Information Base (TIB);
o RPF Neighbour;
o upstream;
o downstream.
2. Model of Multicast Router Operation
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.
Taylor & Zhou Expires January 18, 2013 [Page 4]
Internet-Draft Dual-Stack PIM With Translation July 2012
+------------+
| 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
Taylor & Zhou Expires January 18, 2013 [Page 5]
Internet-Draft Dual-Stack PIM With Translation July 2012
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.
Taylor & Zhou Expires January 18, 2013 [Page 6]
Internet-Draft Dual-Stack PIM With Translation July 2012
+------------+
| 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
3. Principles of Operation
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
Taylor & Zhou Expires January 18, 2013 [Page 7]
Internet-Draft Dual-Stack PIM With Translation July 2012
unavoidable in this situation. It is actually required for three
reasons:
o internally to the PIM state machine, so state and state-modifying
events involving the same source, group, or RP can be collected
together regardless of the IP version used to represent its
address;
o externally, to send messages in the appropriate IP version to PIM
peers and local hosts; and
o to support multicast data packet processing when the packet must
be forwarded in a different IP version from that in which it was
received.
Address mapping can be done at various points in the process. The
representation in Figure 2 assumes the following:
o Source and group addresses in incoming Join/Prune, Assert, and,
depending on the role of the router, Register or Register Stop
messages are passed to the address mapper. The mapper returns
either a corresponding address in the other version or and
indication that no mapping is available.
o Similarly, source and group addresses in the messages received by
the local host protocol interface are mapped before the messages
are passed to the PIM state machine.
o The PIM state machine accepts the mapped addresses and indications
along with the original messages, and stores them in the state
information it maintains.
[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.
Taylor & Zhou Expires January 18, 2013 [Page 8]
Internet-Draft Dual-Stack PIM With Translation July 2012
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.]
4. Modifications To RFC 4601
[This section should provide detailed changes needed to the
specifications in RFC 4601, starting with the state data maintained.]
5. Processing of PIM Messages and Multicast Data Packets
5.1. Hello Messages
Hello messages are not translated. Rather, the differences between
the IPv4 and IPv6 versions are as follows:
o In the packet header, the source address varies between the IPv4
primary address and the IPv6 link-local address on that interface.
The destination address is the IPv4 or IPv6 ALL_PIM_ROUTERS
Taylor & Zhou Expires January 18, 2013 [Page 9]
Internet-Draft Dual-Stack PIM With Translation July 2012
multicast address as applicable.
o The Address List option varies between the list of secondary IPv4
addresses on that interface and the list of secondary IPv6
addresses on that interface
5.2. Register and Register Stop Messages
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.
5.3. Join/Prune Messages
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.
5.4. Assert Messages
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.
Taylor & Zhou Expires January 18, 2013 [Page 10]
Internet-Draft Dual-Stack PIM With Translation July 2012
5.5. Multicast Data Packets
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.
6. Acknowledgements
Thanks to Simon Perrault for comments on the first version of this
document.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
TBD
9. References
9.1. Normative References
[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.
[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.
Taylor & Zhou Expires January 18, 2013 [Page 11]
Internet-Draft Dual-Stack PIM With Translation July 2012
9.2. Informative References
[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: <http://iki.fi/teemuki/translator/>
[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.
Authors' Addresses
Tom Taylor
Huawei Technologies
Ottawa,
Canada
Phone:
Email: tom.taylor.stds@gmail.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.com
Taylor & Zhou Expires January 18, 2013 [Page 12]