idnits 2.17.1 draft-bonica-6man-seg-end-opt-02.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 9, 2019) is 1847 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: 1 error (**), 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 J. Halpern 5 Expires: September 10, 2019 Ericsson 6 X. Xu 7 Alibaba Inc 8 G. Chen 9 Baidu 10 Y. Zhu 11 G. Yang 12 China Telecom 13 March 9, 2019 15 The IPv6 Segment Endpoint Option 16 draft-bonica-6man-seg-end-opt-02 18 Abstract 20 This document defines the IPv6 Segment Endpoint Option. Source nodes 21 can use this option to convey internet-layer information to selected 22 segment endpoints along a packet's delivery path. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Option Processing . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 IPv6 [RFC8200] options convey optional internet-layer information to 75 selected nodes along a packets delivery path. IPv6 options can be 76 encoded as follows: 78 o In a Hop-by-hop Options header. 80 o In a Destination Options header that precedes a Routing header. 82 o In a Destination Options header that precedes an upper-layer 83 header. 85 If an option is encoded in a Hop-by-hop Options header, it conveys 86 information to every node along the packet's delivery path, including 87 the destination node. (See NOTE 1). If an option is encoded in a 88 Destination Options header that precedes a Routing header, it conveys 89 information to every segment endpoint along the packet's delivery 90 path, including the destination node. If an option is encoded in a 91 Destination Options header that precedes an upper-layer header, it 92 conveys information to the destination node only. (See Section 4.3.4 93 of [RFC8200] ) 95 This document defines the IPv6 Segment Endpoint option. The IPv6 96 Segment Endpoint option provides a mechanism through which a source 97 node can convey optional internet-layer information to selected 98 segment endpoints. For example, assume that a packet's delivery path 99 contains three segments. The source node can use the Segment 100 Endpoint option to convey one piece of information to the first 101 segment endpoint, another piece if information to the second segment 102 endpoint, and no information to the third segment endpoint. 104 NOTE 1: As per IPv6 [RFC8200], it is now expected that nodes along a 105 packet's delivery path only examine and process the Hop-by-Hop 106 Options header if explicitly configured to do so. 108 2. Terminology 110 o Segment Endpoint - A packet that contains a Routing header 111 traverses multiple segments. Each segment has an endpoint. The 112 first destination that appears in the IPv6 Destination Address 113 identifies the first segment endpoint. Subsequent destinations 114 listed in the Routing header identify subsequent segment 115 endpoints. A packet that does not contain a Routing Header 116 traverses exactly one segment had has exactly one segment endpoint 117 (i.e., the packet's ultimate destination). 119 3. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 4. Option Format 129 The Segment Endpoint option MAY appear in a Destination Options 130 header, regardless of whether that Destination Options header 131 precedes a Routing header or an upper-layer header. The Segment 132 Endpoint option MUST NOT appear in a Hop-by-hop Options header. 134 Figure 1 depicts the Segment Endpoint option. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Option Type | Opt Data Len | Option Data 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 142 Figure 1: Segment Endpoint Option 144 o Option Type - Segment Endpoint option. Value TBD by IANA. See 145 NOTE 1 and NOTE 2, below. 147 o Opt Data Len - 8-bit unsigned integer. Length of the Option Data 148 field, in octets. 150 o Option Data - See Figure 2. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Segments Left | Containers | Container List 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 158 Figure 2: Option Data 160 Option Data contains the following fields: 162 o Segments Left - 8-bit unsigned integer. Number of route segments 163 remaining. If the packet also contains a Routing header, this 164 value MUST be identical to the value of the Segments Left field in 165 the Routing heder. See Section 5. 167 o Containers - 8-bit unsigned integer. The number of containers in 168 the Container List. 170 o Container List - A list of Containers (Figure 3). 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Segment ID | IPv6 Option 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 178 Figure 3: A Container 180 Each element of Container List contains the following fields: 182 o Segment ID - 8-bit unsigned integer. Identifies the segment that 183 should process the IPv6 Option contained by this container. See 184 Section 5. 186 o IPv6 Option - Any IPv6 Option [IPv6-OPT] except for the Segment 187 Endpoint Option. 189 Within a Container list, Containers MUST be sorted in descending 190 order by Segment ID. 192 NOTE 1: The highest-order two bits of the Option Type (i.e., the 193 "act" bits) are 10. These bits specify the action taken by a 194 destination node that does not recognize Segment Endpoint option. 195 The required action is to discard the packet and send an ICMPv6 196 [RFC4443] Parameter Problem, Code 2, message to the packet's Source 197 Address, pointing to the Segment Endpoint option Type. 199 NOTE 2: The third highest-order bit of the Option Type (i.e., the 200 "chg" bit) is 1. This indicates that Option Data can be modified 201 along the path between the packet's source and its destination. 203 5. Option Processing 205 If the option appears in a Hop-by-hop Options header, the processing 206 node discards the packet and sends an ICMPv6 [RFC4443] Parameter 207 Problem, Code 2, message to the packet's Source Address, pointing to 208 the Segment Endpoint option Type. 210 If the option appears in a Destination Options header, the processing 211 node locates the following fields in Option Data: 213 o Segments Left. 215 o Containers. 217 o Container List. 219 It then processes each member of the Container List as follows: 221 o Locate the Segment ID and IPv6 Option field in the container. 223 o If Segments Left less than the Segment ID, skip over the 224 container. 226 o If Segments Left equals the Segment ID, and the IPv6 Option is a 227 Segment Endpoint option, skip over the container. 229 o If Segments Left equals the Segment ID, and the IPv6 Option is not 230 a Segment Endpoint option, process the IPv6 Option as per 231 [RFC8200]. 233 o If Segments Left is greater than Segment ID, skip over all 234 remaining members of the Container List. 236 Finally, decrement the Segment ID field and process the next option 237 or header. 239 6. Mutability 241 The Segments Left field of the Segment Endpoint option is mutable. 242 Intermediate nodes MAY change the value of this field. 244 All other fields in the Segment Endpoint option are immutable. 245 Intermediate nodes MUST NOT change the values of these fields. 247 7. Security Considerations 249 The Segment Endpoint Option shares many security concerns with IPv6 250 routing headers. In particular, any boundary filtering protecting a 251 domain from external routing headers should also protect against 252 external Segment Endpoint Options being processed inside a domain. 253 This occurs naturally if encapsulation is used to add routing headers 254 to a packet. If external routing headers are allowed, then 255 protections must also include ensuring that any provided Segment 256 Endpoint option before the routing header is properly protect, e.g. 257 with an IPSEC AH header or other suitable means. 259 As with Routing headers, the security assumption within a domain is 260 that the domain is trusted to provide, and to avoid improperly 261 modifying, the Segment Endpoint Option. 263 8. IANA Considerations 265 IANA is requested to allocate a codepoint from the Destination 266 Options and Hop-by-hop Options registry 267 (https://www.iana.org/assignments/ipv6-parameters/ 268 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 269 "Segment Endpoint". The "act" bits are 10 and the "chg" bit is 1. 271 9. Acknowledgements 273 Thanks to TBD for their careful review of this document. 275 10. References 277 10.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 285 Control Message Protocol (ICMPv6) for the Internet 286 Protocol Version 6 (IPv6) Specification", STD 89, 287 RFC 4443, DOI 10.17487/RFC4443, March 2006, 288 . 290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 292 May 2017, . 294 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 295 (IPv6) Specification", STD 86, RFC 8200, 296 DOI 10.17487/RFC8200, July 2017, 297 . 299 10.2. Informative References 301 [IPv6-OPT] 302 IANA, ""Destination Options and Hop-by-Hop Options"", 303 August 1987, . 306 Authors' Addresses 308 Ron Bonica 309 Juniper Networks 310 2251 Corporate Park Drive 311 Herndon, Virginia 20171 312 USA 314 Email: rbonica@juniper.net 316 Joel Halpern 317 Ericsson 318 P. O. Box 6049 319 Leesburg, Virginia 20178 320 USA 322 Email: joel.halpern@ericsson.com 323 Xiaohu Xu 324 Alibaba Inc 325 Alibaba Park 326 Hangzhou 327 P.R. China 329 Email: xiaohu.xxh@alibaba-inc.com 331 Gang Chen 332 Baidu 333 Baidu Technology Park Building No.2, No.10 Xibeiwang East Road Haidian District 334 Beijing 100193 335 P.R. China 337 Email: phdgang@gmail.com 339 Yongqing Zhu 340 China Telecom 341 109 West Zhongshan Ave, Tianhe District 342 Guangzhou 343 P.R. China 345 Email: zhuyq.gd@chinatelecom.cn 347 Guangming Yang 348 China Telecom 349 109 West Zhongshan Ave, Tianhe District 350 Guangzhou 351 P.R. China 353 Email: yanggm.gd@chinatelecom.cn