Internet DRAFT - draft-eddy-ipv6-overhead
draft-eddy-ipv6-overhead
Network Working Group W. Eddy
Internet-Draft Verizon Federal Network Systems
Expires: November 9, 2006 May 8, 2006
Comparison of IPv4 and IPv6 Header Overhead
draft-eddy-ipv6-overhead-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on November 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides an analysis and comparison of IPv4 and IPv6
header sizes under various circumstances. The goal of this document
is to provide hard evidence for use in frequent discussions regarding
transition, where header overhead comes up as an issue used to
portray IPv6 depolyment as untenable. The results show that for
links that are not fully utilized, the IPv6 overhead would only add a
few percent to their load over what IPv4 implies, while for congested
links, we note that header compression techniques for IPv6 are at
least as effective as those for IPv4. This demonstrates that the
Eddy Expires November 9, 2006 [Page 1]
Internet-Draft IP Header Overhead May 2006
header overhead argument against IPv6 is misinformed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Case 0: Boundary Conditions . . . . . . . . . . . . . . . 7
3.2 Case 1: Normal Range of Behavior . . . . . . . . . . . . . 8
3.3 Case 2: Fragmentation . . . . . . . . . . . . . . . . . . 9
3.4 Case 3: Jumbograms . . . . . . . . . . . . . . . . . . . . 10
3.5 Case 4: Mobility . . . . . . . . . . . . . . . . . . . . . 11
4. Summary of Findings . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
A. Useful Numeric Values . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19
Eddy Expires November 9, 2006 [Page 2]
Internet-Draft IP Header Overhead May 2006
1. Introduction
While IPv4 has achieved widespread use and acclaim, its intended
successor, IPv6, is still facing some hurdles in large-scale
deployment. In both aeronautical networking and space networks a
move towards network-centric operations and away from application-
specific point-to-point links is occuring. In multiple groups that
are attempting to define aeronautical or space networking
architectures, the use of Internet protocols is well-accepted, but
there is considerable uncertainty on whether to use IPv4, IPv6, or a
dual-stack.
It is the technical opinion of many that IPv6 is favorable, due to
some of its features (mobility and security are particularly
important for network-centric operations). We have also seen IPv4
brought forward as a favored choice by others based on the logic that
it has lower "overhead" than IPv6, and that aeronautical and space
links may often be rather constrained. While it is undeniable that
the IPv6 base header is larger than IPv4's, these arguments tend to
be "hand-waves" that are not based on well-quantified data.
In this document, we systematically consider IPv4 and IPv6 header
overhead in several case studies. Our goal is to provide stronger
material for use in discussions regarding the comparison between IPv4
and IPv6 header sizes, and their effect on link loading. Companion
documents debunk the related myth that IPv6 is not yet mature enough
for production use [EIv06], and compare the feature sets of IPv6 and
IPv4 [EIs06].
Before proceeding into this study, the reader should make an
assessment of the potential relevence of this issue. For networks
that are only lightly loaded, where there is very little congestion
or delay, what effect will increasing the size of packets by only a
few percent have? Contrast this with chronically oversubscribed
links, perhaps due to low physical layer capacities, where there
might be substantial queuing, and consider what effect adding several
dozen bytes to each packet has. Clearly this issue may or may not be
important under different assumptions. In the cases where it is
important, it is likely that header compression techniques are in
use, and so the real trade study should be between the effectiveness
of IPv4 and IPv6 header compression mechanisms. Current methods are
able to compress IPv6 headers at least as well, if not better, than
IPv4 headers [RFC3095].
The problem of header overhead in both IPv4 and IPv6 has long been
recognized and a large amount of work has gone into header
compression techniques. The IETF Robust Header Compression Working
Group, for instance, has delivered particularly effective solutions
Eddy Expires November 9, 2006 [Page 3]
Internet-Draft IP Header Overhead May 2006
for both versions of IP [RFC3843] as well as additional protocols
layered over IP. It is our primary advice that for under-utilized
links, header overhead is not a significant consideration, while for
low-speed or congested links, current header compression technologies
are fully sufficient and make this topic moot. The remainder of this
document assumes no header compression technique is in use, and then
presents quantized evidence that might be compared to the utilization
levels of user LANs or provider backbones to see how insignificant
the difference in overhead between IP versions is.
Section 2 describes the basic terminology and proceedure used in this
study and introduces the scenarios considered in the case studies in
Section 3. A brief summarization of the results is given in
Section 4. Appendix A contains some numeric quantities that are used
in the analysis.
Eddy Expires November 9, 2006 [Page 4]
Internet-Draft IP Header Overhead May 2006
2. Methodology
For the purposes of this study, we will consider the "overhead" to
consist solely of the IP-layer headers, options, and extension
headers. To be specific:
o We define the IP-layer Service Data Unit (SDU) as whatever buffer
of bytes is passed down from a transport protocol (or other layer
above IP), to be sent over the network using IP. The IP-layer
Protocol Data Unit (PDU) that is constructed then consists of the
SDU combined with IP Protocol Control Information (PCI). This
follows the nomenclature used in the ISO/OSI reference model.
o We assume that only the PCI portion of the IP-layer PDU varies
between IPv4 and IPv6. Thus the difference in overhead can be
determined strictly from the size of the PCI. There are certain
applications that may carry IP addresses inside their SDUs (e.g.
FTP or IKE), but our assumption is that this has only a relatively
small affect overall (in FTP, the file transfered is usually much
longer than the length of an IPv6 address, and in IKE,
certificates and keying material are similarly much larger than an
IPv6 address).
o A few components of the PCI may be identical between IPv4 and
IPv6. For instance, the IPsec Authentication Header has the same
size and form when used with IPv4 as it does with IPv6. In this
study, we will only consider PCI components that differ between
the two versions of IP.
Measuring the PCI as a raw number of bytes is useful, but it is also
informative to view the lengths of the IPv4 PCI and IPv6 PCI as
percentages of the total PDU. In the case of relatively small SDUs,
a large PCI size is significant, but in the case of larger SDUs (as
used in bulk file transfer), a difference of even several dozen bytes
in the PCI size will have little effect on the percentage of the PDU
consumed by the PCI.
Since fragmentation of datagrams is treated differently in the IPv4
and IPv6 protocols, we will consider what happens when PDUs known to
be larger than the Path MTU (PMTU) are handled by each version of IP,
in addition to PDUs that fit within the PMTU.
Even with these considerations, this is a somewhat naive comparison
since the overhead implied by the selection of a network layer
protocol also consists of several factors in addition to the per-
packet headers. This includes the size of updates in routing
protocols (e.g. OSPF and BGP), the address fields in queries and
responses to address resolution protocols (e.g. DNS and ARP/ND), and
Eddy Expires November 9, 2006 [Page 5]
Internet-Draft IP Header Overhead May 2006
the configuration protocol packets (e.g. DHCP), to name a few
additional contributions. Compared to the per-packet overhead,
however, these should be negligible contributions.
We define a number of specific cases for which we compute IP-layer
overhead:
Case 0: (a) Consider a 0-byte SDU (i.e. an empty payload). (b) Then
consider a 65,515-byte SDU. Assume the PMTU in both of these
cases is greater than the PDU size.
Case 1: Consider an N-byte SDU (for N > 0), when the PMTU is assumed
to be greater than the PDU size.
Case 2: Consider an N-byte SDU, when the PMTU is assumed to be less
than N, but greater than (N+(PCI*2))/2 (i.e. the SDU can fit
within two IP packet fragments). This demonstrates a simple case
of fragmentation, where only two fragments are needed.
Case 3: Consider an N-byte SDU, where N > 65,535, and the PMTU is
large enough to support the IPv6 PCI and SDU. This allows for
consideration of jumbogram support in IPv6, which IPv4 lacks.
Case 4: Consider an N-byte SDU sent between a mobile node (MN) and a
corresponding node (CN), where the PMTU is greater than the PDU
size, and where the MN and CN support the standard mobility
features of IPv4 or IPv6 (including the route optimization feature
which is a part of IPv6, but not IPv4).
Eddy Expires November 9, 2006 [Page 6]
Internet-Draft IP Header Overhead May 2006
3. Case Studies
In this section, each of the specific cases listed previously is
further described and analyzed.
3.1 Case 0: Boundary Conditions
One way the reader might view the two subcases presented here of
minimum and maximum-sized packets, is as demonstration of the
futility of even attempting to gauge header overhead without any
knowledge of what the offered transport/application load is. For
small packets, any network header at all seems extraordinarily
inefficient since in either IP version the node IP addresses alone
may be larger than the data. For large packets, the reverse is true.
To start, it should be noted that the first part of this case is
somewhat unrealistic. In reality, a 0-byte SDU would never be passed
to the IP layer, since to even address a particular application or
service requires a transport header, and even IP-layer signalling
occurs using ICMP datagrams as SDUs, so there is no practical use for
a 0-byte SDU. This case simply illustrates a hard limit on the
smallest size an IP PDU can take, and the worst relative amount of
the PDU that the PCI can consume.
If it were possible to send a 0-byte PDU, then the overheads for IPv4
and IPv6 would be:
IPv4 PCI (IPv4 Base Header): 20 bytes or 100% of the PDU
IPv6 PCI (IPv6 Base Header): 40 bytes or 100% of the PDU
IPv4 and IPv6 both have the same worst-case bound on the percentage
of the PDU that their headers can take up, although the base IPv6
header is twice as large as the base IPv4 header. Since in reality,
many types of link pad small frames out to reach some minimum length,
small packets (those of only a few bytes in the SDU), may still be
under the link's minimum and require padding. This means that even
measuring the IP header overhead for small packets may be pointless,
since even if the IP header were compressed to 0-bytes, the link
would apply padding to the frame. For instance, Ethernet frames have
a minimum frame size of 64 bytes, and Gigabit Ethernet's minimum is
even larger at 520 bytes. In the case of standard Ethernet, with 18
bytes of frame header/trailer, IPv6 SDUs of up to 6 bytes and IPv4
SDUs of 26 bytes have the same real overhead.
At the other end of the spectrum, the largest possible IPv4 packet is
65,535 bytes, due to the 16-bit IPv4 total length field. IPv6 has a
similar 16-bit field, but its semantics differ, in that it encodes
Eddy Expires November 9, 2006 [Page 7]
Internet-Draft IP Header Overhead May 2006
the payload length. This means that a single IPv6 packet may be
larger than an IPv4 one by the size of the IPv6 header plus the size
of the IPv4 header (60 bytes using only base headers). Given a PDU
of 65,515 bytes (the maximum possible in IPv4):
IPv4 PCI (IPv4 Base Header): 20 bytes or 0.03% of the PDU
IPv6 PCI (IPv6 Base Header): 40 bytes or 0.06% of the PDU
Neither the IPv4 nor IPv6 headers make up any significant portion at
all of the PDU in the case of maximally-sized standard packets. The
case of jumbograms considered later in Case 3, shows that IPv6 is
actually capable of being even more efficient than this, but at this
scale it is almost absurd to even consider.
3.2 Case 1: Normal Range of Behavior
This case considers an IP packet that can be sent end-to-end with no
fragmentation. This is by far the most prevalent case under normal
operating conditions, and so the figures presented for this case
should have the most bearing on a practical determination on the
significance of the header overhead issue.
IPv4 PCI (IPv4 Base Header): 20 bytes or (20/(N+20) * 100)% of PDU
IPv6 PCI (IPv6 Base Header): 40 bytes or (40/(N+40) * 100)% of PDU
Since the PCI is simple (a single IP header) in the case of each
protocol version, the impact of the PCI on the PDU is easy to
understand. For instance, on a 48-byte SDU (the minimum IPv4 MTU
[RFC0791], minus the IPv4 base header size), the IPv4 and IPv6 PCIs
represent 29.41% and 58.82% of the PDU, respectively. For a 1240-
byte SDU (the minimum IPv6 MTU, minus the IPv6 base header size), the
IPv4 and IPv6 PCIs represent 1.58% and 3.13% of the PDU,
respectively.
While it is true that the IPv4 overhead is half that of the IPv6
overhead in this case, with a reasonable-sized SDU, as would be used
by applications such as bulk-transfer, both protocol's headers are of
relatively little consequence, only making up a few percent of the
PDU. Note that when comparing the IPv4 base header size to the IPv4
minimum MTU (29.41%) and the IPv6 base header to the IPv6 minimum MTU
(3.13%), the results of the requirement to support larger MTUs on
IPv6 links are seen to allow for keeping a much tighter handle on the
header overhead than was possible with IPv4's requirement.
As an example of interactive traffic that sends small packets,
consider the SSH protocol when the user types a character at a time
Eddy Expires November 9, 2006 [Page 8]
Internet-Draft IP Header Overhead May 2006
into a remote shell. A single typed character causes a 48-byte block
of application data to be passed to TCP. TCP puts a 20-byte base
header onto this, and then (usually) a 12 byte Timestamp Option, so
an 80-byte SDU (48+20+12) is passed to IP, regardless of whether IPv4
or IPv6 is being used. With base IP-layer headers then, IPv4 PCI
takes up exactly one fifth of the PDU, while the IPv6 PCI takes up
one third of the PDU.
We can also consider very large MTUs, such as those that might be
used on a fiber-optic network bus in an aircraft or space vehicle.
The FDDI MTU of 4352 bytes allows a 4332-byte SDU with IPv4 and a
4312-byte SDU with IPv6 base headers. Respectively, the PCIs are
0.46% and 0.92% of the PDU. OC-3 packet over SONET interfaces
default to a similarly sized MTU of 4470 bytes, giving PCIs that may
be as little as 0.45% and 0.89% of the PDU. In the case of such
links, the header overhead argument against IPv6 seems largely
irrelevent.
3.3 Case 2: Fragmentation
IPv4 and IPv6 take completely different approaches to fragmentation.
In IPv4, fragmentation of a datagram can occur at any point in the
network where a particular link's MTU is too small to accomodate the
entire packet (assuming the Don't Fragment bit is not set); i.e. in
IPv4, fragmentation is a router-level function. In IPv6, a router
never fragements a packet. If an IPv6 packet is larger than a link
MTU, then an ICMPv6 Packet Too Big message is sent to the packet's
source, and the packet is dropped. Fragmentation has been removed
from a router's responsibilities in IPv6, and is strictly an end-
host's task to perform, as needed. For this reason, the header
overhead during a fragmentation scenario in IPv4 and IPv6 has to be
specially compared, since it is static across the path in IPv6, but
differs after the router that performs it in IPv4. We assume that
from a prior failure or PMTU probing, the IPv6 end-host already knows
that fragmentation is required here, so that a failed transmission
does not factor into the overhead computed.
First consider a simple case that only requires a packet to be
segmented into two fragments:
IPv4 PCI, before fragmenting router (IPv4 Base Header): 20 bytes
or (20/(N+20) * 100)% of PDU
IPv4 PCI, after fragmenting router (2x IPv4 Base Headers): 40
bytes or (40/(N+40) * 100)% of PDU
Eddy Expires November 9, 2006 [Page 9]
Internet-Draft IP Header Overhead May 2006
IPv6 PCI, (2x IPv6 Base Headers and IPv6 Fragment Headers): 96
bytes or (96/(N+96) * 100)% of PDU
As an example, consider the case of a PMTU of 1280 bytes (the IPv6
minimum), and an SDU of 1400 bytes, where the MTU of the first-hop
link is greater than 1420 bytes plus link headers (e.g. an Ethernet).
An IPv4 host will send a single 1420 byte PDU on the first link, with
PCI overhead of 1.41%. This IPv4 packet then becomes fragmented, at
some point, into two IPv4 packets, one of which is of size 1280 bytes
(1260 bytes of the original SDU and 20 of IPv4 header) and another of
size 160 (140 bytes of the original SDU and 20 of IPv4 header). The
first new packet has overhead of 1.56%, and the second has overhead
of 12.5%. Together, the combined PCI is 2.78% of the combined PDU
sizes.
Correspondingly, in IPv6, when it is not performing PMTU Discovery, a
host is likely to pro-actively fragment its packets to be within the
1280 byte guideline (or even lower to accomodate some tunneling). So
in a simple setting, the 1400-byte SDU might be fragmented into a
1280-byte and a 216-byte pair of packets (carrying 1232 and 168 bytes
of the original SDU each). These would have overhead of 3.75% and
22.22% each, and a combined overhead of 6.42%. This overhead applies
across the entire end-to-end path.
In general, transport protocols will either not send large SDUs to IP
(they will segment data at the transport layer), or they will perform
some form of PMTU Discovery (e.g. [RFC1191]) in order to send the
largest segments possible without causing fragmentation. In
transport protocol implementations that support IPv6, when reliable
operation is required of the transport, a resegmentation and
retransmission occurs in response to ICMPv6 Packet Too Big messages.
If the PMTU is not known, and the transport sends a segment that is
too large, which is then retransmitted as either multiple IPv6
fragments or resegmented transport data, then the overhead is
actually different than what we report here. The entire PDU sent in
the failed attempt can be considered overhead, as well as the ICMPv6
message in the reverse direction. If the SDU is resegmented by the
transport, then extra transport overhead is imposed.
3.4 Case 3: Jumbograms
One feature that is part of IPv6, but has no analogue in IPv4 is
jumbogram support [RFC2675]. This has proven useful mainly in super-
computing contexts, but to our knowledge has not been deployed
significantly outside this domain. It may be relevent to satellite
networks that interconnect supercomputers. A base IPv4 or IPv6
header includes a 16-bit field for the payload length, but IPv6 has
the Jumbo Payload option, which allows this field to be overidden
Eddy Expires November 9, 2006 [Page 10]
Internet-Draft IP Header Overhead May 2006
with a 32-bit field. This permits two IPv6 hosts with sufficient
knowledge of each other's and the network's capabilities to send
single packets of larger than 65,535 bytes.
The jumbogram feature of IPv6 allows larger SDUs than are possible in
IPv4, and thus can reduce both network layer and transport (or
higher) layer overhead. Sending a jumbogram requires coordinated
support from several protocol layers (at least the link, network, and
transport), and is only possible when as transport/application
actually has greater than 65,515 bytes of data to send. In the case
where this is possible in IPv6, compared to what would be required in
IPv4 for data totaling N (> 65,515) bytes:
IPv4 PCI (H=ceil(N/(65,535-20)) IPv4 Base Headers): H*20 bytes or
(H*20/(N+H*20) * 100)% of PDU
IPv6 PCI, (IPv6 Base Header, IPv6 Hop-by-Hop Option, and IPv6
Jumbo Payload Option): 48 bytes or (48/(N+48) * 100)% of PDU
As a quick example, consider N=200,000. Using IPv4, for maximum
efficiency, the transport could put this into 4 IPv4 SDUs (assuming
it either knew the link could support frames of this size, or did not
care about fragmentation for some reason). This would give an
overall header overhead of 0.03% of the PDU. If a single IPv6
jumbogram is used, the overhead is 0.02% of the PDU. In terms of
header overhead, this is not an area where their is neither an issue
nor any real difference between IPv4 and IPv6. Jumbograms allow a
transport to operate more efficiently by not segmenting and
reassembling data itself (usually involving slow memory copies), and
possibly allow the link to be more efficient, but they do not
significantly affect network layer protocol overhead.
3.5 Case 4: Mobility
Due to the way Mobile IPv4 operates (in its most efficient mode),
using triangle routing, packets will cross part of their path within
a tunnel, and then another part regularly, with no tunnel. Thus, the
IPv4 PCI size changes depending on where in the network it is
measured when Mobile IPv4 is used. On the other hand, we will assume
a Mobile IPv6 scenario where Route Optimization (RO) is supported,
such that packets go directly to their destination without tunneling.
This is a feature of IPv6 that has no analogue in IPv4. In a Mobile
IPv6 with RO setting, though, different PCI components get placed on
a packet depending on whether a mobile node (MN) is using a Care-of
Address as a "from" address in outgoing packets, whether the Care-of
Address is being used as a "to" address by a corresponding node (CN),
or whether Care-of Addresses are used in both directions (between two
MNs, both away from their "home" networks). The reader should refer
Eddy Expires November 9, 2006 [Page 11]
Internet-Draft IP Header Overhead May 2006
to a more detailed Mobile IP reference if these differences seem
confusing (e.g. [RFC3775]).
Mobile IPv4 and Mobile IPv6 (including NEMO) can also both operate in
a bidirectional tunnel mode, in which a direct path between MN and
CN, or vice-versa, is never taken, but packets in both directions are
always redirected through the home network. Since this case is even
less desirable than a triangle route, to simplify analysis, we do not
consider it here.
IPv4 PCI, inside tunnel (2x IPv4 Base Headers): 40 bytes or (40/
(N+40) * 100)% of PDU
IPv4 PCI, outside tunnel (IPv4 Base Header): 20 bytes or (20/
(N+20) * 100)% of PDU
IPv6 PCI, from CN to MN (IPv6 Base Header and Mobile IPv6 Type 2
Routing Header): 64 bytes or (64/(N+64) * 100)% of PDU
IPv6 PCI, from MN to CN (IPv6 Base Header, IPv6 Destination
Option, Mobile IPv6 Home Address Option, and padding): 64 bytes or
(64/(N+64) * 100)% of PDU
IPv6 PCI, between two MNs away from home (IPv6 Base Header, IPv6
Destination Option, Mobile IPv6 Home Address Option and Mobile
IPv6 Type 2 Routing Header, and padding): 88 bytes or (88/(N+88) *
100)% of PDU
In Mobile IPv4, the standard means of tunneling involves using two
IPv4 base headers, although other methods are available, some of
which can be more efficient. In some of the Mobile IPv6 with RO
cases, padding has to be added to the PCI to meet the IPv6
requirement of ending on a 64-bit boundary. Even when the IPv4 PCI
is at its largest, during the tunneled portion of its journey through
the network, it is still smaller than any of the IPv6 PCI
configurations when a mobile node is using a Care-of Address. In the
worst case of IPv6 overhead when both nodes are mobile and in foreign
networks, the 88 bytes of PCI would make up 6.87% of a 1280-byte PDU.
Eddy Expires November 9, 2006 [Page 12]
Internet-Draft IP Header Overhead May 2006
4. Summary of Findings
In general, header overhead at the IP layer is not a relevent concern
in most normal networks in use today for two reasons. The first is
that the bandwidth of many currently-used links (in LANs, and many
provider backbones) seems to be at least adequate, if not plentiful.
For very constrained links, where bandwidth is tight and demand may
be high (as in many types of wireless links), then header overhead
becomes an issue. But the second reason why IP header overhead is
not usually a valid concern, is that in these specific links, header
compression techniques can usually be applied to significantly reduce
IP overhead.
This document computed the size of IPv4 and IPv6 headers relative to
the size of the SDU from a transport/application protocol over a
number of different scenarios and configurations. Typically, IPv6
involved more overhead, but only differed from IPv4 within several
percent of the SDU's size, despite the base IPv6 header being twice
as big as the IPv4 header.
The impact of increasing the capabilities of a protocol at the
expense of blowing up the header overhead is not a new consideration.
One documented example is the analysis of the TCPng proposal in RFC
1705 [RFC1705]. The IPng design effort that resulted in IPv6
considered this and concluded with a 40-byte IPv6 header, a doubling
of IPv4's 20-byte header. Most of the case studies we have presented
in this document show that in reality, this difference in header size
is less significant than it seems at first.
Eddy Expires November 9, 2006 [Page 13]
Internet-Draft IP Header Overhead May 2006
5. Security Considerations
This informational document only contains a comparison of header
sizes. There are no security considerations.
Eddy Expires November 9, 2006 [Page 14]
Internet-Draft IP Header Overhead May 2006
6. Acknowledgements
Work on this document was performed at NASA's Glenn Research Center,
in support of the NASA Space Communications Architecture Working
Group (SCAWG), and the FAA/Eurocontrol Future Communications Study
(FCS). Will Ivancic and Joe Ishac of NASA contributed useful
comments on this document, as well as Terry Bell, Bob Dimond, and
Dave Stewart of Verizon.
7. Informative References
[EIs06] Eddy, W. and J. Ishac, "Comparison of IPv6 and IPv4
Features",
draft-eddy-ipv6-ipv4-comparison-00 Internet-Draft (work in
progress), May 2006.
[EIv06] Eddy, W. and W. Ivancic, "Assessment of IPv6 Maturity",
draft-eddy-ipv6-maturity-00 Internet-Draft (work in
progress), May 2006.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1705] Carlson, R. and D. Ficarella, "Six Virtual Inches to the
Left: The Problem with IPng", RFC 1705, October 1994.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843,
June 2004.
Eddy Expires November 9, 2006 [Page 15]
Internet-Draft IP Header Overhead May 2006
Author's Address
Wesley M. Eddy
Verizon Federal Network Systems
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
Email: weddy@grc.nasa.gov
Eddy Expires November 9, 2006 [Page 16]
Internet-Draft IP Header Overhead May 2006
Appendix A. Useful Numeric Values
This appendix compiles a list of various PCI components and their
sizing information, as well as some MTUs, limits, and link or
Subnetwork Defined Convergence Protocol (SNDCP) requirements that are
used in the case studies.
+-----------------------------------+----------+-----------+
| PCI Component | Size | Reference |
+-----------------------------------+----------+-----------+
| IPv4 Base Header | 20 bytes | [RFC0791] |
| | | |
| IPv6 Base Header | 40 bytes | [RFC2460] |
| | | |
| IPv6 Hop-by-Hop Options Header | 2 bytes | [RFC2460] |
| | | |
| IPv6 Destination Options Header | 2 bytes | [RFC2460] |
| | | |
| IPv6 Fragment Header | 8 bytes | [RFC2460] |
| | | |
| IPv6 Jumbo Payload Option | 6 bytes | [RFC2675] |
| | | |
| Mobile IPv6 Type 2 Routing Header | 24 bytes | [RFC3775] |
| | | |
| Mobile IPv6 Home Address Option | 18 bytes | [RFC3775] |
+-----------------------------------+----------+-----------+
Eddy Expires November 9, 2006 [Page 17]
Internet-Draft IP Header Overhead May 2006
+---------------------------------+---------------------------------+
| Size | Importance |
+---------------------------------+---------------------------------+
| 64 bytes | minimum transmitted Ethernet |
| | frame |
| | |
| 68 bytes | IPv4 (or SNDCP) minimum MTU |
| | |
| 520 bytes | minimum transmitted Gigabit |
| | Ethernet frame |
| | |
| 576 bytes | X.25 MTU and minimum packet |
| | that IPv4 hosts are required to |
| | handle |
| | |
| 1280 bytes | IPv6 (or SNDCP) minimum MTU |
| | |
| 1500 bytes | Ethernet IP MTU |
| | |
| 4352 bytes | FDDI IP MTU |
| | |
| 4470 bytes | OC-3 SONET IP MTU |
| | |
| 65535 bytes | IPv4 maximum total packet size, |
| | IPv6 maximum payload size |
+---------------------------------+---------------------------------+
Eddy Expires November 9, 2006 [Page 18]
Internet-Draft IP Header Overhead May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eddy Expires November 9, 2006 [Page 19]
