idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2019) is 1655 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) == Outdated reference: A later version (-06) exists of draft-bonica-spring-srv6-plus-05 Summary: 0 errors (**), 0 flaws (~~), 2 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 Y. Kamite 5 Expires: April 17, 2020 NTT Communications Corporation 6 L. Jalil 7 C. Lenart 8 Verizon 9 N. So 10 F. Xu 11 Reliance Jio 12 G. Presbury 13 Hughes Network Systems 14 G. Chen 15 Baidu 16 Y. Zhu 17 G. Yang 18 China Telecom 19 Y. Zhou 20 ByteDance 21 October 15, 2019 23 The Per-Path Service Instruction (PPSI) Option 24 draft-bonica-6man-vpn-dest-opt-07 26 Abstract 28 SRm6 encodes Per-Path Service Instructions (PPSI) in a new IPv6 29 option, called the PPSI Option. This document describes the PPSI 30 Option. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 17, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 3. PPSI Identifiers . . . . . . . . . . . . . . . . . . . . . . 3 69 4. The PPSI Option . . . . . . . . . . . . . . . . . . . . . . . 3 70 5. Destination Option Header Considerations . . . . . . . . . . 4 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 9.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Appendix A. Virtual Private Networks (VPN) . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 An SRm6 [I-D.bonica-spring-srv6-plus] path provides unidirectional 83 connectivity from its ingress node to its egress node. While an SRm6 84 path can follow the least cost path from ingress to egress, it can 85 also follow any other path. 87 SRm6 paths are encoded as IPv6 [RFC8200] header chains. When an SRm6 88 ingress node receives a packet, it encapsulates the packet in an IPv6 89 header chain. It then forwards the encapsulated packet to the path's 90 egress node. When the egress node receives the packet, it processes 91 the SRm6 payload (i.e., the original packet). 93 SRm6 paths are programmable. They support several instruction types, 94 including Per-Path Service Instructions (PPSI). PPSIs determine how 95 path egress nodes process SRm6 payloads. In the absence of a PPSI, 96 the egress node processes SRm6 payloads as described in [RFC8200]. 98 The following are examples of PPSIs: 100 o Remove any SRm6 encapsulation and forward the SRm6 payload through 101 a specified interface. 103 o Remove any SRm6 encapsulation and forward the SRm6 payload using a 104 specified routing table. 106 SRm6 encodes PPSIs in a new IPv6 option, called the PPSI Option. 107 This document describes the PPSI Option. 109 PPSIs can be used to support Virtual Private Networks (VPN). 110 Therefore, Appendix A of this document describes VPN technology and 111 how PPSIs can be used to support a VPN. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. PPSI Identifiers 123 PPSI Identifiers identify PPSIs. When a path egress node 124 instantiates a PPSI, it also allocates a PPSI Identifier and 125 associates the PPSI with the identifier. 127 PPSI Identifiers have node-local significance. This means that a 128 path egress node must assign a unique PPSI Identifier to each PPSI 129 that it instantiates. However, one path egress node can assign a 130 PPSI Identifier to an instruction that it instantiates, while another 131 path egress node can assign the same PPSI Identifier to a different 132 PPSI that it instantiates. 134 4. The PPSI Option 136 The PPSI Option contains the following fields: 138 o Option Type: 8-bit selector. PPSI option. Value TBD by IANA. 139 (Suggested value: 144). See Note below. 141 o Opt Data Len - 8-bit unsigned integer. Length of the option, in 142 octets, excluding the Option Type and Option Length fields. This 143 field MUST be set to 4. 145 o PPSI identifier - (32-bit selector). Identifies a PPSI. 147 The SRm6 PPSI option MAY appear in a Destination Options header that 148 precedes an upper-layer header. It MUST NOT appear in a Hop-by-hop 149 Options header or in a Destination Options header that precedes a 150 Routing header. 152 When the SRm6 PPSI option appears in a Destination Options header, it 153 MUST be the only option listed in the header. This is because the 154 PPSI defines all path egress node behaviors. 156 NOTE : The highest-order two bits of the Option Type (i.e., the "act" 157 bits) are 10. These bits specify the action taken by a destination 158 node that does not recognize the option. The required action is to 159 discard the packet and, regardless of whether or not the packet's 160 Destination Address was a multicast address, send an ICMPv6 [RFC4443] 161 Parameter Problem, Code 2, message to the packet's Source Address, 162 pointing to the unrecognized Option Type. 164 The third highest-order bit of the Option Type (i.e., the "chg" bit) 165 is 0. This indicates that Option Data cannot be modified along the 166 path between the packet's source and its destination. 168 5. Destination Option Header Considerations 170 As per [RFC8200], the Destination Options header includes a Next 171 Header field. The Next Header field identifies the header following 172 the Destination Options header. 174 SRm6 can carry Ethernet payload after a Destination option header. 175 Therefore, this document requests IANA to assign a protocol number 176 for Ethernet. (The suggested value is 143.) 178 6. Security Considerations 180 SRm6 domains MUST NOT span security domains. In order to enforce 181 this requirement, security domain edge routers MUST do one of the 182 following: 184 o Discard all inbound SRm6 packets 186 o Authenticate [RFC4302] [RFC4303] all inbound SRm6 packets 188 7. IANA Considerations 190 IANA is requested to allocate a code point from the Destination 191 Options and Hop-by-hop Options registry 192 (https://www.iana.org/assignments/ipv6-parameters/ 193 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 194 "Per-Path Service Instruction Option". The "act" bits are 10 and the 195 "chg" bit is 0. The suggested value is 144. 197 IANA is also requested to allocate a code point for Ethernet from the 198 Assigned Internet Protocol Numbers registry 199 (https://www.iana.org/assignments/protocol-numbers/protocol- 200 numbers.xhtml). The suggested value is 143. 202 8. Acknowledgements 204 Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert, John Leddy and 205 Tony Li for their comments. 207 9. References 209 9.1. Normative References 211 [I-D.bonica-spring-srv6-plus] 212 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 213 D., Halpern, J., Linkova, J., and G. Chen, "IPv6 Support 214 for Segment Routing: SRv6+", draft-bonica-spring- 215 srv6-plus-05 (work in progress), August 2019. 217 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 218 DOI 10.17487/RFC0791, September 1981, 219 . 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, 223 DOI 10.17487/RFC2119, March 1997, 224 . 226 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 227 DOI 10.17487/RFC4302, December 2005, 228 . 230 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 231 RFC 4303, DOI 10.17487/RFC4303, December 2005, 232 . 234 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 235 Control Message Protocol (ICMPv6) for the Internet 236 Protocol Version 6 (IPv6) Specification", STD 89, 237 RFC 4443, DOI 10.17487/RFC4443, March 2006, 238 . 240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 242 May 2017, . 244 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 245 (IPv6) Specification", STD 86, RFC 8200, 246 DOI 10.17487/RFC8200, July 2017, 247 . 249 9.2. Informative References 251 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 252 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 253 DOI 10.17487/RFC2784, March 2000, 254 . 256 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 257 Label Switching Architecture", RFC 3031, 258 DOI 10.17487/RFC3031, January 2001, 259 . 261 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 262 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 263 2006, . 265 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 266 LAN Service (VPLS) Using BGP for Auto-Discovery and 267 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 268 . 270 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 271 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 272 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 273 . 275 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 276 Virtual Private Networks Using BGP for Auto-Discovery and 277 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 278 . 280 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 281 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 282 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 283 2015, . 285 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 286 Maintenance Using the Label Distribution Protocol (LDP)", 287 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 288 . 290 Appendix A. Virtual Private Networks (VPN) 292 Virtual Private Network (VPN) technologies allow network providers to 293 emulate private networks with shared infrastructure. For example, 294 assume that red sites and blue sites connect to a provider network. 295 The provider network facilitates communication among red sites and 296 facilitates communication among blue sites. However, it prevents 297 communication between red sites and blue sites. 299 The IETF has standardized many VPN technologies, including: 301 o Layer 2 VPN (L2VPN) [RFC6624]. 303 o Layer 3 VPN (L3VPN) [RFC4364]. 305 o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. 307 o Ethernet VPN (EVPN) [RFC7432]. 309 o Pseudowires [RFC8077]. 311 The above-mentioned technologies include the following components: 313 o Customer Edge (CE) devices. 315 o Provider Edge (PE) devices. 317 o Routing Instances. 319 o Service Instructions. 321 o Service Instruction Identifiers. 323 o Transport tunnels. 325 CE devices participate in closed communities called VPNs. CEs that 326 participate in one VPN can communicate with one another but cannot 327 communicate with CEs that participate in another VPN. 329 CE devices connect to provider networks through PE devices. Each PE 330 maintains one Routing Instance for each VPN that it supports. A 331 Routing Instance is a VPN specific Forwarding Information Base (FIB). 333 In EVPN, Routing Instances are called Ethernet Virtual Instances 334 (EVI). 336 Assume that one CE sends a packet through a provider network to 337 another CE. The packet enters the provider network through an 338 ingress PE and leaves the provider network through an egress PE. The 339 packet may traverse one or more intermediate nodes on route from PE 340 to PE. 342 When the ingress PE receives the packet, it: 344 o Identifies the Routing Instance that supports the originating CE's 345 VPN. 347 o Searches that Routing Instance for the packet's destination. 349 If the search fails, the ingress PE discards the packet. If the 350 search succeeds, it yields the following: 352 o A Service Instruction Identifier. 354 o The egress PE's IP address. 356 The ingress PE prepends the Service Instruction Identifier and a 357 transport header to the packet, in that order. It then forwards the 358 packet through a transport tunnel to the egress PE. 360 The egress PE removes the transport header, if it has not already 361 been removed by an upstream device. It then examines and removes the 362 Service Instruction Identifier. Finally, it executes a service 363 instruction that is associated with the Service Instruction 364 Identifier. The service instruction causes the egress PE to forward 365 the packet to its destination (i.e., a directly connected CE). 367 In the above-mentioned VPN technologies, the ingress PE encodes 368 Service Instruction Identifiers in Multiprotocol Label Switching 369 (MPLS) [RFC3031] labels. Depending upon the transport tunnel type, 370 the transport header can be: 372 o A MPLS label or label stack. 374 o An IPv4 [RFC0791] header. 376 o An IPv6 [RFC8200] header. 378 o A Generic Routing Encapsulation (GRE) [RFC2784] header 379 encapsulated in IPv4 or IPv6. 381 Some PE devices cannot process MPLS headers. While these devices 382 have several alternatives to MPLS-based transport tunnels, they 383 require an alternative to MPLS-based encoding of Service Instruction 384 Identifiers. The PPSI Option can be used to encode Service 385 Instruction Identifiers . It is applicable when VPN payload is 386 transported over IPv6. 388 Authors' Addresses 390 Ron Bonica 391 Juniper Networks 392 2251 Corporate Park Drive 393 Herndon, Virginia 20171 394 USA 396 Email: rbonica@juniper.net 398 Yuji Kamite 399 NTT Communications Corporation 400 3-4-1 Shibaura, Minato-ku 401 Tokyo 108-8118 402 Japan 404 Email: y.kamite@ntt.com 406 Luay Jalil 407 Verizon 408 Richardson, Texas 409 USA 411 Email: luay.jalil@one.verizon.com 413 Chris Lenart 414 Verizon 415 22001 Loudoun County Parkway 416 Ashburn, Virginia 20147 417 USA 419 Email: chris.lenart@verizon.com 420 Ning So 421 Reliance Jio 422 3010 Gaylord PKWY, Suite 150 423 Frisco, Texas 75034 424 USA 426 Email: Ning.So@ril.com 428 Fengman Xu 429 Reliance Jio 430 3010 Gaylord PKWY, Suite 150 431 Frisco, Texas 75034 432 USA 434 Email: Fengman.Xu@ril.com 436 Greg Presbury 437 Hughes Network Systems 438 11717 Exploration Lane 439 Germantown, Maryland 20876 440 USA 442 Email: greg.presbury@hughes.com 444 Gang Chen 445 Baidu 446 No.10 Xibeiwang East Road Haidian District 447 Beijing 100193 448 P.R. China 450 Email: phdgang@gmail.com 452 Yongqing Zhu 453 China Telecom 454 109 West Zhongshan Ave, Tianhe District 455 Guangzhou 456 P.R. China 458 Email: zhuyq.gd@chinatelecom.cn 459 Guangming Yang 460 China Telecom 461 109 West Zhongshan Ave, Tianhe District 462 Guangzhou 463 P.R. China 465 Email: yanggm.gd@chinatelecom.cn 467 Yifeng Zhou 468 ByteDance 469 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 470 Beijing 100000 471 P.R. China 473 Email: yifeng.zhou@bytedance.com