idnits 2.17.1 draft-eddy-ipv6-overhead-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 655. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 8, 2006) is 6564 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-eddy-ipv6-ipv4-comparison - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft Verizon Federal Network Systems 4 Expires: November 9, 2006 May 8, 2006 6 Comparison of IPv4 and IPv6 Header Overhead 7 draft-eddy-ipv6-overhead-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 9, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document provides an analysis and comparison of IPv4 and IPv6 41 header sizes under various circumstances. The goal of this document 42 is to provide hard evidence for use in frequent discussions regarding 43 transition, where header overhead comes up as an issue used to 44 portray IPv6 depolyment as untenable. The results show that for 45 links that are not fully utilized, the IPv6 overhead would only add a 46 few percent to their load over what IPv4 implies, while for congested 47 links, we note that header compression techniques for IPv6 are at 48 least as effective as those for IPv4. This demonstrates that the 49 header overhead argument against IPv6 is misinformed. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1 Case 0: Boundary Conditions . . . . . . . . . . . . . . . 7 57 3.2 Case 1: Normal Range of Behavior . . . . . . . . . . . . . 8 58 3.3 Case 2: Fragmentation . . . . . . . . . . . . . . . . . . 9 59 3.4 Case 3: Jumbograms . . . . . . . . . . . . . . . . . . . . 10 60 3.5 Case 4: Mobility . . . . . . . . . . . . . . . . . . . . . 11 61 4. Summary of Findings . . . . . . . . . . . . . . . . . . . . . 13 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 64 7. Informative References . . . . . . . . . . . . . . . . . . . . 15 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 66 A. Useful Numeric Values . . . . . . . . . . . . . . . . . . . . 17 67 Intellectual Property and Copyright Statements . . . . . . . . 19 69 1. Introduction 71 While IPv4 has achieved widespread use and acclaim, its intended 72 successor, IPv6, is still facing some hurdles in large-scale 73 deployment. In both aeronautical networking and space networks a 74 move towards network-centric operations and away from application- 75 specific point-to-point links is occuring. In multiple groups that 76 are attempting to define aeronautical or space networking 77 architectures, the use of Internet protocols is well-accepted, but 78 there is considerable uncertainty on whether to use IPv4, IPv6, or a 79 dual-stack. 81 It is the technical opinion of many that IPv6 is favorable, due to 82 some of its features (mobility and security are particularly 83 important for network-centric operations). We have also seen IPv4 84 brought forward as a favored choice by others based on the logic that 85 it has lower "overhead" than IPv6, and that aeronautical and space 86 links may often be rather constrained. While it is undeniable that 87 the IPv6 base header is larger than IPv4's, these arguments tend to 88 be "hand-waves" that are not based on well-quantified data. 90 In this document, we systematically consider IPv4 and IPv6 header 91 overhead in several case studies. Our goal is to provide stronger 92 material for use in discussions regarding the comparison between IPv4 93 and IPv6 header sizes, and their effect on link loading. Companion 94 documents debunk the related myth that IPv6 is not yet mature enough 95 for production use [EIv06], and compare the feature sets of IPv6 and 96 IPv4 [EIs06]. 98 Before proceeding into this study, the reader should make an 99 assessment of the potential relevence of this issue. For networks 100 that are only lightly loaded, where there is very little congestion 101 or delay, what effect will increasing the size of packets by only a 102 few percent have? Contrast this with chronically oversubscribed 103 links, perhaps due to low physical layer capacities, where there 104 might be substantial queuing, and consider what effect adding several 105 dozen bytes to each packet has. Clearly this issue may or may not be 106 important under different assumptions. In the cases where it is 107 important, it is likely that header compression techniques are in 108 use, and so the real trade study should be between the effectiveness 109 of IPv4 and IPv6 header compression mechanisms. Current methods are 110 able to compress IPv6 headers at least as well, if not better, than 111 IPv4 headers [RFC3095]. 113 The problem of header overhead in both IPv4 and IPv6 has long been 114 recognized and a large amount of work has gone into header 115 compression techniques. The IETF Robust Header Compression Working 116 Group, for instance, has delivered particularly effective solutions 117 for both versions of IP [RFC3843] as well as additional protocols 118 layered over IP. It is our primary advice that for under-utilized 119 links, header overhead is not a significant consideration, while for 120 low-speed or congested links, current header compression technologies 121 are fully sufficient and make this topic moot. The remainder of this 122 document assumes no header compression technique is in use, and then 123 presents quantized evidence that might be compared to the utilization 124 levels of user LANs or provider backbones to see how insignificant 125 the difference in overhead between IP versions is. 127 Section 2 describes the basic terminology and proceedure used in this 128 study and introduces the scenarios considered in the case studies in 129 Section 3. A brief summarization of the results is given in 130 Section 4. Appendix A contains some numeric quantities that are used 131 in the analysis. 133 2. Methodology 135 For the purposes of this study, we will consider the "overhead" to 136 consist solely of the IP-layer headers, options, and extension 137 headers. To be specific: 139 o We define the IP-layer Service Data Unit (SDU) as whatever buffer 140 of bytes is passed down from a transport protocol (or other layer 141 above IP), to be sent over the network using IP. The IP-layer 142 Protocol Data Unit (PDU) that is constructed then consists of the 143 SDU combined with IP Protocol Control Information (PCI). This 144 follows the nomenclature used in the ISO/OSI reference model. 146 o We assume that only the PCI portion of the IP-layer PDU varies 147 between IPv4 and IPv6. Thus the difference in overhead can be 148 determined strictly from the size of the PCI. There are certain 149 applications that may carry IP addresses inside their SDUs (e.g. 150 FTP or IKE), but our assumption is that this has only a relatively 151 small affect overall (in FTP, the file transfered is usually much 152 longer than the length of an IPv6 address, and in IKE, 153 certificates and keying material are similarly much larger than an 154 IPv6 address). 156 o A few components of the PCI may be identical between IPv4 and 157 IPv6. For instance, the IPsec Authentication Header has the same 158 size and form when used with IPv4 as it does with IPv6. In this 159 study, we will only consider PCI components that differ between 160 the two versions of IP. 162 Measuring the PCI as a raw number of bytes is useful, but it is also 163 informative to view the lengths of the IPv4 PCI and IPv6 PCI as 164 percentages of the total PDU. In the case of relatively small SDUs, 165 a large PCI size is significant, but in the case of larger SDUs (as 166 used in bulk file transfer), a difference of even several dozen bytes 167 in the PCI size will have little effect on the percentage of the PDU 168 consumed by the PCI. 170 Since fragmentation of datagrams is treated differently in the IPv4 171 and IPv6 protocols, we will consider what happens when PDUs known to 172 be larger than the Path MTU (PMTU) are handled by each version of IP, 173 in addition to PDUs that fit within the PMTU. 175 Even with these considerations, this is a somewhat naive comparison 176 since the overhead implied by the selection of a network layer 177 protocol also consists of several factors in addition to the per- 178 packet headers. This includes the size of updates in routing 179 protocols (e.g. OSPF and BGP), the address fields in queries and 180 responses to address resolution protocols (e.g. DNS and ARP/ND), and 181 the configuration protocol packets (e.g. DHCP), to name a few 182 additional contributions. Compared to the per-packet overhead, 183 however, these should be negligible contributions. 185 We define a number of specific cases for which we compute IP-layer 186 overhead: 188 Case 0: (a) Consider a 0-byte SDU (i.e. an empty payload). (b) Then 189 consider a 65,515-byte SDU. Assume the PMTU in both of these 190 cases is greater than the PDU size. 192 Case 1: Consider an N-byte SDU (for N > 0), when the PMTU is assumed 193 to be greater than the PDU size. 195 Case 2: Consider an N-byte SDU, when the PMTU is assumed to be less 196 than N, but greater than (N+(PCI*2))/2 (i.e. the SDU can fit 197 within two IP packet fragments). This demonstrates a simple case 198 of fragmentation, where only two fragments are needed. 200 Case 3: Consider an N-byte SDU, where N > 65,535, and the PMTU is 201 large enough to support the IPv6 PCI and SDU. This allows for 202 consideration of jumbogram support in IPv6, which IPv4 lacks. 204 Case 4: Consider an N-byte SDU sent between a mobile node (MN) and a 205 corresponding node (CN), where the PMTU is greater than the PDU 206 size, and where the MN and CN support the standard mobility 207 features of IPv4 or IPv6 (including the route optimization feature 208 which is a part of IPv6, but not IPv4). 210 3. Case Studies 212 In this section, each of the specific cases listed previously is 213 further described and analyzed. 215 3.1 Case 0: Boundary Conditions 217 One way the reader might view the two subcases presented here of 218 minimum and maximum-sized packets, is as demonstration of the 219 futility of even attempting to gauge header overhead without any 220 knowledge of what the offered transport/application load is. For 221 small packets, any network header at all seems extraordinarily 222 inefficient since in either IP version the node IP addresses alone 223 may be larger than the data. For large packets, the reverse is true. 225 To start, it should be noted that the first part of this case is 226 somewhat unrealistic. In reality, a 0-byte SDU would never be passed 227 to the IP layer, since to even address a particular application or 228 service requires a transport header, and even IP-layer signalling 229 occurs using ICMP datagrams as SDUs, so there is no practical use for 230 a 0-byte SDU. This case simply illustrates a hard limit on the 231 smallest size an IP PDU can take, and the worst relative amount of 232 the PDU that the PCI can consume. 234 If it were possible to send a 0-byte PDU, then the overheads for IPv4 235 and IPv6 would be: 237 IPv4 PCI (IPv4 Base Header): 20 bytes or 100% of the PDU 239 IPv6 PCI (IPv6 Base Header): 40 bytes or 100% of the PDU 241 IPv4 and IPv6 both have the same worst-case bound on the percentage 242 of the PDU that their headers can take up, although the base IPv6 243 header is twice as large as the base IPv4 header. Since in reality, 244 many types of link pad small frames out to reach some minimum length, 245 small packets (those of only a few bytes in the SDU), may still be 246 under the link's minimum and require padding. This means that even 247 measuring the IP header overhead for small packets may be pointless, 248 since even if the IP header were compressed to 0-bytes, the link 249 would apply padding to the frame. For instance, Ethernet frames have 250 a minimum frame size of 64 bytes, and Gigabit Ethernet's minimum is 251 even larger at 520 bytes. In the case of standard Ethernet, with 18 252 bytes of frame header/trailer, IPv6 SDUs of up to 6 bytes and IPv4 253 SDUs of 26 bytes have the same real overhead. 255 At the other end of the spectrum, the largest possible IPv4 packet is 256 65,535 bytes, due to the 16-bit IPv4 total length field. IPv6 has a 257 similar 16-bit field, but its semantics differ, in that it encodes 258 the payload length. This means that a single IPv6 packet may be 259 larger than an IPv4 one by the size of the IPv6 header plus the size 260 of the IPv4 header (60 bytes using only base headers). Given a PDU 261 of 65,515 bytes (the maximum possible in IPv4): 263 IPv4 PCI (IPv4 Base Header): 20 bytes or 0.03% of the PDU 265 IPv6 PCI (IPv6 Base Header): 40 bytes or 0.06% of the PDU 267 Neither the IPv4 nor IPv6 headers make up any significant portion at 268 all of the PDU in the case of maximally-sized standard packets. The 269 case of jumbograms considered later in Case 3, shows that IPv6 is 270 actually capable of being even more efficient than this, but at this 271 scale it is almost absurd to even consider. 273 3.2 Case 1: Normal Range of Behavior 275 This case considers an IP packet that can be sent end-to-end with no 276 fragmentation. This is by far the most prevalent case under normal 277 operating conditions, and so the figures presented for this case 278 should have the most bearing on a practical determination on the 279 significance of the header overhead issue. 281 IPv4 PCI (IPv4 Base Header): 20 bytes or (20/(N+20) * 100)% of PDU 283 IPv6 PCI (IPv6 Base Header): 40 bytes or (40/(N+40) * 100)% of PDU 285 Since the PCI is simple (a single IP header) in the case of each 286 protocol version, the impact of the PCI on the PDU is easy to 287 understand. For instance, on a 48-byte SDU (the minimum IPv4 MTU 288 [RFC0791], minus the IPv4 base header size), the IPv4 and IPv6 PCIs 289 represent 29.41% and 58.82% of the PDU, respectively. For a 1240- 290 byte SDU (the minimum IPv6 MTU, minus the IPv6 base header size), the 291 IPv4 and IPv6 PCIs represent 1.58% and 3.13% of the PDU, 292 respectively. 294 While it is true that the IPv4 overhead is half that of the IPv6 295 overhead in this case, with a reasonable-sized SDU, as would be used 296 by applications such as bulk-transfer, both protocol's headers are of 297 relatively little consequence, only making up a few percent of the 298 PDU. Note that when comparing the IPv4 base header size to the IPv4 299 minimum MTU (29.41%) and the IPv6 base header to the IPv6 minimum MTU 300 (3.13%), the results of the requirement to support larger MTUs on 301 IPv6 links are seen to allow for keeping a much tighter handle on the 302 header overhead than was possible with IPv4's requirement. 304 As an example of interactive traffic that sends small packets, 305 consider the SSH protocol when the user types a character at a time 306 into a remote shell. A single typed character causes a 48-byte block 307 of application data to be passed to TCP. TCP puts a 20-byte base 308 header onto this, and then (usually) a 12 byte Timestamp Option, so 309 an 80-byte SDU (48+20+12) is passed to IP, regardless of whether IPv4 310 or IPv6 is being used. With base IP-layer headers then, IPv4 PCI 311 takes up exactly one fifth of the PDU, while the IPv6 PCI takes up 312 one third of the PDU. 314 We can also consider very large MTUs, such as those that might be 315 used on a fiber-optic network bus in an aircraft or space vehicle. 316 The FDDI MTU of 4352 bytes allows a 4332-byte SDU with IPv4 and a 317 4312-byte SDU with IPv6 base headers. Respectively, the PCIs are 318 0.46% and 0.92% of the PDU. OC-3 packet over SONET interfaces 319 default to a similarly sized MTU of 4470 bytes, giving PCIs that may 320 be as little as 0.45% and 0.89% of the PDU. In the case of such 321 links, the header overhead argument against IPv6 seems largely 322 irrelevent. 324 3.3 Case 2: Fragmentation 326 IPv4 and IPv6 take completely different approaches to fragmentation. 327 In IPv4, fragmentation of a datagram can occur at any point in the 328 network where a particular link's MTU is too small to accomodate the 329 entire packet (assuming the Don't Fragment bit is not set); i.e. in 330 IPv4, fragmentation is a router-level function. In IPv6, a router 331 never fragements a packet. If an IPv6 packet is larger than a link 332 MTU, then an ICMPv6 Packet Too Big message is sent to the packet's 333 source, and the packet is dropped. Fragmentation has been removed 334 from a router's responsibilities in IPv6, and is strictly an end- 335 host's task to perform, as needed. For this reason, the header 336 overhead during a fragmentation scenario in IPv4 and IPv6 has to be 337 specially compared, since it is static across the path in IPv6, but 338 differs after the router that performs it in IPv4. We assume that 339 from a prior failure or PMTU probing, the IPv6 end-host already knows 340 that fragmentation is required here, so that a failed transmission 341 does not factor into the overhead computed. 343 First consider a simple case that only requires a packet to be 344 segmented into two fragments: 346 IPv4 PCI, before fragmenting router (IPv4 Base Header): 20 bytes 347 or (20/(N+20) * 100)% of PDU 349 IPv4 PCI, after fragmenting router (2x IPv4 Base Headers): 40 350 bytes or (40/(N+40) * 100)% of PDU 351 IPv6 PCI, (2x IPv6 Base Headers and IPv6 Fragment Headers): 96 352 bytes or (96/(N+96) * 100)% of PDU 354 As an example, consider the case of a PMTU of 1280 bytes (the IPv6 355 minimum), and an SDU of 1400 bytes, where the MTU of the first-hop 356 link is greater than 1420 bytes plus link headers (e.g. an Ethernet). 357 An IPv4 host will send a single 1420 byte PDU on the first link, with 358 PCI overhead of 1.41%. This IPv4 packet then becomes fragmented, at 359 some point, into two IPv4 packets, one of which is of size 1280 bytes 360 (1260 bytes of the original SDU and 20 of IPv4 header) and another of 361 size 160 (140 bytes of the original SDU and 20 of IPv4 header). The 362 first new packet has overhead of 1.56%, and the second has overhead 363 of 12.5%. Together, the combined PCI is 2.78% of the combined PDU 364 sizes. 366 Correspondingly, in IPv6, when it is not performing PMTU Discovery, a 367 host is likely to pro-actively fragment its packets to be within the 368 1280 byte guideline (or even lower to accomodate some tunneling). So 369 in a simple setting, the 1400-byte SDU might be fragmented into a 370 1280-byte and a 216-byte pair of packets (carrying 1232 and 168 bytes 371 of the original SDU each). These would have overhead of 3.75% and 372 22.22% each, and a combined overhead of 6.42%. This overhead applies 373 across the entire end-to-end path. 375 In general, transport protocols will either not send large SDUs to IP 376 (they will segment data at the transport layer), or they will perform 377 some form of PMTU Discovery (e.g. [RFC1191]) in order to send the 378 largest segments possible without causing fragmentation. In 379 transport protocol implementations that support IPv6, when reliable 380 operation is required of the transport, a resegmentation and 381 retransmission occurs in response to ICMPv6 Packet Too Big messages. 382 If the PMTU is not known, and the transport sends a segment that is 383 too large, which is then retransmitted as either multiple IPv6 384 fragments or resegmented transport data, then the overhead is 385 actually different than what we report here. The entire PDU sent in 386 the failed attempt can be considered overhead, as well as the ICMPv6 387 message in the reverse direction. If the SDU is resegmented by the 388 transport, then extra transport overhead is imposed. 390 3.4 Case 3: Jumbograms 392 One feature that is part of IPv6, but has no analogue in IPv4 is 393 jumbogram support [RFC2675]. This has proven useful mainly in super- 394 computing contexts, but to our knowledge has not been deployed 395 significantly outside this domain. It may be relevent to satellite 396 networks that interconnect supercomputers. A base IPv4 or IPv6 397 header includes a 16-bit field for the payload length, but IPv6 has 398 the Jumbo Payload option, which allows this field to be overidden 399 with a 32-bit field. This permits two IPv6 hosts with sufficient 400 knowledge of each other's and the network's capabilities to send 401 single packets of larger than 65,535 bytes. 403 The jumbogram feature of IPv6 allows larger SDUs than are possible in 404 IPv4, and thus can reduce both network layer and transport (or 405 higher) layer overhead. Sending a jumbogram requires coordinated 406 support from several protocol layers (at least the link, network, and 407 transport), and is only possible when as transport/application 408 actually has greater than 65,515 bytes of data to send. In the case 409 where this is possible in IPv6, compared to what would be required in 410 IPv4 for data totaling N (> 65,515) bytes: 412 IPv4 PCI (H=ceil(N/(65,535-20)) IPv4 Base Headers): H*20 bytes or 413 (H*20/(N+H*20) * 100)% of PDU 415 IPv6 PCI, (IPv6 Base Header, IPv6 Hop-by-Hop Option, and IPv6 416 Jumbo Payload Option): 48 bytes or (48/(N+48) * 100)% of PDU 418 As a quick example, consider N=200,000. Using IPv4, for maximum 419 efficiency, the transport could put this into 4 IPv4 SDUs (assuming 420 it either knew the link could support frames of this size, or did not 421 care about fragmentation for some reason). This would give an 422 overall header overhead of 0.03% of the PDU. If a single IPv6 423 jumbogram is used, the overhead is 0.02% of the PDU. In terms of 424 header overhead, this is not an area where their is neither an issue 425 nor any real difference between IPv4 and IPv6. Jumbograms allow a 426 transport to operate more efficiently by not segmenting and 427 reassembling data itself (usually involving slow memory copies), and 428 possibly allow the link to be more efficient, but they do not 429 significantly affect network layer protocol overhead. 431 3.5 Case 4: Mobility 433 Due to the way Mobile IPv4 operates (in its most efficient mode), 434 using triangle routing, packets will cross part of their path within 435 a tunnel, and then another part regularly, with no tunnel. Thus, the 436 IPv4 PCI size changes depending on where in the network it is 437 measured when Mobile IPv4 is used. On the other hand, we will assume 438 a Mobile IPv6 scenario where Route Optimization (RO) is supported, 439 such that packets go directly to their destination without tunneling. 440 This is a feature of IPv6 that has no analogue in IPv4. In a Mobile 441 IPv6 with RO setting, though, different PCI components get placed on 442 a packet depending on whether a mobile node (MN) is using a Care-of 443 Address as a "from" address in outgoing packets, whether the Care-of 444 Address is being used as a "to" address by a corresponding node (CN), 445 or whether Care-of Addresses are used in both directions (between two 446 MNs, both away from their "home" networks). The reader should refer 447 to a more detailed Mobile IP reference if these differences seem 448 confusing (e.g. [RFC3775]). 450 Mobile IPv4 and Mobile IPv6 (including NEMO) can also both operate in 451 a bidirectional tunnel mode, in which a direct path between MN and 452 CN, or vice-versa, is never taken, but packets in both directions are 453 always redirected through the home network. Since this case is even 454 less desirable than a triangle route, to simplify analysis, we do not 455 consider it here. 457 IPv4 PCI, inside tunnel (2x IPv4 Base Headers): 40 bytes or (40/ 458 (N+40) * 100)% of PDU 460 IPv4 PCI, outside tunnel (IPv4 Base Header): 20 bytes or (20/ 461 (N+20) * 100)% of PDU 463 IPv6 PCI, from CN to MN (IPv6 Base Header and Mobile IPv6 Type 2 464 Routing Header): 64 bytes or (64/(N+64) * 100)% of PDU 466 IPv6 PCI, from MN to CN (IPv6 Base Header, IPv6 Destination 467 Option, Mobile IPv6 Home Address Option, and padding): 64 bytes or 468 (64/(N+64) * 100)% of PDU 470 IPv6 PCI, between two MNs away from home (IPv6 Base Header, IPv6 471 Destination Option, Mobile IPv6 Home Address Option and Mobile 472 IPv6 Type 2 Routing Header, and padding): 88 bytes or (88/(N+88) * 473 100)% of PDU 475 In Mobile IPv4, the standard means of tunneling involves using two 476 IPv4 base headers, although other methods are available, some of 477 which can be more efficient. In some of the Mobile IPv6 with RO 478 cases, padding has to be added to the PCI to meet the IPv6 479 requirement of ending on a 64-bit boundary. Even when the IPv4 PCI 480 is at its largest, during the tunneled portion of its journey through 481 the network, it is still smaller than any of the IPv6 PCI 482 configurations when a mobile node is using a Care-of Address. In the 483 worst case of IPv6 overhead when both nodes are mobile and in foreign 484 networks, the 88 bytes of PCI would make up 6.87% of a 1280-byte PDU. 486 4. Summary of Findings 488 In general, header overhead at the IP layer is not a relevent concern 489 in most normal networks in use today for two reasons. The first is 490 that the bandwidth of many currently-used links (in LANs, and many 491 provider backbones) seems to be at least adequate, if not plentiful. 492 For very constrained links, where bandwidth is tight and demand may 493 be high (as in many types of wireless links), then header overhead 494 becomes an issue. But the second reason why IP header overhead is 495 not usually a valid concern, is that in these specific links, header 496 compression techniques can usually be applied to significantly reduce 497 IP overhead. 499 This document computed the size of IPv4 and IPv6 headers relative to 500 the size of the SDU from a transport/application protocol over a 501 number of different scenarios and configurations. Typically, IPv6 502 involved more overhead, but only differed from IPv4 within several 503 percent of the SDU's size, despite the base IPv6 header being twice 504 as big as the IPv4 header. 506 The impact of increasing the capabilities of a protocol at the 507 expense of blowing up the header overhead is not a new consideration. 508 One documented example is the analysis of the TCPng proposal in RFC 509 1705 [RFC1705]. The IPng design effort that resulted in IPv6 510 considered this and concluded with a 40-byte IPv6 header, a doubling 511 of IPv4's 20-byte header. Most of the case studies we have presented 512 in this document show that in reality, this difference in header size 513 is less significant than it seems at first. 515 5. Security Considerations 517 This informational document only contains a comparison of header 518 sizes. There are no security considerations. 520 6. Acknowledgements 522 Work on this document was performed at NASA's Glenn Research Center, 523 in support of the NASA Space Communications Architecture Working 524 Group (SCAWG), and the FAA/Eurocontrol Future Communications Study 525 (FCS). Will Ivancic and Joe Ishac of NASA contributed useful 526 comments on this document, as well as Terry Bell, Bob Dimond, and 527 Dave Stewart of Verizon. 529 7. Informative References 531 [EIs06] Eddy, W. and J. Ishac, "Comparison of IPv6 and IPv4 532 Features", 533 draft-eddy-ipv6-ipv4-comparison-00 Internet-Draft (work in 534 progress), May 2006. 536 [EIv06] Eddy, W. and W. Ivancic, "Assessment of IPv6 Maturity", 537 draft-eddy-ipv6-maturity-00 Internet-Draft (work in 538 progress), May 2006. 540 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 541 September 1981. 543 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 544 November 1990. 546 [RFC1705] Carlson, R. and D. Ficarella, "Six Virtual Inches to the 547 Left: The Problem with IPng", RFC 1705, October 1994. 549 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 550 (IPv6) Specification", RFC 2460, December 1998. 552 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 553 RFC 2675, August 1999. 555 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 556 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 557 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 558 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 559 Compression (ROHC): Framework and four profiles: RTP, UDP, 560 ESP, and uncompressed", RFC 3095, July 2001. 562 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 563 in IPv6", RFC 3775, June 2004. 565 [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 566 (ROHC): A Compression Profile for IP", RFC 3843, 567 June 2004. 569 Author's Address 571 Wesley M. Eddy 572 Verizon Federal Network Systems 573 21000 Brookpark Rd, MS 54-5 574 Cleveland, OH 44135 576 Phone: 216-433-6682 577 Email: weddy@grc.nasa.gov 579 Appendix A. Useful Numeric Values 581 This appendix compiles a list of various PCI components and their 582 sizing information, as well as some MTUs, limits, and link or 583 Subnetwork Defined Convergence Protocol (SNDCP) requirements that are 584 used in the case studies. 586 +-----------------------------------+----------+-----------+ 587 | PCI Component | Size | Reference | 588 +-----------------------------------+----------+-----------+ 589 | IPv4 Base Header | 20 bytes | [RFC0791] | 590 | | | | 591 | IPv6 Base Header | 40 bytes | [RFC2460] | 592 | | | | 593 | IPv6 Hop-by-Hop Options Header | 2 bytes | [RFC2460] | 594 | | | | 595 | IPv6 Destination Options Header | 2 bytes | [RFC2460] | 596 | | | | 597 | IPv6 Fragment Header | 8 bytes | [RFC2460] | 598 | | | | 599 | IPv6 Jumbo Payload Option | 6 bytes | [RFC2675] | 600 | | | | 601 | Mobile IPv6 Type 2 Routing Header | 24 bytes | [RFC3775] | 602 | | | | 603 | Mobile IPv6 Home Address Option | 18 bytes | [RFC3775] | 604 +-----------------------------------+----------+-----------+ 606 +---------------------------------+---------------------------------+ 607 | Size | Importance | 608 +---------------------------------+---------------------------------+ 609 | 64 bytes | minimum transmitted Ethernet | 610 | | frame | 611 | | | 612 | 68 bytes | IPv4 (or SNDCP) minimum MTU | 613 | | | 614 | 520 bytes | minimum transmitted Gigabit | 615 | | Ethernet frame | 616 | | | 617 | 576 bytes | X.25 MTU and minimum packet | 618 | | that IPv4 hosts are required to | 619 | | handle | 620 | | | 621 | 1280 bytes | IPv6 (or SNDCP) minimum MTU | 622 | | | 623 | 1500 bytes | Ethernet IP MTU | 624 | | | 625 | 4352 bytes | FDDI IP MTU | 626 | | | 627 | 4470 bytes | OC-3 SONET IP MTU | 628 | | | 629 | 65535 bytes | IPv4 maximum total packet size, | 630 | | IPv6 maximum payload size | 631 +---------------------------------+---------------------------------+ 633 Intellectual Property Statement 635 The IETF takes no position regarding the validity or scope of any 636 Intellectual Property Rights or other rights that might be claimed to 637 pertain to the implementation or use of the technology described in 638 this document or the extent to which any license under such rights 639 might or might not be available; nor does it represent that it has 640 made any independent effort to identify any such rights. Information 641 on the procedures with respect to rights in RFC documents can be 642 found in BCP 78 and BCP 79. 644 Copies of IPR disclosures made to the IETF Secretariat and any 645 assurances of licenses to be made available, or the result of an 646 attempt made to obtain a general license or permission for the use of 647 such proprietary rights by implementers or users of this 648 specification can be obtained from the IETF on-line IPR repository at 649 http://www.ietf.org/ipr. 651 The IETF invites any interested party to bring to its attention any 652 copyrights, patents or patent applications, or other proprietary 653 rights that may cover technology that may be required to implement 654 this standard. Please address the information to the IETF at 655 ietf-ipr@ietf.org. 657 Disclaimer of Validity 659 This document and the information contained herein are provided on an 660 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 661 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 662 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 663 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 664 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 665 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 667 Copyright Statement 669 Copyright (C) The Internet Society (2006). This document is subject 670 to the rights, licenses and restrictions contained in BCP 78, and 671 except as set forth therein, the authors retain all their rights. 673 Acknowledgment 675 Funding for the RFC Editor function is currently provided by the 676 Internet Society.