idnits 2.17.1 draft-bonica-6man-ext-hdr-update-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 : ---------------------------------------------------------------------------- == 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 (March 16, 2020) is 1502 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: September 17, 2020 March 16, 2020 8 Inserting, Processing And Deleting IPv6 Extension Headers 9 draft-bonica-6man-ext-hdr-update-03 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 September 17, 2020. 33 Copyright Notice 35 Copyright (c) 2020 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 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Updates To RFC 8200 . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Original Text . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Updated Text . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 In IPv6 [RFC8200] optional internet-layer information is encoded in 65 extension headers. As specified by [RFC8200], "extension headers 66 (except for the Hop-by-Hop Options header) are not processed, 67 inserted, or deleted by any node along a packet's delivery path, 68 until the packet reaches the node (or each of the set of nodes, in 69 the case of multicast) identified in the Destination Address field of 70 the IPv6 header". 72 The statement quoted above identifies nodes upon which extension 73 headers are not processed, inserted or deleted. It does not imply 74 that extension headers can be processed, inserted or deleted on any 75 other node along a packet's delivery path. 77 This document provides guidance regarding the processing, insertion 78 and deletion of IPv6 extension headers. It clarifies the statement 79 quoted above and updates [RFC8200]. 81 2. Terminology 83 The following terms are used in this document: 85 o Source node - An IPv6 source node accepts data from an upper-layer 86 protocol, prepends an IPv6 header, and sends the resulting IPv6 87 packet to a destination node. 89 o Final destination node - An IPv6 final destination node receives 90 an IPv6 packet and delivers its payload to an upper-layer 91 protocol. If a packet contains a Routing header, its destination 92 address may represent an interface that belongs to a node other 93 than the final destination node. 95 o Delivery path - A packet's delivery path is a series of nodes that 96 a packet traverses on route to its final destination. The 97 delivery path includes the final destination node. 99 o Segment - A segment is a series of links and nodes in a packet's 100 delivery path. An IPv6 Routing header steers packets from segment 101 to segment along the delivery path. If a packet contains a 102 Routing header, its delivery path can contain multiple segments. 103 If a packet does not contain a Routing header, its delivery path 104 contains only one segment. 106 o Segment egress node - A segment egress node terminates a segment. 107 When a packet arrives at a segment egress node, its IPv6 108 Destination Address identifies an interface that belongs to the 109 node. All final destination nodes are also segment egress nodes. 111 o Extension header processing - Each IPv6 extension header is 112 associated with a procedure. For example, the Fragment header is 113 associated with fragmentation and reassembly procedures. 114 Extension header processing is the reception of an extension 115 header and the execution of its associated procedure. 117 3. Updates To RFC 8200 119 The terms defined in Section 2 of this document should be added to 120 Section 2 of [RFC8200]. 122 Section 3.1 of this document quotes text from [RFC8200]. That text 123 should be replaced with the text contained by Section 3.2 of this 124 document. 126 3.1. Original Text 128 "Extension headers (except for the Hop-by-Hop Options header) are not 129 processed, inserted, or deleted by any node along a packet's delivery 130 path, until the packet reaches the node (or each of the set of nodes, 131 in the case of multicast) identified in the Destination Address field 132 of the IPv6 header. 134 The Hop-by-Hop Options header is not inserted or deleted, but may be 135 examined or processed by any node along a packet's delivery path, 136 until the packet reaches the node (or each of the set of nodes, in 137 the case of multicast) identified in the Destination Address field of 138 the IPv6 header. The Hop-by-Hop Options header, when present, must 139 immediately follow the IPv6 header. Its presence is indicated by the 140 value zero in the Next Header field of the IPv6 header." 142 3.2. Updated Text 144 Source nodes can send packets that include extension headers. 145 Extension headers are not inserted by subsequent nodes along a 146 packet's delivery path. 148 The Hop-by-Hop Options header, when present, must immediately follow 149 the IPv6 header. Its presence is indicated by the value zero in the 150 Next Header field of the IPv6 header. 152 The Hop-by-Hop Options header can be processed by any node in a 153 packet's delivery path. All remaining extension headers can be 154 processed at segment endpoints only. While some extension headers 155 can be processed at any segment endpoint node, others (e.g., the 156 Fragment header) can only be processed at the final destination node. 158 The following extension header fields, if present, are not modified 159 by nodes along a packet's delivery path: 161 o Next Header. 163 o Hdr Ext Len. 165 Extension headers are not deleted by any node along a packet's 166 delivery path, until the packet reaches the final destination node 167 (or each of the set of final destination nodes, in the case of 168 multicast). 170 Extension headers can be inspected for various purposes (e.g., 171 firewall filtering) by any node along a packet's delivery path. 173 4. Motivation 175 The following are reasons why extension headers are not inserted by 176 nodes along a packet's delivery path: 178 o Nodes that execute Path MTU Discovery (PMTUD) [RFC8201] procedures 179 can send packets that are nearly as large as the Path MTU. Adding 180 an extension header to such a packet can cause MTU black holing. 182 o IPv6 Authentication Header [RFC4302] processing relies on the 183 immutability of the Payload Length field in the IPv6 header. When 184 a node along a packet's delivery path inserts an extension header, 185 it must also update the Payload Length field in the IPv6 header. 186 Therefore, it causes IPv6 Authentication Header processing to fail 187 on the final destination node. 189 o When a source node sends a packet to a final destination node, and 190 a node along the packet's delivery path inserts an extension 191 header, the final destination node will mistakenly attribute the 192 extension header to the source node. Attackers can leverage this 193 mistaken attribution. 195 The following are reasons why extension headers are not deleted by 196 any node along a packet's delivery path, until the packet reaches the 197 destination node: 199 o IPv6 Authentication Header processing relies on the immutability 200 of the Payload Length field in the IPv6 header. When a node along 201 a packet's delivery path inserts an extension header, it must also 202 update the Payload Length field in the IPv6 header. Therefore, it 203 causes IPv6 Authentication Header processing to fail on the final 204 destination node. 206 o When a source node sends a packet to a final destination node, and 207 a node along the packet's delivery path removes an extension 208 header, the resulting packet may not elicit the behavior intended 209 by the source node. For example, if a Destination Options header 210 is removed, none of the options that it contains will be delivered 211 to the final destination node. 213 5. Security Considerations 215 This document does not introduce any new security considerations. 217 6. IANA Considerations 219 This document does not request any IANA actions. 221 7. Acknowledgements 223 Thanks to Bob Hinden, Brian Carpenter, Tom Herbert and Fernando Gont 224 for their comments and review. 226 8. Normative References 228 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 229 DOI 10.17487/RFC4302, December 2005, 230 . 232 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 233 (IPv6) Specification", STD 86, RFC 8200, 234 DOI 10.17487/RFC8200, July 2017, 235 . 237 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 238 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 239 DOI 10.17487/RFC8201, July 2017, 240 . 242 Authors' Addresses 244 Ron Bonica 245 Juniper Networks 246 2251 Corporate Park Drive 247 Herndon, Virginia 20171 248 USA 250 Email: rbonica@juniper.net 252 Tatuya Jinmei 253 Infoblox 255 Email: jinmei@wide.ad.jp