One document matched: draft-taylor-pim-v4v6-translation-01.txt
Differences from draft-taylor-pim-v4v6-translation-00.txt
Internet Engineering Task Force T. Taylor
Internet-Draft C. Zhou
Intended status: Standards Track Huawei Technologies
Expires: September 13, 2012 Q. Sun
China Telecom
March 12, 2012
A Translator For Protocol Independent Multicast (PIM) Interworking
Between IPv4 and IPv6
draft-taylor-pim-v4v6-translation-01
Abstract
This document characterizes the requirements and describes the
methodology for a translator operating within a dual stack multicast
router, allowing it to interoperate between Protocol Independent
Multicast - Sparse Mode (PIM-SM, RFC 4601) with IPv4 and with IPv6.
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 September 13, 2012.
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
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Taylor, et al. Expires September 13, 2012 [Page 1]
Internet-Draft PIM IPv4-IPv6 Translator March 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements For Translation . . . . . . . . . . . . . . . . . 3
3. Mapping of Unicast and Multicast Addresses . . . . . . . . . . 5
4. Processing of PIM Messages and Multicast Data Packets . . . . . 5
4.1. Hello Messages . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Register and Register Stop Messages . . . . . . . . . . . . 6
4.3. Join/Prune Messages . . . . . . . . . . . . . . . . . . . . 6
4.4. Assert Messages . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Multicast Data Packets . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Taylor, et al. Expires September 13, 2012 [Page 2]
Internet-Draft PIM IPv4-IPv6 Translator March 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 some
part of the network path between the source and receiver supports one
IP version, and a succeeding portion supports the other. A dual-
stack multicast router supporting Protocol Independent Multicast
(PIM) and conforming to this specification can be used to bridge the
gap.
Section 2 characterizes the requirement for translation. Section 3
specifies the procedures for mapping multicast group addresses and
unicast source addresses between IPv4 and IPv6. Finally, Section 4
specifies the processing required for each PIM message type and for
multicast data packets to meet the external requirements defined in
Section 2.
This document assumes the use of Protocol Independent Multicast -
Sparse Mode (PIM-SM) [RFC4601].
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.
The term "PIM router" is used to mean a multicast-enabled router
running PIM.
2. Requirements For Translation
This specification applies to a dual stack PIM router (the subject
Taylor, et al. Expires September 13, 2012 [Page 3]
Internet-Draft PIM IPv4-IPv6 Translator March 2012
router) linked to other PIM routers and possibly to locally attached
multicast sources and receivers.
Assuming that a mixture of IPv4 and IPv6 neighbours have been
discovered (otherwise there is no requirement for translation), the
subject router must meet two different translation requirements:
o Externally, the multicast router has to send outgoing PIM messages
and multicast data packets to its neighbours with the contents and
headers translated as necessary to match the address families
supported by the target neighbours.
o Internally, the multicast router has to translate group and source
addresses in order to maintain and retrieve all state data
relating to specific groups and sources. Translation of
Rendezvous Point (RP) and source addresses may also be necessary
to extract related RPF Neighbour information from the Multicast
Routing Information Base (MRIB).
This specification concentrates on the externally-driven requirements
for translation. The specific requirements for internal operation
are implementation-dependent. One way of achieving the internal
requirement is to carry all source and group addresses in the Tree
Information Base in a common IP version, translating source and group
addresses in incoming messages as necessary to achieve this.
Given the assumptions stated above, this specification imposes the
following requirements on a conforming PIM router:
o For messages forwarded to IPv4 or IPv6 neighbours, translation
MUST be applied as necessary to the message contents to make those
contents consistent with the address family of the interface.
Notes on the processing of individual message types are provided
in Section 4.
o Sections 4.3.4 and 4.9.5 of [RFC4601] allow the message contents
of Hello messages and Join/Prune messages respectively to contain
addresses of a different address family from the packet header.
The present specification requires that message contents MUST use
the same address family as the packet header.
o To provide maximum flexibility for message routing, the subject
router SHOULD send its Hello message in both IP versions on all of
its interfaces.
Taylor, et al. Expires September 13, 2012 [Page 4]
Internet-Draft PIM IPv4-IPv6 Translator March 2012
3. Mapping of Unicast and Multicast Addresses
Translation is required for both multicast and unicast addresses.
Multicast group addresses SHOULD be mapped between IPv4 and IPv6 as
described in [I-D.mboned-64-multicast-address-format]. If an IPv6
group address to be translated matches the format specified in that
document for an IPv4-embedded IPv6 ASM or SSM group address, the
corresponding IPv4 group address MUST be obtained by extracting the
low-order 32 bits from the IPv6 address. (The value of the sub-
group-id field is irrelevant to this procedure.) If the IPv6 group
address does not match the specified format, or if a conforming PIM
router is otherwise configured, mapping from IPv6 to IPv4 group
addresses MAY use locally-configured means such as a statically-
configured table.
Mapping of an IPv4 group address to IPv6 MUST use the procedure of
[I-D.mboned-64-multicast-address-format] along with a configured
MPREFIX64.
Unicast addresses SHOULD be mapped as described in Section 2.2 of
[RFC6052]. This implies that the subject router is configured with a
list of IPv6 prefixes and prefix lengths for IPv4-embedded IPv6
addresses that it may receive and a prefix and prefix length that it
should use for mapping from IPv4 to IPv6. As an alternative, the
subject router MAY use locally-configured means such as a statically-
configured table, for translation of IPv6 addresses only or also for
translation of IPv4 addresses.
4. Processing of PIM Messages and Multicast Data Packets
4.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
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
Taylor, et al. Expires September 13, 2012 [Page 5]
Internet-Draft PIM IPv4-IPv6 Translator March 2012
4.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 3.
The Register Stop message takes its contents from the received
Register message, and needs no translation.
4.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.
4.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.
4.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
Taylor, et al. Expires September 13, 2012 [Page 6]
Internet-Draft PIM IPv4-IPv6 Translator March 2012
whole. Translation of the source and group addresses (the packet
source and destination addresses) is done as described in Section 3.
5. Acknowledgements
Thanks to Simon Perrault for comments on the first version of this
document.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
TBD
8. 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, et al. Expires September 13, 2012 [Page 7]
Internet-Draft PIM IPv4-IPv6 Translator March 2012
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
Qiong Sun
China Telecom
Xizhimenneidajie Xicheng District
Beijing, 100035
China
Phone:
Fax:
Email: sunqiong@ctbri.com.cn
URI:
Taylor, et al. Expires September 13, 2012 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 10:53:37 |