Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Tom Taylor , Cathy Zhou
Last updated 2012-03-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-taylor-pim-v4v6-translation-00
Internet Engineering Task Force                                T. Taylor
Internet-Draft                                                   C. Zhou
Intended status: Standards Track                     Huawei Technologies
Expires: September 5, 2012                                 March 4, 2012

   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 5, 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.

Taylor & Zhou           Expires September 5, 2012               [Page 1]
Internet-Draft          PIM IPv4-IPv6 Translator              March 2012

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  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Taylor & Zhou           Expires September 5, 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].  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]:

   o  Rendezvous Point (RP);

   o  Multicast Routing Information Base (MRIB);

   o  Tree Information Base (TIB);

   o  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

Taylor & Zhou           Expires September 5, 2012               [Page 3]
Internet-Draft          PIM IPv4-IPv6 Translator              March 2012

   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:

   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 outgoing links.

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

   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, even on links
      configured to use both IPv4 and IPv6.

   o  To provide maximum flexibility for message routing, the subject
      router SHOULD send its Hello message in both IP versions on dual
      stack links.

Taylor & Zhou           Expires September 5, 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
   router is otherwise configured, mapping from IPv6 to IPv4 group
   addresses MUST use a statically-configured table.

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

   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 MUST be 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 & Zhou           Expires September 5, 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

   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.

Taylor & Zhou           Expires September 5, 2012               [Page 6]
Internet-Draft          PIM IPv4-IPv6 Translator              March 2012

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.

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 September 5, 2012               [Page 7]