<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>

<rfc number="4820" category="std" >
<front>
<title abbrev="Padding Chunk and Parameter for SCTP">
Padding Chunk and Parameter 
for&nbsp;the&nbsp;Stream&nbsp;Control&nbsp;Transmission&nbsp;Protocol&nbsp;(SCTP)</title>


<!-- ************** MICHAEL TUEXEN *************** -->
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization>Muenster Univ. of Applied Sciences</organization>
<address>
    <postal>
        <street>Stegerwaldstr. 39</street>
        <city>48565 Steinfurt</city>
        <country>Germany</country>
    </postal>
    <email>tuexen@fh-muenster.de</email>
</address>
</author>

<!-- ************** RANDALL STEWART ***************-->
<author initials="R. R." surname="Stewart" fullname="Randall R. Stewart">
<organization>Cisco Systems, Inc.</organization>
<address>
    <postal>
        <street>4875 Forest Drive</street>
        <street> Suite 200</street>
        <city>Columbia</city> <region>SC</region>
        <code>29206</code>
        <country>USA</country>
    </postal>
    <email>rrs@cisco.com</email>
</address>
</author>

<!-- *************** PETER LEI ***************** -->
<author initials="P." surname="Lei" fullname="Peter Lei">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
 <street>955 Happfield Dr.</street>
 <city>Arlington Heights</city> <region>IL</region>
 <code>60004</code>
 <country>US</country>
</postal>
<phone>+1 773 695-8201</phone>
<email>peterlei@cisco.com</email>
</address>
</author>

<date month="March" year="2007" />

<!-- RFC Editor Comment: Please insert any keywords (beyond those that appear in
 the title) for use on http://www.rfc-editor.org/search.html. -->


<abstract>
<t>This document defines a padding chunk and a padding parameter and
describes the required receiver side procedures.  The padding chunk
is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size.  The padding
parameter is used to pad an SCTP INIT chunk to an arbitrary size.</t>
</abstract>

</front>

<middle>

<section anchor="intro" title="Introduction">
<t>This document defines a padding chunk and a padding parameter and
describes the required receiver side procedures.  The padding chunk
is used to pad an SCTP packet to an arbitrary size.  The padding
parameter is used to pad an SCTP INIT chunk to an arbitrary size.
The usage of the PAD chunk for path MTU discovery is described in
<xref target="RFC4821">PMTU</xref>. The inappropriate
usage of the PAD parameter or PAD chunk can result in wasted
bandwidth.</t>
</section>

<section anchor="conventions" title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when
they appear in this document, are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</section> <!-- conventions -->

<section title="Padding Chunk (PAD)">
<!-- RFC Editor Comment: Is (PAD) supposed to be an abbreviation for
Padding?  If so, then it might make more sense to have the section
titles read as "Padding (PAD) Chunk", so as to not confuse others with
the idea that (PAD) is short for "Padding Chunk". -->
<t>This chunk is used to pad an SCTP packet. A PAD chunk can
be used to enlarge the packet by 4 to 65536 bytes in steps of 4 bytes.
An SCTP packet MAY contain multiple PAD chunks.</t>

<figure anchor="padchunkformat">
<artwork>
 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x84   |   Flags=0     |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
\                         Padding Data                          /
/                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t><list style="hanging">
<t hangText="Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This value MUST be set to 0x84 for all PAD chunks.</t>
<t hangText="Flags: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This value SHOULD be set to zero on transmit and MUST be ignored on receipt.</t>
<t hangText="Length: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
This value holds the length of the Padding Data plus 4.</t>
<t hangText="Padding Data: n bytes (unsigned integer)">
<vspace blankLines="0"/>
This holds the Padding Data. The Padding Data MUST be ignored by the receiver.</t>
</list>
The receiver of the PAD chunk MUST discard this chunk and continue
processing the rest of the chunks in the packet. 
Please note that this is also the required processing behavior
for any unknown chunk having the same highest-order two bits of
the type as the PAD chunk.</t>
</section>

<section title="Padding Parameter (PAD)">
<t>This parameter is used to pad an INIT chunk. A PAD parameter can
be used to enlarge the INIT chunk by 4 bytes as the minimum to the
maximum size of the INIT chunk in steps of 4 bytes.
An INIT chunk MAY contain multiple PAD parameters.</t>

<figure anchor="chunksparameterformat">
<artwork>
 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Parameter Type = 0x8005   |       Parameter Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
\                          Padding Data                         \
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t><list style="hanging">
<t hangText="Parameter Type: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
This value MUST be set to 0x8005.</t>
<t hangText="Parameter Length: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
This value holds the length of the Padding Data plus 4.</t>
</list>
The PAD parameter MAY be included only in the INIT chunk. It MUST NOT
be included in any other chunk.
The receiver of the PAD parameter MUST silently discard this parameter and
continue processing the rest of the  INIT chunk. This means that
the size of the generated COOKIE parameter in the INIT-ACK
MUST NOT depend on the existence of the PAD parameter
in the INIT chunk. A receiver of a PAD parameter MUST NOT include
the PAD parameter within any State Cookie parameter it generates.</t>
</section>

<?rfc needLines="7"?>
<section title="IANA Considerations">

<t>This document is the reference for all registrations
described in this section. All registrations have been listed
in the document available at 
<xref target="URL-sctp-parameters">sctp-parameters</xref>.
The changes are described below.</t>

<section title="A New Chunk Type">
<t>A chunk type for the PAD chunk has been assigned by IANA.
The value has been assigned as described in <xref target="padchunkformat"/>.
The following has been added to the "CHUNK TYPES" table of
<xref target="URL-sctp-parameters">sctp-parameters</xref>:

<figure>
<artwork>
CHUNK TYPES

ID Value    Chunk Type                                     Reference
--------    ----------                                     ---------
132(0x84)   Padding Chunk (PAD)                            [RFC4820]
</artwork>
</figure>
<!-- RFC Editor Comment: Should this match what is on IANAs site
exactly?  IANA has the following (without (0x84)):
132        - Padding Chunk (PAD)  [RFC-ietf-tsvwg-sctp-padding-02.txt]
-->

</t>
</section>

<section title="A New Parameter Type">
<t>A parameter type has been assigned for the PAD parameter by IANA.
The value has been assigned as described in <xref target="chunksparameterformat"/>.
The following has been added to the "CHUNK PARAMETER TYPES" table in
<xref target="URL-sctp-parameters">sctp-parameters</xref>:
<vspace blankLines="1" />
INIT Chunk Parameter Types
<figure>
<artwork>
Chunk Parameter Type			   Value
--------------------			   -----
Padding                            32773(0x8005)
</artwork>
</figure>
</t>
</section>
</section>

<section title="Security Considerations">
<t>This document does not add any additional security considerations
to the ones given in <xref target="RFC2960">RFC 2960</xref>.</t>
</section>

<section anchor="acks" title="Acknowledgments">
<t>The authors wish to thank
Matthew J. Zekauskas and Lars Eggert
for their invaluable comments.</t>
</section>

</middle>

<back>

<?rfc needLines="10"?>

<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2960" ?>
</references>

<references title='Informative References'>

<reference anchor="URL-sctp-parameters"
	    target="http://www.iana.org/assignments/sctp-parameters">
<front>
<title>IANA registry</title>
<author>
<organization />
</author>
<seriesInfo name="" value=""/>
</front>
</reference>

<reference anchor='RFC4821'>
<front>
<title>Packetization Layer Path MTU Discovery</title>
<author initials='M' surname='Mathis' fullname='Matt Mathis'>
    <organization />
</author>
<author initials='J' surname='Heffner' fullname='John Heffner'>
    <organization />
</author>
<date month='March' year='2007' />
</front>
<seriesInfo name='RFC' value='4821' />
</reference>

</references>
</back>
</rfc>
