idnits 2.17.1 draft-ietf-pim-ipv4-prefix-over-ipv6-nh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC5549]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2017) is 2417 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4601' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC6395' is defined on line 178, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Gupta 3 Internet-Draft Avi Networks 4 Intended status: Experimental S. Venaas 5 Expires: March 16, 2018 Cisco Systems 6 September 12, 2017 8 PIM Encoding and Procedures for Unicast IPv4 prefixes with IPv6 next-hop 9 draft-ietf-pim-ipv4-prefix-over-ipv6-nh-00.txt 11 Abstract 13 Multi-Protocol BGP (MP-BGP) has support for distributing next-hop 14 information for multiple address families using one AFI/SAFI Network 15 Layer Reachability Information (NLRI). [RFC5549] specifies the 16 extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI 17 with a Next Hop address that belongs to the IPv6 protocol. While the 18 next-hop info is learnt via MP-BGP, certain procedures are needed to 19 enable traffic forwarding. This document describes PIM extensions 20 and the use-cases for multicast forwarding in various scenarios. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 16, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 74 5.2. Informative References . . . . . . . . . . . . . . . . . 4 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 77 1. Introduction 79 Figure 1: Example Topology 81 +-------------+ +-------------+ 82 | | | | 83 | Router1 1::1/64 1::2/64 Router2 | 84 10.1.1.1/32--+ +--------I1---------| +-+PIM receiver 85 | 1.1.1.1/24 1.1.1.2/24 | 86 | + + | 87 | | | | 88 +-------------+ +-------------+ 90 While use of MP-BGP along with [RFC5549] enables one routing protocol 91 session to exchange next-hop info for both IPv4 and IPv6 prefixes, 92 forwarding plane needs additional procedures to enable forwarding in 93 data-plane. For example, when a IPv4 prefix is learnt over IPv6 94 next-hop, forwarding plane resolves the MAC-Address (L2-Adjacency) 95 for IPv6 next-hop and uses it as destination-mac while doing inter- 96 subnet forwarding. While it's simple to find the required 97 information for unicast forwarding, multicast forwarding in same 98 scenario poses additional requirements. 100 Multicast traffic is forwarding on a tree build by multicast routing 101 protocols such as PIM. Multicast routing protocols are address 102 family dependent and hence a system enabled with IPv4 and IPv6 103 multicast routing will have two PIM sessions one for each of the AF. 104 Also, Multicast routing protocol uses Unicast reachability 105 information to find unique Reverse Path Forwarding Neighbor. Further 106 it sends control messages such as PIM Join to form the tree. Now 107 when a PIMv4 session needs to initiate new multicast tree in event of 108 discovering new receiver It consults Unicast control plane to find 109 next-hop information. While this multicast tree can be Shared or 110 Shortest Path tree, PIMv4 will need a PIMv4 neighbor to send join. 111 However, the Unicast control plane can provide IPv6 next-hop as 112 explained earlier and hence we need certain procedures to find 113 corresponding PIMv4 neighbor address. This address is vital for 114 correct prorogation of join and furthermore to build multicast tree. 115 This document describes various approaches along with their use-cases 116 and pros-cons. 118 In example topology, Router1 and Router2 are PIMv4 and PIMv6 119 neighbors on Interface I1. Router2 leanrns prefix 10.1.1.1/32's 120 next-hop as 1::164 on Interface I1 as advertised by Router1 using BGP 121 IPV6 NLRI.But in order to send (10.1.1.1/32, multicast-group) PIMv4 122 join on Interface I1, Router1 needs to find corresponding PIMv4 123 neighbor. In case there are multiple PIMv4 neighbors on same 124 Interface I1, problem is aggravated. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in BCP 14, RFC 2119 129 [RFC2119]. 131 2. Solution 133 A PIM router can advertise its locally configured IPv6 addresses on 134 the interface in PIMv4 Hello messages as per RFC4601 section 4.3.4. 135 Same applies for IPv4 address in PIMv6 Hello. PIM will keep this 136 info for each neighbor in Neighbor-cache along with DR-priority, 137 hold-time etc. Once IPv6 Next-hop is notified to PIMv4, it will look 138 into neighbors on the notified RPF-interface and find PIMv4 neighbor 139 advertising same IPv6 local address in secondary Neighbor-list. If 140 such a match is found, that particular neighbor will be uses as IPv4 141 RPF-Neighbor for initiating upstream join. 143 This method is valid for networks enabled with PIMv4 and PIMv6 both 144 as well for the networks enabled with only PIMv4 with IPv6 BGP 145 session or PIMv6 with IPv4 BGP session. This method does't required 146 any additional config changes in the network. 148 3. Security Considerations 150 There are no new security considerations. 152 4. IANA Considerations 154 There are no IANA considerations. 156 5. References 158 5.1. Normative References 160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, 162 DOI 10.17487/RFC2119, March 1997, 163 . 165 5.2. Informative References 167 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 168 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 169 Protocol Specification (Revised)", RFC 4601, 170 DOI 10.17487/RFC4601, August 2006, 171 . 173 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 174 Layer Reachability Information with an IPv6 Next Hop", 175 RFC 5549, DOI 10.17487/RFC5549, May 2009, 176 . 178 [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) 179 Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395, 180 October 2011, . 182 Authors' Addresses 183 Ashutosh Gupta 184 Avi Networks 185 5155 Old Ironsides Dr. Suite 100 186 Santa Clara, CA 95054 187 USA 189 Email: ashutosh@avinetworks.com 191 Stig Venaas 192 Cisco Systems 193 821 Alder Drive 194 San Jose, CA 95035 195 USA 197 Email: stig@cisco.com