idnits 2.17.00 (12 Aug 2021) /tmp/idnits29557/draft-mishra-bess-ipv6-all-pe-design-any-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: 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]. 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. -- The document date (7 March 2022) is 68 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 1000, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 1137, 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: 8 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 7 March 2022 18 IPv6-Only PE Design All SAFI 19 draft-mishra-bess-ipv6-all-pe-design-any-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 8 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 . . . . . . . . . . . . . 9 97 4.3. IPv6-Only Edge Peering Design . . . . . . . . . . . . . . 10 98 4.3.1. IPv6-Only Edge Peering Packet Walk . . . . . . . . . 10 99 4.3.2. 6to4 Softwire IPv4-Only Core packet walk . . . . . . 10 100 4.3.3. 4to6 Softwire IPv6-Only Core packet walk . . . . . . 12 101 4.4. RFC5549 and RFC8950 Applicability . . . . . . . . . . . . 14 102 4.4.1. IPv6-Only Edge Peering design next-hop encoding . . . 15 103 4.4.2. RFC8950 updates to RFC5549 applicability . . . . . . 15 104 5. IPv6-Only PE Design Edge E2E Design for all AFI/SAFI . . . . 16 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 . . 16 107 5.2. IPv6-Only PE Design All SAFI Case-2 E2E IPv6-Only PE-CE, 108 VPN over IPv4-Only Core, 6to4 Softwire . . . . . . . . . 17 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 . 17 111 5.4. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, 112 VPN over IPv6-Only Core, 4to6 Softwire . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 19 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 . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 136 5.13. IPv6-Only PE-CE Operational Considerations Testing . . . 22 137 6. IPv6-Only PE ALL AFI/SFI Operational Considerations . . . . . 22 138 7. Vendor Implementations and Operator Deployments . . . . . . . 23 139 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 140 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 141 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 142 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 143 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 144 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 145 12.2. Informative References . . . . . . . . . . . . . . . . . 26 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 design change from 233 a control plane perspective a single IPv6-Only peer is required for 234 both IPv4 and IPv6 routing updates and from a data plane forwarindg 235 perspective an IPv6 address MUST ONLY be configured on the PE-CE Edge 236 or PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet 237 forwarding. This document extends the IPv6-Only PE-CE peering 238 architecture defined in [I-D.ietf-bess-ipv6-only-pe-design] to PE-PE 239 inter-as peering architecture to now apply to all AFI/SAFI 240 ubiquitously. As service providers migrate to Segment Routing 241 architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus 242 Inter-AS options Option-A, Option-AB and Option-C are still 243 applicable and thus this extension of IPv6-Only peering architecure 244 extension to Inter-AS peering is relevant to Segment Routing as well 245 as any other AFI/SAFi that is relevant. 247 With this IPv6-Only PE Design, IPv4 address MUST not be configured on 248 the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR 249 (Autonomous System Boundary Router) to ASBR (Autonomous System 250 Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From 251 a control plane perspective a single IPv6-Only peer MUST be 252 configured for both IPv4 and IPv6 routing updates and from a data 253 plane forwarindg perspective only an IPv6 address MUST be configured 254 on the PE-CE Edge or ASBR-ASBR, PE to PE Inter-AS peering interface 255 for both IPv4 and IPv6 packet forwarding. This document defines the 256 IPv6-Only PE Design as a new Intra-AS PE-CE Edge and Inter-AS PE-PE 257 BGP peering Standard which is described in the POC testing document 258 in detail, [I-D.ietf-bess-ipv6-only-pe-design]. As service providers 259 migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay 260 exsits as well, and thus Inter-AS options Option-A, Option-AB and 261 Option-C are still applicable and thus this extension of IPv6-Only 262 peering architecure extension to Inter-AS peering is very relevant to 263 Segment Routing as well. 265 This document details an important External BGP (eBGP) PE-PE Inter-AS 266 IPv6-Only peering design that leverages the MP-BGP capability 267 exchange by using IPv6 peering as pure transport, allowing both IPv4 268 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 269 Reachability Information (NLRI)to be carried over the same (Border 270 Gateway Protocol) BGP TCP session for the following Address Family 271 Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI) to 272 be carried over IPv6-Only Inter-AS peerings described in detail in 273 this document: IPv4 Unicast <1/1>, IPv4 Multicast 274 <1/2>,VPN-IPV4 <1/128>, Multicasat VPN <1/129>, BGP-LU IPV4 (4PE) 275 <1/4>, BGP-LU IPV4 <1/4> 277 This IPv6-Only PE ALL SAFI Design details an important External BGP 278 (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP- 279 BGP capability exchange by using IPv6 peering as pure transport, 280 allowing both IPv4 Network Layer Reachability Information (NLRI) and 281 IPv6 Network Layer Reachability Information (NLRI)to be carried over 282 the same (Border Gateway Protocol) BGP TCP session for all remaining 283 Address Family Identifiers (AFI) and Subsequent Address Family 284 Identifiers(SAFI) below as well that can be carried over IPv6-Only 285 Inter-AS peerings: MCAST-VPN [RFC6514] <1/5>, NLRI Multi- 286 Segment Pseudowires [RFC7267] <1/6>, BGP Tunnel Encapsulation SAFI 287 [RFC9012] <1/7>, MCAST-VPLS [RFC7117] <1/8>, BGP SFC [RFC9015] <1/9>, 288 Tunnel SAFI [I-D.nalawade-kapoor-tunnel-safi] <1/6>, Virtual Private 289 LAN Service (VPLS) [RFC4761] and [RFC6074] <1/5>, BGP MDT SAFI 290 [RFC6037] <1/66>, BGP 4to6 SAFI [RFC5747] <1/67>, BGP 6to4 SAFI draft 291 xx <1/8>, Layer 1 VPN Auto-Discovery [RFC5195] <1/69>, BGP EVPNs 292 [RFC7432] <1/70>, BGP-LS (VPLS) [RFC7752] <1/71>, BGP-LS-EVPN 293 [RFC7752] <72/>, SR-TE Policy SAFI draftxx <1/73>, BGP 6to4 SAFI 294 draft xx <1/8>, SDN WAN Capabilities draftxx <1/74>, Routing Policy 295 SAFI draftxx <1/75>, Classful-Transport SAFI draftxx <1/76>, Tunneled 296 Traffic FlowSpec draftxx <1/77>, MCAST-TREE SAFI draft xx <1/78>, 297 Route Target Constraints [RFC4684] <1/132>, Dissemination of Flow 298 Specification Rules [RFC8955] <1/133>, L3 VPN Dissemination of Flow 299 Specification Rules [RFC8955] <1/1344>, VPN Auto-Discovery SAFI 300 draftxx <1/140> 302 2. Requirements Language 304 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 305 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 306 "OPTIONAL" in this document are to be interpreted as described in BCP 307 14 [RFC2119] [RFC8174] when, and only when, they appear in all 308 capitals, as shown here. 310 3. Terminology 312 Terminolgoy used in defining the IPv6-Only Edge specification. 314 AFBR: Address Family Border Router Provider Edge (PE). 316 Edge: PE-CE Edge Network Provider Edge - Customer Edge 318 Core: P Core Network Provider (P) 320 4to6 Softwire : IPv4 edge over an IPv6-Only core 322 6to4 Softwire: IPv6 edge over an IPv4-Only core 324 E2E: End to End 326 4. IPv6-Only Edge Peering Architecture 328 4.1. Problem Statement 330 This specification addresses a real issue that has been discussed at 331 many operator groups around the world related to IXP major peering 332 points where hundreds of AS's have both IPv4 and IPv6 dual stacked 333 peering. IPv4 address depletion have been a major issue issue for 334 many years now. Operators around the world are clamoring for a 335 solution that can help solve issues related to IPv4 address depletion 336 at these large IXP peering points. With this solution IXPs as well 337 as all infrastructure networks such as Core networks, DC networks, 338 Access networks as well as any PE-CE public or private network can 339 now utilize this IPv6-Only Edge solution and reap the benefits 340 immediately on IPv4 address space saving. 342 IXP Problem Statement 344 Dual Stacked Dual Stacked 345 CE PE 347 +-------+ IPv4 BGP Peer +-------+ 348 | |---------------| | 349 | CE | IPv6 BGP Peer | PE | 350 | |---------------| | 351 +-------+ +-------+ 352 IPv4 forwarding IPv4 forwarding 353 IPv6 forwarding IPv6 forwarding 355 Figure 1: Problem Statement - IXP Dual Stack Peering 357 ________ 358 Dual Stacked _____ / \ Dual Stacked 359 PE / CE / \__/ \___ PE / CE 360 +----+ +----+ / \ +------+ +-----+ 361 | | | | |0====VPN Overlay Tunnel ==0| | | | | 362 | | | | | \ | | | | 363 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 364 | | | | \0=========Underlay =======0| | | | | 365 +----+ +----+ \ __/ +------+ +-----+ 366 IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer 367 IPv4 forwarding \__ __ / IPv4 forwarding 368 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 370 Figure 2: Problem Statement - E2E Dual Stack Edge 372 4.2. IPv6-Only PE-CE Design Solution 374 The IPv6-Only Edge design solution provides a means of E2E single 375 protocol design solution extension of [RFC5565] Softwire Mesh 376 framework from the PE-CE Edge to the Core from ingres so egress 377 through the entire operators domain. This solution eliminates all 378 IPv4 addressing from end to end while still providing the same Dual 379 Stack functionality of IPv4 and IPv6 packet forwarding from a data 380 plane perspective by leveraging the [RFC8950] extended next hop 381 encoding so that IPv4 NLRI can be advertised over a single IPv6 pure 382 transport TCP session. This IPv6-Only E2E architecture eliminates 383 all IPv4 peering and IPv4 addressing E2E from the ingress CE to 384 ingress PE to egress PE to egress CE and all hops along the operator 385 E2E path. 387 Solution applicable to 388 any Edge peering scenario - IXP, Core, DC, Access, etc 390 +-------+ +-------+ 391 | | IPv6 Only | | 392 | CE |----------------| PE | 393 | | IPv6 BGP Peer | | 394 +-------+ +-------+ 395 IPv4 forwarding IPv4 forwarding 396 IPv6 forwarding IPv6 forwarding 398 Figure 3: IPv6-Only Solution Applicability 400 ________ 401 IPv6-Only _____ / \ IPv6-Only 402 PE / CE / \__/ \___ PE / CE 403 +----+ +----+ / \ +------+ +-----+ 404 | | | | |0====VPN Overlay Tunnel ==0| | | | | 405 | | | | | \ | | | | 406 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 407 | | | | \0=========Underlay ===== ==0 | | | | 408 +----+ +----+ \ __/ +------+ +-----+ 409 IPv6 BGP peer \IP / MPLS / SR domain / IPv6 BGP peer 410 IPv4 forwarding \__ __ / IPv4 forwarding 411 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 413 Figure 4: E2E VPN Solution 415 4.3. IPv6-Only Edge Peering Design 417 4.3.1. IPv6-Only Edge Peering Packet Walk 419 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 420 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 421 mesh framework concept is based on the overlay and underlay MPLS or 422 SR based technology framework, where the underlay is the transport 423 layer and the overlay is a Virtual Private Network (VPN) layer, and 424 is the the tunneled virtualization layer containing the customer 425 payload. The concept of a 6to4 Softwire is based on transmission of 426 IPv6 packets at the edge of the network by tunneling the IPv6 packets 427 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 428 on transmission of IPv4 packets at the edge of the network by 429 tunneling the IPv4 packets over an IPv6-Only Core. 431 This document describes End to End (E2E) test scenarios that follow a 432 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 433 egress PE-CE tracing the routing protocol control plane and data 434 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 435 within the IPv4-Only or IPv6-Only Core network. In both secneario we 436 are focusing on IPv4 packets and the control plane and data plane 437 forwarding aspects of IPv4 packets from the PE-CE Edge network over 438 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 439 network. With this IPv6-Only Edge peering design, the Softwire Mesh 440 Framework is not extended beyond the Provider Edge (PE) and continues 441 to terminate on the PE router. 443 4.3.2. 6to4 Softwire IPv4-Only Core packet walk 445 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 446 network Edge traverse a IPv4-Only Core 448 In the scenario where IPv4 packets originating from a PE-CE edge are 449 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 450 the PE and CE only have an IPv6 address configured on the interface. 451 In this scenario the IPv4 packets that ingress the CE from within the 452 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 453 NLRI destination prefix learned from the Pure Transport Single IPv6 454 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 455 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 456 the PE-CE interface is the only interface that is IPv6-Only and all 457 other interfaces may or may not be IPv6-Only. Following the data 458 plane packet flow, IPv4 packets are forwarded from the ingress CE to 459 the IPv6-Only ingress PE where the VPN label imposition push per 460 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 461 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 462 label disposition pop occurs and the native IPv4 packet is forwarded 463 to the egress CE. In the reverse direction IPv4 packets are 464 forwarded from the egress CE to egress PE where the VPN label 465 imposition per prefix, per-vrf, per-CE push occurs and the labeled 466 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 467 the ingress PE where the VPN label disposition pop occurs and the 468 native IPv4 packet is forwarded to the ingress CE. . The 469 functionality of the IPv4 forwarding plane in this scenario is 470 identical from a data plane forwarding perspective to Dual Stack IPv4 471 forwarding scenario. 473 +--------+ +--------+ 474 | IPv4 | | IPv4 | 475 | Client | | Client | 476 | Network| | Network| 477 +--------+ +--------+ 478 | \ / | 479 | \ / | 480 | \ / | 481 | X | 482 | / \ | 483 | / \ | 484 | / \ | 485 +--------+ +--------+ 486 | AFBR | | AFBR | 487 +--| IPv4/6 |---| IPv4/6 |--+ 488 | +--------+ +--------+ | 489 +--------+ | | +--------+ 490 | IPv4 | | | | IPv4 | 491 | Client | | | | Client | 492 | Network|------| IPv4 |-------| Network| 493 +--------+ | only | +--------+ 494 | | 495 | +--------+ +--------+ | 496 +--| AFBR |---| AFBR |--+ 497 | IPv4/6 | | IPv4/6 | 498 +--------+ +--------+ 499 | \ / | 500 | \ / | 501 | \ / | 502 | X | 503 | / \ | 504 | / \ | 505 | / \ | 506 +--------+ +--------+ 507 | IPv6 | | IPv4 | 508 | Client | | Client | 509 | Network| | Network| 510 +--------+ +--------+ 512 Figure 5: 6to4 Softwire - IPv6 Edge over an IPv4-Only Core 514 4.3.3. 4to6 Softwire IPv6-Only Core packet walk 516 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 517 network Edge traverse a IPv6-Only Core 518 In the scenario where IPv4 packets originating from a PE-CE edge are 519 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 520 the PE and CE only have an IPv6 address configured on the interface. 521 In this scenario the IPv4 packets that ingress the CE from within the 522 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 523 NLRI destination prefix learned from the Pure Transport Single IPv6 524 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 525 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 526 the PE-CE interface is the only interface that is IPv6-Only and all 527 other interfaces may or may not be IPv6-Only. Following the data 528 plane packet flow, IPv4 packets are forwarded from the ingress CE to 529 the IPv6-Only ingress PE where the VPN label imposition push per 530 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 531 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 532 label disposition pop occurs and the native IPv4 packet is forwarded 533 to the egress CE. In the reverse direction IPv4 packets are 534 forwarded from the egress CE to egress PE where the VPN label 535 imposition per prefix, per-vrf, per-CE push occurs and the labeled 536 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 537 the ingress PE where the VPN label disposition pop occurs and the 538 native IPv4 packet is forwarded to the ingress CE. . The 539 functionality of the IPv4 forwarding plane in this scenario is 540 identical from a data plane forwarding perspective to Dual Stack IPv4 541 forwarding scenario. 543 +--------+ +--------+ 544 | IPv4 | | IPv4 | 545 | Client | | Client | 546 | Network| | Network| 547 +--------+ +--------+ 548 | \ / | 549 | \ / | 550 | \ / | 551 | X | 552 | / \ | 553 | / \ | 554 | / \ | 555 +--------+ +--------+ 556 | AFBR | | AFBR | 557 +--| IPv4/6 |---| IPv4/6 |--+ 558 | +--------+ +--------+ | 559 +--------+ | | +--------+ 560 | IPv6 | | | | IPv6 | 561 | Client | | | | Client | 562 | Network|------| IPv6 |-------| Network| 563 +--------+ | only | +--------+ 564 | | 565 | +--------+ +--------+ | 566 +--| AFBR |---| AFBR |--+ 567 | IPv4/6 | | IPv4/6 | 568 +--------+ +--------+ 569 | \ / | 570 | \ / | 571 | \ / | 572 | X | 573 | / \ | 574 | / \ | 575 | / \ | 576 +--------+ +--------+ 577 | IPv4 | | IPv4 | 578 | Client | | Client | 579 | Network| | Network| 580 +--------+ +--------+ 582 Figure 6: 4to6 Softwire - IPv4 Edge over an IPv6-Only Core 584 4.4. RFC5549 and RFC8950 Applicability 585 4.4.1. IPv6-Only Edge Peering design next-hop encoding 587 This section describes [RFC8950] next hop encoding updates to 588 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 589 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 590 an IPv6 next hop BGP capability extended hop encoding IANA capability 591 codepoint value 5 defined is applicable to both [RFC5549] and 592 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 593 in the RFC updates. 595 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 596 part of the IPv6-Only design vendor interoperaiblity test cases and 597 in that respect is applicable as [RFC8950] updates [RFC5549] for 598 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 600 4.4.2. RFC8950 updates to RFC5549 applicability 602 This section describes the [RFC8950] next hop encoding updates to 603 [RFC5549] 605 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 606 encoded as an IPv6 address with a length of 16 or 32 bytes. This 607 document modifies how the next-hop address is encoded to accommodate 608 all existing implementations and bring consistency with VPNv4oIPv4 609 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 610 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 611 6.2 of this document). This change addresses Erratum ID 5253 612 (Err5253). As all known and deployed implementations are 613 interoperable today and use the new proposed encoding, the change 614 does not break existing interoperability. Updates to [RFC8950] is 615 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 616 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 617 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 618 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 620 comes into play which is discussed in section 8.9. 622 [RFC5549] next hop encoding of MP_REACH_NLRI with: 624 * NLRI= NLRI as per current AFI/SAFI definition 626 Advertising with [RFC4760] MP_REACH_NLRI with: 628 * AFI = 1 630 * SAFI = 128 or 129 632 * Length of Next Hop Address = 16 or 32 633 * NLRI= NLRI as per current AFI/SAFI definition 635 [RFC8950] next hop encoding of MP_REACH_NLRI with: 637 * NLRI= NLRI as per current AFI/SAFI definition 639 Advertising with [RFC4760] MP_REACH_NLRI with: 641 * AFI = 1 643 * SAFI = 128 or 129 645 * Length of Next Hop Address = 24 or 48 647 * Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 648 set to zero (potentially followed by the link-local VPN-IPv6 649 address of the next hop with an 8-octet RD is set to zero). 651 * NLRI= NLRI as per current AFI/SAFI definition 653 5. IPv6-Only PE Design Edge E2E Design for all AFI/SAFI 655 Proof of conept interoperability testing of the 4 test cases bet 657 5.1. IPv6-Only PE Design All SAFI Case-1 E2E IPv6-Only PE-CE, Global 658 Table over IPv4-Only Core(6PE), 6to4 softwire 660 ________ 661 IPv6-Only _____ / \ IPv6-Only 662 PE / CE / \__/ \___ PE / CE 663 +----+ +----+ / \ +------+ +-----+ 664 | | | | | |_ | | | | 665 | | | | | \ | | | | 666 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 667 | | | | \0=========Underlay =======0| | | | | 668 +----+ +----+ \ __/ +------+ +-----+ 669 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 670 IPv4 forwarding \__ __ / IPv4 forwarding 671 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 673 Figure 7: Design Solution-1 E2E IPv6-Only PE-CE, Global 674 Table over IPv4-Only Core (6PE) 676 5.2. IPv6-Only PE Design All SAFI Case-2 E2E IPv6-Only PE-CE, VPN over 677 IPv4-Only Core, 6to4 Softwire 679 ________ 680 IPv6-Only _____ / \ IPv6-Only 681 PE / CE / \__/ \___ PE / CE 682 +----+ +----+ / \ +------+ +-----+ 683 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 684 | | | | | \ | | | | 685 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 686 | | | | \0=========Underlay =======0| | | | | 687 +----+ +----+ \ __/ +------+ +-----+ 688 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 689 IPv4 forwarding \__ __ / IPv4 forwarding 690 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 692 Figure 8: Design Solution-2 E2E IPv6-Only PE-CE, VPN over 693 IPv4-Only Core 695 5.3. IPv6-Only PE Design All SAFI Case-3 E2E IPv6-Only PE-CE, Global 696 Table over IPv6-Only Core (4PE), 4to6 Softwire 698 ________ 699 IPv6-Only _____ / \ IPv6-Only 700 PE / CE / \__/ \___ PE / CE 701 +----+ +----+ / \ +------+ +-----+ 702 | | | | | |_ | | | | 703 | | | | | \ | | | | 704 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 705 | | | | \0=========Underlay =======0| | | | | 706 +----+ +----+ \ __/ +------+ +-----+ 707 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 708 IPv4 forwarding \__ __ / IPv4 forwarding 709 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 711 Figure 9: Design Solution-3 E2E IPv6-Only PE-CE, Global 712 Table over IPv6-Only Core (4PE) 714 5.4. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, VPN over 715 IPv6-Only Core, 4to6 Softwire 717 ________ 718 IPv6-Only _____ / \ IPv6-Only 719 PE / CE / \__/ \___ PE / CE 720 +----+ +----+ / \ +------+ +-----+ 721 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 722 | | | | | \ | | | | 723 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 724 | | | | \0=========Underlay =======0| | | | | 725 +----+ +----+ \ __/ +------+ +-----+ 726 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 727 IPv4 forwarding \__ __ / IPv4 forwarding 728 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 730 Figure 10: Design Solution-4 E2E IPv6-Only PE-CE, VPN over 731 IPv6-Only Core 733 5.5. IPv6-Only PE Design All SAFI Case-5 E2E IPv6-Only PE-CE, Global 734 Table over IPv4-Only Core(6PE), 6to4 softwire -Inter-AS Option-B 736 IPv6-Only __________ __________ IPv6-Only 737 PE / CE / \ / \ PE / CE 738 +--+ +----+ / \ / \ +--+ +--+ 739 | | | | | AS 1 \ | AS 2 \ | | | | 740 | | | | | \ | \ | | | | 741 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 742 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 743 +--+ +----+ \ / \ / +--+ +--+ 744 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 745 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 746 IPv6 forwarding IPv6 forwarding 748 Figure 11: Design Solution-5 E2E IPv6-Only PE-CE, Global 749 Table over IPv4-Only Core (6PE) - Inter-AS Option-B 751 5.6. IPv6-Only PE Design All SAFI Case-6 E2E IPv6-Only PE-CE, Global 752 Table over IPv4-Only Core(6PE), 6to4 softwire -Inter-AS Option-C 754 IPv6-Only __________ __________ IPv6-Only 755 PE / CE / \ / \ PE / CE 756 +--+ +----+ / \ / \ +--+ +--+ 757 | | | | | AS 1 \ | AS 2 \ | | | | 758 | | | | | \ | \ | | | | 759 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 760 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 761 +--+ +----+ \ / \ / +--+ +--+ 762 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 763 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 764 IPv6 forwarding IPv6 forwarding 766 Figure 12: Design Solution-6 E2E IPv6-Only PE-CE, Global 767 Table over IPv4-Only Core (6PE) - Inter-AS Option-C 769 5.7. IPv6-Only PE Design All SAFI Case-7 E2E IPv6-Only PE-CE, VPN over 770 IPv4-Only, 6to4 softwire -Inter-AS Option-B 772 IPv6-Only __________ __________ IPv6-Only 773 PE / CE / \ / \ PE / CE 774 +--+ +----+ / \ / \ +--+ +--+ 775 | | | | | AS 1 \ | AS 2 \ | | | | 776 | | | | | \ | \ | | | | 777 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 778 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 779 +--+ +----+ \ / \ / +--+ +--+ 780 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 781 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 782 IPv6 forwarding IPv6 forwarding 784 Figure 13: Design Solution-7 E2E IPv6-Only PE-CE, VPN over 785 IPv4-Only Core - Inter-AS Option-B 787 5.8. IPv6-Only PE Design All SAFI Case-8 E2E IPv6-Only PE-CE, VPN over 788 IPv4-Only Core, 6to4 softwire -Inter-AS Option-C 790 IPv6-Only __________ __________ IPv6-Only 791 PE / CE / \ / \ PE / CE 792 +--+ +----+ / \ / \ +--+ +--+ 793 | | | | | AS 1 \ | AS 2 \ | | | | 794 | | | | | \ | \ | | | | 795 |CE|-| PE |--| IPv4-Only Core|---| IPv4-Only Core|-|PE|-|CE| 796 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 797 +--+ +----+ \ / \ / +--+ +--+ 798 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 799 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 800 IPv6 forwarding IPv6 forwarding 802 Figure 14: Design Solution-8 E2E IPv6-Only PE-CE, VPN over 803 IPv4-Only Core - Inter-AS Option-C 805 5.9. IPv6-Only PE Design All SAFI Case-9 E2E IPv6-Only PE-CE, Global 806 Table over IPv6-Only Core, 4to6 softwire -Inter-AS Option-B 808 IPv6-Only __________ __________ IPv6-Only 809 PE / CE / \ / \ PE / CE 810 +--+ +----+ / \ / \ +--+ +--+ 811 | | | | | AS 1 \ | AS 2 \ | | | | 812 | | | | | \ | \ | | | | 813 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 814 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 815 +--+ +----+ \ / \ / +--+ +--+ 816 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 817 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 818 IPv6 forwarding IPv6 forwarding 820 Figure 15: Design Solution-9 E2E IPv6-Only PE-CE, Global 821 Table over IPv6-Only Core - Inter-AS Option-B 823 5.10. IPv6-Only PE Design All SAFI Case-10 E2E IPv6-Only PE-CE, Global 824 Table over IPv6-Only Core, 4to6 softwire -Inter-AS Option-C 826 IPv6-Only __________ __________ IPv6-Only 827 PE / CE / \ / \ PE / CE 828 +--+ +----+ / \ / \ +--+ +--+ 829 | | | | | AS 1 \ | AS 2 \ | | | | 830 | | | | | \ | \ | | | | 831 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 832 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 833 +--+ +----+ \ / \ / +--+ +--+ 834 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 835 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 836 IPv6 forwarding IPv6 forwarding 838 Figure 16: Design Solution-10 E2E IPv6-Only PE-CE, Global 839 Table over IPv6-Only Core - Inter-AS Option-C 841 5.11. IPv6-Only PE Design All SAFI Case-4 E2E IPv6-Only PE-CE, VPN over 842 IPv6-Only Core, 4to6 softwire -Inter-AS Option-B 844 IPv6-Only __________ __________ IPv6-Only 845 PE / CE / \ / \ PE / CE 846 +--+ +----+ / \ / \ +--+ +--+ 847 | | | | | AS 1 \ | AS 2 \ | | | | 848 | | | | | \ | \ | | | | 849 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 850 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 851 +--+ +----+ \ / \ / +--+ +--+ 852 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 853 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 854 IPv6 forwarding IPv6 forwarding 856 Figure 17: Design Solution-11 E2E IPv6-Only PE-CE, VPN over 857 IPv6-Only Core - Inter-AS Option-B 859 5.12. IPv6-Only PE Design All SAFI Case-12 E2E IPv6-Only PE-CE, VPN 860 over IPv6-Only Core, 4to6 softwire -Inter-AS Option-C 862 IPv6-Only __________ __________ IPv6-Only 863 PE / CE / \ / \ PE / CE 864 +--+ +----+ / \ / \ +--+ +--+ 865 | | | | | AS 1 \ | AS 2 \ | | | | 866 | | | | | \ | \ | | | | 867 |CE|-| PE |--| IPv6-Only Core|---| IPv6-Only Core|-|PE|-|CE| 868 | | | | |0=Underlay==0 | |0==Underlay===0| | | | | 869 +--+ +----+ \ / \ / +--+ +--+ 870 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 871 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 872 IPv6 forwarding IPv6 forwarding 874 Figure 18: Design Solution-12 E2E IPv6-Only PE-CE, VPN over 875 IPv6-Only Core - Inter-AS Option-C 877 5.13. IPv6-Only PE-CE Operational Considerations Testing 879 Ping CE to PE when destination prefix is withdrawn 880 Traceroute CE to PE and test all ICMPv4 and ICMPv6 type codes 882 +-------+ +-------+ 883 | | IPv6 Only | | 884 | CE |----------------| PE | 885 | | IPv6 BGP Peer | | 886 +-------+ +-------+ 887 IPv4 forwarding IPv4 forwarding 888 IPv6 forwarding IPv6 forwarding 890 Figure 19: Ping and Trace Test Case 892 6. IPv6-Only PE ALL AFI/SFI Operational Considerations 894 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 895 some operational considerations in terms of what changes and what 896 does not change. 898 What does not change with a single IPv6 transport peer carrying IPv4 899 NLRI and IPv6 NLRI below: 901 Routing Policy configuration is still separate for IPv4 and IPv6 902 configured by capability as previously. 904 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 905 impact both IPv4 and IPv6 as previously. 907 If the interface is in the Admin Down state, the IPv6 peer would go 908 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 910 Changes resulting from a single IPv6 transport peer carrying IPv4 911 NLRI and IPv6 NLRI below: 913 Physical interface is no longer dual stacked. 915 Any change in IPv6 address or DAD state will impact both IPv4 and 916 IPv6 NLRI exchange. 918 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 919 session is now tied to the transport, which now is only IPv6 address 920 family. 922 Both IPv4 and IPv6 peer now exists under the IPv6 address family 923 configuration. 925 Fate sharing of IPv4 and IPv6 address family from a logical 926 perspective now carried over a single physical IPv6 peer. 928 From an operations perspective, prior to elimination of IPv4 peers, 929 an audit is recommended to identify and IPv4 and IPv6 peering 930 incongruencies that may exist and to rectify them. No operational 931 impacts or issues are expected with this change. 933 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 934 both IPv4 and IPv6 prefixes have the same label in no table lookup 935 pop-n-forward mode should be taken into consideration. 937 7. Vendor Implementations and Operator Deployments 939 Vendor implementations are with Cisco, Juniper, Nokia, Arista and 940 Huawei 942 8. IANA Considerations 944 There are not any IANA considerations. 946 9. Security Considerations 948 The extensions defined in this document allow BGP to propagate 949 reachability information about IPv4 prefixes over an MPLS or SR 950 IPv6-Only core network. As such, no new security issues are raised 951 beyond those that already exist in BGP-4 and the use of MP-BGP for 952 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 953 configuration. The security features of BGP and corresponding 954 security policy defined in the ISP domain are applicable. For the 955 inter-AS distribution of IPv6 routes according to case (a) of 956 Section 4 of this document, no new security issues are raised beyond 957 those that already exist in the use of eBGP for IPv6 [RFC2545]. 959 10. Acknowledgments 961 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 962 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 963 review comments. 965 11. Contributors 967 The following people contributed substantive text to this document: 969 Mohana Sundari 970 EMail: mohanas@juniper.net 972 12. References 974 12.1. Normative References 976 [I-D.ietf-bess-ipv6-only-pe-design] 977 Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang, 978 Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for 979 IPv4-NLRI with IPv6-NH", Work in Progress, Internet-Draft, 980 draft-ietf-bess-ipv6-only-pe-design-00, 20 September 2021, 981 . 984 [I-D.nalawade-kapoor-tunnel-safi] 985 Nalawade, G., "BGP Tunnel SAFI", Work in Progress, 986 Internet-Draft, draft-nalawade-kapoor-tunnel-safi-05, 29 987 June 2006, . 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, 992 DOI 10.17487/RFC2119, March 1997, 993 . 995 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 996 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 997 DOI 10.17487/RFC2545, March 1999, 998 . 1000 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1001 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1002 2006, . 1004 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1005 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1006 2006, . 1008 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1009 "Multiprotocol Extensions for BGP-4", RFC 4760, 1010 DOI 10.17487/RFC4760, January 2007, 1011 . 1013 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1014 LAN Service (VPLS) Using BGP for Auto-Discovery and 1015 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1016 . 1018 [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based 1019 Auto-Discovery for Layer-1 VPNs", RFC 5195, 1020 DOI 10.17487/RFC5195, June 2008, 1021 . 1023 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 1024 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 1025 2009, . 1027 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 1028 Transit Solution Using IP Encapsulation and MP-BGP 1029 Extensions", RFC 5747, DOI 10.17487/RFC5747, March 2010, 1030 . 1032 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 1033 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 1034 RFC 6037, DOI 10.17487/RFC6037, October 2010, 1035 . 1037 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 1038 C. Kodeboniya, "Multicast in Virtual Private LAN Service 1039 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 1040 . 1042 [RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., 1043 "Dynamic Placement of Multi-Segment Pseudowires", 1044 RFC 7267, DOI 10.17487/RFC7267, June 2014, 1045 . 1047 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1048 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1049 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1050 2015, . 1052 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1053 S. Ray, "North-Bound Distribution of Link-State and 1054 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1055 DOI 10.17487/RFC7752, March 2016, 1056 . 1058 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1059 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1060 May 2017, . 1062 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1063 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1064 . 1066 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 1067 Bacher, "Dissemination of Flow Specification Rules", 1068 RFC 8955, DOI 10.17487/RFC8955, December 2020, 1069 . 1071 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1072 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1073 DOI 10.17487/RFC9012, April 2021, 1074 . 1076 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1077 Jalil, "BGP Control Plane for the Network Service Header 1078 in Service Function Chaining", RFC 9015, 1079 DOI 10.17487/RFC9015, June 2021, 1080 . 1082 12.2. Informative References 1084 [I-D.ietf-idr-dynamic-cap] 1085 Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", 1086 Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- 1087 cap-16, 21 October 2021, . 1090 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1091 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1092 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1093 . 1095 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1096 R., Patel, K., and J. Guichard, "Constrained Route 1097 Distribution for Border Gateway Protocol/MultiProtocol 1098 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1099 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1100 November 2006, . 1102 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1103 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1104 Provider Edge Routers (6PE)", RFC 4798, 1105 DOI 10.17487/RFC4798, February 2007, 1106 . 1108 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 1109 Durand, Ed., "Softwire Problem Statement", RFC 4925, 1110 DOI 10.17487/RFC4925, July 2007, 1111 . 1113 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 1114 Layer Reachability Information with an IPv6 Next Hop", 1115 RFC 5549, DOI 10.17487/RFC5549, May 2009, 1116 . 1118 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1119 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 1120 . 1122 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1123 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1124 Virtual Private Networks (L2VPNs)", RFC 6074, 1125 DOI 10.17487/RFC6074, January 2011, 1126 . 1128 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1129 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1130 2012, . 1132 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1133 Encodings and Procedures for Multicast in MPLS/BGP IP 1134 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1135 . 1137 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1138 Writing an IANA Considerations Section in RFCs", BCP 26, 1139 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1140 . 1142 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 1143 Patel, "Advertising IPv4 Network Layer Reachability 1144 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 1145 DOI 10.17487/RFC8950, November 2020, 1146 . 1148 Authors' Addresses 1150 Gyan Mishra 1151 Verizon Inc. 1152 Email: gyan.s.mishra@verizon.com 1154 Mankamana Mishra 1155 Cisco Systems 1156 821 Alder Drive, 1157 MILPITAS 1158 Email: mankamis@cisco.com 1160 Jeff Tantsura 1161 Microsoft, Inc. 1162 Email: jefftant.ietf@gmail.com 1164 Sudha Madhavi 1165 Juniper Networks, Inc. 1166 Email: smadhavi@juniper.net 1168 Qing Yang 1169 Arista Networks 1170 Email: qyang@arista.com 1172 Adam Simpson 1173 Nokia 1174 Email: adam.1.simpson@nokia.com 1175 Shuanglong Chen 1176 Huawei Technologies 1177 Email: chenshuanglong@huawei.com