idnits 2.17.00 (12 Aug 2021) /tmp/idnits8759/draft-krishnan-conex-ipv6-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 14, 2011) is 4079 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) == Outdated reference: draft-ietf-conex-abstract-mech has been published as RFC 7713 ** Downref: Normative reference to an Informational draft: draft-ietf-conex-abstract-mech (ref. 'CAM') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 conex Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Kuehlewind 5 Expires: September 15, 2011 IKR University of Stuttgart 6 C. Ucendo 7 Telefonica 8 March 14, 2011 10 Options for Conex marking in IPv6 packets 11 draft-krishnan-conex-ipv6-02 13 Abstract 15 Conex is a mechanism by which senders inform the network about the 16 congestion encountered by packets earlier in the same flow. This 17 document describes the requirements for conex markings in IPv6 18 datagrams and describes the various options for performing conex 19 markings in IPv6. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 15, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions used in this document . . . . . . . . . . . . . . . 3 57 3. Requirements for marking IPv6 packets . . . . . . . . . . . . . 3 58 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Hop-by-hop options . . . . . . . . . . . . . . . . . . . . 3 60 4.2. Destination options . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Header bits . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.4. Extension Headers . . . . . . . . . . . . . . . . . . . . . 4 63 5. ConEx Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 Conex is a mechanism by which senders inform the network about the 73 congestion encountered by packets earlier in the same flow. This 74 document describes the requirements for conex markings in IPv6 75 datagrams and describes the various options for performing conex 76 markings in IPv6. 78 2. Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 3. Requirements for marking IPv6 packets 86 R-1: The marking mechanism needs to be visible to all conex-capable 87 nodes on the path. 89 R-2: The mechanism needs to be able to traverse nodes that do not 90 understand the markings. This is required to ensure that conex can 91 be incrementally deployed over the Internet. 93 R-3: The presence of the marking mechanism should not significantly 94 alter the processing of the packet. This is required to ensure that 95 conex marked packets do not face any undue delays or drops due to a 96 badly chosen mechanism. 98 R-4: The markings should be immutable once set by the sender. At the 99 very least, any tampering should be detectable. 101 4. Possible Solutions 103 4.1. Hop-by-hop options 105 The base IPv6 standard [RFC2460] defines hop-by-hop options. These 106 options are processed by every node on the path. Hence they meet 107 R-1. The options have variable semantics based on the 3 MSB of the 108 option code. The state of these bits controls the behavior of nodes 109 to either ignore unknown options or drop packets containing them. It 110 also defines the ICMPv6 error message sending behavior and the 111 mutability of the options en-route. This means that it is possible 112 for hop-by-hop options to satisfy R-2 and R-4. In most commercial 113 router implementations the mere presence of hop-by-hopoptions rResult 114 in the packet being punted to the Slow path instead of being accorded 115 regular forwarding behavior (Fast Path). This means that R-3 is not 116 satisifed. 118 4.2. Destination options 120 The base IPv6 standard [RFC2460] defines the destination options. 121 These options are processed only by the ultimate receiver of the 122 packet (as specified in the Destination Address field) and not by 123 nodes on the path. Hence they do not meet R-1. The options have the 124 same variable semantics based on the 3 MSBs as the hop-by-hop option 125 which means that they can satisfy R-2 and R-4. As intermediate nodes 126 currently do not process destination options R-3 is easily satisifed. 128 4.3. Header bits 130 The IPv6 header has no free bits. The only bits in the IPv6 header 131 that are not widely used are the flow label bits [RFC3697]. There 132 are some initiatives to redefine the use of the flow label for other 133 purposes (e.g. Load balancing, nonce). It may be possible (but 134 highly unlikeley) to save a few bits from the flow label for 135 alternate purposes to end up with a shorter flow label. The use of 136 IPv6 header bits can satisfy all the requirements for conex markings 137 but using valuable header bits for experimental purposes (such as 138 conex) may not be acceptable. 140 4.4. Extension Headers 142 The base IPv6 standard [RFC2460] defines extension headers as an 143 expansion mechanism to carry optional internet layer information. 144 Extension headers, with the exception of the hop-by-hop options 145 header, are not usually processed on intermediate nodes. This means 146 that R-1 cannot be met. Unknown extension headers cause the packet 147 to be dropped and hence such mechanism is not incrementally 148 deployable. Hence R-3 is not met either. 150 5. ConEx Encoding 152 The decision about where to code the ConEx inform might also 153 influence the decision on how to code congestion information itself. 154 Of course, a ConEx capable transport has to inform the network that 155 it is actually ConEx enabled. Thus, as a minimum, every packet has 156 to carry the information that the sender is ConEx enabled and, also 157 whether it is ConEx marked. Moreover, the abstract conex mechanism 158 [CAM] requires that that a distinction between loss or ECN marks as 159 congestion signal is needed in addition to the so-called 'congestion 160 credits'. This implies that a minimum of 4 bits is needed if bit- 161 wise encoding is used , and a minimum of 3 bits is needed if 162 codepoints are used. Further ideas on additional ConEx information 163 are currently discussed on the mailing list. Moreover, the ConEx 164 information could be represented in a more sophisticated manner than 165 a binary signal (Yes/No), if additional bits are available for use. 167 6. Acknowledgements 169 The authors would like to thank Marcelo Bagnulo, Bob Briscoe, Ingemar 170 Johansson, Joel Halpern and John Leslie for the discussions that led 171 to this document. 173 7. Security Considerations 175 This document does not bring up any new security issues. 177 8. IANA Considerations 179 This document does not require any IANA action. 181 9. Normative References 183 [CAM] Briscoe, B., "Congestion Exposure (ConEx) Concepts and 184 Abstract Mechanism", draft-ietf-conex-abstract-mech-01 185 (work in progress), March 2011. 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 191 (IPv6) Specification", RFC 2460, December 1998. 193 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 194 "IPv6 Flow Label Specification", RFC 3697, March 2004. 196 Authors' Addresses 198 Suresh Krishnan 199 Ericsson 200 8400 Blvd Decarie 201 Town of Mount Royal, Quebec 202 Canada 204 Email: suresh.krishnan@ericsson.com 206 Mirja Kuehlewind 207 IKR University of Stuttgart 209 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 211 Carlos Ralli Ucendo 212 Telefonica 214 Email: ralli@tid.es