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]