idnits 2.17.00 (12 Aug 2021) /tmp/idnits65357/draft-eddy-ipv6-ip4-comparison-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 619. ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 262: '... MUST implement the IPsec Authentica...' RFC 2119 keyword, line 265: '...date that IPv6 nodes MUST support both...' 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 9, 2006) is 5849 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) == Unused Reference: 'RFC4489' is defined on line 563, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-chown-v6ops-renumber-thinkabout-00 -- No information found for draft-eddy-ip-overhead - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 1825 (Obsoleted by RFC 2401) -- Obsolete informational reference (is this intentional?): RFC 2050 (Obsoleted by RFC 7020) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: draft-ietf-v6ops-nap has been published as RFC 4864 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 21 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 10, 2006 J. Ishac 5 NASA Glenn Research Center 6 May 9, 2006 8 Comparison of IPv6 and IPv4 Features 9 draft-eddy-ipv6-ip4-comparison-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 10, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document collects and comments on several aspects IPv6 that 43 differ from IPv4, and what practical impacts these differences might 44 have to an organization. This data can be used in decision-making 45 processes where the business case for deploying IPv6 is under 46 consideration. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Addressing and Routing . . . . . . . . . . . . . . . . . . . . 4 52 3. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 7 53 4. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 6. Multicast and Anycast . . . . . . . . . . . . . . . . . . . . 11 56 7. Flexibility and Growth . . . . . . . . . . . . . . . . . . . . 13 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 59 10. Informative References . . . . . . . . . . . . . . . . . . . 15 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 61 Intellectual Property and Copyright Statements . . . . . . . . 19 63 1. Introduction 65 While IPv4 has achieved widespread use and acclaim, its intended 66 successor, IPv6, is still facing some hurdles in large-scale 67 deployment. In both aeronautical networking and space networks a 68 move towards network-centric operations and away from application- 69 specific point-to-point links is occuring. In multiple groups that 70 are attempting to define aeronautical or space networking 71 architectures, the use of Internet protocols is well-accepted, but 72 there is considerable uncertainty on whether to use IPv4, IPv6, or a 73 dual-stack. 75 It is the technical opinion of many that IPv6 is favorable, due to 76 some of its features (mobility and security are particularly 77 important for network-centric operations). However, some decision- 78 makers have been misinformed that IPv6 is equivalent to IPv4 with 79 larger addresses. This document sheds light on the reality that IPv6 80 contains several additional features which may give it an improved 81 business case over IPv4. Companion documents debunk arguments where 82 IPv4 is brought forward as a favored choice based on the logic that 83 it has lower "overhead" than IPv6 [Eddy06], and provide evidence that 84 IPv6 is currently mature enough for widespread use [EI06]. 86 This document is broken down as follows. Section 2 compares the 87 addressing and routing functions and capabilities in IPv4 and IPv6. 88 Section 3 describes Quality of Service (QoS) features in both 89 protocols. Section 5 considers the mobility extensions to each 90 protocol. Section 6 discusses the multicast and anycast capabilities 91 of IPv4 and IPv6, and Section 7 examines flexibility and 92 extensibility. 94 2. Addressing and Routing 96 The most obvious difference between IPv4 and IPv6 is the change in 97 the address size from 32 bits in IPv4 [RFC0791] to 128 bits in IPv6 98 [RFC2460]. This increase in the raw number of bits means that there 99 is a factor of 2^96 more addresses available in IPv6 than in IPv4. 100 Due to the way that the address spaces are subnetted, scoped, and 101 defined for multicast, private/experimental use, and other factors, 102 however, the actual contrast is less direct than this simple factor. 104 Aside from a few specific blocks for local-use, multicast, or other 105 specific functions, the majority of the IPv4 32-bit address space is 106 designated for global unicast addresses [RFC3330]. In the IPv4 107 addressing architecture, IANA delegates Regional Internet Registries 108 (RIRs) /8 address blocks (8-bit network identifiers), which the RIRs 109 can then divide into variable-length blocks for further assignment to 110 ISPs or other registries [RFC2050] [RFC1519]. The maximum address 111 block that a site could ever be given is a /8, which leaves only 24- 112 bits for subnetting and addressing within the organization. 113 Historically, large or complexly-organized groups required multiple 114 /8s. For instance, at least 7 /8s belong to the US Department of 115 Defense. Considering there are only 256 such blocks, the IPv4 116 address space can be seen as severely limited. To compound matters, 117 even using multiple /8s is a poor solution, since there is no 118 guarantee that they will be numerically continuous, and if they are 119 not, then both the local numbering scheme may be awkward, and 120 multiple global routing table entries will be stored and propagated. 121 In recent years, many IPv4 users have circumented these issues by 122 using Network Address Translators (NATs), although this practice is 123 known to be frought with problems of its own [RFC2993] [RFC3027]. 125 According to the IPv6 addressing architecture [RFC4291], the prefix 126 of 001 identifies IPv6 global unicast addresses, so 1/8 of the 127 address space, or 2^125 such addresses are available. To date, IANA 128 has given IPv6 address blocks varying from /16 to /23 in size to the 129 RIRs. The documented policy for the downstream assignment from RIRs 130 to LIRs is that each LIR receive a minimum of a /32. The minimum 131 sized address block that an LIR can then give to a site is a /48. 132 For more details see: 133 http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02. Since 134 an IPv6 site can expect a *minimum* of a /48, this gives 16 bits of 135 subneting space and 64 bits of interface identifier within a subnet 136 (80 bits combined). Contrast this to an IPv4 site that can expect a 137 *maximum* of a /8, leaving only 24 bits of space to be used for 138 subnetting and host addressing combined. Since in reality, most 139 sites do not get /8s, but rather /16s or /24s, there are more likely 140 to be only 4-8 bits for subneting and 4-8 bits for identifying hosts 141 within a subnet. 143 The IPv6 addressing architecture includes scoped-addresses, including 144 scoped multicast addresses. Support for scoping in IPv6 is more 145 fully defined and has some features that IPv4 has no analogues to. 146 As a simple example, IPv6 has all-routers addresses, which allow a 147 node to find or communicate with routers without knowing their 148 unicast address ahead of time. In IPv4, this is not possible without 149 the assistance of other protocols. 151 Configuring and managing addresses in IPv6 and IPv4 can both be 152 accomplished using versions of the DHCP protocol. However, IPv6 has 153 mechanisms that allow a node to configure its own globally routable 154 address, without the need for DHCP [RFC2462], and IPv4 has no 155 counterpart to this functionality. DHCP is still of practical use in 156 both protocols though, due to its ability to provide other 157 configuration data, such as DNS server addresses. 159 Due to the fact that LIRs assign subnet addresses in IPv6, rather 160 than simply end-node addresses (as often done in IPv4), DHCP supports 161 prefix-delegation extensions for IPv6. Prefix-delegation allows DHCP 162 to manage the assignment of subnet prefixes in an automated fashion, 163 and allows IPv6 routers to be automatically configured. IPv4 has no 164 comparable feature. 166 In conjunction with the depletion of the IPv4 address pool, a second 167 major driver in the design of IPv6 is that IPv4 inter-domain routing 168 tables are very large. This is due to the inability to aggregate 169 addresses based on the way that IPv4 blocks have been assigned. The 170 IPv6 addressing architecture and assignment policy is designed such 171 that subnet addresses can potentially be aggregated very effectively. 172 Essentially, the idea is that the global routing table only has to 173 know how to reach a small number of large backbone networks, and the 174 subnet addresses belonging to millions of end-sites can be aggregated 175 hierarchically under the backbone provider addresses. This prevents 176 routers from using large amounts of memory on the routing table, thus 177 allowing lookups to be faster, and network operators to spend less 178 money on expensive router memory upgrades. Recent developments 179 indicate that Provider Independent addressing may become more 180 prevalent in IPv6 assignments, and so this feature could be negated. 182 In the effort to build faster router platforms, two well-known speed- 183 bumps in IPv4 were performing the checksum operations, and 184 fragmenting datagrams, when required. While relatively efficient 185 means of computing the IPv4 checksum [RFC1624], and even implementing 186 it in hardware [RFC1936], were developed, it was decided to improve 187 speed by not including any checksum at all in IPv6. The rationale 188 behind this is that most link-layer protocols have at least their own 189 checksum (and often their own retransmission protocols and error- 190 correcting codes), and reliable application or transport protocols 191 also implement checksums. Since some of the link and higher-layer 192 checksums in use were actually more powerful than the simple IPv4 193 checksum, it was of relatively little utility. Typical IPv4 router 194 designs are incapable of performing fragmentation operations in their 195 optimized "fast-path", and instead have to resort to the "slow-path" 196 when fragmentation is required. This can represent a bottleneck that 197 limits throughput and loads the central processor (also used for 198 routing table maintenance and general device control). Since this is 199 exploitable merely by users at any point in the network sending 200 packets larger than a particular link's MTU, this could be seen as a 201 weakness. In IPv6, routers never fragment packets; packets larger 202 than an outgoing link's MTU are dropped. It is a source node's duty 203 to pro-actively fragment its own packets. The lack of checksum and 204 fragmentation responsibilties potentially allow IPv6 routers to 205 perform slightly faster and with lower power requirements, but these 206 differences are likely to be fairly minimal under typical use cases. 208 Another difference between IPv4 and IPv6 is in the way that IP 209 addresses within a subnet are resolved into link-layer protocol 210 addresses. IPv4 used the ARP [RFC0826] mechanism for this, while 211 IPv6 uses Neighbor Discovery (ND) [RFC2461]. There are at least two 212 key differences betwen ARP and ND. The first is that ARP operates 213 directly on top of the link layer, while ND operates using ICMPv6, on 214 top of IPv6, on top of the link layer. Practically, this means that 215 in the design of link layer protocols, distinct codes identifying ND 216 and IPv6 payload types do not have to be defined, whereas IPv4 and 217 ARP require separate codepoints. This is of only marginal 218 importance. The main difference between ARP and ND, is that IPv6's 219 ND is highly extensible and this extensibility has been used for a 220 number of purposes, including security (authentication of network 221 elements and resolution protocol messages), automatic prefix and 222 interface identifier configuration, and advertisement of the MTU. 223 IPv4's ARP has no such facilities and no means for extension. 225 Altogether, in terms of addressing, routing, and forwarding features, 226 IPv6 has advantages over IPv4 in every respect considered. 228 3. Quality of Service 230 The Differentiated Services QoS architecture utilizes the IPv4 Type 231 of Service byte and the IPv6 Traffic Class byte in the same way 232 [RFC2474]. In this respect, IPv4 and IPv6 are equivalent. 234 A significant capability that is part of the standard IPv6 header, 235 and is not present in IPv4, is the ability to classify traffic into 236 flows based on a flow label header field. This can be used as a 237 basic building block to efficiently support QoS policies and 238 protocols. In IPv4, flows can only be classified by the relatively 239 expensive process of examining (and possibly parsing) header fields. 240 Thus, certain types of per-flow QoS can be enabled in routers with 241 lower computational overhead when using IPv6. 243 4. Security 245 Both IPv4 and IPv6 can be used in conjunction with the IPsec suite of 246 protocols [RFC4301]. In fact, the operation of the IPsec protocols 247 is basically identical whether they are being used with IPv4 or IPv6. 248 Since the Transport Layer Security (TLS) protocol [RFC4346] runs over 249 top of the transport layer, and does not interface directly with IP, 250 it is similarly mostly agnostic to the version of IP that is used. 251 Both TCP and SCTP can run TLS, and both will run over IPv4 and IPv6. 252 Additionally, the X.509 format for certificates that is often used in 253 IPsec and TLS, has encoding methods for both IPv4 and IPv6 addresses 254 [RFC3779]. So, the two most prevalent security architectures in the 255 Internet suite, IPsec and TLS, have no significant differences 256 between use with IPv4 and IPv6. 258 It is often touted that IPv6 has superior security properties to 259 IPv4. In the majority of cases, the reasoning used to justify this 260 is that IPsec is a part of IPv6, because in early IPsec 261 specifications [RFC1825], it was stated that all IPv6-capable hosts 262 MUST implement the IPsec Authentication Header in a basic 263 configuration (keyed-MD5 with 128-bit key [RFC1828]), while for IPv4 264 supporting any part of IPsec was optional. In fact, current IPv6 265 node requirements mandate that IPv6 nodes MUST support both 266 Authentication Header and Encapsulating Security Payload portions of 267 IPsec [RFC4294]. However, since IPv6's core functions do not rely on 268 IPsec, and only support for manual keying is required, the argument 269 that IPv6 is more secure than IPv4 based on the requirement to 270 support IPsec is not well-founded. The reality of the situation is 271 that IPv6-conformant implementations can more certainly be expected 272 to have support for IPsec, but it is still up to the users and 273 network managers to configure them, and the exact same IPsec features 274 are also readily available in IPv4 implementations, but not required 275 by IETF fiat to be present. 277 Outside of IPsec, there are other features of IPv6 that are not found 278 in IPv4, and can potentially give IPv6 better security properties. A 279 couple of the features included under the Network Architecture 280 Protection umbrella [VHDCK05] that are relevent to security are end- 281 system privacy and topology hiding. End-system privacy refers to the 282 ability of an IPv6 end-system to generate and change its own IPv6 283 address through selection of the Interface Identifier portion of the 284 address. A node can use this capability to change its address 285 periodically to avoid things like easily being able to correllate 286 remote log files of world-wide web activity [RFC3041]. IPv4 has no 287 equivalent capability. IPv4 nodes can dynamically change their 288 public addresses using DHCP, but DHCP servers are rarely configured 289 to permit this, and it requires a DHCP server, whereas the IPv6 290 solution is end-host based. Topology hiding is a similar technique 291 that involves changing the prefix refering to a subnet, rather than 292 the interface identifier. This prevents an attacker from being able 293 to easily determine other related addresses from a known address. 295 In addition, IPv6 has the optional secure neighbor discovery 296 extension, which allows hosts to authenticate the ND messages 297 [RFC3971], and uses cryptographically-generated addresses to prove 298 address ownership without any certificate management or other 299 security infrastructure [RFC3972]. IPv4 has no comparable features, 300 and its address space is too small for the features to be portable to 301 IPv4. 303 In summary, IPv6 does have superior security features in comparison 304 to IPv4, but these have little to do with IPsec, and both the IPsec 305 and TLS functionalities are equivalent without regard to the 306 underlying IP version. 308 5. Mobility 310 Support for node mobility is not required in either IPv4 or IPv6, 311 however, both protocols support mobility extensions [RFC3344] 312 [RFC3775]. The means of supporting mobility, and the features of 313 each mobility protocol differ. Mobile IPv4 uses UDP for signaling, 314 whereas Mobile IPv6 uses IPv6 extension headers. This allows for a 315 cleaner implementation, since the code can fully integrated with the 316 IP-processing where it belongs, and no transport protocol port 317 numbers need to be bound for special use. 319 Mobile IPv4 has two basic modes of operation, triangle routing and 320 bi-directional tunneling. Mobile IPv6 supports an optional route 321 optimization mode that is more efficient than the alternatives 322 available in Mobile IPv4. Route optimization avoids both the header 323 overhead of tunneling and the latency involved in the routing 324 indirection that Mobile IPv4 depends on for reaching mobile nodes. 325 In certain business scenarios, the Mobile IPv6 route optimization 326 feature might actually result in saving money, since it greatly 327 reduces the amount of traffic to and from the home network. 329 Mobile routers (and correspondingly, the mobile networks behind them) 330 are supported in Mobile IPv4, but their operation is not particularly 331 well specified. In contrast, Mobile IPv6 mobile routers, called NEMO 332 routers, have been specified very clearly in their own standards 333 documents [RFC3963]. Many of the complications and difficulties that 334 arise only in mobile router scenarios, but not with simple mobile 335 nodes, are only being solved actively in the IETF in the context of 336 NEMO, and not in the context of Mobile IPv4. 338 In summary, based on cleaner design, support for route optimization, 339 and NEMO extensions, IPv6 has superior mobility features than IPv4. 341 6. Multicast and Anycast 343 IPv4 and IPv6 are both capable of supporting network-layer multicast 344 communications. The major differences between IPv4 and IPv6 in terms 345 of multicast lie mainly in the fact that multicast support is 346 considered an "additional" part of IPv4, whereas in IPv6 it is 347 integral. IPv6's addressing architecture defines certain commonly 348 useful multicast addresses (e.g. all-routers), and describes the 349 ability to scope multicast addresses (e.g. there is a link-local 350 scope that can refer only to neighbors, along with scopes for 351 interface-local, admin-local, site-local, organization-local, and 352 global) [RFC4291]. This is used as a building block for the ND 353 service for autoconfiguration in IPv6. Broadcast addresses as used 354 in IPv4 are then replaced with multicast addresss of the appropriate 355 scope. 357 The basic host to router multicast protocol in IPv4 is IGMPv3 358 [RFC3376]. In IPv6, this function is filled by MLDv2 [RFC3810], 359 which is functionally equivalent. The main difference between the 360 two protocols is similar to one of the differences between ARP and 361 ND, in that IGMPv3 messages are encapsulated directly in IPv4 362 datagrams, whereas MLDv2 messages are carried by ICMPv6 inside IPv6. 363 The difference is in the reuse of ICMPv6 as a general purpose control 364 messaging/signaling protocol, rather than defining a new protocol 365 number with separate processing. 367 In theory the IPv4 and IPv6 multicast features might be seen as 368 comparable, but in reality, IPv6 has a large advantage in that it was 369 designed from the start with multicast as a consideration. As 370 deployed, IPv4 routers on the public Internet are usually not 371 configured to support much if any multicast traffic, whereas IPv6 372 routers must support multicast to perform basic functions. IPv6 373 multicast also does not rely on the ungainly tunnels that are used in 374 IPv4 multicast to get around the common one-to-one mapping between 375 interfaces and IPv4 addresses. Since IPv6 specifically supports 376 assigning several addresses to an interface, multicast support is 377 more straightforward. 379 While the early work on the concept of anycast involved IPv4 380 [RFC1546], and in the IPv4 Internet, anycast is actively being used 381 in particular niches [Woodcock02], anycast features are not formally 382 a feature of the IPv4 standard, but are supported in the IPv6 383 standard. Technically, most unicast routing protocols can support 384 anycast without any changes, since routing messages advertising 385 anycast groups have similar semantics as those advertising multihomed 386 sites. However, due to the difference in nature between unicast and 387 anycast communications, changes at other layers of the protocol stack 388 are required to properly use anycast. Anycast continues to be a 389 research area with several challenging topics. Particularly it is 390 not clear how IPv6 anycast will be used on a global scale [WC04]. 391 Given the degree of uncertainty in what the utility of anycast is, 392 and how technical barriers for global use could be overcome, it does 393 not seem to be possible to assess IPv4 versus IPv6 anycast features 394 at this time. 396 7. Flexibility and Growth 398 Enterprise network designers have a strong desire for their networks 399 to be able to grow with an organizations needs and be flexible enough 400 to allow for rapid deployment of new applications and services. IPv6 401 currently seems much more capable than IPv4 in meeting these demands. 402 For instance, the limited amount of space available for subnetting in 403 IPv4 makes networks relatively inflexible. Renumbering in IPv4 is a 404 difficult operation that the protocol was not designed for, whereas 405 IPv6's design has a number of features that allow automatic 406 renumbering to be smoothly and efficiently supported [Chown04]. 408 As noted in the companion IPv6 maturity study [EI06], there is 409 currently only one IETF working group that seems to be chartered to 410 provide an IPv4-specific solution, while there are many groups 411 working on IPv6-specific solutions. This indicates that in the 412 future, it is possible that a number of specific network layer 413 enhancements may only be available for IPv6 networks. It should be 414 noted however, that the vast majority of IETF groups are pursuing 415 solutions that work in conjunction with both IPv4 and IPv6. 417 In many IPv4 end-sites, the use of NAT is popular for a number of 418 reasons. However, NAT is known to have many poor architectural 419 properties [RFC2993] [RFC3027]. In IPv6, the common NAT 420 functionalities that network administrators are interested in can all 421 be performed without any of the negative repercusions [VHDCK05]. The 422 ability to deploy new applications without any concern for 423 application layer gateways in the NAT, or complex tunneling 424 mechanisms [RFC3489] [RFC4380] alone is large practical benefit of 425 IPv6. 427 8. Security Considerations 429 This informational document only contains informational text about 430 IPv6 and IPv4 features. There are no new security considerations 431 raised by this material. 433 9. Acknowledgements 435 Work on this document was performed at NASA's Glenn Research Center, 436 in support of the NASA Space Communications Architecture Working 437 Group (SCAWG), and the FAA/Eurocontrol Future Communications Study 438 (FCS). Will Ivancic of NASA contributed useful comments on this 439 document. 441 10. Informative References 443 [Chown04] Chown, T., "Things to Think About When Renumbering an IPv6 444 Network", 445 draft-chown-v6ops-renumber-thinkabout-00 Internet-Draft 446 (expired), October 2004. 448 [EI06] Eddy, W. and W. Ivancic, "Assessment of IPv6 Maturity", 449 draft-eddy-ipv6-maturity-00 Internet-Draft (work in 450 progress), May 2006. 452 [Eddy06] Eddy, W., "Comparison of IPv4 and IPv6 Header Overhead", 453 draft-eddy-ip-overhead-00 Internet-Draft (work in 454 progress), May 2006. 456 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 457 September 1981. 459 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 460 converting network protocol addresses to 48.bit Ethernet 461 address for transmission on Ethernet hardware", STD 37, 462 RFC 826, November 1982. 464 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 465 Inter-Domain Routing (CIDR): an Address Assignment and 466 Aggregation Strategy", RFC 1519, September 1993. 468 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 469 Anycasting Service", RFC 1546, November 1993. 471 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 472 Incremental Update", RFC 1624, May 1994. 474 [RFC1825] Atkinson, R., "Security Architecture for the Internet 475 Protocol", RFC 1825, August 1995. 477 [RFC1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed 478 MD5", RFC 1828, August 1995. 480 [RFC1936] Touch, J. and B. Parham, "Implementing the Internet 481 Checksum in Hardware", RFC 1936, April 1996. 483 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 484 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 485 BCP 12, RFC 2050, November 1996. 487 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 488 (IPv6) Specification", RFC 2460, December 1998. 490 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 491 Discovery for IP Version 6 (IPv6)", RFC 2461, 492 December 1998. 494 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 495 Autoconfiguration", RFC 2462, December 1998. 497 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 498 "Definition of the Differentiated Services Field (DS 499 Field) in the IPv4 and IPv6 Headers", RFC 2474, 500 December 1998. 502 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 503 November 2000. 505 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 506 with the IP Network Address Translator", RFC 3027, 507 January 2001. 509 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 510 Stateless Address Autoconfiguration in IPv6", RFC 3041, 511 January 2001. 513 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 514 September 2002. 516 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 517 August 2002. 519 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 520 Thyagarajan, "Internet Group Management Protocol, Version 521 3", RFC 3376, October 2002. 523 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 524 "STUN - Simple Traversal of User Datagram Protocol (UDP) 525 Through Network Address Translators (NATs)", RFC 3489, 526 March 2003. 528 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 529 in IPv6", RFC 3775, June 2004. 531 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 532 Addresses and AS Identifiers", RFC 3779, June 2004. 534 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 535 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 537 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 538 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 539 RFC 3963, January 2005. 541 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 542 Neighbor Discovery (SEND)", RFC 3971, March 2005. 544 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 545 RFC 3972, March 2005. 547 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 548 Architecture", RFC 4291, February 2006. 550 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 551 April 2006. 553 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 554 Internet Protocol", RFC 4301, December 2005. 556 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 557 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 559 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 560 Network Address Translations (NATs)", RFC 4380, 561 February 2006. 563 [RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for 564 Generating Link-Scoped IPv6 Multicast Addresses", 565 RFC 4489, April 2006. 567 [VHDCK05] de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. 568 Klein, "IPv6 Network Architecture Protection", 569 draft-ietf-v6ops-nap-02 Internet-Draft (work in progress), 570 October 2005. 572 [WC04] Weber, S. and L. Cheng, "A Survey of Anycast in IPv6 573 Networks", IEEE Communications Magazine , January 2004. 575 [Woodcock02] 576 Woodcock, B., "Best Practices in IPv4 Anycast Routing", 577 presentation slides version 0.9, August 2002. 579 Authors' Addresses 581 Wesley M. Eddy 582 Verizon Federal Network Systems 583 21000 Brookpark Rd, MS 54-5 584 Cleveland, OH 44135 586 Phone: 216-433-6682 587 Email: weddy@grc.nasa.gov 589 Joseph Ishac 590 NASA Glenn Research Center 591 21000 Brookpark Rd, MS 54-5 592 Cleveland, OH 44135 594 Phone: 216-433-3494 595 Email: jishac@grc.nasa.gov 597 Intellectual Property Statement 599 The IETF takes no position regarding the validity or scope of any 600 Intellectual Property Rights or other rights that might be claimed to 601 pertain to the implementation or use of the technology described in 602 this document or the extent to which any license under such rights 603 might or might not be available; nor does it represent that it has 604 made any independent effort to identify any such rights. Information 605 on the procedures with respect to rights in RFC documents can be 606 found in BCP 78 and BCP 79. 608 Copies of IPR disclosures made to the IETF Secretariat and any 609 assurances of licenses to be made available, or the result of an 610 attempt made to obtain a general license or permission for the use of 611 such proprietary rights by implementers or users of this 612 specification can be obtained from the IETF on-line IPR repository at 613 http://www.ietf.org/ipr. 615 The IETF invites any interested party to bring to its attention any 616 copyrights, patents or patent applications, or other proprietary 617 rights that may cover technology that may be required to implement 618 this standard. Please address the information to the IETF at 619 ietf-ipr@ietf.org. 621 Disclaimer of Validity 623 This document and the information contained herein are provided on an 624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 626 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 627 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 628 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 Copyright Statement 633 Copyright (C) The Internet Society (2006). This document is subject 634 to the rights, licenses and restrictions contained in BCP 78, and 635 except as set forth therein, the authors retain all their rights. 637 Acknowledgment 639 Funding for the RFC Editor function is currently provided by the 640 Internet Society.