idnits 2.17.00 (12 Aug 2021) /tmp/idnits1251/draft-roberts-inband-qos-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 249. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 263 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 117 has weird spacing: '...rotocol to im...' == Unrecognized Status in 'Intended Status: Standard Anagran Inc.', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2005) is 6150 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) == Unused Reference: 'RFC2640' is defined on line 150, but no explicit reference was found in the text == Unused Reference: 'TIA1039' is defined on line 155, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'RFC2640') (Obsoleted by RFC 8200) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Roberts 2 Intended Status: Standard Anagran Inc. 3 Expires: January 19, 2006 J. Harford 4 Blue Wave Labs 5 July 19, 2005 7 In-Band QoS Signaling for IPv6 9 draft-roberts-inband-qos-ipv6-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 13, 2006 36 Copyright Notice 38 Copyright(C) The Internet Society (2005). 40 Abstract 42 This specification describes the basic requirements 43 for In-Band QoS Signaling in IPv6. The context is 44 where a QoS requirement is passed across the network 45 and some of the routers need to modify the request to 46 modify the request if the requested QoS is not 47 available at that node, indicating what QoS is 48 available. 50 1. Introduction 51 There are some applications for IPv6 where it would be 52 of great value for the user to request a specific 53 level of QoS and have the routers along the data path 54 agree on the or adjust downward the request to permit 55 the user to know exactly what QoS was available. An 56 example of this is to agree on the maximum rate that a 57 TCP flow can be permitted at this time. The benefits 58 of such network wide agreement particularly important 59 for operation over high delay paths like satellites or 60 high noise paths like radio links as are common in 61 military or civilian emergency forward areas. Here 62 determining the TCP rate, by rate feedback can greatly 63 improve the performance. There are also many other 64 application areas such as video conferencing where 65 confirming the available rate (capacity), jitter and 66 precedence can be very important at the start of a 67 call. 69 2. Discussion 71 To accomplish this requires an in-band signaling 72 capability and in many of these cases, more 73 information than the 6 bits in Diffserv are required. 74 The only possible way to add more information to a 75 packet stream in-band for IPv6 is to use a 76 hop-by-hop option field. All other optional fields are 77 encrypted and thus are not available to the routers. 79 In the past it has been very hard for routers to take 80 the time to modify a packet in-flight. However, 81 advances in electronics hardware now permits much more 82 extensible packet processing that could look at a QoS 83 request, determine the available resources, and to 84 modify the packet accordingly. Given that this 85 capability is either now available or soon will become 86 available, it is important to make provision in the 87 IPv6 protocol for such in-band QoS options to be 88 possible and tested. One particular reason for 89 approving the basic option structure now is that new 90 satellites with onboard routing are now being designed 91 and this design needs to be frozen soon, even though 92 their launch is several years away. 94 3. Basic Requirement 96 If in-band QoS Signaling of any format is to be used 97 with IPv6, it is essential that a hop-by-hop option 98 code for QoS signaling be assigned. It should have a 99 version field so that various designs can be designed 100 and tested. The main requirement for routers to 101 process the option is at choke points in the network. 102 Since the option in many cases need not be processed 103 by over-capacity core routers or in MPLS tunnels, the 104 option code should be one that is ignored by routers 105 if they do not understand the code. It also should be 106 one where fragments do not replicate the option and 107 one where it can be modified. Thus the option code 108 must be of the form 001xxxx. None of this type has 109 ever been assigned due to the past difficulty of 110 modifying packet in flight. 112 4. Interest 114 This RFC is being distributed to members of the 115 Internet community in order to solicit their reaction 116 to this proposal. The TIA has already approved a 117 protocol to improve satellite operation where such an 118 option assignment is required. The ITU has in progress 119 proposals similar to the TIA protocol. The IETF may 120 well design its own protocol for in-band QoS Signaling 121 in the future. Since there is only one possible way to 122 accomplish this, by using a hop-by-hop option, there 123 is considerable reason to consider assigning such a 124 code now and allowing the other standard bodies to 125 proceed where they have identified a critical 126 requirement. If the IETF chooses never to use this 127 code, it cannot hurt the network since it will be 128 ignored by the routers and they will discard any 129 packets that exceed their capacity. If they do decide 130 to use the code, a separate version code can be used. 131 However, where such a protocol is used in certain 132 critical areas like over satellites, or in noisy radio 133 domains, it can be of critical benefit to specific 134 users and it is important to permit other standard 135 groups like the TIA to address their problem using 136 compatable IP. 138 5. Status Report 140 In response to the need for maintenance of current 141 information about the status and progress of various 142 projects in the Internet community, this RFC is issued 143 for the benefit of community members. The information 144 contained in this document is accurate as of the date 145 of publication, but is subject to change. Subsequent 146 RFCs will reflect such changes. 148 6. Normative References 150 [RFC2640] Internet Protocol, Version 6 (IPv6) Specification, 151 S. Deering, R. Hinden, RFC 2460, December 1998 153 6.1 Informative References 155 [TIA1039] Revised to RFC Format, QoS Signaling 157 7. Security Considerations 159 There are no security issues in assigning a option 160 code. There may be various security considerations in 161 any particular protocol using the option code such as 162 authentication and authorization. However, for IPv6, 163 these security issues have already been addressed. If 164 new issues are created by a particular protocol, those 165 issues should be addressed for that protocol. 167 8. IANA Considerations 169 The request is for IANA to assign a hop-by-hop option 170 code of the form 001xxxx for the type of usage, QoS 171 Signaling. The request is for IANA to assign a hop- 172 by-hop option code of the form 001xxxx for the type of 173 usage, QoS Signaling. A Version Field can be located 174 starting at byte 25 for 12 bits. This would be 175 desirable to maintain correspondence with the TIA and 176 the ITU specifications and permit multiple protocol 177 versions. 179 9. IETF Consensus 181 In order for IANA to assign an IPv6 hop-by-hop option code, 182 either IESG agreement or IETF Consensus is required. This 183 ID need not be approved, just the code for general use. 184 Since all IPv6 protocols that attempt in-band QoS Signaling 185 must use an IPv6 hop-by-hop option code of this type to 186 allow over-capacity routers to ignore this option and to 187 avoid encryption, the assignment is of general use as we 188 move IPv6 into areas where low error rate, low delay fiber 189 does not exist. 191 10. Authors Addresses 193 Lawrence Roberts 194 Anagran Inc. 195 2055 Woodside Road #200 196 Redwood City, CA 94061 197 Email: lroberts@anagran.com 199 Jim Harford 200 Blue Wave Labs 201 P.O. Box 10 202 Rougemont, NC 27572 203 Email: harford@bluewavelabs.com 205 Full Copyright Statement 207 Copyright (C) The Internet Society (2005). 209 This document is subject to the rights, licenses and 210 restrictions contained in BCP 78, and except as set forth 211 therein, the authors retain all their rights. 213 This document and the information contained herein are 214 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 215 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF 216 ANY), THE INTERNET SOCIETY AND THE INTERNET 217 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 218 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 219 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 220 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 221 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 223 Intellectual Property 225 The IETF takes no position regarding the validity or 226 scope of any Intellectual Property Rights or other 227 rights that might be claimed to pertain to the 228 implementation or use of the technology described in 229 this document or the extent to which any license under 230 such rights might or might not be available; nor does 231 it represent that it has made any independent effort 232 to identify any such rights. Information on the 233 procedures with respect to rights in RFC documents can 234 be found in BCP 78 and BCP 79. 236 Copies of IPR disclosures made to the IETF Secretariat 237 and any assurances of licenses to be made available, 238 or the result of an attempt made to obtain a general 239 license or permission for the use of such proprietary 240 rights by implementers or users of this specification 241 can be obtained from the IETF on-line IPR repository 242 at http://www.ietf.org/ipr. 244 The IETF invites any interested party to bring to its 245 attention any copyrights, patents or patent 246 applications, or other proprietary rights that may 247 cover technology that may be required to implement 248 this standard. Please address the information to the 249 IETF at ietf-ipr@ietf.org. 251 Acknowledgement 253 Funding for the RFC Editor function is currently 254 provided by the Internet Society.