Skip to main content

Adaptation Layer Fragmentation Indication

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Carsten Bormann
Last updated 2014-03-13 (Latest revision 2013-09-09)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


IPv6 defines a minimum MTU of 1280 bytes. Many link layers are more limited in the maximum size of packets they can communicate. In order to enable the transport of IP packets that are too large for these link layers, typically their IP adaptation layers define a segmentation or fragmentation scheme to transport an IP packet in a sequence of multiple link layer packets. Often, adaption layer fragmentation schemes reduce some performance metric, such as the packet delivery probability. Application or transport protocols may be able to reduce the maximum size of packets they send, e.g. by transport layer segmentation or choice of application layer data object size, which may have less of a performance impact. It would therefore be desirable for them to know about any adaptation layer fragmentation that is going on, so they can choose packet sizes that minimize adaptation layer fragmentation. At the IP layer, fragmentation can be detected using a number of mechanisms used in Packetization Layer Path MTU Discovery [RFC4821]. However, adaptation layer fragmentation schemes are often designed to be "transparent", i.e. there is no way at higher layers to find out whether they had to be employed (except maybe by elaborate measurement schemes targeting one of the impacted performance metrics; this approach does not appear to be viable) [WEI]. The present specification defines two alternative mechanisms for IPv6 adaptation layers to indicate the presence of adaptation layer fragmentation on one or more hops on the path from an IP sender to an IP receiver, and to provide an indication of preferred (smaller) packet sizes on these hops. One design is based on the the IPv6 design and probably doesn't work on the Internet. The other design goes strictly against the IPv6 design and probably works well on the Internet. Comments are appreciated and should go to the mailing list.


Carsten Bormann

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)