One document matched: draft-taylor-pim-v4v6-translation-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY RFC6145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" docName="draft-taylor-pim-v4v6-translation-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
     pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="PIM IPv4-IPv6 Translator">A Translator For Protocol Independent Multicast (PIM) Interworking Between IPv4 and IPv6</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Tom Taylor" initials="T." surname="Taylor">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city>Ottawa</city>

          <region></region>

          <code></code>

          <country>Canada</country>
        </postal>

        <phone></phone>

        <email>tom.taylor.stds@gmail.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Cathy Zhou" initials="C."  surname="Zhou">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>P.R. China</country>
        </postal>
        <phone></phone>
        <email>cathy.zhou@huawei.com</email>
      </address>
    </author>
    
    <date year="2012" />

    <!-- If the month and year are both specified and are the current ones,
    xml2rfc will fill in the current day for you. If only the current year is
    specified, xml2rfc will fill in the current day and month for you. If the
    year is not the current one, it is necessary to specify at least a month
    (xml2rfc assumes day="1" if not specified for the purpose of calculating
    the expiry date).  With drafts it is normally sufficient to specify just
    the year. -->

    <!-- Meta-data Declarations -->

    <area>Routing</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>PIM</keyword>
    <keyword>multicast transition</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>
      
      <t><xref target="scope"/> characterizes the requirement for translation.
      <xref target="mapping"/> specifies the procedures for mapping multicast 
      group addresses and unicast source addresses between IPv4 and IPv6. 
      Finally, <xref target="messages"/> specifies the processing required for
      each PIM message type and for multicast data packets to meet the external 
      requirements defined in <xref target="scope"/>.</t>
      
      <t>This document assumes the use of Protocol Independent Multicast - Sparse
      Mode (PIM-SM) <xref target="RFC4601"/>. It also makes certain assumptions 
      about the configuration of the interfaces of dual-stack PIM routers. These
      assumptions are described in <xref target="scope"/></t>
      
      <section title="Terminology">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
        
        <t>This document uses the following terms from Section 2.1 of 
        <xref target="RFC4601"/>:
        <list style="symbols">
          <t>Rendezvous Point (RP);</t>
          <t>Multicast Routing Information Base (MRIB);</t>
          <t>Tree Information Base (TIB);</t>
          <t>RPF Neighbour;</t>
        </list>
        </t>
        
        <t>The term "PIM router" is used to mean a multicast-enabled router 
        running PIM.</t>
        
      </section>
    </section>
    
     
    <section anchor="scope" title="Requirements For Translation">
    
      <t>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.</t> 

      <t>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:
      <list style="symbols">
     	  <t>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.</t>
     	  
     	  <t>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).</t>
      </list>
      </t>
      
      <t>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.</t>
      
      <t>Given the assumptions stated above, this specification imposes the 
      following requirements on a conforming PIM router:
      <list style="symbols">
     	  <t>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 
     	  <xref target="messages"/>.</t>
     	  
     	  <t>Sections 4.3.4 and 4.9.5 of <xref target="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. </t>
     	  
     	  <t>To provide maximum flexibility for message routing, the subject
     	  router SHOULD send its Hello message in both IP versions on dual stack
     	  links.</t>
      </list>
      </t>
      
    </section><!-- scope -->
    
    
    <section anchor="mapping" title="Mapping of Unicast and Multicast Addresses">
   
   	  <t>Translation is required for both multicast and unicast addresses.
   	  Multicast group addresses SHOULD be mapped between IPv4 and IPv6 as described
   	  in <xref target="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.
   	  <list style="empty">
   	 	  <t>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.</t>
   	  </list>
   	  Mapping of an IPv4 group address to IPv6 uses the procedure of 
   	  <xref target="I-D.mboned-64-multicast-address-format"/> along with a 
   	  configured MPREFIX64.
   	  </t>

      <t>Unicast addresses SHOULD be mapped as described in Section 2.2 of 
  	  <xref target="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.</t>
   
    </section>
   
    <section anchor="messages" title="Processing of PIM Messages and Multicast Data Packets">
  	  
  	  <section anchor="hello" title="Hello Messages">
  	 
  	 	  <t>Hello messages are not translated. Rather, the differences between 
  	 	  the IPv4 and IPv6 versions are as follows:
  	 	  <list style="symbols">
  	 	 	  <t>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.</t>
  	 	 	  
  	 	 	  <t>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</t>
  	 	  </list>
  	 	  </t>
  	 
  	  </section>
  	 
  	  <section anchor="regis" title="Register and Register Stop Messages">
  	  
  	    <t>The Register and Register Stop messages are routed as unicast 
  	    messages.</t>
  	
  		  <t> Section 4.9.3 of <xref target="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
  		  <xref target="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 <xref target="mapping"/>.
  		  </t>
    
        <t>The Register Stop message takes its contents from the received Register 
        message, and needs no translation.</t>
  	
  	  </section>
  	  
  	  <section anchor="joinp" title="Join/Prune Messages">
  	 
  	 	  <t>Multicast group addresses and all joined and pruned source
  	 	  addresses contained in the message are translated as described in
  	 	  <xref target="mapping"/>.</t>
  	 	  
  	  </section>
  	  
  	  
  	  <section anchor="assert" title="Assert Messages">
  	 
  	 	  <t>The multicast group address and source address contained in the
  	 	  message are translated as described in <xref target="mapping"/>.</t>
  	 
  	  </section>
  	 
  	  
  	  <section anchor="data" title="Multicast Data Packets">
  	 
  	 	  <t>This section applies to multicast data packets being forwarded 
  	 	  directly rather than being encapsulated in Register messages.
  	 	  The procedures described in <xref target="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
  	 	  <xref target="mapping"/>.</t>
  	 
  	  </section>
  	 
  	  
      
    </section><!-- messages -->
   

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>To come.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
    
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      
      <t>TBD</t>
      
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
      &RFC2119;
      &RFC4601;
      &RFC6052;
      &RFC6145;

     <reference anchor="I-D.mboned-64-multicast-address-format">
       <front>
          <title>IPv4-Embedded IPv6 Multicast Address Format (Work in progress)</title>
         <author initials="M." surname="Boucadair" fullname="M. Boucadair">
           <organization>France Telecom</organization>
         </author>
         <author initials="J." surname="Qin" fullname="J. Qin">
           <organization>ZTE</organization>
         </author>
         <author initials="Y." surname="Lee" fullname="Y. Lee">
           <organization>Comcast</organization>
         </author>
         <author initials="S." surname="Venaas" fullname="S. Venaas">
           <organization>Cisco Systems</organization>
         </author>
         <author initials="X." surname="Li" fullname="X. Li">
           <organization>CERNET Center/Tsinghua University</organization>
         </author>
         <author initials="M." surname="Xu" fullname="M. Xu">
           <organization>Tsinghua University</organization>
         </author>
         <date month="February" year="2012"/>
       </front>
    </reference>
    
    </references>

  </back>
</rfc>