idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2019) is 1877 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: 'I-D.ietf-6man-segment-routing-header' is defined on line 312, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track C. Lenart 5 Expires: September 7, 2019 Verizon 6 G. Presbury 7 Hughes Network Systems 8 G. Chen 9 Baidu 10 Y. Zhu 11 China Telecom 12 March 6, 2019 14 The IPv6 Virtual Private Network (VPN) Context Information Option 15 draft-bonica-6man-vpn-dest-opt-03 17 Abstract 19 This document defines a new IPv6 Destination Option that can be used 20 to encode Virtual Private Network (VPN) context information. It is 21 applicable when VPN payload is transported over IPv6. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 7, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. VPN Context Information . . . . . . . . . . . . . . . . . . . 4 60 4. The VPN Context Information Option . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Virtual Private Network (VPN) technologies allow network providers to 72 emulate private networks with shared infrastructure. For example, 73 assume that a red sites and blue sites connect to a provider network. 74 The provider network facilitates communication among red sites and 75 facilitates communication among blue sites. However, it prevents 76 communication between red sites and blue sites. 78 The IETF has standardized many VPN technologies, including: 80 o Layer 2 VPN (L2VPN) [RFC6624]. 82 o Layer 3 VPN (L3VPN) [RFC4364]. 84 o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. 86 o Ethernet VPN (EVPN) [RFC7432]. 88 o Pseudowires [RFC8077]. 90 The above-mentioned technologies include the following components: 92 o Customer Edge (CE) devices. 94 o Provider Edge (PE) devices. 96 o Routing Instances. 98 o VPN context information. 100 o Transport tunnels. 102 CE devices participate in closed communities called VPNs. CEs that 103 participate in one VPN can communicate with one another but cannot 104 communicate with CEs that participate in another VPN. 106 CE devices connect to provider networks through PE devices. Each PE 107 maintains one Routing Instance for each VPN that it supports. A 108 Routing Instance is a VPN specific Forwarding Information Base (FIB). 109 In EVPN, Routing Instances are called Ethernet Virtual Instances 110 (EVI). 112 Assume that one CE sends a packet through a provider network to 113 another CE. The packet enters the provider network through an 114 ingress PE and leaves the provider network through an egress PE. The 115 packet may traverse one or more intermediate nodes on route from PE 116 to PE. 118 When the ingress PE receives the packet, it: 120 o Identifies the Routing Instance that supports the originating CE's 121 VPN. 123 o Searches that Routing Instance for the packet's destination. 125 If the search fails, the ingress PE discards the packet. If the 126 search succeeds, it yields the following: 128 o VPN context information. 130 o The egress PE's IP address. 132 The ingress PE prepends VPN context information and a transport 133 header to the packet, in that order. It then forwards the packet 134 through a transport tunnel to the egress PE. 136 The egress PE removes the transport header, if it has not already 137 been removed by an upstream device. It then examines and removes the 138 VPN context information. Finally, it uses the VPN context 139 information to forward the packet to its destination (i.e., a 140 directly connected CE). 142 In the above-mentioned VPN technologies, the ingress PE encodes VPN 143 context information in a Multiprotocol Label Switching (MPLS) 144 [RFC3031] label. Depending upon the transport tunnel type, the 145 transport header can be: 147 o A MPLS label or label stack. 149 o An IPv4 [RFC0791] header. 151 o An IPv6 [RFC8200] header. 153 o A Generic Routing Encapsulation (GRE) [RFC2784] header 154 encapsulated in IPv4 or IPv6. 156 Some PE devices cannot process MPLS headers. While these devices 157 have several alternatives to MPLS-based transport tunnels, they 158 require an alternative to MPLS-based encoding of VPN context 159 information. This document defines a new IPv6 Destination Option 160 that can be used to encode VPN context information. It is applicable 161 when VPN payload is transported over IPv6. 163 2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 3. VPN Context Information 173 VPN context information specifies a forwarding procedure to be 174 executed by the egress PE. However, VPN context information values 175 are not globally mapped to forwarding procedures. Each egress PE 176 maps each forwarding procedure that it supports to a VPN context 177 information value. Therefore, VPN context information values are 178 locally scoped to the egress PE. 180 PE devices can acquire VPN Context Information: 182 o From one another, using a distributed, control plane protocol 183 (e.g., BGP [RFC4271] [RFC4760]) 185 o From a controller. 187 The mechanisms by which PE devices acquire VPN Context Information 188 are beyond the scope of this document. 190 4. The VPN Context Information Option 191 0 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Option Type | Opt Data Len | VPN Context Information ... 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 197 Figure 1 199 Figure 1 depicts the VPN Context Information Option. 201 Option fields are as follows: 203 o Option Type - VPN Context Information option. Value TBD by IANA. 204 See Notes below. 206 o Opt Data Len - Length of Option Data, measured in bytes. 208 o VPN Context Information - Specifies a forwarding procedure to be 209 executed by the egress PE. 211 The VPN Context Information Option MAY appear in a Destination 212 Options header that precedes an upper-layer header. It MUST NOT 213 appear in a Hop-by-hop Options header and SHOULD NOT appear in a 214 Destination Options header that precedes a Routing header. If it 215 appears in a Hop-by-hop Options header, the processing node will 216 discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, 217 Code 2, message to the packet's Source Address, pointing to the 218 Option Type. If it appears in a Destination Options header that 219 precedes a Routing header, the processing node will attempt to 220 process the option, because it has not yet encountered the Routing 221 header. 223 If the VPN Context Information appears in a Destination Options 224 header, it SHOULD be the final option listed in the header. Because 225 the VPN Context Information Option causes the packet to be 226 decapsulated and forwarded, all options listed after the VPN Context 227 Information Option will be ignored. 229 NOTE 1: The highest-order two bits of the Option Type (i.e., the 230 "act" bits) are 10. These bits specify the action taken by a 231 destination node that does not recognize VPN Context Information 232 option. The required action is to discard the packet and, regardless 233 of whether or not the packet's Destination Address was a multicast 234 address, send an ICMPv6 Parameter Problem, Code 2, message to the 235 packet's Source Address, pointing to the unrecognized Option Type. 237 NOTE 2: The third highest-order bit of the Option Type (i.e., the 238 "chg" bit) is 0. This indicates that Option Data cannot be modified 239 along the path between the packet's source and its destination. 241 5. Security Considerations 243 A VPN can be deployed: 245 o In a walled-garden environment. 247 o In an over-the-top environment. 249 In a walled-garden environment, all PE devices and all devices that 250 connect PEs to one another reside in the same security domain. 251 Therefore, there is no risk that a packet might be modified as it 252 travels from PE to PE. 254 In an over-the-top environment, all PE devices reside in one security 255 domain while devices that connect PEs to one another can reside in a 256 different security domain. In that case, there is significant risk 257 that a packet might be modified as it travels from PE to PE. 259 Therefore, the VPN Context Information option MUST be authenticated 260 when used in over-the-top environments. In this scenario, an IPv6 261 Encapsulating Security Payload (ESP) [RFC4303] MUST proceed the 262 Destination Options header that carries the VPN Context Information 263 option. The ESP integrity service MUST be enabled. 265 6. IANA Considerations 267 IANA is requested to allocate a codepoint from the Destination 268 Options and Hop-by-hop Options registry 269 (https://www.iana.org/assignments/ipv6-parameters/ 270 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "VPN 271 Context Information". The "act" bits are 10 and the "chg" bit is 0. 273 7. Acknowledgements 275 Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert and John Leddy 276 for their comments. 278 8. References 280 8.1. Normative References 282 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 283 DOI 10.17487/RFC0791, September 1981, 284 . 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 292 RFC 4303, DOI 10.17487/RFC4303, December 2005, 293 . 295 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 296 Control Message Protocol (ICMPv6) for the Internet 297 Protocol Version 6 (IPv6) Specification", STD 89, 298 RFC 4443, DOI 10.17487/RFC4443, March 2006, 299 . 301 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 302 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 303 May 2017, . 305 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 306 (IPv6) Specification", STD 86, RFC 8200, 307 DOI 10.17487/RFC8200, July 2017, 308 . 310 8.2. Informative References 312 [I-D.ietf-6man-segment-routing-header] 313 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 314 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 315 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 316 progress), February 2019. 318 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 319 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 320 DOI 10.17487/RFC2784, March 2000, 321 . 323 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 324 Label Switching Architecture", RFC 3031, 325 DOI 10.17487/RFC3031, January 2001, 326 . 328 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 329 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 330 DOI 10.17487/RFC4271, January 2006, 331 . 333 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 334 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 335 2006, . 337 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 338 "Multiprotocol Extensions for BGP-4", RFC 4760, 339 DOI 10.17487/RFC4760, January 2007, 340 . 342 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 343 LAN Service (VPLS) Using BGP for Auto-Discovery and 344 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 345 . 347 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 348 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 349 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 350 . 352 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 353 Virtual Private Networks Using BGP for Auto-Discovery and 354 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 355 . 357 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 358 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 359 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 360 2015, . 362 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 363 Maintenance Using the Label Distribution Protocol (LDP)", 364 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 365 . 367 Authors' Addresses 369 Ron Bonica 370 Juniper Networks 371 2251 Corporate Park Drive 372 Herndon, Virginia 20171 373 USA 375 Email: rbonica@juniper.net 376 Chris Lenart 377 Verizon 378 22001 Loudoun County Parkway 379 Ashburn, Virginia 20147 380 USA 382 Email: chris.lenart@verizon.com 384 Greg Presbury 385 Hughes Network Systems 386 11717 Exploration Lane 387 Germantown, Maryland 20876 388 USA 390 Email: greg.presbury@hughes.com 392 Gang Chen 393 Baidu 394 Baidu Technology Park Building No.2, No.10 Xibeiwang East Road Haidian District 395 Beijing 100193 396 P.R. China 398 Email: phdgang@gmail.com 400 Yongqing Zhu 401 China Telecom 402 109 West Zhongshan Ave, Tianhe District 403 Guangzhou 404 P.R. China 406 Email: zhuyq.gd@chinatelecom.cn