idnits 2.17.00 (12 Aug 2021) /tmp/idnits14166/draft-mishra-bess-ipv6-only-pe-design-all-safi-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-bess-ipv6-only-pe-design]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This document details an important External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv6-Only PE Design, IPv4 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv6-Only peer is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv6 address need only be configured on the PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding. This document defines the IPv6-Only PE Design as a new PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard which is described in the POC testing document [I-D.ietf-bess-ipv6-only-pe-design] which is now extended to support to all AFI/SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-B, Option-AB and Option-C are still applicable and thus this extension of IPv6-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This document defines the IPv6-Only PE Design Architecture details for External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv6-Only PE Design, IPv4 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv6-Only peer MUST be configured for both IPv4 and IPv6 routing updates, and from a data plane forwarindg perspective only an IPv6 address MUST be configured on the PE-CE Edge or ASBR-ASBR, PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding for all AFI/SAFI. This document defines the IPv6-Only PE Design as a new Intra-AS PE-CE Edge and Inter-AS PE-PE BGP peering Standard which is described in the POC testing document in detail, [I-D.ietf-bess-ipv6-only-pe-design] which is now extended for applicability to to all AFI/SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-AB and Option-C are still applicable and thus this extension of IPv6-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well as well as any other applicable AFI/SAFI is now as well relevant. -- The document date (20 March 2022) is 55 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4291' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 1067, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-bess-ipv6-only-pe-design-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.nalawade-kapoor-tunnel-safi' ** Downref: Normative reference to an Experimental RFC: RFC 5747 ** Downref: Normative reference to an Historic RFC: RFC 6037 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group G. Mishra 3 Internet-Draft Verizon Inc. 4 Intended status: Standards Track M. Mishra 5 Expires: 21 September 2022 Cisco Systems 6 J. Tantsura 7 Microsoft, Inc. 8 S. Madhavi 9 Juniper Networks, Inc. 10 Q. Yang 11 Arista Networks 12 A. Simpson 13 Nokia 14 S. Chen 15 Huawei Technologies 16 20 March 2022 18 IPv6-Only PE Design All SAFI 19 draft-mishra-bess-ipv6-only-pe-design-all-safi-01 21 Abstract 23 As Enterprises and Service Providers upgrade their brown field or 24 green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- 25 BGP)now plays an important role in the transition of their Provider 26 (P) core network as well as Provider Edge (PE) Inter-AS peering 27 network from IPv4 to IPv6. Operators must be able to continue to 28 support IPv4 customers when both the Core and Edge networks are 29 IPv6-Only. 31 This document details an important External BGP (eBGP) PE-PE Inter-AS 32 IPv6-Only peering design that leverages the MP-BGP capability 33 exchange by using IPv6 peering as pure transport, allowing all and 34 any IPv4 Network Layer Reachability Information (NLRI) and IPv6 35 Network Layer Reachability Information (NLRI)to be carried over the 36 same (Border Gateway Protocol) BGP TCP session for all Address Family 37 Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). 38 The design change provides the same Dual Stacking functionality that 39 exists today with separate IPv4 and IPv6 BGP sessions as we have 40 today. With this IPv6-Only PE Design, IPv4 address MUST not be 41 configured on the the Provider Edge (PE) - Customer Edge (CE), or 42 Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous 43 System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge 44 (PE). From a control plane perspective a single IPv6-Only peer is 45 required for both IPv4 and IPv6 routing updates and from a data plane 46 forwarindg perspective an IPv6 address need only be configured on the 47 PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet 48 forwarding. This document defines the IPv6-Only PE Design as a new 49 PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard which is 50 described in the POC testing document 51 [I-D.ietf-bess-ipv6-only-pe-design] which is now extended to support 52 to all AFI/SAFI ubiquitously. As service providers migrate to 53 Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as 54 well, and thus Inter-AS options Option-A, Option-B, Option-AB and 55 Option-C are still applicable and thus this extension of IPv6-Only 56 peering architecure extension to Inter-AS peering is very relevant to 57 Segment Routing as well. 59 Status of This Memo 61 This Internet-Draft is submitted in full conformance with the 62 provisions of BCP 78 and BCP 79. 64 Internet-Drafts are working documents of the Internet Engineering 65 Task Force (IETF). Note that other groups may also distribute 66 working documents as Internet-Drafts. The list of current Internet- 67 Drafts is at https://datatracker.ietf.org/drafts/current/. 69 Internet-Drafts are draft documents valid for a maximum of six months 70 and may be updated, replaced, or obsoleted by other documents at any 71 time. It is inappropriate to use Internet-Drafts as reference 72 material or to cite them other than as "work in progress." 74 This Internet-Draft will expire on 21 September 2022. 76 Copyright Notice 78 Copyright (c) 2022 IETF Trust and the persons identified as the 79 document authors. All rights reserved. 81 This document is subject to BCP 78 and the IETF Trust's Legal 82 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 83 license-info) in effect on the date of publication of this document. 84 Please review these documents carefully, as they describe your rights 85 and restrictions with respect to this document. Code Components 86 extracted from this document must include Revised BSD License text as 87 described in Section 4.e of the Trust Legal Provisions and are 88 provided without warranty as described in the Revised BSD License. 90 Table of Contents 92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 93 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 94 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 95 4. IPv6-Only PE-CE Design ALL SAFI Solution . . . . . . . . . . 7 96 5. IPv6-Only Edge Peering Design ALL SAFI . . . . . . . . . . . 8 97 5.1. IPv6-Only Edge Peering Packet Walk ALL SAFI . . . . . . . 8 98 5.2. IPv6-Only PE Design ALL SAFI 6to4 Softwire IPv4-Only Core 99 packet walk . . . . . . . . . . . . . . . . . . . . . . . 9 100 5.3. IPv6-Only PE Design ALL SAFI 4to6 Softwire IPv6-Only Core 101 packet walk . . . . . . . . . . . . . . . . . . . . . . . 11 102 6. IPv6-Only PE Design ALL SAFI RFC8950 Applicability . . . . . 13 103 6.1. IPv6-Only Edge Peering design next-hop encoding . . . . . 13 104 6.2. RFC8950 updates to RFC5549 applicability . . . . . . . . 13 105 7. IPv6-Only PE Design Edge E2E Design for ALL AFI/SAFI . . . . 14 106 7.1. IPv6-Only PE Design All SAFI Case-1 E2E IPv6-Only PE-CE, 107 Global Table over IPv4-Only Core(6PE), 6to4 softwire . . 14 108 7.2. IPv6-Only PE Design All SAFI Case-2 E2E IPv6-Only PE-CE, 109 VPN over IPv4-Only Core, 6to4 Softwire . . . . . . . . . 15 110 7.3. IPv6-Only PE Design All SAFI Case-3 E2E IPv6-Only PE-CE, 111 Global Table over IPv6-Only Core (4PE), 4to6 Softwire . 15 112 7.4. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, 113 VPN over IPv6-Only Core, 4to6 Softwire . . . . . . . . . 16 114 7.5. IPv6-Only PE Design All SAFI Case-5 E2E IPv6-Only PE-CE, 115 Global Table over IPv4-Only Core(6PE), 6to4 softwire 116 -Inter-AS Option-B . . . . . . . . . . . . . . . . . . . 16 117 7.6. IPv6-Only PE Design All SAFI Case-6 E2E IPv6-Only PE-CE, 118 Global Table over IPv4-Only Core(6PE), 6to4 softwire 119 -Inter-AS Option-C . . . . . . . . . . . . . . . . . . . 17 120 7.7. IPv6-Only PE Design All SAFI Case-7 E2E IPv6-Only PE-CE, 121 VPN over IPv4-Only, 6to4 softwire -Inter-AS Option-B . . 17 122 7.8. IPv6-Only PE Design All SAFI Case-8 E2E IPv6-Only PE-CE, 123 VPN over IPv4-Only Core, 6to4 softwire -Inter-AS 124 Option-C . . . . . . . . . . . . . . . . . . . . . . . . 18 125 7.9. IPv6-Only PE Design All SAFI Case-9 E2E IPv6-Only PE-CE, 126 Global Table over IPv6-Only Core, 4to6 softwire -Inter-AS 127 Option-B . . . . . . . . . . . . . . . . . . . . . . . . 18 128 7.10. IPv6-Only PE Design All SAFI Case-10 E2E IPv6-Only PE-CE, 129 Global Table over IPv6-Only Core, 4to6 softwire -Inter-AS 130 Option-C . . . . . . . . . . . . . . . . . . . . . . . . 19 131 7.11. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, 132 VPN over IPv6-Only Core, 4to6 softwire -Inter-AS 133 Option-B . . . . . . . . . . . . . . . . . . . . . . . . 19 134 7.12. IPv6-Only PE Design All SAFI Case-12 E2E IPv6-Only PE-CE, 135 VPN over IPv6-Only Core, 4to6 softwire -Inter-AS 136 Option-C . . . . . . . . . . . . . . . . . . . . . . . . 20 137 8. IPv6-Only PE Design ALL AFI/SFI Operational Considerations . 20 138 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 139 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 140 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 141 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 143 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 144 13.2. Informative References . . . . . . . . . . . . . . . . . 24 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 148 1. Introduction 150 As Enterprises and Service Providers upgrade their brown field or 151 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 152 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important 153 role in the transition of the Provider (P) core networks and Provider 154 Edge (PE) edge networks from IPv4 to IPv6. Operators have a 155 requirement to support IPv4 customers and must be able to support 156 IPv4 address family and Sub-Address-Family Virtual Private Network 157 (VPN)-IPv4, and Multicast VPN IPv4 customers. 159 IXP are also facing IPv4 address depletion at their peering points, 160 which are large Layer 2 transit backbones that service providers peer 161 and exchange IPv4 and IPv6 Network Layer Reachability Information 162 (NLRI). Today, these transit exchange points are Dual Stacked. With 163 this IPv6-only BGP peering design, only IPv6 MUST be configured on 164 the PE-PE inter-as peering interface, the Inter-AS Provider Edge (PE) 165 - Provider Edge (PE), the IPv6 BGP peer is now used to carry IPv4 166 (Network Layer Reachability Information) NLRI over an IPv6 next hop 167 using IPv6 next hop encoding defined in [RFC8950], while continuing 168 to forward both IPv4 and IPv6 packets. With this IPv6-Only PE 169 Design, ASBRs providing Inter-AS options peering PE to PE extending 170 L3 VPN services is now no longer Dual Stacked and as well can support 171 ALL AFI/SAFI. 173 MP-BGP specifies that the set of usable next-hop address families is 174 determined by the Address Family Identifier (AFI) and the Subsequent 175 Address Family Identifier (SAFI). Historically the AFI/SAFI 176 definitions for the IPv4 address family only have provisions for 177 advertising a Next Hop address that belongs to the IPv4 protocol when 178 advertising IPv4 or VPN-IPv4. [RFC8950] specifies the extensions 179 necessary to allow advertising IPv4 NLRI, Virtual Private Network 180 Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN- 181 IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. 182 This comprises of an extended next hop encoding MP-REACH BGP 183 capability exchange to allow the address of the Next Hop for IPv4 184 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 185 Protocol. [RFC8950] defines the encoding of the Next Hop to 186 determine which of the protocols the address actually belongs to, and 187 a new BGP Capability allowing MP-BGP Peers to discover dynamically 188 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 189 Next Hop. 191 The current specification for carrying IPv4 NLRI of a given address 192 family via a Next Hop of a different address family is now defined in 193 [RFC8950], and specifies the extended next hop encoding MP-REACH 194 capability extension necessary to do so. This comprises an extension 195 of the AFI/SAFI definitions to allow the address of the Next Hop for 196 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 197 protocol, the encoding of the Next Hop information to determine which 198 of the protocols the address belongs to, and a new BGP Capability 199 allowing MP-BGP peers to dynamically discover whether they can 200 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 202 With the new extensions defined in [RFC8950] supporting NLRI and next 203 hop address family mismatch, the BGP peer session can now be treated 204 as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the 205 Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP 206 session. This allows for the elimination of dual stack from the PE- 207 PE Inter-AS peering point, and now enable the Inter-AS peering to be 208 IPv6-ONLY. The elimination of IPv4 Inter Provider ASBR tie point, 209 PE-PE Inter-AS peering points translates into OPEX expenditure 210 savings of point-to-point infrastructure links as well as /31 address 211 space savings and administration and network management of both IPv4 212 and IPv6 BGP peers. This reduction decreases the number of PE-PE 213 Inter-AS options BGP peers by fifty percent, which is a tremendous 214 cost savings for operators. 216 While the savings exists at the Edge eBGP PE-PE Inter-AS peering, on 217 the core side PE to Route Reflector (RR) peering carrying 218 IPv4 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no 219 savings as the Provider (P) Core is IPv6 Only and thus can only have 220 an IPv6 peer and must use [RFC8950] extended next hop encoding to 221 carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicast VPN 222 <2/129> over an IPv6 next hop. 224 This document defines the IPv6-Only PE Design Architecture details 225 for External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that 226 leverages the MP-BGP capability exchange by using IPv6 peering as 227 pure transport, allowing all and any IPv4 Network Layer Reachability 228 Information (NLRI) and IPv6 Network Layer Reachability Information 229 (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP 230 session for all Address Family Identifiers (AFI) and Subsequent 231 Address Family Identifiers(SAFI). The design change provides the 232 same Dual Stacking functionality that exists today with separate IPv4 233 and IPv6 BGP sessions as we have today. With this IPv6-Only PE 234 Design, IPv4 address MUST not be configured on the the Provider Edge 235 (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System 236 Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE 237 Provider Edge (PE) - Provider Edge (PE). From a control plane 238 perspective a single IPv6-Only peer MUST be configured for both IPv4 239 and IPv6 routing updates, and from a data plane forwarindg 240 perspective only an IPv6 address MUST be configured on the PE-CE Edge 241 or ASBR-ASBR, PE to PE Inter-AS peering interface for both IPv4 and 242 IPv6 packet forwarding for all AFI/SAFI. This document defines the 243 IPv6-Only PE Design as a new Intra-AS PE-CE Edge and Inter-AS PE-PE 244 BGP peering Standard which is described in the POC testing document 245 in detail, [I-D.ietf-bess-ipv6-only-pe-design] which is now extended 246 for applicability to to all AFI/SAFI ubiquitously. As service 247 providers migrate to Segment Routing architecture SR-MPLS and SRv6, 248 VPN overlay exsits as well, and thus Inter-AS options Option-A, 249 Option-AB and Option-C are still applicable and thus this extension 250 of IPv6-Only peering architecure extension to Inter-AS peering is 251 very relevant to Segment Routing as well as well as any other 252 applicable AFI/SAFI is now as well relevant. 254 This IPv6-Only PE ALL SAFI Design details an important External BGP 255 (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP- 256 BGP capability exchange by using IPv6 peering as pure transport, 257 allowing all and any IPv4 Network Layer Reachability Information 258 (NLRI) and IPv6 Network Layer Reachability Information (NLRI) to be 259 carried over the same (Border Gateway Protocol) BGP TCP session for 260 all remaining Address Family Identifiers (AFI) and Subsequent Address 261 Family Identifiers(SAFI) below as well that can be carried over 262 IPv6-Only Inter-AS peerings: MCAST-VPN [RFC6514] <1/5>, 263 NLRI Multi-Segment Pseudowires [RFC7267] <1/6>, BGP Tunnel 264 Encapsulation SAFI [RFC9012] <1/7>, MCAST-VPLS [RFC7117] <1/8>, BGP 265 SFC [RFC9015] <1/9>, Tunnel SAFI [I-D.nalawade-kapoor-tunnel-safi] 266 <1/6>, Virtual Private LAN Service (VPLS) [RFC4761] and [RFC6074] 267 <1/5>, BGP MDT SAFI [RFC6037] <1/66>, BGP 4to6 SAFI [RFC5747] <1/67>, 268 BGP 6to4 SAFI draft xx <1/8>, Layer 1 VPN Auto-Discovery [RFC5195] 269 <1/69>, BGP EVPNs [RFC7432] <1/70>, BGP-LS (VPLS) [RFC7752] <1/71>, 270 BGP-LS-EVPN [RFC7752] <72/>, SR-TE Policy SAFI draftxx <1/73>, BGP 271 6to4 SAFI draft xx <1/8>, SDN WAN Capabilities draftxx <1/74>, 272 Routing Policy SAFI draftxx <1/75>, Classful-Transport SAFI draftxx 273 <1/76>, Tunneled Traffic FlowSpec draftxx <1/77>, MCAST-TREE SAFI 274 draft xx <1/78>, Route Target Constraints [RFC4684] <1/132>, 275 Dissemination of Flow Specification Rules [RFC8955] <1/133>, L3 VPN 276 Dissemination of Flow Specification Rules [RFC8955] <1/1344>, VPN 277 Auto-Discovery SAFI draftxx <1/140> 279 2. Requirements Language 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 283 "OPTIONAL" in this document are to be interpreted as described in BCP 284 14 [RFC2119] [RFC8174] when, and only when, they appear in all 285 capitals, as shown here. 287 3. Terminology 289 Terminolgoy used in defining the IPv6-Only Edge specification. 291 AFBR: Address Family Border Router Provider Edge (PE). 293 Edge: PE-CE Edge Network Provider Edge - Customer Edge 295 Core: P Core Network Provider (P) 297 4to6 Softwire : IPv4 edge over an IPv6-Only core 299 6to4 Softwire: IPv6 edge over an IPv4-Only core 301 E2E: End to End 303 4. IPv6-Only PE-CE Design ALL SAFI Solution 305 The IPv6-Only Edge design solution applies to any and all IPv4 306 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 307 Reachability Information (NLRI) over an IPv6-Only BGP Peering 308 session. 310 IPv6-Only PE Design ALL SAFI can be broken up into the following 311 design scenario's below: 313 Edge Customer NLRI IPv4 or IPV6 related AFI/SAFI (PE-CE): 1/1 2/1 314 (Unicast), 1/2 2/2 (Multicast) 316 Inter-AS Customer NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR): 1/1 317 2/1 (Unicast), 1/2 2/2 (Multicast), 1/128 2/128 (VPN), 1/129 2/129 318 (MVPN), 1/4 2/4 BGP-LU (6PE/4PE), 1/140 2/140 (BGP VPN Auto 319 Discovery) 321 Inter-AS Multicast NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR): 322 1/5 2/5 (MCAST-VPN) , 1/8 2/8 (MCAST-VPLS), 1/66 2/66 (BGP MDT-SAFI), 323 1/78 2/78 (MCAST-TREE) 325 PE to Controller NLRI IPv4 or IPV6 related AFI/SAFI 1/71 2/71 (BGP- 326 LS), 1/72 2/72 (BGP-LS VPN), 1/75 2/75 (Routing Policy SAFI), 1/80 327 2/80 BGP-LS-SPF 329 Inter-AS L1 VPN, L2 VPN NLRI IPv4 or IPV6 related AFI/SAFI (ASBR- 330 ASBR) 1/65 2/65 (VPLS), 1/70 2/70 (BGP EVPN), 1/69 2/69 (L1 VPN) 332 Inter-AS BGP FlowSpec, Optimizations and SFC NLRI IPv4 or IPV6 333 related AFI/SAFI (ASBR-ASBR) 1/132 2/132 (RTC), 1/133 2/133 (BGP 334 FlowSpec), 1/134 2/134 (VPN BGP FlowSpec), 1/9 2/9 (BGP SFC) 335 Inter-AS BGP Policy - SR-TE Policy, SD-WAN Policy NLRI IPv4 or IPV6 336 related AFI/SAFI (ASBR-ASBR) 1/73 2/73 (SR-TE), 1/74 2/74 (SD-WAN 337 Capabilities) 339 Solution applicable to all AFI/SAFI 340 AFI/SAFI 1/X 2/X Where X = ALL SAFI 342 +-------+ +-------+ 343 | AS1 | IPv6 Only | AS2 | 344 | PE1 |----------------| PE2 | 345 | (ASBR)| IPv6 BGP Peer |(ASBR) | 346 +-------+ +-------+ 347 IPv4 forwarding IPv4 forwarding 348 IPv6 forwarding IPv6 forwarding 350 Figure 1: IPv6-Only Solution Applicability to ALL AFI/SAFI 352 5. IPv6-Only Edge Peering Design ALL SAFI 354 5.1. IPv6-Only Edge Peering Packet Walk ALL SAFI 356 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 357 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 358 mesh framework concept is based on the overlay and underlay MPLS or 359 SR based technology framework, where the underlay is the transport 360 layer and the overlay is a Virtual Private Network (VPN) layer, and 361 is the the tunneled virtualization layer containing the customer 362 payload. The concept of a 6to4 Softwire is based on transmission of 363 IPv6 packets at the edge of the network by tunneling the IPv6 packets 364 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 365 on transmission of IPv4 packets at the edge of the network by 366 tunneling the IPv4 packets over an IPv6-Only Core. 368 This document describes End to End (E2E) test scenarios that follow a 369 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 370 egress PE-CE tracing the routing protocol control plane and data 371 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 372 within the IPv4-Only or IPv6-Only Core network. In both secneario we 373 are focusing on IPv4 packets and the control plane and data plane 374 forwarding aspects of IPv4 packets from the PE-CE Edge network over 375 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 376 network. With this IPv6-Only Edge peering design, the Softwire Mesh 377 Framework is not extended beyond the Provider Edge (PE) and continues 378 to terminate on the PE router. 380 5.2. IPv6-Only PE Design ALL SAFI 6to4 Softwire IPv4-Only Core packet 381 walk 383 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 384 network Edge traverse a IPv4-Only Core 386 In the scenario where IPv4 packets originating from a PE-CE edge are 387 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 388 the PE and CE only have an IPv6 address configured on the interface. 389 In this scenario the IPv4 packets that ingress the CE from within the 390 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 391 NLRI destination prefix learned from the Pure Transport Single IPv6 392 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 393 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 394 the PE-CE interface is the only interface that is IPv6-Only and all 395 other interfaces may or may not be IPv6-Only. Following the data 396 plane packet flow, IPv4 packets are forwarded from the ingress CE to 397 the IPv6-Only ingress PE where the VPN label imposition push per 398 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 399 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 400 label disposition pop occurs and the native IPv4 packet is forwarded 401 to the egress CE. In the reverse direction IPv4 packets are 402 forwarded from the egress CE to egress PE where the VPN label 403 imposition per prefix, per-vrf, per-CE push occurs and the labeled 404 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 405 the ingress PE where the VPN label disposition pop occurs and the 406 native IPv4 packet is forwarded to the ingress CE. . The 407 functionality of the IPv4 forwarding plane in this scenario is 408 identical from a data plane forwarding perspective to Dual Stack IPv4 409 forwarding scenario. 411 +--------+ +--------+ 412 | IPv4 | | IPv4 | 413 | Client | | Client | 414 | Network| | Network| 415 +--------+ +--------+ 416 | \ / | 417 | \ / | 418 | \ / | 419 | X | 420 | / \ | 421 | / \ | 422 | / \ | 423 +--------+ +--------+ 424 | AFBR | | AFBR | 425 +--| IPv4/6 |---| IPv4/6 |--+ 426 | +--------+ +--------+ | 427 +--------+ | | +--------+ 428 | IPv4 | | | | IPv4 | 429 | Client | | | | Client | 430 | Network|------| IPv4 |-------| Network| 431 +--------+ | only | +--------+ 432 | | 433 | +--------+ +--------+ | 434 +--| AFBR |---| AFBR |--+ 435 | IPv4/6 | | IPv4/6 | 436 +--------+ +--------+ 437 | \ / | 438 | \ / | 439 | \ / | 440 | X | 441 | / \ | 442 | / \ | 443 | / \ | 444 +--------+ +--------+ 445 | IPv6 | | IPv4 | 446 | Client | | Client | 447 | Network| | Network| 448 +--------+ +--------+ 450 Figure 2: IPv6-Only PE Design ALL SAFI 6to4 Softwire - IPv6 Edge 451 over an IPv4-Only Core 453 5.3. IPv6-Only PE Design ALL SAFI 4to6 Softwire IPv6-Only Core packet 454 walk 456 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 457 network Edge traverse a IPv6-Only Core 459 In the scenario where IPv4 packets originating from a PE-CE edge are 460 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 461 the PE and CE only have an IPv6 address configured on the interface. 462 In this scenario the IPv4 packets that ingress the CE from within the 463 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 464 NLRI destination prefix learned from the Pure Transport Single IPv6 465 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 466 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 467 the PE-CE interface is the only interface that is IPv6-Only and all 468 other interfaces may or may not be IPv6-Only. Following the data 469 plane packet flow, IPv4 packets are forwarded from the ingress CE to 470 the IPv6-Only ingress PE where the VPN label imposition push per 471 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 472 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 473 label disposition pop occurs and the native IPv4 packet is forwarded 474 to the egress CE. In the reverse direction IPv4 packets are 475 forwarded from the egress CE to egress PE where the VPN label 476 imposition per prefix, per-vrf, per-CE push occurs and the labeled 477 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 478 the ingress PE where the VPN label disposition pop occurs and the 479 native IPv4 packet is forwarded to the ingress CE. . The 480 functionality of the IPv4 forwarding plane in this scenario is 481 identical from a data plane forwarding perspective to Dual Stack IPv4 482 forwarding scenario. 484 +--------+ +--------+ 485 | IPv4 | | IPv4 | 486 | Client | | Client | 487 | Network| | Network| 488 +--------+ +--------+ 489 | \ / | 490 | \ / | 491 | \ / | 492 | X | 493 | / \ | 494 | / \ | 495 | / \ | 496 +--------+ +--------+ 497 | AFBR | | AFBR | 498 +--| IPv4/6 |---| IPv4/6 |--+ 499 | +--------+ +--------+ | 500 +--------+ | | +--------+ 501 | IPv6 | | | | IPv6 | 502 | Client | | | | Client | 503 | Network|------| IPv6 |-------| Network| 504 +--------+ | only | +--------+ 505 | | 506 | +--------+ +--------+ | 507 +--| AFBR |---| AFBR |--+ 508 | IPv4/6 | | IPv4/6 | 509 +--------+ +--------+ 510 | \ / | 511 | \ / | 512 | \ / | 513 | X | 514 | / \ | 515 | / \ | 516 | / \ | 517 +--------+ +--------+ 518 | IPv4 | | IPv4 | 519 | Client | | Client | 520 | Network| | Network| 521 +--------+ +--------+ 523 Figure 3: IPv6-Only PE Design ALL SAFI 4to6 Softwire - IPv4 Edge 524 over an IPv6-Only Core 526 6. IPv6-Only PE Design ALL SAFI RFC8950 Applicability 528 6.1. IPv6-Only Edge Peering design next-hop encoding 530 This section describes [RFC8950] next hop encoding updates to 531 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 532 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 533 an IPv6 next hop BGP capability extended hop encoding IANA capability 534 codepoint value 5 defined is applicable to both [RFC5549] and 535 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 536 in the RFC updates. 538 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 539 part of the IPv6-Only design vendor interoperaiblity test cases and 540 in that respect is applicable as [RFC8950] updates [RFC5549] for 541 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 543 6.2. RFC8950 updates to RFC5549 applicability 545 This section describes the [RFC8950] next hop encoding updates to 546 [RFC5549] 548 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 549 encoded as an IPv6 address with a length of 16 or 32 bytes. This 550 document modifies how the next-hop address is encoded to accommodate 551 all existing implementations and bring consistency with VPNv4oIPv4 552 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 553 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 554 6.2 of this document). This change addresses Erratum ID 5253 555 (Err5253). As all known and deployed implementations are 556 interoperable today and use the new proposed encoding, the change 557 does not break existing interoperability. Updates to [RFC8950] is 558 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 559 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 560 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 561 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 563 comes into play which is discussed in section 8.9. 565 [RFC5549] next hop encoding of MP_REACH_NLRI with: 567 * NLRI= NLRI as per current AFI/SAFI definition 569 Advertising with [RFC4760] MP_REACH_NLRI with: 571 * AFI = 1 573 * SAFI = 128 or 129 574 * Length of Next Hop Address = 16 or 32 576 * NLRI= NLRI as per current AFI/SAFI definition 578 [RFC8950] next hop encoding of MP_REACH_NLRI with: 580 * NLRI= NLRI as per current AFI/SAFI definition 582 Advertising with [RFC4760] MP_REACH_NLRI with: 584 * AFI = 1 586 * SAFI = 128 or 129 588 * Length of Next Hop Address = 24 or 48 590 * Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 591 set to zero (potentially followed by the link-local VPN-IPv6 592 address of the next hop with an 8-octet RD is set to zero). 594 * NLRI= NLRI as per current AFI/SAFI definition 596 7. IPv6-Only PE Design Edge E2E Design for ALL AFI/SAFI 598 Listed below are the following IPv6-Only PE Design ALL SAFI design 599 scenario's: 601 IPv4 Unicast <1/1>, IPv6 Unicast <2/1>, VPN-IPV4 <1/128>, 602 VPN-IPV6 <2/128>, Multicasat VPN <1/129>, Multicasat VPN <2/129>,BGP- 603 LU IPV4 (GRT) <1/4> 605 7.1. IPv6-Only PE Design All SAFI Case-1 E2E IPv6-Only PE-CE, Global 606 Table over IPv4-Only Core(6PE), 6to4 softwire 607 ________ 608 IPv6-Only _____ / \ IPv6-Only 609 PE / CE / \__/ \___ PE / CE 610 +----+ +----+ / \ +------+ +-----+ 611 | | | | | |_ | | | | 612 | | | | | \ | | | | 613 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 614 | | | | \0=========Underlay =======0| | | | | 615 +----+ +----+ \ __/ +------+ +-----+ 616 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 617 IPv4 forwarding \__ __ / IPv4 forwarding 618 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 620 Figure 4: Design Solution-1 E2E IPv6-Only PE-CE, Global 621 Table over IPv4-Only Core (6PE) 623 7.2. IPv6-Only PE Design All SAFI Case-2 E2E IPv6-Only PE-CE, VPN over 624 IPv4-Only Core, 6to4 Softwire 626 ________ 627 IPv6-Only _____ / \ IPv6-Only 628 PE / CE / \__/ \___ PE / CE 629 +----+ +----+ / \ +------+ +-----+ 630 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 631 | | | | | \ | | | | 632 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 633 | | | | \0=========Underlay =======0| | | | | 634 +----+ +----+ \ __/ +------+ +-----+ 635 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 636 IPv4 forwarding \__ __ / IPv4 forwarding 637 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 639 Figure 5: Design Solution-2 E2E IPv6-Only PE-CE, VPN over 640 IPv4-Only Core 642 7.3. IPv6-Only PE Design All SAFI Case-3 E2E IPv6-Only PE-CE, Global 643 Table over IPv6-Only Core (4PE), 4to6 Softwire 644 ________ 645 IPv6-Only _____ / \ IPv6-Only 646 PE / CE / \__/ \___ PE / CE 647 +----+ +----+ / \ +------+ +-----+ 648 | | | | | |_ | | | | 649 | | | | | \ | | | | 650 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 651 | | | | \0=========Underlay =======0| | | | | 652 +----+ +----+ \ __/ +------+ +-----+ 653 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 654 IPv4 forwarding \__ __ / IPv4 forwarding 655 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 657 Figure 6: Design Solution-3 E2E IPv6-Only PE-CE, Global 658 Table over IPv6-Only Core (4PE) 660 7.4. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, VPN over 661 IPv6-Only Core, 4to6 Softwire 663 ________ 664 IPv6-Only _____ / \ IPv6-Only 665 PE / CE / \__/ \___ PE / CE 666 +----+ +----+ / \ +------+ +-----+ 667 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 668 | | | | | \ | | | | 669 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 670 | | | | \0=========Underlay =======0| | | | | 671 +----+ +----+ \ __/ +------+ +-----+ 672 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 673 IPv4 forwarding \__ __ / IPv4 forwarding 674 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 676 Figure 7: Design Solution-4 E2E IPv6-Only PE-CE, VPN over 677 IPv6-Only Core 679 7.5. IPv6-Only PE Design All SAFI Case-5 E2E IPv6-Only PE-CE, Global 680 Table over IPv4-Only Core(6PE), 6to4 softwire -Inter-AS Option-B 681 Inter-AS ASBR-ASBR link is IPv6-Only PE 682 IPv6-Only __________ __________ IPv6-Only 683 PE / CE / \ / \ PE / CE 684 +--+ +----+ / \ / \ +--+ +--+ 685 | | | | | AS 1 \ | AS 2 \ | | | | 686 | | | | | \IPv6| \ | | | | 687 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 688 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 689 +--+ +----+ \ / \ / +--+ +--+ 690 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 691 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 692 IPv6 forwarding IPv6 forwarding 694 Figure 8: Design Solution-5 E2E IPv6-Only PE-CE, Global 695 Table over IPv4-Only Core (6PE) - Inter-AS Option-B 697 7.6. IPv6-Only PE Design All SAFI Case-6 E2E IPv6-Only PE-CE, Global 698 Table over IPv4-Only Core(6PE), 6to4 softwire -Inter-AS Option-C 700 Inter-AS ASBR-ASBR link is IPv6-Only PE 701 IPv6-Only __________ __________ IPv6-Only 702 PE / CE / \ / \ PE / CE 703 +--+ +----+ / \ / \ +--+ +--+ 704 | | | | | AS 1 \ | AS 2 \ | | | | 705 | | | | | \IPv6| \ | | | | 706 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 707 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 708 +--+ +----+ \ / \ / +--+ +--+ 709 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 710 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 711 IPv6 forwarding IPv6 forwarding 713 Figure 9: Design Solution-6 E2E IPv6-Only PE-CE, Global 714 Table over IPv4-Only Core (6PE) - Inter-AS Option-C 716 7.7. IPv6-Only PE Design All SAFI Case-7 E2E IPv6-Only PE-CE, VPN over 717 IPv4-Only, 6to4 softwire -Inter-AS Option-B 718 Inter-AS ASBR-ASBR link is IPv6-Only PE 719 IPv6-Only __________ __________ IPv6-Only 720 PE / CE / \ / \ PE / CE 721 +--+ +----+ / \ / \ +--+ +--+ 722 | | | | | AS 1 \ | AS 2 \ | | | | 723 | | | | | \IPv6| \ | | | | 724 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 725 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 726 +--+ +----+ \ / \ / +--+ +--+ 727 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 728 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 729 IPv6 forwarding IPv6 forwarding 731 Figure 10: Design Solution-7 E2E IPv6-Only PE-CE, VPN over 732 IPv4-Only Core - Inter-AS Option-B 734 7.8. IPv6-Only PE Design All SAFI Case-8 E2E IPv6-Only PE-CE, VPN over 735 IPv4-Only Core, 6to4 softwire -Inter-AS Option-C 737 Inter-AS ASBR-ASBR link is IPv6-Only PE 738 IPv6-Only __________ __________ IPv6-Only 739 PE / CE / \ / \ PE / CE 740 +--+ +----+ / \ / \ +--+ +--+ 741 | | | | | AS 1 \ | AS 2 \ | | | | 742 | | | | | \IPv6| \ | | | | 743 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 744 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 745 +--+ +----+ \ / \ / +--+ +--+ 746 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 747 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 748 IPv6 forwarding IPv6 forwarding 750 Figure 11: Design Solution-8 E2E IPv6-Only PE-CE, VPN over 751 IPv4-Only Core - Inter-AS Option-C 753 7.9. IPv6-Only PE Design All SAFI Case-9 E2E IPv6-Only PE-CE, Global 754 Table over IPv6-Only Core, 4to6 softwire -Inter-AS Option-B 755 Inter-AS ASBR-ASBR link is IPv6-Only PE 756 IPv6-Only __________ __________ IPv6-Only 757 PE / CE / \ / \ PE / CE 758 +--+ +----+ / \ / \ +--+ +--+ 759 | | | | | AS 1 \ | AS 2 \ | | | | 760 | | | | | \IPv6| \ | | | | 761 |CE|-| PE |--| IPv6-Only Core|----|IPv6-Only Core|--|PE|-|CE| 762 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 763 +--+ +----+ \ / \ / +--+ +--+ 764 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 765 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 766 IPv6 forwarding IPv6 forwarding 768 Figure 12: Design Solution-9 E2E IPv6-Only PE-CE, Global 769 Table over IPv6-Only Core - Inter-AS Option-B 771 7.10. IPv6-Only PE Design All SAFI Case-10 E2E IPv6-Only PE-CE, Global 772 Table over IPv6-Only Core, 4to6 softwire -Inter-AS Option-C 774 Inter-AS ASBR-ASBR link is IPv6-Only PE 775 IPv6-Only __________ __________ IPv6-Only 776 PE / CE / \ / \ PE / CE 777 +--+ +----+ / \ / \ +--+ +--+ 778 | | | | | AS 1 \ | AS 2 \ | | | | 779 | | | | | \IPv6| \ | | | | 780 |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| 781 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 782 +--+ +----+ \ / \ / +--+ +--+ 783 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 784 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 785 IPv6 forwarding IPv6 forwarding 787 Figure 13: Design Solution-10 E2E IPv6-Only PE-CE, Global 788 Table over IPv6-Only Core - Inter-AS Option-C 790 7.11. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, VPN over 791 IPv6-Only Core, 4to6 softwire -Inter-AS Option-B 792 Inter-AS ASBR-ASBR link is IPv6-Only PE 793 IPv6-Only __________ __________ IPv6-Only 794 PE / CE / \ / \ PE / CE 795 +--+ +----+ / \ / \ +--+ +--+ 796 | | | | | AS 1 \ | AS 2 \ | | | | 797 | | | | | \IPv6| \ | | | | 798 |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| 799 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 800 +--+ +----+ \ / \ / +--+ +--+ 801 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 802 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 803 IPv6 forwarding IPv6 forwarding 805 Figure 14: Design Solution-11 E2E IPv6-Only PE-CE, VPN over 806 IPv6-Only Core - Inter-AS Option-B 808 7.12. IPv6-Only PE Design All SAFI Case-12 E2E IPv6-Only PE-CE, VPN 809 over IPv6-Only Core, 4to6 softwire -Inter-AS Option-C 811 Inter-AS ASBR-ASBR link is IPv6-Only PE 812 IPv6-Only __________ __________ IPv6-Only 813 PE / CE / \ / \ PE / CE 814 +--+ +----+ / \ / \ +--+ +--+ 815 | | | | | AS 1 \ | AS 2 \ | | | | 816 | | | | | \IPv6| \ | | | | 817 |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| 818 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 819 +--+ +----+ \ / \ / +--+ +--+ 820 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 821 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 822 IPv6 forwarding IPv6 forwarding 824 Figure 15: Design Solution-12 E2E IPv6-Only PE-CE, VPN over 825 IPv6-Only Core - Inter-AS Option-C 827 8. IPv6-Only PE Design ALL AFI/SFI Operational Considerations 829 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 830 some operational considerations in terms of what changes and what 831 does not change. 833 What does not change with a single IPv6 transport peer carrying IPv4 834 NLRI and IPv6 NLRI below: 836 Routing Policy configuration is still separate for IPv4 and IPv6 837 configured by capability as previously. 839 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 840 impact both IPv4 and IPv6 as previously. 842 If the interface is in the Admin Down state, the IPv6 peer would go 843 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 845 Changes resulting from a single IPv6 transport peer carrying IPv4 846 NLRI and IPv6 NLRI below: 848 Physical interface is no longer dual stacked. 850 Any change in IPv6 address or DAD state will impact both IPv4 and 851 IPv6 NLRI exchange. 853 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 854 session is now tied to the transport, which now is only IPv6 address 855 family. 857 Both IPv4 and IPv6 peer now exists under the IPv6 address family 858 configuration. 860 Fate sharing of IPv4 and IPv6 address family from a logical 861 perspective now carried over a single physical IPv6 peer. 863 From an operations perspective, prior to elimination of IPv4 peers, 864 an audit is recommended to identify and IPv4 and IPv6 peering 865 incongruencies that may exist and to rectify them. No operational 866 impacts or issues are expected with this change. 868 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 869 both IPv4 and IPv6 prefixes have the same label in no table lookup 870 pop-n-forward mode should be taken into consideration. 872 9. IANA Considerations 874 There are not any IANA considerations. 876 10. Security Considerations 878 The extensions defined in this document allow BGP to propagate 879 reachability information about IPv4 prefixes over an MPLS or SR 880 IPv6-Only core network. As such, no new security issues are raised 881 beyond those that already exist in BGP-4 and the use of MP-BGP for 882 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 883 configuration. The security features of BGP and corresponding 884 security policy defined in the ISP domain are applicable. For the 885 inter-AS distribution of IPv6 routes according to case (a) of 886 Section 4 of this document, no new security issues are raised beyond 887 those that already exist in the use of eBGP for IPv6 [RFC2545]. 889 11. Acknowledgments 891 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 892 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 893 review comments. 895 12. Contributors 897 The following people contributed substantive text to this document: 899 Mohana Sundari 900 EMail: mohanas@juniper.net 902 13. References 904 13.1. Normative References 906 [I-D.ietf-bess-ipv6-only-pe-design] 907 Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang, 908 Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for 909 IPv4-NLRI with IPv6-NH", Work in Progress, Internet-Draft, 910 draft-ietf-bess-ipv6-only-pe-design-00, 20 September 2021, 911 . 914 [I-D.nalawade-kapoor-tunnel-safi] 915 Nalawade, G., "BGP Tunnel SAFI", Work in Progress, 916 Internet-Draft, draft-nalawade-kapoor-tunnel-safi-05, 29 917 June 2006, . 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 926 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 927 DOI 10.17487/RFC2545, March 1999, 928 . 930 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 931 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 932 2006, . 934 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 935 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 936 2006, . 938 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 939 "Multiprotocol Extensions for BGP-4", RFC 4760, 940 DOI 10.17487/RFC4760, January 2007, 941 . 943 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 944 LAN Service (VPLS) Using BGP for Auto-Discovery and 945 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 946 . 948 [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based 949 Auto-Discovery for Layer-1 VPNs", RFC 5195, 950 DOI 10.17487/RFC5195, June 2008, 951 . 953 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 954 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 955 2009, . 957 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 958 Transit Solution Using IP Encapsulation and MP-BGP 959 Extensions", RFC 5747, DOI 10.17487/RFC5747, March 2010, 960 . 962 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 963 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 964 RFC 6037, DOI 10.17487/RFC6037, October 2010, 965 . 967 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 968 C. Kodeboniya, "Multicast in Virtual Private LAN Service 969 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 970 . 972 [RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., 973 "Dynamic Placement of Multi-Segment Pseudowires", 974 RFC 7267, DOI 10.17487/RFC7267, June 2014, 975 . 977 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 978 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 979 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 980 2015, . 982 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 983 S. Ray, "North-Bound Distribution of Link-State and 984 Traffic Engineering (TE) Information Using BGP", RFC 7752, 985 DOI 10.17487/RFC7752, March 2016, 986 . 988 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 989 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 990 May 2017, . 992 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 993 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 994 . 996 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 997 Bacher, "Dissemination of Flow Specification Rules", 998 RFC 8955, DOI 10.17487/RFC8955, December 2020, 999 . 1001 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1002 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1003 DOI 10.17487/RFC9012, April 2021, 1004 . 1006 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1007 Jalil, "BGP Control Plane for the Network Service Header 1008 in Service Function Chaining", RFC 9015, 1009 DOI 10.17487/RFC9015, June 2021, 1010 . 1012 13.2. Informative References 1014 [I-D.ietf-idr-dynamic-cap] 1015 Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", 1016 Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- 1017 cap-16, 21 October 2021, . 1020 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1021 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1022 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1023 . 1025 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1026 R., Patel, K., and J. Guichard, "Constrained Route 1027 Distribution for Border Gateway Protocol/MultiProtocol 1028 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1029 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1030 November 2006, . 1032 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1033 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1034 Provider Edge Routers (6PE)", RFC 4798, 1035 DOI 10.17487/RFC4798, February 2007, 1036 . 1038 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 1039 Durand, Ed., "Softwire Problem Statement", RFC 4925, 1040 DOI 10.17487/RFC4925, July 2007, 1041 . 1043 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 1044 Layer Reachability Information with an IPv6 Next Hop", 1045 RFC 5549, DOI 10.17487/RFC5549, May 2009, 1046 . 1048 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1049 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 1050 . 1052 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1053 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1054 Virtual Private Networks (L2VPNs)", RFC 6074, 1055 DOI 10.17487/RFC6074, January 2011, 1056 . 1058 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1059 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1060 2012, . 1062 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1063 Encodings and Procedures for Multicast in MPLS/BGP IP 1064 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1065 . 1067 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1068 Writing an IANA Considerations Section in RFCs", BCP 26, 1069 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1070 . 1072 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 1073 Patel, "Advertising IPv4 Network Layer Reachability 1074 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 1075 DOI 10.17487/RFC8950, November 2020, 1076 . 1078 Authors' Addresses 1080 Gyan Mishra 1081 Verizon Inc. 1082 Email: gyan.s.mishra@verizon.com 1084 Mankamana Mishra 1085 Cisco Systems 1086 821 Alder Drive, 1087 MILPITAS 1088 Email: mankamis@cisco.com 1090 Jeff Tantsura 1091 Microsoft, Inc. 1092 Email: jefftant.ietf@gmail.com 1094 Sudha Madhavi 1095 Juniper Networks, Inc. 1096 Email: smadhavi@juniper.net 1098 Qing Yang 1099 Arista Networks 1100 Email: qyang@arista.com 1102 Adam Simpson 1103 Nokia 1104 Email: adam.1.simpson@nokia.com 1105 Shuanglong Chen 1106 Huawei Technologies 1107 Email: chenshuanglong@huawei.com