idnits 2.17.1 draft-bonica-6man-ext-hdr-update-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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 February 2022) is 789 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 (~~), 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 Updates: RFC 8200 (if approved) T. Jinmei 5 Intended status: Standards Track Infoblox 6 Expires: 28 August 2022 24 February 2022 8 Inserting, Processing And Deleting IPv6 Extension Headers 9 draft-bonica-6man-ext-hdr-update-07 11 Abstract 13 This document provides guidance regarding the processing, insertion, 14 and deletion of IPv6 extension headers. It updates RFC 8200. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 28 August 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Updates To RFC 8200 . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Original Text . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2. Updated Text . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 58 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 In IPv6 [RFC8200] optional internet-layer information is encoded in 64 extension headers. As specified by [RFC8200], "extension headers 65 (except for the Hop-by-Hop Options header) are not processed, 66 inserted, or deleted by any node along a packet's delivery path, 67 until the packet reaches the node (or each of the set of nodes, in 68 the case of multicast) identified in the Destination Address field of 69 the IPv6 header". 71 The statement quoted above identifies nodes upon which extension 72 headers are not processed, inserted, or deleted. It does not imply 73 that extension headers can be processed, inserted, or deleted on any 74 other node along a packet's delivery path. 76 This document provides guidance regarding the processing, insertion, 77 and deletion of IPv6 extension headers. It clarifies the statement 78 quoted above and updates [RFC8200]. 80 2. Terminology 82 The following terms are used in this document: 84 * Source node - An IPv6 source node accepts data from an upper-layer 85 protocol, prepends an IPv6 header, and sends the resulting IPv6 86 packet to a destination node. 88 * Final destination node - An IPv6 final destination node receives 89 an IPv6 packet and delivers its payload to an upper-layer 90 protocol. 92 * Delivery path - A packet's delivery path is a series of nodes that 93 a packet traverses on route to its final destination. The 94 delivery path includes the final destination node. 96 * Segment - A segment is a series of links and nodes in a packet's 97 delivery path. An IPv6 Routing header steers packets from segment 98 to segment along the delivery path. If a packet contains a 99 Routing header, its delivery path can contain multiple segments. 100 If a packet does not contain a Routing header, its delivery path 101 contains only one segment. 103 * Segment egress node - A segment egress node terminates a segment. 104 When a packet arrives at a segment egress node, its IPv6 105 Destination Address identifies an interface that belongs to the 106 node. All final destination nodes are also segment egress nodes. 108 * Extension header processing - Each IPv6 extension header is 109 associated with a procedure. For example, the Fragment header is 110 associated with fragmentation and reassembly procedures. 111 Extension header processing is the reception of an extension 112 header and the execution of its associated procedure. 114 3. Updates To RFC 8200 116 The terms defined in Section 2 of this document should be added to 117 Section 2 of [RFC8200]. 119 Section 3.1 of this document quotes text from [RFC8200]. That text 120 should be replaced with the text contained by Section 3.2 of this 121 document. 123 3.1. Original Text 125 "Extension headers (except for the Hop-by-Hop Options header) are not 126 processed, inserted, or deleted by any node along a packet's delivery 127 path, until the packet reaches the node (or each of the set of nodes, 128 in the case of multicast) identified in the Destination Address field 129 of the IPv6 header. 131 The Hop-by-Hop Options header is not inserted or deleted, but may be 132 examined or processed by any node along a packet's delivery path, 133 until the packet reaches the node (or each of the set of nodes, in 134 the case of multicast) identified in the Destination Address field of 135 the IPv6 header. The Hop-by-Hop Options header, when present, must 136 immediately follow the IPv6 header. Its presence is indicated by the 137 value zero in the Next Header field of the IPv6 header." 139 3.2. Updated Text 141 Source nodes can send packets that include extension headers. 142 Extension headers are not inserted by subsequent nodes along a 143 packet's delivery path. 145 The Hop-by-Hop Options header, when present, must immediately follow 146 the IPv6 header. Its presence is indicated by the value zero in the 147 Next Header field of the IPv6 header. 149 The Hop-by-Hop Options header can be processed by any node in a 150 packet's delivery path. All remaining extension headers can be 151 processed at segment egress nodes only. While some extension headers 152 are processed at any segment egress node, others (e.g., the Fragment 153 header) can only be processed at the final destination node. 155 Except for the Routing header, extension headers cannot be deleted by 156 any node along a packet's delivery path. If the following conditions 157 are true, a Routing header can be deleted by any segment egress node: 159 * The Segments Left field in the routing header is equal to zero. 161 * The packet does not contain an Authentication header. 163 Extension headers can be inspected for various purposes (e.g., 164 firewall filtering) by any node along a packet's delivery path. 166 4. Motivation 168 The following are reasons why extension headers are not inserted by 169 nodes along a packet's delivery path: 171 * Nodes that execute Path MTU Discovery (PMTUD) [RFC8201] procedures 172 can send packets that are nearly as large as the Path MTU. Adding 173 an extension header to such a packet can cause MTU black holing. 175 * IPv6 Authentication Header [RFC4302] processing relies on the 176 immutability of the Payload Length field in the IPv6 header. When 177 a node along a packet's delivery path inserts an extension header, 178 it must also update the Payload Length field in the IPv6 header. 179 Therefore, it causes IPv6 Authentication Header processing to fail 180 on the final destination node. 182 * When a source node sends a packet to a final destination node, and 183 a node along the packet's delivery path inserts an extension 184 header, the final destination node will mistakenly attribute the 185 extension header to the source node. Attackers can leverage this 186 mistaken attribution. 188 The following are reasons why extension headers, except for the 189 Routing header, are not deleted by any node along a packet's delivery 190 path: 192 * IPv6 Authentication Header processing relies on the immutability 193 of the Payload Length field in the IPv6 header. When a node along 194 a packet's delivery path inserts an extension header, it must also 195 update the Payload Length field in the IPv6 header. Therefore, it 196 causes IPv6 Authentication Header processing to fail on the final 197 destination node. 199 * When a source node sends a packet to a final destination node, and 200 a node along the packet's delivery path removes an extension 201 header, the resulting packet may not elicit the behavior intended 202 by the source node. For example, if a Destination Options header 203 is removed, none of the options that it contains will be delivered 204 to the final destination node. 206 The following are reasons why Routing headers can be deleted by any 207 segment egress node when the Segments Left field is equal to zero and 208 the packet does not contain an authentication header: 210 * Because every segment that the routing header contains has already 211 been processed. 213 * Because [RFC8986] has set a precedent for deletion in this case. 215 5. Security Considerations 217 This document does not introduce any new security considerations. 219 6. IANA Considerations 221 This document does not request any IANA actions. 223 7. Acknowledgements 225 Thanks to Bob Hinden, Brian Carpenter, Tom Herbert and Fernando Gont 226 for their comments and review. 228 8. Normative References 230 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 231 DOI 10.17487/RFC4302, December 2005, 232 . 234 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 235 (IPv6) Specification", STD 86, RFC 8200, 236 DOI 10.17487/RFC8200, July 2017, 237 . 239 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 240 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 241 DOI 10.17487/RFC8201, July 2017, 242 . 244 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 245 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 246 (SRv6) Network Programming", RFC 8986, 247 DOI 10.17487/RFC8986, February 2021, 248 . 250 Authors' Addresses 252 Ron Bonica 253 Juniper Networks 254 2251 Corporate Park Drive 255 Herndon, Virginia 20171 256 United States of America 257 Email: rbonica@juniper.net 259 Tatuya Jinmei 260 Infoblox 261 Email: jinmei@wide.ad.jp