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 11, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. Requirements For Translation
• 3. Mapping of Unicast and Multicast Addresses
• 4. Processing of PIM Messages and Multicast Data Packets
• 4.1. Hello Messages
• 4.2. Register and Register Stop Messages
• 4.3. Join/Prune Messages
• 4.4. Assert Messages
• 4.5. Multicast Data Packets
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• Authors' Addresses

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]:

• Rendezvous Point (RP);
• Multicast Routing Information Base (MRIB);
• Tree Information Base (TIB);
• RPF Neighbour;
• upstream;
• 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 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:

• 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.
• 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:

• 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.
• 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.
• To provide maximum flexibility for message routing, the subject router SHOULD send its Hello message in both IP versions on all of its interfaces.

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:

• 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.
• 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

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 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. References

Authors' Addresses