idnits 2.17.00 (12 Aug 2021) /tmp/idnits28515/draft-mishra-bess-ipv6-only-pe-design-all-safi-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 are 3 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** 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 both 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 and PE-PE BGP peering Standard which is described in the POC testing document [I-D.ietf-bess-ipv6-only-pe-design] 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. == 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 both 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. 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 (19 March 2022) is 63 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 988, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 1125, 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: 4 errors (**), 0 flaws (~~), 13 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: 20 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 19 March 2022 18 IPv6-Only PE Design All SAFI 19 draft-mishra-bess-ipv6-only-pe-design-all-safi-00 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 both IPv4 34 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 35 Reachability Information (NLRI)to be carried over the same (Border 36 Gateway Protocol) BGP TCP session for all Address Family Identifiers 37 (AFI) and Subsequent Address Family Identifiers(SAFI). The design 38 change provides the same Dual Stacking functionality that exists 39 today with separate IPv4 and IPv6 BGP sessions as we have today. 40 With this IPv6-Only PE Design, IPv4 address MUST not be configured on 41 the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR 42 (Autonomous System Boundary Router) to ASBR (Autonomous System 43 Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From 44 a control plane perspective a single IPv6-Only peer is required for 45 both IPv4 and IPv6 routing updates and from a data plane forwarindg 46 perspective an IPv6 address need only be configured on the PE to PE 47 Inter-AS peering interface for both IPv4 and IPv6 packet forwarding. 48 This document defines the IPv6-Only PE Design as a new PE-CE and PE- 49 PE BGP peering Standard which is described in the POC testing 50 document [I-D.ietf-bess-ipv6-only-pe-design] to all AFI/SAFI 51 ubiquitously. As service providers migrate to Segment Routing 52 architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus 53 Inter-AS options Option-A, Option-AB and Option-C are still 54 applicable and thus this extension of IPv6-Only peering architecure 55 extension to Inter-AS peering is very relevant to Segment Routing as 56 well. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at https://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on 20 September 2022. 75 Copyright Notice 77 Copyright (c) 2022 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 82 license-info) in effect on the date of publication of this document. 83 Please review these documents carefully, as they describe your rights 84 and restrictions with respect to this document. Code Components 85 extracted from this document must include Revised BSD License text as 86 described in Section 4.e of the Trust Legal Provisions and are 87 provided without warranty as described in the Revised BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 93 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 94 4. IPv6-Only Edge Peering Architecture . . . . . . . . . . . . . 7 95 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 96 4.2. IPv6-Only PE-CE Design Solution . . . . . . . . . . . . . 8 97 4.3. IPv6-Only Edge Peering Design . . . . . . . . . . . . . . 9 98 4.3.1. IPv6-Only Edge Peering Packet Walk . . . . . . . . . 9 99 4.3.2. 6to4 Softwire IPv4-Only Core packet walk . . . . . . 10 100 4.3.3. 4to6 Softwire IPv6-Only Core packet walk . . . . . . 11 101 4.4. RFC5549 and RFC8950 Applicability . . . . . . . . . . . . 13 102 4.4.1. IPv6-Only Edge Peering design next-hop encoding . . . 14 103 4.4.2. RFC8950 updates to RFC5549 applicability . . . . . . 14 104 5. IPv6-Only PE Design Edge E2E Design for all AFI/SAFI . . . . 15 105 5.1. IPv6-Only PE Design All SAFI Case-1 E2E IPv6-Only PE-CE, 106 Global Table over IPv4-Only Core(6PE), 6to4 softwire . . 15 107 5.2. IPv6-Only PE Design All SAFI Case-2 E2E IPv6-Only PE-CE, 108 VPN over IPv4-Only Core, 6to4 Softwire . . . . . . . . . 16 109 5.3. IPv6-Only PE Design All SAFI Case-3 E2E IPv6-Only PE-CE, 110 Global Table over IPv6-Only Core (4PE), 4to6 Softwire . 16 111 5.4. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, 112 VPN over IPv6-Only Core, 4to6 Softwire . . . . . . . . . 17 113 5.5. IPv6-Only PE Design All SAFI Case-5 E2E IPv6-Only PE-CE, 114 Global Table over IPv4-Only Core(6PE), 6to4 softwire 115 -Inter-AS Option-B . . . . . . . . . . . . . . . . . . . 17 116 5.6. IPv6-Only PE Design All SAFI Case-6 E2E IPv6-Only PE-CE, 117 Global Table over IPv4-Only Core(6PE), 6to4 softwire 118 -Inter-AS Option-C . . . . . . . . . . . . . . . . . . . 18 119 5.7. IPv6-Only PE Design All SAFI Case-7 E2E IPv6-Only PE-CE, 120 VPN over IPv4-Only, 6to4 softwire -Inter-AS Option-B . . 18 121 5.8. IPv6-Only PE Design All SAFI Case-8 E2E IPv6-Only PE-CE, 122 VPN over IPv4-Only Core, 6to4 softwire -Inter-AS 123 Option-C . . . . . . . . . . . . . . . . . . . . . . . . 19 124 5.9. IPv6-Only PE Design All SAFI Case-9 E2E IPv6-Only PE-CE, 125 Global Table over IPv6-Only Core, 4to6 softwire -Inter-AS 126 Option-B . . . . . . . . . . . . . . . . . . . . . . . . 19 127 5.10. IPv6-Only PE Design All SAFI Case-10 E2E IPv6-Only PE-CE, 128 Global Table over IPv6-Only Core, 4to6 softwire -Inter-AS 129 Option-C . . . . . . . . . . . . . . . . . . . . . . . . 20 130 5.11. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, 131 VPN over IPv6-Only Core, 4to6 softwire -Inter-AS 132 Option-B . . . . . . . . . . . . . . . . . . . . . . . . 20 133 5.12. IPv6-Only PE Design All SAFI Case-12 E2E IPv6-Only PE-CE, 134 VPN over IPv6-Only Core, 4to6 softwire -Inter-AS 135 Option-C . . . . . . . . . . . . . . . . . . . . . . . . 21 136 5.13. IPv6-Only PE-CE Operational Considerations Testing . . . 21 137 6. IPv6-Only PE ALL AFI/SFI Operational Considerations . . . . . 21 138 7. Vendor Implementations and Operator Deployments . . . . . . . 22 139 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 140 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 141 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 142 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 143 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 144 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 145 12.2. Informative References . . . . . . . . . . . . . . . . . 25 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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. 172 MP-BGP specifies that the set of usable next-hop address families is 173 determined by the Address Family Identifier (AFI) and the Subsequent 174 Address Family Identifier (SAFI). Historically the AFI/SAFI 175 definitions for the IPv4 address family only have provisions for 176 advertising a Next Hop address that belongs to the IPv4 protocol when 177 advertising IPv4 or VPN-IPv4. [RFC8950] specifies the extensions 178 necessary to allow advertising IPv4 NLRI, Virtual Private Network 179 Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN- 180 IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. 181 This comprises of an extended next hop encoding MP-REACH BGP 182 capability exchange to allow the address of the Next Hop for IPv4 183 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 184 Protocol. [RFC8950] defines the encoding of the Next Hop to 185 determine which of the protocols the address actually belongs to, and 186 a new BGP Capability allowing MP-BGP Peers to discover dynamically 187 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 188 Next Hop. 190 The current specification for carrying IPv4 NLRI of a given address 191 family via a Next Hop of a different address family is now defined in 192 [RFC8950], and specifies the extended next hop encoding MP-REACH 193 capability extension necessary to do so. This comprises an extension 194 of the AFI/SAFI definitions to allow the address of the Next Hop for 195 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 196 protocol, the encoding of the Next Hop information to determine which 197 of the protocols the address belongs to, and a new BGP Capability 198 allowing MP-BGP peers to dynamically discover whether they can 199 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 201 With the new extensions defined in [RFC8950] supporting NLRI and next 202 hop address family mismatch, the BGP peer session can now be treated 203 as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the 204 Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP 205 session. This allows for the elimination of dual stack from the PE- 206 PE Inter-AS peering point, and now enable the Inter-AS peering to be 207 IPv6-ONLY. The elimination of IPv4 Inter Provider ASBR tie point, 208 PE-PE Inter-AS peering points translates into OPEX expenditure 209 savings of point-to-point infrastructure links as well as /31 address 210 space savings and administration and network management of both IPv4 211 and IPv6 BGP peers. This reduction decreases the number of PE-PE 212 Inter-AS options BGP peers by fifty percent, which is a tremendous 213 cost savings for operators. 215 While the savings exists at the Edge eBGP PE-PE Inter-AS peering, on 216 the core side PE to Route Reflector (RR) peering carrying 217 IPv4 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no 218 savings as the Provider (P) Core is IPv6 Only and thus can only have 219 an IPv6 peer and must use [RFC8950] extended next hop encoding to 220 carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicast VPN 221 <2/129> over an IPv6 next hop. 223 This document defines the IPv6-Only PE Design Architecture details 224 for External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that 225 leverages the MP-BGP capability exchange by using IPv6 peering as 226 pure transport, allowing both IPv4 Network Layer Reachability 227 Information (NLRI) and IPv6 Network Layer Reachability Information 228 (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP 229 session for all Address Family Identifiers (AFI) and Subsequent 230 Address Family Identifiers(SAFI). The design change provides the 231 same Dual Stacking functionality that exists today with separate IPv4 232 and IPv6 BGP sessions as we have today. With this IPv6-Only PE 233 Design, IPv4 address MUST not be configured on the the Provider Edge 234 (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System 235 Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE 236 Provider Edge (PE) - Provider Edge (PE). From a control plane 237 perspective a single IPv6-Only peer MUST be configured for both IPv4 238 and IPv6 routing updates, and from a data plane forwarindg 239 perspective only an IPv6 address MUST be configured on the PE-CE Edge 240 or ASBR-ASBR, PE to PE Inter-AS peering interface for both IPv4 and 241 IPv6 packet forwarding. This document defines the IPv6-Only PE 242 Design as a new Intra-AS PE-CE Edge and Inter-AS PE-PE BGP peering 243 Standard which is described in the POC testing document in detail, 244 [I-D.ietf-bess-ipv6-only-pe-design] which is now extended for 245 applicability to to all AFI/SAFI ubiquitously. As service providers 246 migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay 247 exsits as well, and thus Inter-AS options Option-A, Option-AB and 248 Option-C are still applicable and thus this extension of IPv6-Only 249 peering architecure extension to Inter-AS peering is very relevant to 250 Segment Routing as well as well as any other applicable AFI/SAFI is 251 now as well relevant. 253 This document details an important External BGP (eBGP) PE-PE Inter-AS 254 IPv6-Only peering design that leverages the MP-BGP capability 255 exchange by using IPv6 peering as pure transport, allowing both IPv4 256 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 257 Reachability Information (NLRI)to be carried over the same (Border 258 Gateway Protocol) BGP TCP session for the following Address Family 259 Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI) to 260 be carried over IPv6-Only Inter-AS peerings described in detail in 261 this document: IPv4 Unicast <1/1>, IPv4 Multicast 262 <1/2>,VPN-IPV4 <1/128>, Multicasat VPN <1/129>, BGP-LU IPV4 (4PE) 263 <1/4>, BGP-LU IPV4 <1/4> 265 This IPv6-Only PE ALL SAFI Design details an important External BGP 266 (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP- 267 BGP capability exchange by using IPv6 peering as pure transport, 268 allowing both IPv4 Network Layer Reachability Information (NLRI) and 269 IPv6 Network Layer Reachability Information (NLRI)to be carried over 270 the same (Border Gateway Protocol) BGP TCP session for all remaining 271 Address Family Identifiers (AFI) and Subsequent Address Family 272 Identifiers(SAFI) below as well that can be carried over IPv6-Only 273 Inter-AS peerings: MCAST-VPN [RFC6514] <1/5>, NLRI Multi- 274 Segment Pseudowires [RFC7267] <1/6>, BGP Tunnel Encapsulation SAFI 275 [RFC9012] <1/7>, MCAST-VPLS [RFC7117] <1/8>, BGP SFC [RFC9015] <1/9>, 276 Tunnel SAFI [I-D.nalawade-kapoor-tunnel-safi] <1/6>, Virtual Private 277 LAN Service (VPLS) [RFC4761] and [RFC6074] <1/5>, BGP MDT SAFI 278 [RFC6037] <1/66>, BGP 4to6 SAFI [RFC5747] <1/67>, BGP 6to4 SAFI draft 279 xx <1/8>, Layer 1 VPN Auto-Discovery [RFC5195] <1/69>, BGP EVPNs 280 [RFC7432] <1/70>, BGP-LS (VPLS) [RFC7752] <1/71>, BGP-LS-EVPN 281 [RFC7752] <72/>, SR-TE Policy SAFI draftxx <1/73>, BGP 6to4 SAFI 282 draft xx <1/8>, SDN WAN Capabilities draftxx <1/74>, Routing Policy 283 SAFI draftxx <1/75>, Classful-Transport SAFI draftxx <1/76>, Tunneled 284 Traffic FlowSpec draftxx <1/77>, MCAST-TREE SAFI draft xx <1/78>, 285 Route Target Constraints [RFC4684] <1/132>, Dissemination of Flow 286 Specification Rules [RFC8955] <1/133>, L3 VPN Dissemination of Flow 287 Specification Rules [RFC8955] <1/1344>, VPN Auto-Discovery SAFI 288 draftxx <1/140> 290 2. Requirements Language 292 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 293 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 294 "OPTIONAL" in this document are to be interpreted as described in BCP 295 14 [RFC2119] [RFC8174] when, and only when, they appear in all 296 capitals, as shown here. 298 3. Terminology 300 Terminolgoy used in defining the IPv6-Only Edge specification. 302 AFBR: Address Family Border Router Provider Edge (PE). 304 Edge: PE-CE Edge Network Provider Edge - Customer Edge 306 Core: P Core Network Provider (P) 308 4to6 Softwire : IPv4 edge over an IPv6-Only core 310 6to4 Softwire: IPv6 edge over an IPv4-Only core 312 E2E: End to End 314 4. IPv6-Only Edge Peering Architecture 316 4.1. Problem Statement 318 This specification addresses a real issue that has been discussed at 319 many operator groups around the world related to IXP major peering 320 points where hundreds of AS's have both IPv4 and IPv6 dual stacked 321 peering. IPv4 address depletion have been a major issue issue for 322 many years now. Operators around the world are clamoring for a 323 solution that can help solve issues related to IPv4 address depletion 324 at these large IXP peering points. With this solution IXPs as well 325 as all infrastructure networks such as Core networks, DC networks, 326 Access networks as well as any PE-CE public or private network can 327 now utilize this IPv6-Only Edge solution and reap the benefits 328 immediately on IPv4 address space saving. 330 IXP Problem Statement 332 Dual Stacked Dual Stacked 333 CE PE 335 +-------+ IPv4 BGP Peer +-------+ 336 | |---------------| | 337 | CE | IPv6 BGP Peer | PE | 338 | |---------------| | 339 +-------+ +-------+ 340 IPv4 forwarding IPv4 forwarding 341 IPv6 forwarding IPv6 forwarding 343 Figure 1: Problem Statement - IXP Dual Stack Peering 345 ________ 346 Dual Stacked _____ / \ Dual Stacked 347 PE / CE / \__/ \___ PE / CE 348 +----+ +----+ / \ +------+ +-----+ 349 | | | | |0====VPN Overlay Tunnel ==0| | | | | 350 | | | | | \ | | | | 351 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 352 | | | | \0=========Underlay =======0| | | | | 353 +----+ +----+ \ __/ +------+ +-----+ 354 IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer 355 IPv4 forwarding \__ __ / IPv4 forwarding 356 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 358 Figure 2: Problem Statement - E2E Dual Stack Edge 360 4.2. IPv6-Only PE-CE Design Solution 362 The IPv6-Only Edge design solution provides a means of E2E single 363 protocol design solution extension of [RFC5565] Softwire Mesh 364 framework from the PE-CE Edge to the Core from ingres so egress 365 through the entire operators domain. This solution eliminates all 366 IPv4 addressing from end to end while still providing the same Dual 367 Stack functionality of IPv4 and IPv6 packet forwarding from a data 368 plane perspective by leveraging the [RFC8950] extended next hop 369 encoding so that IPv4 NLRI can be advertised over a single IPv6 pure 370 transport TCP session. This IPv6-Only E2E architecture eliminates 371 all IPv4 peering and IPv4 addressing E2E from the ingress CE to 372 ingress PE to egress PE to egress CE and all hops along the operator 373 E2E path. 375 Solution applicable to 376 any Edge peering scenario - IXP, Core, DC, Access, etc 378 +-------+ +-------+ 379 | | IPv6 Only | | 380 | CE |----------------| PE | 381 | | IPv6 BGP Peer | | 382 +-------+ +-------+ 383 IPv4 forwarding IPv4 forwarding 384 IPv6 forwarding IPv6 forwarding 386 Figure 3: IPv6-Only Solution Applicability 388 ________ 389 IPv6-Only _____ / \ IPv6-Only 390 PE / CE / \__/ \___ PE / CE 391 +----+ +----+ / \ +------+ +-----+ 392 | | | | |0====VPN Overlay Tunnel ==0| | | | | 393 | | | | | \ | | | | 394 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 395 | | | | \0=========Underlay ===== ==0 | | | | 396 +----+ +----+ \ __/ +------+ +-----+ 397 IPv6 BGP peer \IP / MPLS / SR domain / IPv6 BGP peer 398 IPv4 forwarding \__ __ / IPv4 forwarding 399 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 401 Figure 4: E2E VPN Solution 403 4.3. IPv6-Only Edge Peering Design 405 4.3.1. IPv6-Only Edge Peering Packet Walk 407 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 408 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 409 mesh framework concept is based on the overlay and underlay MPLS or 410 SR based technology framework, where the underlay is the transport 411 layer and the overlay is a Virtual Private Network (VPN) layer, and 412 is the the tunneled virtualization layer containing the customer 413 payload. The concept of a 6to4 Softwire is based on transmission of 414 IPv6 packets at the edge of the network by tunneling the IPv6 packets 415 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 416 on transmission of IPv4 packets at the edge of the network by 417 tunneling the IPv4 packets over an IPv6-Only Core. 419 This document describes End to End (E2E) test scenarios that follow a 420 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 421 egress PE-CE tracing the routing protocol control plane and data 422 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 423 within the IPv4-Only or IPv6-Only Core network. In both secneario we 424 are focusing on IPv4 packets and the control plane and data plane 425 forwarding aspects of IPv4 packets from the PE-CE Edge network over 426 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 427 network. With this IPv6-Only Edge peering design, the Softwire Mesh 428 Framework is not extended beyond the Provider Edge (PE) and continues 429 to terminate on the PE router. 431 4.3.2. 6to4 Softwire IPv4-Only Core packet walk 433 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 434 network Edge traverse a IPv4-Only Core 436 In the scenario where IPv4 packets originating from a PE-CE edge are 437 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 438 the PE and CE only have an IPv6 address configured on the interface. 439 In this scenario the IPv4 packets that ingress the CE from within the 440 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 441 NLRI destination prefix learned from the Pure Transport Single IPv6 442 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 443 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 444 the PE-CE interface is the only interface that is IPv6-Only and all 445 other interfaces may or may not be IPv6-Only. Following the data 446 plane packet flow, IPv4 packets are forwarded from the ingress CE to 447 the IPv6-Only ingress PE where the VPN label imposition push per 448 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 449 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 450 label disposition pop occurs and the native IPv4 packet is forwarded 451 to the egress CE. In the reverse direction IPv4 packets are 452 forwarded from the egress CE to egress PE where the VPN label 453 imposition per prefix, per-vrf, per-CE push occurs and the labeled 454 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 455 the ingress PE where the VPN label disposition pop occurs and the 456 native IPv4 packet is forwarded to the ingress CE. . The 457 functionality of the IPv4 forwarding plane in this scenario is 458 identical from a data plane forwarding perspective to Dual Stack IPv4 459 forwarding scenario. 461 +--------+ +--------+ 462 | IPv4 | | IPv4 | 463 | Client | | Client | 464 | Network| | Network| 465 +--------+ +--------+ 466 | \ / | 467 | \ / | 468 | \ / | 469 | X | 470 | / \ | 471 | / \ | 472 | / \ | 473 +--------+ +--------+ 474 | AFBR | | AFBR | 475 +--| IPv4/6 |---| IPv4/6 |--+ 476 | +--------+ +--------+ | 477 +--------+ | | +--------+ 478 | IPv4 | | | | IPv4 | 479 | Client | | | | Client | 480 | Network|------| IPv4 |-------| Network| 481 +--------+ | only | +--------+ 482 | | 483 | +--------+ +--------+ | 484 +--| AFBR |---| AFBR |--+ 485 | IPv4/6 | | IPv4/6 | 486 +--------+ +--------+ 487 | \ / | 488 | \ / | 489 | \ / | 490 | X | 491 | / \ | 492 | / \ | 493 | / \ | 494 +--------+ +--------+ 495 | IPv6 | | IPv4 | 496 | Client | | Client | 497 | Network| | Network| 498 +--------+ +--------+ 500 Figure 5: 6to4 Softwire - IPv6 Edge over an IPv4-Only Core 502 4.3.3. 4to6 Softwire IPv6-Only Core packet walk 504 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 505 network Edge traverse a IPv6-Only Core 506 In the scenario where IPv4 packets originating from a PE-CE edge are 507 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 508 the PE and CE only have an IPv6 address configured on the interface. 509 In this scenario the IPv4 packets that ingress the CE from within the 510 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 511 NLRI destination prefix learned from the Pure Transport Single IPv6 512 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 513 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 514 the PE-CE interface is the only interface that is IPv6-Only and all 515 other interfaces may or may not be IPv6-Only. Following the data 516 plane packet flow, IPv4 packets are forwarded from the ingress CE to 517 the IPv6-Only ingress PE where the VPN label imposition push per 518 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 519 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 520 label disposition pop occurs and the native IPv4 packet is forwarded 521 to the egress CE. In the reverse direction IPv4 packets are 522 forwarded from the egress CE to egress PE where the VPN label 523 imposition per prefix, per-vrf, per-CE push occurs and the labeled 524 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 525 the ingress PE where the VPN label disposition pop occurs and the 526 native IPv4 packet is forwarded to the ingress CE. . The 527 functionality of the IPv4 forwarding plane in this scenario is 528 identical from a data plane forwarding perspective to Dual Stack IPv4 529 forwarding scenario. 531 +--------+ +--------+ 532 | IPv4 | | IPv4 | 533 | Client | | Client | 534 | Network| | Network| 535 +--------+ +--------+ 536 | \ / | 537 | \ / | 538 | \ / | 539 | X | 540 | / \ | 541 | / \ | 542 | / \ | 543 +--------+ +--------+ 544 | AFBR | | AFBR | 545 +--| IPv4/6 |---| IPv4/6 |--+ 546 | +--------+ +--------+ | 547 +--------+ | | +--------+ 548 | IPv6 | | | | IPv6 | 549 | Client | | | | Client | 550 | Network|------| IPv6 |-------| Network| 551 +--------+ | only | +--------+ 552 | | 553 | +--------+ +--------+ | 554 +--| AFBR |---| AFBR |--+ 555 | IPv4/6 | | IPv4/6 | 556 +--------+ +--------+ 557 | \ / | 558 | \ / | 559 | \ / | 560 | X | 561 | / \ | 562 | / \ | 563 | / \ | 564 +--------+ +--------+ 565 | IPv4 | | IPv4 | 566 | Client | | Client | 567 | Network| | Network| 568 +--------+ +--------+ 570 Figure 6: 4to6 Softwire - IPv4 Edge over an IPv6-Only Core 572 4.4. RFC5549 and RFC8950 Applicability 573 4.4.1. IPv6-Only Edge Peering design next-hop encoding 575 This section describes [RFC8950] next hop encoding updates to 576 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 577 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 578 an IPv6 next hop BGP capability extended hop encoding IANA capability 579 codepoint value 5 defined is applicable to both [RFC5549] and 580 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 581 in the RFC updates. 583 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 584 part of the IPv6-Only design vendor interoperaiblity test cases and 585 in that respect is applicable as [RFC8950] updates [RFC5549] for 586 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 588 4.4.2. RFC8950 updates to RFC5549 applicability 590 This section describes the [RFC8950] next hop encoding updates to 591 [RFC5549] 593 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 594 encoded as an IPv6 address with a length of 16 or 32 bytes. This 595 document modifies how the next-hop address is encoded to accommodate 596 all existing implementations and bring consistency with VPNv4oIPv4 597 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 598 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 599 6.2 of this document). This change addresses Erratum ID 5253 600 (Err5253). As all known and deployed implementations are 601 interoperable today and use the new proposed encoding, the change 602 does not break existing interoperability. Updates to [RFC8950] is 603 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 604 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 605 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 606 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 608 comes into play which is discussed in section 8.9. 610 [RFC5549] next hop encoding of MP_REACH_NLRI with: 612 * NLRI= NLRI as per current AFI/SAFI definition 614 Advertising with [RFC4760] MP_REACH_NLRI with: 616 * AFI = 1 618 * SAFI = 128 or 129 620 * Length of Next Hop Address = 16 or 32 621 * NLRI= NLRI as per current AFI/SAFI definition 623 [RFC8950] next hop encoding of MP_REACH_NLRI with: 625 * NLRI= NLRI as per current AFI/SAFI definition 627 Advertising with [RFC4760] MP_REACH_NLRI with: 629 * AFI = 1 631 * SAFI = 128 or 129 633 * Length of Next Hop Address = 24 or 48 635 * Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 636 set to zero (potentially followed by the link-local VPN-IPv6 637 address of the next hop with an 8-octet RD is set to zero). 639 * NLRI= NLRI as per current AFI/SAFI definition 641 5. IPv6-Only PE Design Edge E2E Design for all AFI/SAFI 643 Proof of conept interoperability testing of the 4 test cases bet 645 5.1. IPv6-Only PE Design All SAFI Case-1 E2E IPv6-Only PE-CE, Global 646 Table over IPv4-Only Core(6PE), 6to4 softwire 648 ________ 649 IPv6-Only _____ / \ IPv6-Only 650 PE / CE / \__/ \___ PE / CE 651 +----+ +----+ / \ +------+ +-----+ 652 | | | | | |_ | | | | 653 | | | | | \ | | | | 654 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 655 | | | | \0=========Underlay =======0| | | | | 656 +----+ +----+ \ __/ +------+ +-----+ 657 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 658 IPv4 forwarding \__ __ / IPv4 forwarding 659 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 661 Figure 7: Design Solution-1 E2E IPv6-Only PE-CE, Global 662 Table over IPv4-Only Core (6PE) 664 5.2. IPv6-Only PE Design All SAFI Case-2 E2E IPv6-Only PE-CE, VPN over 665 IPv4-Only Core, 6to4 Softwire 667 ________ 668 IPv6-Only _____ / \ IPv6-Only 669 PE / CE / \__/ \___ PE / CE 670 +----+ +----+ / \ +------+ +-----+ 671 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 672 | | | | | \ | | | | 673 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 674 | | | | \0=========Underlay =======0| | | | | 675 +----+ +----+ \ __/ +------+ +-----+ 676 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 677 IPv4 forwarding \__ __ / IPv4 forwarding 678 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 680 Figure 8: Design Solution-2 E2E IPv6-Only PE-CE, VPN over 681 IPv4-Only Core 683 5.3. IPv6-Only PE Design All SAFI Case-3 E2E IPv6-Only PE-CE, Global 684 Table over IPv6-Only Core (4PE), 4to6 Softwire 686 ________ 687 IPv6-Only _____ / \ IPv6-Only 688 PE / CE / \__/ \___ PE / CE 689 +----+ +----+ / \ +------+ +-----+ 690 | | | | | |_ | | | | 691 | | | | | \ | | | | 692 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 693 | | | | \0=========Underlay =======0| | | | | 694 +----+ +----+ \ __/ +------+ +-----+ 695 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 696 IPv4 forwarding \__ __ / IPv4 forwarding 697 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 699 Figure 9: Design Solution-3 E2E IPv6-Only PE-CE, Global 700 Table over IPv6-Only Core (4PE) 702 5.4. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, VPN over 703 IPv6-Only Core, 4to6 Softwire 705 ________ 706 IPv6-Only _____ / \ IPv6-Only 707 PE / CE / \__/ \___ PE / CE 708 +----+ +----+ / \ +------+ +-----+ 709 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 710 | | | | | \ | | | | 711 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 712 | | | | \0=========Underlay =======0| | | | | 713 +----+ +----+ \ __/ +------+ +-----+ 714 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 715 IPv4 forwarding \__ __ / IPv4 forwarding 716 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 718 Figure 10: Design Solution-4 E2E IPv6-Only PE-CE, VPN over 719 IPv6-Only Core 721 5.5. IPv6-Only PE Design All SAFI Case-5 E2E IPv6-Only PE-CE, Global 722 Table over IPv4-Only Core(6PE), 6to4 softwire -Inter-AS Option-B 724 IPv6-Only __________ __________ IPv6-Only 725 PE / CE / \ / \ PE / CE 726 +--+ +----+ / \ / \ +--+ +--+ 727 | | | | | AS 1 \ | AS 2 \ | | | | 728 | | | | | \ | \ | | | | 729 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 730 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 731 +--+ +----+ \ / \ / +--+ +--+ 732 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 733 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 734 IPv6 forwarding IPv6 forwarding 736 Figure 11: Design Solution-5 E2E IPv6-Only PE-CE, Global 737 Table over IPv4-Only Core (6PE) - Inter-AS Option-B 739 5.6. IPv6-Only PE Design All SAFI Case-6 E2E IPv6-Only PE-CE, Global 740 Table over IPv4-Only Core(6PE), 6to4 softwire -Inter-AS Option-C 742 IPv6-Only __________ __________ IPv6-Only 743 PE / CE / \ / \ PE / CE 744 +--+ +----+ / \ / \ +--+ +--+ 745 | | | | | AS 1 \ | AS 2 \ | | | | 746 | | | | | \ | \ | | | | 747 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 748 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 749 +--+ +----+ \ / \ / +--+ +--+ 750 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 751 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 752 IPv6 forwarding IPv6 forwarding 754 Figure 12: Design Solution-6 E2E IPv6-Only PE-CE, Global 755 Table over IPv4-Only Core (6PE) - Inter-AS Option-C 757 5.7. IPv6-Only PE Design All SAFI Case-7 E2E IPv6-Only PE-CE, VPN over 758 IPv4-Only, 6to4 softwire -Inter-AS Option-B 760 IPv6-Only __________ __________ IPv6-Only 761 PE / CE / \ / \ PE / CE 762 +--+ +----+ / \ / \ +--+ +--+ 763 | | | | | AS 1 \ | AS 2 \ | | | | 764 | | | | | \ | \ | | | | 765 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 766 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 767 +--+ +----+ \ / \ / +--+ +--+ 768 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 769 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 770 IPv6 forwarding IPv6 forwarding 772 Figure 13: Design Solution-7 E2E IPv6-Only PE-CE, VPN over 773 IPv4-Only Core - Inter-AS Option-B 775 5.8. IPv6-Only PE Design All SAFI Case-8 E2E IPv6-Only PE-CE, VPN over 776 IPv4-Only Core, 6to4 softwire -Inter-AS Option-C 778 IPv6-Only __________ __________ IPv6-Only 779 PE / CE / \ / \ PE / CE 780 +--+ +----+ / \ / \ +--+ +--+ 781 | | | | | AS 1 \ | AS 2 \ | | | | 782 | | | | | \ | \ | | | | 783 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 784 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 785 +--+ +----+ \ / \ / +--+ +--+ 786 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 787 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 788 IPv6 forwarding IPv6 forwarding 790 Figure 14: Design Solution-8 E2E IPv6-Only PE-CE, VPN over 791 IPv4-Only Core - Inter-AS Option-C 793 5.9. IPv6-Only PE Design All SAFI Case-9 E2E IPv6-Only PE-CE, Global 794 Table over IPv6-Only Core, 4to6 softwire -Inter-AS Option-B 796 IPv6-Only __________ __________ IPv6-Only 797 PE / CE / \ / \ PE / CE 798 +--+ +----+ / \ / \ +--+ +--+ 799 | | | | | AS 1 \ | AS 2 \ | | | | 800 | | | | | \ | \ | | | | 801 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 802 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 803 +--+ +----+ \ / \ / +--+ +--+ 804 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 805 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 806 IPv6 forwarding IPv6 forwarding 808 Figure 15: Design Solution-9 E2E IPv6-Only PE-CE, Global 809 Table over IPv6-Only Core - Inter-AS Option-B 811 5.10. IPv6-Only PE Design All SAFI Case-10 E2E IPv6-Only PE-CE, Global 812 Table over IPv6-Only Core, 4to6 softwire -Inter-AS Option-C 814 IPv6-Only __________ __________ IPv6-Only 815 PE / CE / \ / \ PE / CE 816 +--+ +----+ / \ / \ +--+ +--+ 817 | | | | | AS 1 \ | AS 2 \ | | | | 818 | | | | | \ | \ | | | | 819 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 820 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 821 +--+ +----+ \ / \ / +--+ +--+ 822 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 823 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 824 IPv6 forwarding IPv6 forwarding 826 Figure 16: Design Solution-10 E2E IPv6-Only PE-CE, Global 827 Table over IPv6-Only Core - Inter-AS Option-C 829 5.11. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, VPN over 830 IPv6-Only Core, 4to6 softwire -Inter-AS Option-B 832 IPv6-Only __________ __________ IPv6-Only 833 PE / CE / \ / \ PE / CE 834 +--+ +----+ / \ / \ +--+ +--+ 835 | | | | | AS 1 \ | AS 2 \ | | | | 836 | | | | | \ | \ | | | | 837 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 838 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 839 +--+ +----+ \ / \ / +--+ +--+ 840 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 841 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 842 IPv6 forwarding IPv6 forwarding 844 Figure 17: Design Solution-11 E2E IPv6-Only PE-CE, VPN over 845 IPv6-Only Core - Inter-AS Option-B 847 5.12. IPv6-Only PE Design All SAFI Case-12 E2E IPv6-Only PE-CE, VPN 848 over IPv6-Only Core, 4to6 softwire -Inter-AS Option-C 850 IPv6-Only __________ __________ IPv6-Only 851 PE / CE / \ / \ PE / CE 852 +--+ +----+ / \ / \ +--+ +--+ 853 | | | | | AS 1 \ | AS 2 \ | | | | 854 | | | | | \ | \ | | | | 855 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 856 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 857 +--+ +----+ \ / \ / +--+ +--+ 858 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 859 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 860 IPv6 forwarding IPv6 forwarding 862 Figure 18: Design Solution-12 E2E IPv6-Only PE-CE, VPN over 863 IPv6-Only Core - Inter-AS Option-C 865 5.13. IPv6-Only PE-CE Operational Considerations Testing 867 Ping CE to PE when destination prefix is withdrawn 868 Traceroute CE to PE and test all ICMPv4 and ICMPv6 type codes 870 +-------+ +-------+ 871 | | IPv6 Only | | 872 | CE |----------------| PE | 873 | | IPv6 BGP Peer | | 874 +-------+ +-------+ 875 IPv4 forwarding IPv4 forwarding 876 IPv6 forwarding IPv6 forwarding 878 Figure 19: Ping and Trace Test Case 880 6. IPv6-Only PE ALL AFI/SFI Operational Considerations 882 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 883 some operational considerations in terms of what changes and what 884 does not change. 886 What does not change with a single IPv6 transport peer carrying IPv4 887 NLRI and IPv6 NLRI below: 889 Routing Policy configuration is still separate for IPv4 and IPv6 890 configured by capability as previously. 892 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 893 impact both IPv4 and IPv6 as previously. 895 If the interface is in the Admin Down state, the IPv6 peer would go 896 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 898 Changes resulting from a single IPv6 transport peer carrying IPv4 899 NLRI and IPv6 NLRI below: 901 Physical interface is no longer dual stacked. 903 Any change in IPv6 address or DAD state will impact both IPv4 and 904 IPv6 NLRI exchange. 906 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 907 session is now tied to the transport, which now is only IPv6 address 908 family. 910 Both IPv4 and IPv6 peer now exists under the IPv6 address family 911 configuration. 913 Fate sharing of IPv4 and IPv6 address family from a logical 914 perspective now carried over a single physical IPv6 peer. 916 From an operations perspective, prior to elimination of IPv4 peers, 917 an audit is recommended to identify and IPv4 and IPv6 peering 918 incongruencies that may exist and to rectify them. No operational 919 impacts or issues are expected with this change. 921 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 922 both IPv4 and IPv6 prefixes have the same label in no table lookup 923 pop-n-forward mode should be taken into consideration. 925 7. Vendor Implementations and Operator Deployments 927 Vendor implementations are with Cisco, Juniper, Nokia, Arista and 928 Huawei 930 8. IANA Considerations 932 There are not any IANA considerations. 934 9. Security Considerations 936 The extensions defined in this document allow BGP to propagate 937 reachability information about IPv4 prefixes over an MPLS or SR 938 IPv6-Only core network. As such, no new security issues are raised 939 beyond those that already exist in BGP-4 and the use of MP-BGP for 940 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 941 configuration. The security features of BGP and corresponding 942 security policy defined in the ISP domain are applicable. For the 943 inter-AS distribution of IPv6 routes according to case (a) of 944 Section 4 of this document, no new security issues are raised beyond 945 those that already exist in the use of eBGP for IPv6 [RFC2545]. 947 10. Acknowledgments 949 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 950 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 951 review comments. 953 11. Contributors 955 The following people contributed substantive text to this document: 957 Mohana Sundari 958 EMail: mohanas@juniper.net 960 12. References 962 12.1. Normative References 964 [I-D.ietf-bess-ipv6-only-pe-design] 965 Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang, 966 Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for 967 IPv4-NLRI with IPv6-NH", Work in Progress, Internet-Draft, 968 draft-ietf-bess-ipv6-only-pe-design-00, 20 September 2021, 969 . 972 [I-D.nalawade-kapoor-tunnel-safi] 973 Nalawade, G., "BGP Tunnel SAFI", Work in Progress, 974 Internet-Draft, draft-nalawade-kapoor-tunnel-safi-05, 29 975 June 2006, . 978 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 979 Requirement Levels", BCP 14, RFC 2119, 980 DOI 10.17487/RFC2119, March 1997, 981 . 983 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 984 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 985 DOI 10.17487/RFC2545, March 1999, 986 . 988 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 989 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 990 2006, . 992 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 993 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 994 2006, . 996 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 997 "Multiprotocol Extensions for BGP-4", RFC 4760, 998 DOI 10.17487/RFC4760, January 2007, 999 . 1001 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1002 LAN Service (VPLS) Using BGP for Auto-Discovery and 1003 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1004 . 1006 [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based 1007 Auto-Discovery for Layer-1 VPNs", RFC 5195, 1008 DOI 10.17487/RFC5195, June 2008, 1009 . 1011 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 1012 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 1013 2009, . 1015 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 1016 Transit Solution Using IP Encapsulation and MP-BGP 1017 Extensions", RFC 5747, DOI 10.17487/RFC5747, March 2010, 1018 . 1020 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 1021 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 1022 RFC 6037, DOI 10.17487/RFC6037, October 2010, 1023 . 1025 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 1026 C. Kodeboniya, "Multicast in Virtual Private LAN Service 1027 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 1028 . 1030 [RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., 1031 "Dynamic Placement of Multi-Segment Pseudowires", 1032 RFC 7267, DOI 10.17487/RFC7267, June 2014, 1033 . 1035 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1036 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1037 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1038 2015, . 1040 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1041 S. Ray, "North-Bound Distribution of Link-State and 1042 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1043 DOI 10.17487/RFC7752, March 2016, 1044 . 1046 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1047 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1048 May 2017, . 1050 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1051 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1052 . 1054 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 1055 Bacher, "Dissemination of Flow Specification Rules", 1056 RFC 8955, DOI 10.17487/RFC8955, December 2020, 1057 . 1059 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1060 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1061 DOI 10.17487/RFC9012, April 2021, 1062 . 1064 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1065 Jalil, "BGP Control Plane for the Network Service Header 1066 in Service Function Chaining", RFC 9015, 1067 DOI 10.17487/RFC9015, June 2021, 1068 . 1070 12.2. Informative References 1072 [I-D.ietf-idr-dynamic-cap] 1073 Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", 1074 Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- 1075 cap-16, 21 October 2021, . 1078 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1079 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1080 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1081 . 1083 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1084 R., Patel, K., and J. Guichard, "Constrained Route 1085 Distribution for Border Gateway Protocol/MultiProtocol 1086 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1087 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1088 November 2006, . 1090 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1091 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1092 Provider Edge Routers (6PE)", RFC 4798, 1093 DOI 10.17487/RFC4798, February 2007, 1094 . 1096 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 1097 Durand, Ed., "Softwire Problem Statement", RFC 4925, 1098 DOI 10.17487/RFC4925, July 2007, 1099 . 1101 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 1102 Layer Reachability Information with an IPv6 Next Hop", 1103 RFC 5549, DOI 10.17487/RFC5549, May 2009, 1104 . 1106 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1107 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 1108 . 1110 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1111 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1112 Virtual Private Networks (L2VPNs)", RFC 6074, 1113 DOI 10.17487/RFC6074, January 2011, 1114 . 1116 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1117 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1118 2012, . 1120 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1121 Encodings and Procedures for Multicast in MPLS/BGP IP 1122 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1123 . 1125 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1126 Writing an IANA Considerations Section in RFCs", BCP 26, 1127 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1128 . 1130 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 1131 Patel, "Advertising IPv4 Network Layer Reachability 1132 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 1133 DOI 10.17487/RFC8950, November 2020, 1134 . 1136 Authors' Addresses 1138 Gyan Mishra 1139 Verizon Inc. 1140 Email: gyan.s.mishra@verizon.com 1142 Mankamana Mishra 1143 Cisco Systems 1144 821 Alder Drive, 1145 MILPITAS 1146 Email: mankamis@cisco.com 1148 Jeff Tantsura 1149 Microsoft, Inc. 1150 Email: jefftant.ietf@gmail.com 1152 Sudha Madhavi 1153 Juniper Networks, Inc. 1154 Email: smadhavi@juniper.net 1156 Qing Yang 1157 Arista Networks 1158 Email: qyang@arista.com 1160 Adam Simpson 1161 Nokia 1162 Email: adam.1.simpson@nokia.com 1163 Shuanglong Chen 1164 Huawei Technologies 1165 Email: chenshuanglong@huawei.com