idnits 2.17.1 draft-herbert-ipv6-update-opts-00.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 120: '...ype of an option MUST NOT be changed e...' RFC 2119 keyword, line 125: '...gth of an option MUST NOT be changed e...' RFC 2119 keyword, line 128: '...then any changes MUST be to the existi...' RFC 2119 keyword, line 129: '... Option Length MUST be preserved. No...' RFC 2119 keyword, line 132: '... Options MUST NOT be added to or rem...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2018) is 2044 days in the past. Is this intentional? Checking references for intended status: Full 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 INTERNET-DRAFT Tom Herbert 3 Intended Status: Standard Quantonium 4 Expires: March 10, 2019 6 September 14, 2018 8 Updates to Requirements for IPv6 Options 9 draft-herbert-ipv6-update-opts-00 11 Abstract 13 This document updates requirements for IPv6 Destination and Hop-by- 14 Hop Options. The requirements that option type and option length 15 cannot change en route, as well as the requirements that options 16 cannot be added or removed, are made explicit. The meaning and 17 requirements of a Destination Option marked as changeable are 18 clarified. Finally, the requirement that all destinations listed in a 19 Routing header must process options in a Destination Options header 20 preceding the Routing header is relaxed. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Requirements for adding, removing, or changing options . . . . 4 62 3 Requirements for changeable Destination Options . . . . . . . . 4 63 4 Requirements for processing Destination Options . . . . . . . . 5 64 5 Detecting that Destination Options precede a Routing header . . 5 65 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1 Normative References . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1 Introduction 73 [RFC8200] defines Hop-by-Hop and Destination Options. This document 74 clarifies requirements for changing, adding, or removing options in a 75 packet en route to its final destination. It also relaxes the 76 requirement that Destination Options preceding a Routing header must 77 be processed by all destinations listed in the Routing header. 79 [RFC8200] specifies that "The third-highest-order bit of the Option 80 Type specifies whether or not the Option Data of that option can 81 change en route to the packet's final destination." It is implicit in 82 this requirement that neither the Option Type nor Option Data Length 83 can change en route to the packet's destination. It also follows that 84 options cannot be added or removed while a packet is en route. This 85 document makes these requirements explicit. 87 Per [RFC8200], Destination Options may be marked as changeable (the 88 third-highest-order bit of the Option Type for the Destination Option 89 is set). [RFC8200] also states that with the exception of Hop-by-Hop 90 options, extension headers are not processed except by the 91 destination node. It follows that the only possible case that a 92 Destination Option may be modified en route is by a node that is one 93 of destinations to be visited in a Routing header. This document 94 clarifies this requirement. 96 Per [RFC8200], if a Destination Options header precedes a Routing 97 header, then all of the destinations listed in the Routing header 98 must process the Destination Options. This document proposes to relax 99 that requirement by allowing nodes listed in the Routing header to 100 ignore Destination Options that precede the Routing header. The 101 motivation for this is similar to that of relaxing the requirement 102 that all intermediate nodes process Hop-by-Hop options in [RFC8200]. 103 Intermediate destination nodes may be closer in taxonomy to switches 104 and routers than end hosts, so it follows that they may have similar 105 processing constraints in efficiently processing extension headers 106 and TLVs. Those constraints could lead to similar ad hoc behaviors 107 for processing packets with options-- some implementations have 108 dropped packets with options, others have relegated them to slow path 109 processing. In any case, such behaviors at even a few nodes can 110 essentially render options unusable. Allowing nodes to ignore options 111 retains the primary value and usability of Destination Options 112 preceding a Routing header. Nodes that are not interested in them can 113 ignore them, nodes that fully support them can process them. 115 2 Requirements for adding, removing, or changing options 117 This section clarifies requirements of [RFC8200] for changing, 118 adding, or removing Destination Options or Hop-by-Hop Options. 120 The Option Type of an option MUST NOT be changed en route to a 121 packet's final destination. Note that this precludes changing the 122 high order bits of an Option Type which indicate a changeable option 123 or the action to take for an unknown option. 125 The Option Data Length of an option MUST NOT be changed en route to a 126 packet's final destination. If the third-highest-order bit of the 127 Option Type is set indicating that the Option Data can change en 128 route, then any changes MUST be to the existing Option Data and the 129 Option Length MUST be preserved. Note, if the Option Data Length is 130 zero then the option cannot be modified in any way. 132 Options MUST NOT be added to or removed from a packet en route to its 133 final destination. This requirement precludes adding or removing 134 options within an existing extension header, as well as adding or 135 removing a Destination or Hop-by-Hop extension headers in a packet. 137 Note that in the case that a routing header is present, the "final 138 destination" refers to the final destination listed to visit in the 139 routing header. At intermediate destinations of a routing header, the 140 packet is considered en route to the final destination, so that 141 requirements about changing a packet en route to its final 142 destination are applicable. 144 3 Requirements for changeable Destination Options 146 If a Destination Option in a Destination Options header that precedes 147 a Routing header is marked as changeable (the third-highest order bit 148 of the option type is set), then the Option Data may be changed by 149 any destination node en route to the final destination. Specifically, 150 the node for the initial destination address as well as any nodes to 151 visit as listed in the Routing header may change the Option Data. 153 If a Destination Option is marked as changeable (the third-highest 154 order bit of the option type is set) and is in a Destination Options 155 header that follows a Routing header, or there is no Routing header 156 present, then the Option Data cannot be changed en route. There are 157 no nodes in the path that are permitted to change the Option Data. 158 Note that the requirement when an Authentication header is present 159 the entire Option Data field must be treated as zero-valued octets 160 when computing or verifying the packet's authenticating value is 161 still applicable. 163 4 Requirements for processing Destination Options 165 This section clarifies requirements of processing Destination Options 166 with respect to its relationship to a Routing header. 168 Options in a Destination Options header that follow a Routing header, 169 or are in a packet having no Routing header, MUST be processed by the 170 destination node. In the case that a Routing header is present, the 171 Destination Options that follow the Routing header MUST be processed 172 by the final destination listed in the Routing header. 174 Options in a Destination Options header that precede a Routing header 175 MAY be examined or processed by the original destination node and 176 nodes listed to visit in the Routing header (including the final 177 destination of the Routing Header). If a node does not process the 178 options in a Destination Option header, then it MUST skip over the 179 Destination Options header and continue to process the next header 180 which is likely the Routing header. 182 5 Detecting that Destination Options precede a Routing header 184 As specified in requirements of this document, an implementation 185 might process Destination Options differently depending on whether 186 they precede a Routing header. Procedures are therefore needed to 187 detect if Destination Options precede a Routing header. 189 An implementation MAY determine that Destination Options precede a 190 Routing Header by inspecting the Next Header field of the Destination 191 Option. If the Next Header field indicates a Routing Header, then the 192 implementation can conclude that Destination Options precede a 193 Routing Header. Note that this employs a heuristic based on the 194 recommended ordering of extension headers of [RFC8200] in which the 195 Routing header should immediately follow Destination Options before a 196 Routing header. 198 An implementation MAY scan the packet to determine if a Routing 199 header is present that follows a Destination Options header. If such 200 a scan is performed, an implementation MUST NOT process any scanned 201 extension headers beyond inspecting their Next Header and Header Ext 202 Length fields. This requirement is necessary ensure that extension 203 headers are strictly processed order as manadated by [RFC8200]. 205 If a node is not able to determine that Destination Options precede a 206 Routing header, the Destinations Options MUST be processed as though 207 they do not precede a Routing header. In this case, a destination 208 node, regardless whether it is an intermediate or final destination, 209 MUST process the Destination Options and MUST NOT change any 210 Destination Options even if they are marked as changeable. 212 6 Security Considerations 214 Relaxing the requirement that Destination Options preceding a Routing 215 header can be ignored by intermediate destination nodes should not 216 pose any new security risk. It should be noted that any security 217 mechanism specified in a Destination Option should take into account 218 that not all intermediate destinations would necessarily process the 219 security option. 221 7 IANA Considerations 223 There are no IANA considerations in this specification. 225 8 References 227 8.1 Normative References 229 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 230 (IPv6) Specification", STD 86, RFC 8200, DOI 231 10.17487/RFC8200, July 2017, . 234 Author's Address 236 Tom Herbert 237 Quantonium 238 Santa Clara, CA 239 USA 241 Email: tom@quantonium.net