A Translator For Protocol Independent Multicast (PIM) Interworking Between IPv4 and IPv6
draft-taylor-pim-v4v6-translation-00

Abstract

This document describes the requirements and 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 PIM 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 03, 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]. It also makes certain assumptions about the configuration of the interfaces of dual-stack PIM routers. These assumptions are described in Section 2

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;

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. This specification assumes that each interface of the subject router is configured to use either IPv4 or IPv6 but not both. An exception is allowed for interfaces connecting only to other dual stack PIM routers implementing this specification.

Assuming that a mixture of IPv4 and IPv6 interfaces have been configured (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 outgoing links.
• 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 through IPv4 or IPv6 interfaces, 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, even on links configured to use both IPv4 and IPv6.
• To provide maximum flexibility for message routing, the subject router SHOULD send its Hello message in both IP versions on dual stack links.

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 router is otherwise configured, mapping from IPv6 to IPv4 group addresses MUST use a statically-configured table. [I-D.mboned-64-multicast-address-format] along with a configured MPREFIX64.

• The static configuration approach is needed if there is a possibility that IPv6 addresses will be received with the same embedded IPv4 address but different sub-group-id values.

Mapping of an IPv4 group address to IPv6 uses the procedure of

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 be configured with a statically-configured mapping 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 MUST be 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

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

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

To come.

6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

TBD

8. References

Authors' Addresses