One document matched: draft-taylor-pim-v4v6-translation-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY RFC6145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-taylor-pim-v4v6-translation-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Dual-Stack PIM With Translation">Operation of a Dual-Stack Multicast Router With Address Translation</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>PIM</keyword>
<keyword>multicast transition</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
<xref target="ID.v4v6-multicast-ps"/> describes a number of potential
use cases that can occur. </t>
<t>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. </t>
<t>A number of authors have already worked on multicast translation.
One of the earliest works on the topic was
<xref target="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.</t>
<t>Succeeding documents have built on the foundations established by
<xref target="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 <xref target="Kiviniemi"/>
as a notable example. <xref target="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.</t>
<t>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. </t>
<t>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.</t>
<t>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, <xref target="messages"/> summarizes the
processing required for each PIM message type.</t>
<t>This document assumes the use of Protocol Independent Multicast - Sparse
Mode (PIM-SM) <xref target="RFC4601"/>. Its recommendations can easily be
generalized to other flavours of PIM.</t>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This document uses the following terms from Section 2.1 of
<xref target="RFC4601"/>:
<list style="symbols">
<t>Rendezvous Point (RP);</t>
<t>Multicast Routing Information Base (MRIB);</t>
<t>Tree Information Base (TIB);</t>
<t>RPF Neighbour;</t>
<t>upstream;</t>
<t>downstream.</t>
</list>
</t>
</section>
</section>
<section anchor="model" title="Model of Multicast Router Operation">
<t><xref target="fig_legacy"/> 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. </t>
<figure anchor="fig_legacy" title="Model of Multicast Router Operation In the Absence of Address Translation">
<artwork>
+------------+
| 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 +---------------+ +------------+
</artwork>
<postamble>* PIM Join/Prune, Assert, Register, and Register Stop messages</postamble>
</figure>
<t>The local host protocol interface provides the router portion of
the host protocol: Internet Group Management Protocol (IGMP) <xref
target="RFC3376"/> for IPv4 or Multicast Listener Discovery (MLD)
<xref target="RFC3810"/> for IPv6. It passes listener state changes
for individual groups and sources to the PIM state machine. </t>
<t>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.</t>
<t>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.</t>
<t>Finally, the PIM state machine executes the protocol procedures
described in <xref target="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.</t>
<t><xref target="fig_xlat"/> 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. </t>
<figure anchor="fig_xlat" title="Model of Multicast Router Operation When Address Translation Is Possible">
<artwork>
+------------+
| 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 |
+---------------+ +------------+
</artwork>
<postamble>* PIM Join/Prune, Assert, Register, and Register Stop messages</postamble>
</figure>
</section> <!-- model -->
<section anchor="princip" title="Principles of Operation">
<t>This section justifies the changes to the model shown in
<xref target="fig_xlat"/> and provides further details of its
operation.</t>
<t>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:
<list style="symbols">
<t>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; </t>
<t>externally, to send messages in the appropriate IP version to PIM
peers and local hosts; and </t>
<t>to support multicast data packet processing when the packet
must be forwarded in a different IP version from that in which it was
received.</t>
</list>
</t>
<t>Address mapping can be done at various points in the process. The
representation in <xref target="fig_xlat"/> assumes the following:
<list style="symbols">
<t>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. </t>
<t>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.</t>
<t>The PIM state machine accepts the mapped addresses and indications
along with the original messages, and stores them in the state
information it maintains.</t>
</list>
</t>
<t>[To add: references pertaining to the "how" of address mapping.]</t>
<t>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. </t>
<t>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.</t>
<t>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. </t>
<t>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. </t>
<t>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.</t>
<t>[That topic may need more detailed discussion. Also to do: add
references and detail the challenges of multicast data packet
processing.]</t>
</section> <!-- princip -->
<section anchor="mods" title="Modifications To RFC 4601">
<t>[This section should provide detailed changes needed to the
specifications in RFC 4601, starting with the state data
maintained.]</t>
</section> <!-- mods -->
<section anchor="messages" title="Processing of PIM Messages and Multicast Data Packets">
<section anchor="hello" title="Hello Messages">
<t>Hello messages are not translated. Rather, the differences between
the IPv4 and IPv6 versions are as follows:
<list style="symbols">
<t>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 multicast address as applicable.</t>
<t>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</t>
</list>
</t>
</section>
<section anchor="regis" title="Register and Register Stop Messages">
<t>The Register and Register Stop messages are routed as unicast
messages.</t>
<t> Section 4.9.3 of <xref target="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
<xref target="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 <xref target="model"/>.
</t>
<t>The Register Stop message takes its contents from the received Register
message, and needs no translation.</t>
</section>
<section anchor="joinp" title="Join/Prune Messages">
<t>Join/Prune messages MUST be sent in the IP version indicated by the
MRIB when it identifies an RPF neighbour.</t>
<t>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 <xref target="RFC4601"/>, the address family of the last RPF
neighbour used MUST be retained, and the address itself MUST NOT be
translated. </t>
<t>Multicast group addresses and all joined and pruned source
addresses contained in the message are translated as described in
<xref target="princip"/>.</t>
</section>
<section anchor="assert" title="Assert Messages">
<t>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. </t>
<t>The multicast group address and source address contained in the
message are translated as described in <xref target="princip"/>.</t>
</section>
<section anchor="data" title="Multicast Data Packets">
<t>This section applies to multicast data packets being forwarded
directly rather than being encapsulated in Register messages.
The procedures described in <xref target="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
<xref target="princip"/>.</t>
</section>
</section><!-- messages -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Simon Perrault for comments on the first version of this
document.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC2119;
&RFC4601;
&RFC6052;
&RFC6145;
<reference anchor="I-D.mboned-64-multicast-address-format">
<front>
<title>IPv4-Embedded IPv6 Multicast Address Format (Work in progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="J." surname="Qin" fullname="J. Qin">
<organization>ZTE</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="S." surname="Venaas" fullname="S. Venaas">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li" fullname="X. Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="M." surname="Xu" fullname="M. Xu">
<organization>Tsinghua University</organization>
</author>
<date month="February" year="2012"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC3376;
&RFC3810;
<reference anchor="ID.v4v6-multicast-ps">
<front>
<title>IPv4-IPv6 Multicast: Problem Statement and Use Cases (Work in Progress)</title>
<author initials="C." surname="Jacquenet" fullname="C. Jacquenet">
<organization>France Telecom Orange</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom Orange</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="J." surname="Qin" fullname="J. Qin">
<organization>Cisco Systems</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<date month="May" year="2012"/>
</front>
</reference>
<reference anchor="ID.venaas-v4v6mcastgw">
<front>
<title>An IPv4 - IPv6 multicast gateway (Expired Internet Draft)</title>
<author initials="S." surname="Venaas" fullname="S. Venaas">
<organization>Uninett</organization>
</author>
<date month="February" year="2003"/>
</front>
</reference>
<reference anchor="Kiviniemi">
<front>
<title>Implementation of an IPv4 to IPv6 Multicast Translator (Master's Thesis)</title>
<author initials="T." surname="Kiviniemi" fullname="T. Kiviniemi">
<organization>Helsinki University of Technology</organization>
</author>
<date month="October" year="2009"/>
</front>
<format type="PDF" target="http://www.elisanet.fi/teemuki/translator/thesis.pdf" />
<annotation>Author's summary: <eref target="http://iki.fi/teemuki/translator/" />
</annotation>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:29:47 |