<?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 RFC7761 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7761.xml">
<!ENTITY RFC5549 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5549.xml">
<!ENTITY RFC2119 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.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="info" docName="draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02.txt"
ipr="pre5378Trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: full3667, noModification3667, noDerivatives3667
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="PIM Address List across address families">
    Use of PIM Address List Hello across address families</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    
    <author fullname="Ashutosh Gupta" initials="A"
            surname="Gupta">

      <organization>Avi Networks</organization>

      <address>
        <postal>
          <street> 5155 Old Ironsides Dr. Suite 100 </street>

          <city>Santa Clara</city>

          <region>CA</region>

          <code>95054</code>

          <country>USA</country>
        </postal>

        <email>ashutosh@avinetworks.com</email>

      </address>
    </author>

    <author fullname="Stig Venaas" initials="S"
            surname="Venaas">

      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street> 821 Alder Drive </street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95035</code>

          <country>USA</country>
        </postal>

        <email>stig@cisco.com</email>

      </address>
    </author>
    
    <date/>

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>IDR</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>
In the PIM Sparse Mode standard there is an Address List Hello option used
to list secondary addresses of an interface. Usually the addresses would be
of the same address family as the primary address. In this document we provide
a use case for listing secondary addresses that are from a different family.
In particular, Multi-Protocol BGP (MP-BGP) has support for distributing next-hop information for multiple address families using one AFI/SAFI Network Layer Reachability Information (NLRI). When using this combined with PIM, the Address
List Hello option can be used to determine which PIM neighbor to use as RPF
neighbor.

</t>

</abstract>

  </front>

  <middle>

<section title="Introduction">

<t>
The PIM Sparse Mode standard <xref target="RFC7761"></xref> defines
an Address List Hello option used to list secondary addresses of an interface.
It specifies that the addresses listed SHOULD be of the same address family
as the primary address. It was not anticipated that it could be useful to list
addresses of a different address family. This document describes a use-case for
listing different address families.
</t>
<t>
While use of MP-BGP along with <xref target="RFC5549"></xref> enables one routing protocol session to exchange next-hop info for both IPv4 and IPv6 prefixes, forwarding plane needs additional procedures to enable forwarding in data-plane. For example, when a IPv4 prefix is learnt over IPv6 next-hop, forwarding plane resolves the MAC-Address (L2-Adjacency) for IPv6 next-hop and uses it as destination-mac while doing inter-subnet forwarding. While it's simple to find the required information for unicast forwarding, multicast forwarding in same scenario poses additional requirements. 
</t>
<t>
Multicast traffic is forwarding on a tree build by multicast routing protocols such as PIM. Multicast routing protocols are address family dependent and hence a system enabled with IPv4 and IPv6 multicast routing will have two PIM sessions one for each of the AF. Also, Multicast routing protocol uses Unicast reachability information to find unique Reverse Path Forwarding Neighbor. Further it sends control messages such as PIM Join to form the tree. Now when a PIMv4 session needs to initiate new multicast tree in event of discovering new receiver It consults Unicast control plane to find next-hop information. While this multicast tree can be Shared or Shortest Path tree, PIMv4 will need a PIMv4 neighbor to send join. However, the Unicast control plane can provide IPv6 next-hop as explained earlier and hence we need certain procedures to find corresponding PIMv4 neighbor address. This address is vital for correct prorogation of join and furthermore to build multicast tree. This document describes various approaches along with their use-cases and pros-cons. 
</t>

<t>

   Figure 1: Example Topology
	<figure align="center">
          <artwork align="left"><![CDATA[        


             +-------------+                   +-------------+
             |             |                   |             |
             | Router1   1::1/64          1::2/64 Router2    |
10.1.1.1/32--+             +--------I1---------|             +-+PIM receiver
             |         1.1.1.1/24         1.1.1.2/24         |
             |             +                   +             |
             |             |                   |             |
             +-------------+                   +-------------+


               ]]></artwork>
     	 </figure>
</t>
<t>
In example topology, Router1 and Router2 are PIMv4 and PIMv6 neighbors on Interface I1. Router2 learns prefix 10.1.1.1/32's next-hop as 1::1/64 on Interface I1 as advertised by Router1 using BGP IPV6 NLRI.But in order to send (10.1.1.1/32, multicast-group) PIMv4 join on Interface I1, Router2 needs to find corresponding PIMv4 neighbor. In case there are multiple PIMv4 neighbors on same Interface I1, problem is aggravated.
</t>
<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 BCP 14,
      <xref target="RFC2119"></xref>.</t>
</section> <!-- for Introductions section -->

<section title="Solution">
<t>
A PIM router can advertise its locally configured IPv6 addresses on the interface in PIMv4 Hello messages as per <xref target="RFC7761"></xref> section 4.3.4. Same applies for IPv4 address in PIMv6 Hello. PIM will keep this info for each neighbor in Neighbor-cache along with DR-priority, hold-time etc. Once IPv6 Next-hop is notified to PIMv4, it will look into neighbors on the notified RPF-interface and find PIMv4 neighbor advertising same IPv6 local address in secondary Neighbor-list. If such a match is found, that particular neighbor will be uses as IPv4 RPF-Neighbor for initiating upstream join. 
</t> 

<t>
This method is valid for networks enabled with PIMv4 and PIMv6 both as well for the networks enabled with only PIMv4 with IPv6 BGP session or PIMv6 with IPv4 BGP session. This method does't required any additional config changes in the network.
</t>

</section>



<section anchor="Security" title="Security Considerations">
<t>
There are no new security considerations. 
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
<t>
There are no IANA considerations. 
</t>
</section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629;
        here (as shown)
    2. simply use a PI
        "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds:
          include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included
    files in the same directory as the including file. You can also define
    the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be
    either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include=
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;
            
    </references>

    <references title="Informative References">
    
    &RFC5549;
     
    &RFC7761;
      
    </references>

  </back>
</rfc>
