idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-08.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 (November 20, 2019) is 1612 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: May 23, 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 China Telecom 18 Y. Zhou 19 ByteDance 20 November 20, 2019 22 The Per-Path Service Instruction (PPSI) Option 23 draft-bonica-6man-vpn-dest-opt-08 25 Abstract 27 SRm6 encodes Per-Path Service Instructions (PPSI) in a new IPv6 28 option, called the PPSI Option. This document describes the PPSI 29 Option. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 23, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. PPSI Identifiers . . . . . . . . . . . . . . . . . . . . . . 3 68 4. The PPSI Option . . . . . . . . . . . . . . . . . . . . . . . 3 69 5. Destination Option Header Considerations . . . . . . . . . . 4 70 6. ICMPv6 Considerations . . . . . . . . . . . . . . . . . . . . 4 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 10.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. ICMPv6 Considerations 180 SRm6 implementations MUST comply with the ICMPv6 processing rules 181 specified in Section 2.4 of [RFC4443]. For example: 183 o An SRm6 implementation MUST NOT originate an ICMPv6 error message 184 in response to another ICMPv6 error message. 186 o An SRm6 implementation MUST rate limit the ICMPv6 messages that it 187 originates. 189 7. Security Considerations 191 SRm6 domains MUST NOT span security domains. In order to enforce 192 this requirement, security domain edge routers MUST do one of the 193 following: 195 o Discard all inbound SRm6 packets 197 o Authenticate [RFC4302] [RFC4303] all inbound SRm6 packets 199 8. IANA Considerations 201 IANA is requested to allocate a code point from the Destination 202 Options and Hop-by-hop Options registry 203 (https://www.iana.org/assignments/ipv6-parameters/ 204 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 205 "Per-Path Service Instruction Option". The "act" bits are 10 and the 206 "chg" bit is 0. The suggested value is 144. 208 IANA is also requested to allocate a code point for Ethernet from the 209 Assigned Internet Protocol Numbers registry 210 (https://www.iana.org/assignments/protocol-numbers/protocol- 211 numbers.xhtml). The suggested value is 143. 213 9. Acknowledgements 215 Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert, John Leddy and 216 Tony Li for their comments. 218 10. References 220 10.1. Normative References 222 [I-D.bonica-spring-srv6-plus] 223 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 224 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 225 "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica- 226 spring-srv6-plus-06 (work in progress), October 2019. 228 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 229 DOI 10.17487/RFC0791, September 1981, 230 . 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 238 DOI 10.17487/RFC4302, December 2005, 239 . 241 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 242 RFC 4303, DOI 10.17487/RFC4303, December 2005, 243 . 245 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 246 Control Message Protocol (ICMPv6) for the Internet 247 Protocol Version 6 (IPv6) Specification", STD 89, 248 RFC 4443, DOI 10.17487/RFC4443, March 2006, 249 . 251 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 252 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 253 May 2017, . 255 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 256 (IPv6) Specification", STD 86, RFC 8200, 257 DOI 10.17487/RFC8200, July 2017, 258 . 260 10.2. Informative References 262 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 263 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 264 DOI 10.17487/RFC2784, March 2000, 265 . 267 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 268 Label Switching Architecture", RFC 3031, 269 DOI 10.17487/RFC3031, January 2001, 270 . 272 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 273 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 274 2006, . 276 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 277 LAN Service (VPLS) Using BGP for Auto-Discovery and 278 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 279 . 281 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 282 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 283 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 284 . 286 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 287 Virtual Private Networks Using BGP for Auto-Discovery and 288 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 289 . 291 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 292 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 293 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 294 2015, . 296 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 297 Maintenance Using the Label Distribution Protocol (LDP)", 298 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 299 . 301 Appendix A. Virtual Private Networks (VPN) 303 Virtual Private Network (VPN) technologies allow network providers to 304 emulate private networks with shared infrastructure. For example, 305 assume that red sites and blue sites connect to a provider network. 306 The provider network facilitates communication among red sites and 307 facilitates communication among blue sites. However, it prevents 308 communication between red sites and blue sites. 310 The IETF has standardized many VPN technologies, including: 312 o Layer 2 VPN (L2VPN) [RFC6624]. 314 o Layer 3 VPN (L3VPN) [RFC4364]. 316 o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. 318 o Ethernet VPN (EVPN) [RFC7432]. 320 o Pseudowires [RFC8077]. 322 The above-mentioned technologies include the following components: 324 o Customer Edge (CE) devices. 326 o Provider Edge (PE) devices. 328 o Routing Instances. 330 o Service Instructions. 332 o Service Instruction Identifiers. 334 o Transport tunnels. 336 CE devices participate in closed communities called VPNs. CEs that 337 participate in one VPN can communicate with one another but cannot 338 communicate with CEs that participate in another VPN. 340 CE devices connect to provider networks through PE devices. Each PE 341 maintains one Routing Instance for each VPN that it supports. A 342 Routing Instance is a VPN specific Forwarding Information Base (FIB). 343 In EVPN, Routing Instances are called Ethernet Virtual Instances 344 (EVI). 346 Assume that one CE sends a packet through a provider network to 347 another CE. The packet enters the provider network through an 348 ingress PE and leaves the provider network through an egress PE. The 349 packet may traverse one or more intermediate nodes on route from PE 350 to PE. 352 When the ingress PE receives the packet, it: 354 o Identifies the Routing Instance that supports the originating CE's 355 VPN. 357 o Searches that Routing Instance for the packet's destination. 359 If the search fails, the ingress PE discards the packet. If the 360 search succeeds, it yields the following: 362 o A Service Instruction Identifier. 364 o The egress PE's IP address. 366 The ingress PE prepends the Service Instruction Identifier and a 367 transport header to the packet, in that order. It then forwards the 368 packet through a transport tunnel to the egress PE. 370 The egress PE removes the transport header, if it has not already 371 been removed by an upstream device. It then examines and removes the 372 Service Instruction Identifier. Finally, it executes a service 373 instruction that is associated with the Service Instruction 374 Identifier. The service instruction causes the egress PE to forward 375 the packet to its destination (i.e., a directly connected CE). 377 In the above-mentioned VPN technologies, the ingress PE encodes 378 Service Instruction Identifiers in Multiprotocol Label Switching 379 (MPLS) [RFC3031] labels. Depending upon the transport tunnel type, 380 the transport header can be: 382 o A MPLS label or label stack. 384 o An IPv4 [RFC0791] header. 386 o An IPv6 [RFC8200] header. 388 o A Generic Routing Encapsulation (GRE) [RFC2784] header 389 encapsulated in IPv4 or IPv6. 391 Some PE devices cannot process MPLS headers. While these devices 392 have several alternatives to MPLS-based transport tunnels, they 393 require an alternative to MPLS-based encoding of Service Instruction 394 Identifiers. The PPSI Option can be used to encode Service 395 Instruction Identifiers . It is applicable when VPN payload is 396 transported over IPv6. 398 Authors' Addresses 400 Ron Bonica 401 Juniper Networks 402 2251 Corporate Park Drive 403 Herndon, Virginia 20171 404 USA 406 Email: rbonica@juniper.net 408 Yuji Kamite 409 NTT Communications Corporation 410 3-4-1 Shibaura, Minato-ku 411 Tokyo 108-8118 412 Japan 414 Email: y.kamite@ntt.com 416 Luay Jalil 417 Verizon 418 Richardson, Texas 419 USA 421 Email: luay.jalil@one.verizon.com 422 Chris Lenart 423 Verizon 424 22001 Loudoun County Parkway 425 Ashburn, Virginia 20147 426 USA 428 Email: chris.lenart@verizon.com 430 Ning So 431 Reliance Jio 432 3010 Gaylord PKWY, Suite 150 433 Frisco, Texas 75034 434 USA 436 Email: Ning.So@ril.com 438 Fengman Xu 439 Reliance Jio 440 3010 Gaylord PKWY, Suite 150 441 Frisco, Texas 75034 442 USA 444 Email: Fengman.Xu@ril.com 446 Greg Presbury 447 Hughes Network Systems 448 11717 Exploration Lane 449 Germantown, Maryland 20876 450 USA 452 Email: greg.presbury@hughes.com 454 Gang Chen 455 Baidu 456 No.10 Xibeiwang East Road Haidian District 457 Beijing 100193 458 P.R. China 460 Email: phdgang@gmail.com 461 Yongqing Zhu 462 China Telecom 463 109 West Zhongshan Ave, Tianhe District 464 Guangzhou 465 P.R. China 467 Email: zhuyq.gd@chinatelecom.cn 469 Yifeng Zhou 470 ByteDance 471 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian 472 District 473 Beijing 100000 474 P.R. China 476 Email: yifeng.zhou@bytedance.com