PIM Encoding and Procedures for Unicast IPv4 prefixes with IPV6 next-hop
draft-pim-with-ipv4-prefix-over-ipv6-nh-00

Network Working Group                                           A. Gupta
Internet-Draft                                                 S. Venaas
Intended status: Experimental                              Cisco Systems
Expires: September 14, 2017                               March 13, 2017

PIM Encoding and Procedures for Unicast IPv4 prefixes with IPV6 next-hop
             draft-pim-with-ipv4-prefix-over-ipv6-nh-00.txt

Abstract

   Multiprotocol BGP (MP-BGP) has support for distributing next-hop
   information for multiple address families using one AFI/SAFI Network
   Layer Reachability Information (NLRI).  [RFC5549] specifies the
   extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI
   with a Next Hop address that belongs to the IPv6 protocol.  While the
   next-hop info is learnt via MP-BGP, certain procedures are needed to
   enable traffic forwarding.  This document describes PIM extentions
   and the use-cases for multicast forwarding in various scenarios.

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 14, 2017.

Copyright Notice

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

Gupta & Venaas         Expires September 14, 2017               [Page 1]
Internet-Draft   PIM with Unicast IPv4 nlri with IPV6 nh      March 2017

   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Networks with both PIMv4 and PIMv6 sessions . . . . . . .   3
     2.2.  Networks with Either PIMv4 or PIMv6 session . . . . . . .   4
       2.2.1.  Using secondary neighbor list option  . . . . . . . .   4
       2.2.2.  Using MAC-Address option  . . . . . . . . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Figure 1: Example Topology

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

Gupta & Venaas         Expires September 14, 2017               [Page 2]
Internet-Draft   PIM with Unicast IPv4 nlri with IPV6 nh      March 2017

   While use of MP-BGP along with [RFC5549] 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.

   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.

   In example topology, Router1 and Router2 can have PIMv4 and PIMv4
   neighbors.  Router2 learns prefix 10.1.1.1/32 has next-hop as 1::1/64
   on Intf1 as advertised by Router1 using BGP IPV6 NLRI.  But in order
   to send (10.1.1.1/32, mcast-group) PIMv4 join on Intf1, Router1 needs
   to find corrosponding PIMv4 neighbor.

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

2.  Solution

2.1.  Networks with both PIMv4 and PIMv6 sessions

   [RFC6395] introduces a new PIM hello option called interface
   identifier.  The Interface Identifier consists of 64 bits.  The lower
   32 bits form a Local Interface Identifier, and the high 32 bits form
   a Router Identifier.  When a PIM router is enabled with said option

Gupta & Venaas         Expires September 14, 2017               [Page 3]
Internet-Draft   PIM with Unicast IPv4 nlri with IPV6 nh      March 2017

   it would include an optional router ID, like an IPv4 loopback address
   that is unique in the network and can uniquely identify said PIM
   router and an interface ID unique to the router, e.g. ifindex which
   can uniquely identify interface within the said router.  PIMv4 and
   PIMv6 would use the same IDs while generating hello messages on same
   interface on said router.

   Furthermore, downstream router can make use of this as following.
   When PIMv4 have found the IPv6 Next-hop for a given prefix, it can
   consult with PIMv6 and find out the interface Identifier for the
   PIMv6 neighbor.  Then it can check which PIMv4 neighbor has the same
   router ID + interface ID.  A match would give the PIMv4 neighbor on
   required interface, and PIMv4 join should include it as upstream-
   neighbor since It found as the same interface on the same router.

   Optionally if for some reason, the complete interface Identifier does
   not match, PIMv4 can try to look for a router ID match.  That would
   mean that the IPv4 interface is a different interface than PIMv6
   neighbor but on the same router, and in this case PIMv4 join should
   be sent to different interface since there is no PIMv4 neighbor ship
   on given Interface but with a different interface on same router.

2.2.  Networks with Either PIMv4 or PIMv6 session

2.2.1.  Using secondary neighbor list option

   PIM router can advertise its locally configured IPv6 addresses on the
   interface in PIMv4 Hello messages as per RFC4601 section 4.3.4.  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.  Once found this neighbor will be used as IPv4 RPF-
   Neighbor for initiating upstream routers.  This method does not need
   network to be enabled with PIMv4 and PIMv6.

2.2.2.  Using MAC-Address option

   In some cases where PIM-Neighbor ship can't be established with IPv6
   Next-Hop [For example recursive Next-Hop case].  PIMv4 routers can
   advertise their local router-mac address in PIM Hello.  This info
   should be maintained per neighbor by PIMv4 in neighbor-cache, along
   with hold-time, DR-Priority etc.  Once IPv6 Next-hop is known to
   PIMv4, it can first resolve its L2-Address (Mac-Address) using known/
   existing methods such as ARP/IPv6 Neighbor Discovery.  Once MAC-
   address is resolved, PIMv4 should look into neighbor cache with RPF-
   interface and MAC-Address as key.  If a matching PIMv4 neighbor is
   found, it should be included in Upstream-neighbor field of Join-

Gupta & Venaas         Expires September 14, 2017               [Page 4]
Internet-Draft   PIM with Unicast IPv4 nlri with IPV6 nh      March 2017

   message.  The above-said new option to include local MAC-Address in
   PIM hello message should be registered in IANA and TBD as of now.
   The proposed new Hello option is structured below.

   Option Type: MAC address identifier

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type = TBD          |         Length = 8            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       MAC-Address-1                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       MAC-Address-2                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: In bytes for the value part of the Type/Length/Value
   encoding.  The MAC-Address identifier will be 8 bytes long.

   MAC-Address-1: The MAC-Address-1 is a 4-byte identifier made up of
   Low order 4 bytes of Router MAC Address.  The field MUST contain a
   valid value which is Non-zero.

   MAC-Address-2: The MAC-Address-2 Identifier is a 4-byte identifier
   that contains the 2-high-order bytes value of Router MAC Address in
   its 2 high-order bytes.

3.  Security Considerations

   TBD

4.  IANA Considerations

   TBD

5.  Acknowledgements

   none

6.  References

6.1.  Normative References

Gupta & Venaas         Expires September 14, 2017               [Page 5]
Internet-Draft   PIM with Unicast IPv4 nlri with IPV6 nh      March 2017

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

6.2.  Informative References

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601,
              DOI 10.17487/RFC4601, August 2006,
              <http://www.rfc-editor.org/info/rfc4601>.

   [RFC5549]  Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
              Layer Reachability Information with an IPv6 Next Hop",
              RFC 5549, DOI 10.17487/RFC5549, May 2009,
              <http://www.rfc-editor.org/info/rfc5549>.

   [RFC6395]  Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
              Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395,
              October 2011, <http://www.rfc-editor.org/info/rfc6395>.

Authors' Addresses

   Ashutosh Gupta
   Cisco Systems
   821 Alder Drive
   San Jose, CA  95035
   USA

   Email: ashugupt@cisco.com

   Stig Venaas
   Cisco Systems
   821 Alder Drive
   San Jose, CA  95035
   USA

   Email: stig@cisco.com

Gupta & Venaas         Expires September 14, 2017               [Page 6]