idnits 2.17.1 draft-ietf-tsvwg-sctp-padding-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 286. ** 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: ---------------------------------------------------------------------------- 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 16, 2006) is 6394 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 177 ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) == Outdated reference: A later version (-11) exists of draft-ietf-pmtud-method-10 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Applied Sciences 4 Intended status: Standards Track R. Stewart 5 Expires: April 19, 2007 P. Lei 6 Cisco Systems, Inc. 7 October 16, 2006 9 Padding Chunk and Parameter for SCTP 10 draft-ietf-tsvwg-sctp-padding-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 19, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document defines a padding chunk and a padding parameter and 44 describes the required receiver side procedures. The padding chunk 45 is used to pad an SCTP packet to an arbitrary size. The padding 46 parameter is used to pad an SCTP INIT chunk to an arbitrary size. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Padding Chunk (PAD) . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Padding Parameter (PAD) . . . . . . . . . . . . . . . . . . . . 4 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 5.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 5 56 5.2. A New Parameter Type . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 This document defines a padding chunk and a padding parameter and 68 describes the required receiver side procedures. The padding chunk 69 is used to pad an SCTP packet to an arbitrary size. The padding 70 parameter is used to pad an SCTP INIT chunk to an arbitrary size. 71 The usage of the PAD chunk for path MTU discovery is described in 72 PMTU [3]. The inappropriate usage of the PAD parameter or PAD chunk 73 can result in wasted bandwidth. 75 2. Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL", when they appear in this document, are to be interpreted 80 as described in RFC2119 [1]. 82 3. Padding Chunk (PAD) 84 This chunk is used to pad an SCTP packet. A PAD chunk can be used to 85 enlarge the packet by 4 to 65536 bytes in steps of 4 bytes. An SCTP 86 packet MAY contain multiple PAD chunks. 88 0 1 2 3 89 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Type = 0x84 | Flags=0 | Length | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | | 94 \ Padding Data / 95 / \ 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 Figure 1 100 Type: 1 byte (unsigned integer) 101 This value MUST be set to 0x84 for all PAD-chunks. 103 Flags: 1 byte (unsigned integer) 104 This value SHOULD be set to zero on transmit and MUST be ignored 105 on receipt. 107 Length: 2 bytes (unsigned integer) 108 This value holds the length of the Padding Data plus 4. 110 Padding Data: n bytes (unsigned integer) 111 This holds the Padding Data. The Padding Data MUST be ignored by 112 the receiver. 114 The receiver of the PAD chunk MUST discard this chunk and continue 115 processing the rest of the chunks in the packet. Please note that 116 this is also the required processing behavior for any unknown chunk 117 having the same highest order two bits of the type as the PAD chunk. 119 4. Padding Parameter (PAD) 121 This parameter is used to pad an INIT chunk. A PAD parameter can be 122 used to enlarge the INIT chunk by 4 bytes as the minimum to the 123 maximum size of the INIT chunk in steps of 4 bytes. An INIT chunk 124 MAY contain multiple PAD parameters. 126 0 1 2 3 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Parameter Type = 0x8005 | Parameter Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 / / 132 \ Padding Data \ 133 / / 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 2 138 Parameter Type: 2 bytes (unsigned integer) 139 This value MUST be set to 0x8005. 141 Parameter Length: 2 bytes (unsigned integer) 142 This value holds the length of the Padding Data plus 4. 144 The PAD parameter MAY be included only in the INIT chunk. It MUST 145 NOT be included in any other chunk. The receiver of the PAD 146 parameter MUST silently discard this parameter and continue 147 processing the rest of the INIT chunk. This means that the size of 148 the generated COOKIE parameter in the INIT-ACK MUST NOT depend on the 149 existence of the PAD parameter in the INIT chunk. A receiver of a 150 PAD parameter MUST NOT include the PAD parameter within any State 151 Cookie parameter it generates. 153 5. IANA Considerations 155 [NOTE to RFC-Editor: 157 "RFCXXXX" is to be replaced by the RFC number you assign this 158 document. 160 ] 162 This document (RFCXXX) is the reference for all registrations 163 described in this section. All registrations need to be listed in 164 the document available at sctp-parameters [4]. The suggested changes 165 are described below. 167 5.1. A New Chunk Type 169 A chunk type for the PAD chunk has to be assigned by IANA. It is 170 suggested to use the value given in Figure 1. This requires an 171 additional line in the "CHUNK TYPES" table of sctp-parameters [4]: 173 CHUNK TYPES 175 ID Value Chunk Type Reference 176 -------- ---------- --------- 177 132(0x84) Padding Chunk (PAD) [RFCXXXX] 179 5.2. A New Parameter Type 181 A parameter type has to be assigned for the PAD parameter by IANA. 182 It is suggested to use the values given in Figure 2. This requires a 183 modification in the "CHUNK PARAMETER TYPES" table in sctp- 184 parameters [4]: Add a new line to the "INIT Chunk Parameter Types" 185 table: 187 Chunk Parameter Type Value 188 -------------------- ----- 189 Padding 32773(0x8005) 191 6. Security Considerations 193 This document does not add any additional security considerations in 194 addition to the ones given in RFC2960 [2]. 196 7. Acknowledgments 198 The authors wish to thank Matthew J. Zekauskas, and Lars Eggert for 199 his invaluable comments. 201 8. References 202 8.1. Normative References 204 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 205 Levels", BCP 14, RFC 2119, March 1997. 207 [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 208 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 209 "Stream Control Transmission Protocol", RFC 2960, October 2000. 211 8.2. Informative References 213 [3] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 214 Discovery", draft-ietf-pmtud-method-10 (work in progress), 215 September 2006. 217 URIs 219 [4] 221 Authors' Addresses 223 Michael Tuexen 224 Muenster Univ. of Applied Sciences 225 Stegerwaldstr. 39 226 48565 Steinfurt 227 Germany 229 Email: tuexen@fh-muenster.de 231 Randall R. Stewart 232 Cisco Systems, Inc. 233 4875 Forest Drive 234 Suite 200 235 Columbia, SC 29206 236 USA 238 Email: rrs@cisco.com 239 Peter Lei 240 Cisco Systems, Inc. 241 955 Happfield Dr. 242 Arlington Heights, IL 60004 243 US 245 Phone: +1 773 695-8201 246 Email: peterlei@cisco.com 248 Full Copyright Statement 250 Copyright (C) The Internet Society (2006). 252 This document is subject to the rights, licenses and restrictions 253 contained in BCP 78, and except as set forth therein, the authors 254 retain all their rights. 256 This document and the information contained herein are provided on an 257 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 258 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 259 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 260 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 261 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 262 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 264 Intellectual Property 266 The IETF takes no position regarding the validity or scope of any 267 Intellectual Property Rights or other rights that might be claimed to 268 pertain to the implementation or use of the technology described in 269 this document or the extent to which any license under such rights 270 might or might not be available; nor does it represent that it has 271 made any independent effort to identify any such rights. Information 272 on the procedures with respect to rights in RFC documents can be 273 found in BCP 78 and BCP 79. 275 Copies of IPR disclosures made to the IETF Secretariat and any 276 assurances of licenses to be made available, or the result of an 277 attempt made to obtain a general license or permission for the use of 278 such proprietary rights by implementers or users of this 279 specification can be obtained from the IETF on-line IPR repository at 280 http://www.ietf.org/ipr. 282 The IETF invites any interested party to bring to its attention any 283 copyrights, patents or patent applications, or other proprietary 284 rights that may cover technology that may be required to implement 285 this standard. Please address the information to the IETF at 286 ietf-ipr@ietf.org. 288 Acknowledgment 290 Funding for the RFC Editor function is provided by the IETF 291 Administrative Support Activity (IASA).