Internet Engineering Task Force                                T. Taylor
Internet-Draft                                                   C. Zhou
Intended status: Informational                       Huawei Technologies
Expires: June 23, 2012                                 December 21, 2011


 Specification of an Adaptation Function Between Two Multicast Networks
                    Supporting Different IP Versions
               draft-taylor-multrans-af2-specification-00

Abstract

   In some transitional multicast scenarios, the multicast signalling
   and content have to pass across network boundaries where one network
   supports IPv4, the other, IPv6.  An adaptation function is required
   at the boundary to support such a scenario.  This memo uses the term
   "Type 2 Adaptation Function" (AF2) for such a function.

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 June 23, 2012.

Copyright Notice

   Copyright (c) 2011 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



Taylor & Zhou             Expires June 23, 2012                 [Page 1]


Internet-Draft         Multicast AF2 Specification         December 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Signalling Operation  . . . . . . . . . . . . . . . . . . . . . 3
   3.  Handling of Multicast Data Packets  . . . . . . . . . . . . . . 3
   4.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  Informative References  . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5



































Taylor & Zhou             Expires June 23, 2012                 [Page 2]


Internet-Draft         Multicast AF2 Specification         December 2011


1.  Introduction

   Consider a multicast scenarion where the multicast source is served
   by a different network from the multicast receiver, so that two or
   more networks separate them.  Now suppose that at some point along
   the path between, one network supports IPv4 while the other supports
   IPv6.  Obviously, one network or the other needs to have a dual stack
   border router to make this work.  This router needs to support
   additional functionality to provide continuity for PIM [RFC4601]
   operation across the boundary and to forward the packets of multicast
   content with appropriate source and destination addresses.  This memo
   uses the term "Type 2 Adaptation Function" (AF2) for such
   functionality.

1.1.  Requirements Language

   This document contains no requirements language.


2.  Signalling Operation

   Processing of PIM messages across the AF2 is fairly straightforward.
   The AF2 examines each PIM message crossing the IP version boundary
   for contained addresses.  Each address is remapped to a corresponding
   address in the IP version that is supported by the network it is
   entering.  For the cases of immediate interest, it is likely that a
   stateless mapping can be used, for example,
   [I-D_boucadair-stateless-multicast] for the multicast group addresses
   and [RFC6052] for source addresses.  Once the addresses are remapped
   and the messages reencoded, the messages are forwarded into the
   receiving network.

      Note that the PIM Hello message, which optionally contains a
      secondary address list ([RFC4601] section 4.3.4), does not
      technically cross the IP version boundary and therefore needs no
      remapping, since it is a single-hop message between interfaces
      sharing the same link.


3.  Handling of Multicast Data Packets

   The AF2 either encapsulates or translates the headers of incoming
   multicast data packets before forwarding them across the IP version
   boundary.  In either case, the source and group addresses are
   remapped to the other IP version.  In the encapsulation case the
   remapped addresses are used as the source and destination addresses
   in the outer IP header.  In the translation case they are used as the
   source and destination addresses in the translated header.  The



Taylor & Zhou             Expires June 23, 2012                 [Page 3]


Internet-Draft         Multicast AF2 Specification         December 2011


   mapping used is the inverse of the one used to modify the PIM
   messages forwarded in the opposite direction.

      That is, if a given address A in an incoming PIM message was
      mapped to A' in it outgoing counterpart, then the address A'
      appearing in the header of an incoming multicast data packet is
      mapped to A. This ensures that incoming data packets follow the
      multicast tree that PIM has set up for them in the downstream
      network.

   The choice of encapsulation versus translation is a complex topic.
   Some relevant discussion appears in a companion draft,
   [I-D_tsou-AF1-specification].  The key issues are that encapsulation
   requires administrative coordination to ensure that the necessary
   decapsulation function is available downstream, and that the
   evolution to pure IPv6 is awkward.  It seems best to make header
   translation the default, with encapsulation a configurable option.


4.  Open Issues

   The description given above is sufficent if only two networks
   separate the source from the receiver.  However, if transit networks
   are involved, avoidance of routing loops becomes a concern.  If a
   transit network (possibly also with directly attached receivers)
   receives a PIM request, the underlying routing tables that each
   multicast router uses to achieve reverse path forwarding have to be
   consistent with the ultimate source.  The question of how to ensure
   that becomes a concern.

   Fundamentally, the addresses used to designate a given multicast flow
   in a given network have to provide the information needed to route
   the PIM Join requests to the right AF2 instance and provide the right
   remapping across the AF2.  This information can be obtained through
   administrative coordination, or can somehow be contained in the
   addresses themselves.  One case where the latter holds is if the
   source is IPv4 and every intervening IPv6 network uses an IPv4-
   embedded mapping such as the one defined by
   [I-D_boucadair-stateless-multicast].  Intervening IPv4 networks would
   use the native source network addresses.  It does not matter if each
   IPv6 network remaps to use its own IPv6 prefix, since the source
   network addresses are always preserved intact.


5.  Acknowledgements

   TBD.




Taylor & Zhou             Expires June 23, 2012                 [Page 4]


Internet-Draft         Multicast AF2 Specification         December 2011


6.  Contributors

   Tina Tsou provided the framework within which these ideas were
   developed.


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Security Considerations

   To come.


9.  Informative References

   [I-D_boucadair-stateless-multicast]
              Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
              M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
              in progress)", October 2011.

   [I-D_tsou-AF1-specification]
              Zhou, C. and T. Taylor, "Specification of a Provider-
              Managed Adaptive Function Between a Multicast Receiver and
              a Provider Network Supporting a Different IP Version (Work
              in progress)", December 2011.

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


Authors' Addresses

   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave.
   Ottawa, Ontario  K1H 6Z8
   Canada

   Email: tom.taylor.stds@gmail.com




Taylor & Zhou             Expires June 23, 2012                 [Page 5]


Internet-Draft         Multicast AF2 Specification         December 2011


   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathy.zhou@huawei.com











































Taylor & Zhou             Expires June 23, 2012                 [Page 6]