Internet DRAFT - draft-dupont-ipv6-payload
draft-dupont-ipv6-payload
Internet Engineering Task Force Francis Dupont
INTERNET DRAFT ENST Bretagne
Expires in August 2002 March 2002
The IPv6 Payload Header
<draft-dupont-ipv6-payload-01.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Abstract
This draft describes a method by which many IPv6 payload data
bodies may be encapsulated in a single IPv6 datagram using a new
non-terminal header will contain both a payload and necessary
fields (like a ``next header'' field) allowing header chaining.
This document specifies how two packets can be merged into a single
one and the reverse one-step operation. But the main purpose is to
provide a basis to discussions about the pros and cons of such a
mechanism (note: this was done).
draft-dupont-ipv6-payload-01.txt [Page 1]
INTERNET-DRAFT IPv6 payload header Mar 2002
1. Introduction
The IPv6 [1] packet structure is a chain of any number of non-terminal
headers ending by a terminal ``upper-layer'' header with the payload.
By definition there is one and only one terminal header per packet.
This memo proposes a mechanism which removes this limitation, and
collects the pros and cons of such a mechanism.
2. Changes From Previous Draft
The mechanism itself was moved to an annex because there was a
strong consensus against it at the 52th IETF meeting at Salt Lake
City when it was presented at the IPv6 working group session. The
relevant part of the proceeding is available in a second annex.
3. Discussion (Introduction From Previous Draft)
Even specialized similar mechanisms (like piggy-backing of
Binding Updates in IPv6 mobility [10]) are known to interfere
with other mechanisms as path MTU discovery [2], IPsec [3]
selector in SPD or RObust Header Compression [4].
If the path MTU is known per destination, a good implementation
should reduce the impact of the payload header. For instance,
no too large packets should be sent.
The IPsec SPD selector problem is harder because it cannot really
work with non-terminal headers. Outside of this untractable case,
the split procedure will give individual packets to the Security
Policy Database check with clear upper-layer possible selectors.
ROHC issue seems even harder but if the payload header mechanism
is proved to have bad interactions with (another) header
compression one, the split procedure can remove its visible effects
including bad effects.
One can believe with a split procedure or a similar predefined
procedure the payload header class of mechanisms has only
advantages as soon as they are widely supported but things are
not so simple. There are two main reasons to use this kind of
mechanisms: efficiency and atomicity.
draft-dupont-ipv6-payload-01.txt [Page 2]
INTERNET-DRAFT IPv6 payload header Mar 2002
Efficiency because this reduces the number of bytes sent over
the Internet (poor argument) and because this reduces the number
of packets sent over some links with a medium which has a notable
acquisition delay. This is a good argument but a link dedicated
mechanism is do a better job. For this problem a solution in
the IETF scope should be a compatible with or part of ROHC device
which mainly reduces the number of frames.
The atomicity idea is very different: if two control messages
are strongly related, for instance a Binding Update and a RSVP
QoS negotiation, one can want to get them together in the same
smaller packet.
11. Security and IANA Considerations
Not yet!
12. Acknowledgments
The last document [11] about an IPv6 payload header was presented
by Robert Elz in 1995. In a long and warm discussion about the
piggy-backing feature of Mobile IPv6 in the mobile-ip WG list,
some of them, including Eric Nordmark, proposed to reopen the
general idea in order to get an argumented discussion in the
proper place, i.e. the IPv6 WG (aka IPngWG) of the Internet area.
The previous version of the draft was presented and received a not
rough at all consensus against it (so it was in fact very
successful). It was decided to produce a second version in order
to properly kill this bad idea.
13. Normative References
[1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[2] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[3] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[4] C. Bormann & all, "RObust Header Compression (ROHC): ...",
RFC 3095, July 2001.
draft-dupont-ipv6-payload-01.txt [Page 3]
INTERNET-DRAFT IPv6 payload header Mar 2002
[5] D. Borman, S. Deering, R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[6] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.
[7] A. Shacham, R. Monsour, R. Pereira, M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[8] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit
Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[9] A. Conta, S. Deering, "Internet Control Message Protocol
(ICMPv6) ... Specification", RFC 2463, December 1998.
14. Informative References
[10] D. Johnson, C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-15.txt, July 2001.
[11] R. Elz, "The IPv6 Payload Header",
draft-kre-ipv6-payload-01.txt, October 1995.
[12] F. Dupont, "IPv6 destination option header clarification",
draft-dupont-destoptupd-01.txt, November 2001.
15. Author's Address
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
BP 78
35512 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
EMail: Francis.Dupont@enst-bretagne.fr
draft-dupont-ipv6-payload-01.txt [Page 4]
INTERNET-DRAFT IPv6 payload header Mar 2002
ANNEX I. The IPv6 Payload Header
I.1. New Header
A new IPv6 header is proposed to implement the functionality. All
IPv6 nodes must be able to receive and process this header correctly,
though nodes need not send them if the functionality is not required.
The header is a non-terminal [12] one, i.e. it contains a next
header field to allow chaining to further IPv6 headers, often, though
without being required, more of this new header. The header is
followed by a data field, defined as carrying other IPv6 protocol
data, which is interpreted just as if the payload header, and any
other similar headers earlier in the packet, had not existed, and the
packet ended at the point where the enclosed data ends. The header
also contains a Header Length field, giving the length of the header,
an Internal Next Header type field, giving the IP protocol number of
the (first) enclosed header, a Pad Length field, giving the length of
the trailing padding in octets, and a Data Info field, giving
optionally the first four octets of the original packet containing
the data, i.e. the original version, traffic class and flow label.
I.2. Layout
0 7 8 15 16 23 24 31
-----------------------------------------------------------------
| | | | |
| Next Header | Header Length | Int Nxt Hdr | Pad Length |
| | | | |
-----------------------------------------------------------------
| |
| Data Info |
| |
-----------------------------------------------------------------
| |
| Data (8 * Length octets) ... |
| |
| /------------------------------------|
| / Trailing Padding |
-------------------------/---------------------------------------
I.3. Header Values
The IPv6 payload header type is to be defined by the IANA. For
testing purpose only the value 144 can be temporary used.
draft-dupont-ipv6-payload-01.txt [Page 5]
INTERNET-DRAFT IPv6 payload header Mar 2002
I.4. Header Fields
The IPv6 payload header contains fields with the following meanings.
I.4.1. Next Header
This 8 bit field contains the protocol type of the header that
follows the Payload Header and associated data. Its value is taken
from the list of IP protocol types regularly published by the IANA.
I.4.2. Header Length
This 8 bit unsigned integer field contains the length of the whole
payload header in 8 octet units, not including the first 8 octets.
BTW this is the length of the data field including the trailing
padding. This limits the possible length of the payload to 2040
octets, this is not considered as an issue.
I.4.3. Internal Next Header
This 8 bit field contains the protocol type of the header that is to
enclosed at the start of the data field covered by the payload
header. Its value is taken from the list of IP protocol types
regularly published by the IANA.
I.4.4. Pad Length
This 8 bit unsigned integer field contains the number of padding
octets that have to be appended to the Data field in order to make the
whole length a multiple of 8 in octets as described in the next
subsection.
I.4.5. Data
The first octet of this field is also the first octet of a header
of the type defined by the ``Internal Next Header'' field and is
aligned on a 8 octet boundary. If the length of this field is not a
multiple of 8, then enough additional octets, of undefined content
or meaning, are appended to cause the overall length of the total
structure to be a multiple of 8 in octets. At most 7, and of course,
no less than 0, such additional octets are added.
draft-dupont-ipv6-payload-01.txt [Page 6]
INTERNET-DRAFT IPv6 payload header Mar 2002
I.5. Use of the Payload Header
The data field following a payload header may contain any header
valid in an IPv6 packet, other than those intended to be examined by
nodes other than the ultimate source and destination of the packet.
Note that this does not preclude enclosing encapsulated IPv6
datagrams as objects carried in a payload header, such being, for
this purpose anyway, considered to be two separate transactions, one
between the ultimate source and destination of the encapsulated
packet, and one between the entity encapsulating, and the entity
decapsulating.
However IPv6 routing header, hop-by-hop options, and fragmentation
headers, not within an encapsulated IPv6 packet, are undefined within
a Payload Header. Any node that receives such a packet may ignore
the packet, return an ICMP parameter problem, with the pointer
indicating the first octet of the undefined header encountered, or
continue processing the packet as if the payload header was not
present, at its option.
This limitation applies to any case where intended en route
processing should be different between two packets to merge, even
if a logical split operation can be applied in order to recover
hidden differences. For the same kind of reasons, the payload header
should be used end-to-end.
The last limitation avoids a too complex case in the following
procedures: no non-terminal header which contains a packet length
field (i.e. another IP header or a jumbogram [5] option) or which can
hide a next header or a header length field (i.e. ESP [6] or
IPComp [7]) should be considered for sharing.
I.6. Merging Procedure (One Step)
If two small enough packets are to be send to the same destination
still in a sending queue, or an upper-layer service element is to
be sent with the next packet or on timeout (piggy-backing situation
[10]), a merging operation can be applied. The benefits are:
- a packet with smaller length than the sum of the lengths of the
two packets (from sharing).
- one packet in place of two packets (for instance when the medium
acquisition delay is large compared to the time to transmit
many bits).
draft-dupont-ipv6-payload-01.txt [Page 7]
INTERNET-DRAFT IPv6 payload header Mar 2002
Of course this operation can be repeated in order to merge more than
two packets but if possible the order should be kept and merging
should be linear (i.e. payload headers should be chained, not
included into themselves). In the uncommon case where the IPv6
header payload length is smaller than it should be the packet
should be trimmed (i.e. extra octets removed).
The two packets must be scanned in order to verify if the two
packets can be merged (i.e. if there is no exception listed in the
previous section or if the resulting packet will be too large or
the payload header not large enough) and if non-terminal header
chains are identical i.e. can/will be shared. So each packet begins
by a shared part followed by a not-shared part which includes the
terminal stuff.
The not-shared part of the second packet is put a new IPv6 payload
header with in the internal next header field the type of the
first not-shared header (which can be found in the next header
field of the last shared header). Padding is appended if needed
and its length is put in the pad length field. If the first four
octets of the (second) packet are different from the first packet
then they should be saved in the data info field else the data info
field must be set to zero.
Then the IPv6 payload header must be inserted into the first packet
header chain between the shared and the not-shared parts, i.e. the
next header field of the last shared header is copied in the IPv6
payload header and set to the type of the payload header, and the
IPv6 header payload length adjusted according to the IPv6 payload
header length in octets (i.e. 8 + 8 * Header Length).
The merged packet should replace in the sending queue the first
(to be sent) packet. The idea is to try to merge a new packet with
waiting to be sent packets to the same destination when the new
packet will be added in the queue.
I.7. Split Procedure (One Step)
The split procedure must be applied by the receiving end node but
is provided as a logical operation to intermediate routers which
need to look at/into further inside packets (in order to make
individual packet mechanisms still available).
draft-dupont-ipv6-payload-01.txt [Page 8]
INTERNET-DRAFT IPv6 payload header Mar 2002
This description assumes that there is a reception queue where
incoming packets are put in order waiting for processing.
When the header processing encounters a payload header, the already
processed part (the shared part) is duplicated and the further
processing is divided into two phases.
The first phase builds a packet with a copy of the already
processed part and the data field of the payload header, if the
data info field is not zero then it is copied into the first four
octets of the IPv6 header, the internal next header is copied to
the next header field of the last processed header (which should
have contained the type of the IPv6 payload header) and the IPv6
header length must be set (to the sum of the length of the data
field and of the length of the already processed part not
including the IPv6 header).
If the traffic class or the flow label is restored when an en
route processing should have changed it (ECN [8] Congestion
Experienced set) the en route processing should be simulated.
Then the rebuilt packet should be put in the front (i.e. to be
processed next) of the reception queue. After the phase two the
packet processing should be immediately resumed after the last
already processed header.
If there are more than one payload header the merge procedure puts
recent packets before olders and the stack structure of the queue
will restore the original order.
The phase two removes the payload header from the packet, leaving
the (original) already processed and the remaining parts. The chain
must be restored, i.e. the next header field of the payload header
must be copied into the next header field of the last processed
header (same remark than for phase one). The IPv6 header payload
length must be adjusted according to the IPv6 payload header length
in octets.
Then the next header (which has its type into the last processed
header) must be processed, i.e. (header) processing resumes after
the last already processed header.
draft-dupont-ipv6-payload-01.txt [Page 9]
INTERNET-DRAFT IPv6 payload header Mar 2002
I.8. Semantics
A packet containing a payload header shall be semantically
equivalent to two packets, received in the reversed order that they
are present in the combined packet - that is, the body of the payload
second, and the rest of the packet first, with suitable adjustments
assumed to have been made to all headers that precede the payload
header to make them appropriate to each of the resulting packets.
If it should become necessary to send an ICMP [9] error packet in
response to a received packet containing a payload header:
- if the error is detected before the payload header processing
(aka the split procedure), the returned packet contents shall be
the original IPv6 packet (or as much of it as will fit).
- if the error is detected during the payload header processing,
the returned packet contents must be the original IPv6 packet
(same remark). Possible errors are unrecognized ``next header''
or ``internal next header'', bad ``header length'' or ``pad
length''.
- if the error is detected after the payload header processing,
the returned packet contents shall be the a packet produced by
this processing or the original one.
The ICMP error packet reception processing should support returned
packets with a payload header, i.e. should be able to apply the
split procedure on it with the proper computation of the ``pointer''
value.
draft-dupont-ipv6-payload-01.txt [Page 10]
INTERNET-DRAFT IPv6 payload header Mar 2002
ANNEX II. The 52th IETF Proceeding
The IPv6 Payload Header, Francis Dupont
----------------------------------------
<draft-dupont-ipv6-payload-00.txt>
Presented the idea and its origin: old draft by Robert Elz, and
piggy-backing discussion in the mobile-ip mailing-list
Pros & Cons:
+ reduce the number of delays for medium acquisition
+ the "atomicity" argument: if a binding update and a RSVP
renegotiation are in the same packet they should be processed in
the same time.
- this is a link-layer issue
Wants feed back from w.g. Good idea, bad idea, etc.
Steve Deering: This approach was proposed before and the w.g. choose
to not adopt it. The issue comes up when where media access cost is
high. If this is motivation, best to handle at level 2, not at IP
layer.
Francis Dupont: Agrees, not in favor of his own proposal!
Brian Carpenter: This will break boxes that look inside of packets
like firewalls, etc.
Erik Nordmark: Some folks in Mobile IPv6 don't like L2 piggy
backing. L2 approach doesn't help with outgoing traffic. Might be
useful in some environments or some specific cases. Useful to
explore. People who want to use this will need to deal with the
issues.
Hesham Soliman: Dangerous to combine things that are not related to
each other in same packet. They might need different QOS, special
handling, etc.
Strong consensus to not continue this work. Francis Dupont will write
draft that discusses pros and cons and show why this should not be
done.
draft-dupont-ipv6-payload-01.txt [Page 11]
