idnits 2.17.1 draft-herbert-ipv6-update-dest-ops-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 111: '...ith no Routing header present, MUST be...' RFC 2119 keyword, line 115: '... Routing header MAY be examined or pr...' RFC 2119 keyword, line 119: '...re a Routing header, then it MUST skip...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2018) is 2071 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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: Informational Quantonium 4 Expires: February 18, 2019 6 August 17, 2018 8 Updates to Destination Options Processing 9 draft-herbert-ipv6-update-dest-ops-00 11 Abstract 13 This document updates the requirements for processing Destination 14 Options in IPv6 in two ways. First, the requirement that all 15 intermediate destinations in a Routing header must process options in 16 a Destination header appearing before the Routing header is relaxed. 17 Secondly, the processing of a Destination Option marked as changeable 18 is clarified. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Processing Requirements of Destination Options . . . . . . . . 3 60 3 Changeable Destination Options . . . . . . . . . . . . . . . . 4 61 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6.1 Normative References . . . . . . . . . . . . . . . . . . . 4 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1 Introduction 69 [RFC8200] specifies the Destination Options header and processing 70 requirements. Two requirements for processing Destination Options are 71 described based on their association with a Routing header. A 72 Destination Options header that is in a packet with no Routing 73 header, or follows a Routing header, is processed only by the final 74 destination node (if no routing header is present that is simply the 75 destination of the packet). A Destination Options header that comes 76 before a Routing header must be processed by each intermediate 77 destination listed in a Routing header. In the first case, 78 Destination Options are only processed by one node, but in the latter 79 they may need to be processed by many intermediate nodes. This 80 distinction motivates a couple of clarifications to the requirements. 82 In that case of Destination Options that come before a Routing 83 header, this document proposes that intermediate destination nodes 84 may ignore the options. This change has a similar justification for 85 relaxing the requirement that all intermediate nodes process Hop-by- 86 Hop options in [RFC8200]. Intermediate destination nodes may be 87 closer in taxonomy to switches and routers than end hosts, so it 88 follows that they may have similar processing constraints in 89 efficiently processing extension headers and TLVs. Those constraints 90 could lead to similar ad hoc implementation behaviors for processing 91 packets with options. Some implementations have dropped packets with 92 options, others have relegated them to slow path processing; in 93 either case, these behaviors at even a few nodes can essentially 94 render options unusable. Allowing intermediate nodes to ignore 95 options retains the primary value and usability of Destination 96 Options. Intermediate nodes that are not interested in them can 97 ignore them, nodes that fully support them can process them. 99 Destination Options may be marked as changeable (the third-highest- 100 order bit of the Option Type for the Destination Option is set). Per 101 [RFC8200], for such a marked option its Option Data may be changed en 102 route. [RFC8200] also states that with the exception of Hop-by-Hop 103 options, extension headers are not processed except by a destination. 104 It follows that the only possible case that a Destination Option may 105 be modified en route is when an intermediate destination in a Routing 106 header modifies it. This document clarifies that. 108 2 Processing Requirements of Destination Options 110 Options in a Destination Options header that is after a Routing 111 header, or are in a packet with no Routing header present, MUST be 112 examined and processed by the destination node. 114 The options in a Destination Options header that appears before a 115 Routing header MAY be examined or processed by intermediate nodes 116 listed in the routing header, including the original destination as 117 well as the ultimate destination provided in the routing header. If 118 an intermediate node does not process the options in a Destination 119 Option header appearing before a Routing header, then it MUST skip 120 over the Destination Options header and continue to process the next 121 header which should be a Routing header. 123 3 Changeable Destination Options 125 If a Destination Option in a Destination Options header that appears 126 before a Routing header is marked as changeable (the third-highest 127 order bit of the option type is set), then the Option Data may be 128 changed by an intermediate destination node en route to the final 129 destination. Specifically, the node for the initial destination 130 address as well as any intermediate node listed in the Routing header 131 may change the Option Data. 133 If a Destination Option is marked to be changeable (the third-highest 134 order bit of the option type is set) and is in a Destination Options 135 header that follows a Routing header, or there is no Routing header 136 present, then the Option Data cannot be changed en route. There are 137 no nodes in the path that are permitted to change the Option Data. 138 Note that the requirement when an Authentication header is present 139 that the entire Option Data field must be treated as zero-valued 140 octets when computing or verifying the packet's authenticating value 141 is still applicable. 143 4 Security Considerations 145 Relaxing the requirement that Destination Options can be ignored by 146 intermediate nodes should not pose any new security risk. It should 147 be noted that any security mechanism specified in a Destination 148 Option should take into account that not all intermediate 149 destinations would necessarily process the security option. 151 5 IANA Considerations 153 There are no IANA considerations in this specification. 155 6 References 157 6.1 Normative References 159 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 160 (IPv6) Specification", STD 86, RFC 8200, DOI 161 10.17487/RFC8200, July 2017, . 164 Author's Address 166 Tom Herbert 167 Quantonium 168 Santa Clara, CA 169 USA 171 Email: tom@quantonium.net