Network Working Group                                            W. Eddy
Internet-Draft                           Verizon Federal Network Systems
Expires: November 10, 2006                                      J. Ishac
                                              NASA Glenn Research Center
                                                             May 9, 2006


                  Comparison of IPv6 and IPv4 Features
                   draft-eddy-ipv6-ip4-comparison-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 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document collects and comments on several aspects IPv6 that
   differ from IPv4, and what practical impacts these differences might
   have to an organization.  This data can be used in decision-making
   processes where the business case for deploying IPv6 is under
   consideration.





Eddy & Ishac            Expires November 10, 2006               [Page 1]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Addressing and Routing . . . . . . . . . . . . . . . . . . . .  4
   3.  Quality of Service . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Multicast and Anycast  . . . . . . . . . . . . . . . . . . . . 11
   7.  Flexibility and Growth . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10.   Informative References . . . . . . . . . . . . . . . . . . . 15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19





































Eddy & Ishac            Expires November 10, 2006               [Page 2]


Internet-Draft        IPv6-IPv4 Feature Comparison              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).  However, some decision-
   makers have been misinformed that IPv6 is equivalent to IPv4 with
   larger addresses.  This document sheds light on the reality that IPv6
   contains several additional features which may give it an improved
   business case over IPv4.  Companion documents debunk arguments where
   IPv4 is brought forward as a favored choice based on the logic that
   it has lower "overhead" than IPv6 [Eddy06], and provide evidence that
   IPv6 is currently mature enough for widespread use [EI06].

   This document is broken down as follows.  Section 2 compares the
   addressing and routing functions and capabilities in IPv4 and IPv6.
   Section 3 describes Quality of Service (QoS) features in both
   protocols.  Section 5 considers the mobility extensions to each
   protocol.  Section 6 discusses the multicast and anycast capabilities
   of IPv4 and IPv6, and Section 7 examines flexibility and
   extensibility.





















Eddy & Ishac            Expires November 10, 2006               [Page 3]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


2.  Addressing and Routing

   The most obvious difference between IPv4 and IPv6 is the change in
   the address size from 32 bits in IPv4 [RFC0791] to 128 bits in IPv6
   [RFC2460].  This increase in the raw number of bits means that there
   is a factor of 2^96 more addresses available in IPv6 than in IPv4.
   Due to the way that the address spaces are subnetted, scoped, and
   defined for multicast, private/experimental use, and other factors,
   however, the actual contrast is less direct than this simple factor.

   Aside from a few specific blocks for local-use, multicast, or other
   specific functions, the majority of the IPv4 32-bit address space is
   designated for global unicast addresses [RFC3330].  In the IPv4
   addressing architecture, IANA delegates Regional Internet Registries
   (RIRs) /8 address blocks (8-bit network identifiers), which the RIRs
   can then divide into variable-length blocks for further assignment to
   ISPs or other registries [RFC2050] [RFC1519].  The maximum address
   block that a site could ever be given is a /8, which leaves only 24-
   bits for subnetting and addressing within the organization.
   Historically, large or complexly-organized groups required multiple
   /8s.  For instance, at least 7 /8s belong to the US Department of
   Defense.  Considering there are only 256 such blocks, the IPv4
   address space can be seen as severely limited.  To compound matters,
   even using multiple /8s is a poor solution, since there is no
   guarantee that they will be numerically continuous, and if they are
   not, then both the local numbering scheme may be awkward, and
   multiple global routing table entries will be stored and propagated.
   In recent years, many IPv4 users have circumented these issues by
   using Network Address Translators (NATs), although this practice is
   known to be frought with problems of its own [RFC2993] [RFC3027].

   According to the IPv6 addressing architecture [RFC4291], the prefix
   of 001 identifies IPv6 global unicast addresses, so 1/8 of the
   address space, or 2^125 such addresses are available.  To date, IANA
   has given IPv6 address blocks varying from /16 to /23 in size to the
   RIRs.  The documented policy for the downstream assignment from RIRs
   to LIRs is that each LIR receive a minimum of a /32.  The minimum
   sized address block that an LIR can then give to a site is a /48.
   For more details see:
   http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02.  Since
   an IPv6 site can expect a *minimum* of a /48, this gives 16 bits of
   subneting space and 64 bits of interface identifier within a subnet
   (80 bits combined).  Contrast this to an IPv4 site that can expect a
   *maximum* of a /8, leaving only 24 bits of space to be used for
   subnetting and host addressing combined.  Since in reality, most
   sites do not get /8s, but rather /16s or /24s, there are more likely
   to be only 4-8 bits for subneting and 4-8 bits for identifying hosts
   within a subnet.



Eddy & Ishac            Expires November 10, 2006               [Page 4]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


   The IPv6 addressing architecture includes scoped-addresses, including
   scoped multicast addresses.  Support for scoping in IPv6 is more
   fully defined and has some features that IPv4 has no analogues to.
   As a simple example, IPv6 has all-routers addresses, which allow a
   node to find or communicate with routers without knowing their
   unicast address ahead of time.  In IPv4, this is not possible without
   the assistance of other protocols.

   Configuring and managing addresses in IPv6 and IPv4 can both be
   accomplished using versions of the DHCP protocol.  However, IPv6 has
   mechanisms that allow a node to configure its own globally routable
   address, without the need for DHCP [RFC2462], and IPv4 has no
   counterpart to this functionality.  DHCP is still of practical use in
   both protocols though, due to its ability to provide other
   configuration data, such as DNS server addresses.

   Due to the fact that LIRs assign subnet addresses in IPv6, rather
   than simply end-node addresses (as often done in IPv4), DHCP supports
   prefix-delegation extensions for IPv6.  Prefix-delegation allows DHCP
   to manage the assignment of subnet prefixes in an automated fashion,
   and allows IPv6 routers to be automatically configured.  IPv4 has no
   comparable feature.

   In conjunction with the depletion of the IPv4 address pool, a second
   major driver in the design of IPv6 is that IPv4 inter-domain routing
   tables are very large.  This is due to the inability to aggregate
   addresses based on the way that IPv4 blocks have been assigned.  The
   IPv6 addressing architecture and assignment policy is designed such
   that subnet addresses can potentially be aggregated very effectively.
   Essentially, the idea is that the global routing table only has to
   know how to reach a small number of large backbone networks, and the
   subnet addresses belonging to millions of end-sites can be aggregated
   hierarchically under the backbone provider addresses.  This prevents
   routers from using large amounts of memory on the routing table, thus
   allowing lookups to be faster, and network operators to spend less
   money on expensive router memory upgrades.  Recent developments
   indicate that Provider Independent addressing may become more
   prevalent in IPv6 assignments, and so this feature could be negated.

   In the effort to build faster router platforms, two well-known speed-
   bumps in IPv4 were performing the checksum operations, and
   fragmenting datagrams, when required.  While relatively efficient
   means of computing the IPv4 checksum [RFC1624], and even implementing
   it in hardware [RFC1936], were developed, it was decided to improve
   speed by not including any checksum at all in IPv6.  The rationale
   behind this is that most link-layer protocols have at least their own
   checksum (and often their own retransmission protocols and error-
   correcting codes), and reliable application or transport protocols



Eddy & Ishac            Expires November 10, 2006               [Page 5]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


   also implement checksums.  Since some of the link and higher-layer
   checksums in use were actually more powerful than the simple IPv4
   checksum, it was of relatively little utility.  Typical IPv4 router
   designs are incapable of performing fragmentation operations in their
   optimized "fast-path", and instead have to resort to the "slow-path"
   when fragmentation is required.  This can represent a bottleneck that
   limits throughput and loads the central processor (also used for
   routing table maintenance and general device control).  Since this is
   exploitable merely by users at any point in the network sending
   packets larger than a particular link's MTU, this could be seen as a
   weakness.  In IPv6, routers never fragment packets; packets larger
   than an outgoing link's MTU are dropped.  It is a source node's duty
   to pro-actively fragment its own packets.  The lack of checksum and
   fragmentation responsibilties potentially allow IPv6 routers to
   perform slightly faster and with lower power requirements, but these
   differences are likely to be fairly minimal under typical use cases.

   Another difference between IPv4 and IPv6 is in the way that IP
   addresses within a subnet are resolved into link-layer protocol
   addresses.  IPv4 used the ARP [RFC0826] mechanism for this, while
   IPv6 uses Neighbor Discovery (ND) [RFC2461].  There are at least two
   key differences betwen ARP and ND.  The first is that ARP operates
   directly on top of the link layer, while ND operates using ICMPv6, on
   top of IPv6, on top of the link layer.  Practically, this means that
   in the design of link layer protocols, distinct codes identifying ND
   and IPv6 payload types do not have to be defined, whereas IPv4 and
   ARP require separate codepoints.  This is of only marginal
   importance.  The main difference between ARP and ND, is that IPv6's
   ND is highly extensible and this extensibility has been used for a
   number of purposes, including security (authentication of network
   elements and resolution protocol messages), automatic prefix and
   interface identifier configuration, and advertisement of the MTU.
   IPv4's ARP has no such facilities and no means for extension.

   Altogether, in terms of addressing, routing, and forwarding features,
   IPv6 has advantages over IPv4 in every respect considered.















Eddy & Ishac            Expires November 10, 2006               [Page 6]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


3.  Quality of Service

   The Differentiated Services QoS architecture utilizes the IPv4 Type
   of Service byte and the IPv6 Traffic Class byte in the same way
   [RFC2474].  In this respect, IPv4 and IPv6 are equivalent.

   A significant capability that is part of the standard IPv6 header,
   and is not present in IPv4, is the ability to classify traffic into
   flows based on a flow label header field.  This can be used as a
   basic building block to efficiently support QoS policies and
   protocols.  In IPv4, flows can only be classified by the relatively
   expensive process of examining (and possibly parsing) header fields.
   Thus, certain types of per-flow QoS can be enabled in routers with
   lower computational overhead when using IPv6.





































Eddy & Ishac            Expires November 10, 2006               [Page 7]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


4.  Security

   Both IPv4 and IPv6 can be used in conjunction with the IPsec suite of
   protocols [RFC4301].  In fact, the operation of the IPsec protocols
   is basically identical whether they are being used with IPv4 or IPv6.
   Since the Transport Layer Security (TLS) protocol [RFC4346] runs over
   top of the transport layer, and does not interface directly with IP,
   it is similarly mostly agnostic to the version of IP that is used.
   Both TCP and SCTP can run TLS, and both will run over IPv4 and IPv6.
   Additionally, the X.509 format for certificates that is often used in
   IPsec and TLS, has encoding methods for both IPv4 and IPv6 addresses
   [RFC3779].  So, the two most prevalent security architectures in the
   Internet suite, IPsec and TLS, have no significant differences
   between use with IPv4 and IPv6.

   It is often touted that IPv6 has superior security properties to
   IPv4.  In the majority of cases, the reasoning used to justify this
   is that IPsec is a part of IPv6, because in early IPsec
   specifications [RFC1825], it was stated that all IPv6-capable hosts
   MUST implement the IPsec Authentication Header in a basic
   configuration (keyed-MD5 with 128-bit key [RFC1828]), while for IPv4
   supporting any part of IPsec was optional.  In fact, current IPv6
   node requirements mandate that IPv6 nodes MUST support both
   Authentication Header and Encapsulating Security Payload portions of
   IPsec [RFC4294].  However, since IPv6's core functions do not rely on
   IPsec, and only support for manual keying is required, the argument
   that IPv6 is more secure than IPv4 based on the requirement to
   support IPsec is not well-founded.  The reality of the situation is
   that IPv6-conformant implementations can more certainly be expected
   to have support for IPsec, but it is still up to the users and
   network managers to configure them, and the exact same IPsec features
   are also readily available in IPv4 implementations, but not required
   by IETF fiat to be present.

   Outside of IPsec, there are other features of IPv6 that are not found
   in IPv4, and can potentially give IPv6 better security properties.  A
   couple of the features included under the Network Architecture
   Protection umbrella [VHDCK05] that are relevent to security are end-
   system privacy and topology hiding.  End-system privacy refers to the
   ability of an IPv6 end-system to generate and change its own IPv6
   address through selection of the Interface Identifier portion of the
   address.  A node can use this capability to change its address
   periodically to avoid things like easily being able to correllate
   remote log files of world-wide web activity [RFC3041].  IPv4 has no
   equivalent capability.  IPv4 nodes can dynamically change their
   public addresses using DHCP, but DHCP servers are rarely configured
   to permit this, and it requires a DHCP server, whereas the IPv6
   solution is end-host based.  Topology hiding is a similar technique



Eddy & Ishac            Expires November 10, 2006               [Page 8]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


   that involves changing the prefix refering to a subnet, rather than
   the interface identifier.  This prevents an attacker from being able
   to easily determine other related addresses from a known address.

   In addition, IPv6 has the optional secure neighbor discovery
   extension, which allows hosts to authenticate the ND messages
   [RFC3971], and uses cryptographically-generated addresses to prove
   address ownership without any certificate management or other
   security infrastructure [RFC3972].  IPv4 has no comparable features,
   and its address space is too small for the features to be portable to
   IPv4.

   In summary, IPv6 does have superior security features in comparison
   to IPv4, but these have little to do with IPsec, and both the IPsec
   and TLS functionalities are equivalent without regard to the
   underlying IP version.



































Eddy & Ishac            Expires November 10, 2006               [Page 9]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


5.  Mobility

   Support for node mobility is not required in either IPv4 or IPv6,
   however, both protocols support mobility extensions [RFC3344]
   [RFC3775].  The means of supporting mobility, and the features of
   each mobility protocol differ.  Mobile IPv4 uses UDP for signaling,
   whereas Mobile IPv6 uses IPv6 extension headers.  This allows for a
   cleaner implementation, since the code can fully integrated with the
   IP-processing where it belongs, and no transport protocol port
   numbers need to be bound for special use.

   Mobile IPv4 has two basic modes of operation, triangle routing and
   bi-directional tunneling.  Mobile IPv6 supports an optional route
   optimization mode that is more efficient than the alternatives
   available in Mobile IPv4.  Route optimization avoids both the header
   overhead of tunneling and the latency involved in the routing
   indirection that Mobile IPv4 depends on for reaching mobile nodes.
   In certain business scenarios, the Mobile IPv6 route optimization
   feature might actually result in saving money, since it greatly
   reduces the amount of traffic to and from the home network.

   Mobile routers (and correspondingly, the mobile networks behind them)
   are supported in Mobile IPv4, but their operation is not particularly
   well specified.  In contrast, Mobile IPv6 mobile routers, called NEMO
   routers, have been specified very clearly in their own standards
   documents [RFC3963].  Many of the complications and difficulties that
   arise only in mobile router scenarios, but not with simple mobile
   nodes, are only being solved actively in the IETF in the context of
   NEMO, and not in the context of Mobile IPv4.

   In summary, based on cleaner design, support for route optimization,
   and NEMO extensions, IPv6 has superior mobility features than IPv4.



















Eddy & Ishac            Expires November 10, 2006              [Page 10]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


6.  Multicast and Anycast

   IPv4 and IPv6 are both capable of supporting network-layer multicast
   communications.  The major differences between IPv4 and IPv6 in terms
   of multicast lie mainly in the fact that multicast support is
   considered an "additional" part of IPv4, whereas in IPv6 it is
   integral.  IPv6's addressing architecture defines certain commonly
   useful multicast addresses (e.g. all-routers), and describes the
   ability to scope multicast addresses (e.g. there is a link-local
   scope that can refer only to neighbors, along with scopes for
   interface-local, admin-local, site-local, organization-local, and
   global) [RFC4291].  This is used as a building block for the ND
   service for autoconfiguration in IPv6.  Broadcast addresses as used
   in IPv4 are then replaced with multicast addresss of the appropriate
   scope.

   The basic host to router multicast protocol in IPv4 is IGMPv3
   [RFC3376].  In IPv6, this function is filled by MLDv2 [RFC3810],
   which is functionally equivalent.  The main difference between the
   two protocols is similar to one of the differences between ARP and
   ND, in that IGMPv3 messages are encapsulated directly in IPv4
   datagrams, whereas MLDv2 messages are carried by ICMPv6 inside IPv6.
   The difference is in the reuse of ICMPv6 as a general purpose control
   messaging/signaling protocol, rather than defining a new protocol
   number with separate processing.

   In theory the IPv4 and IPv6 multicast features might be seen as
   comparable, but in reality, IPv6 has a large advantage in that it was
   designed from the start with multicast as a consideration.  As
   deployed, IPv4 routers on the public Internet are usually not
   configured to support much if any multicast traffic, whereas IPv6
   routers must support multicast to perform basic functions.  IPv6
   multicast also does not rely on the ungainly tunnels that are used in
   IPv4 multicast to get around the common one-to-one mapping between
   interfaces and IPv4 addresses.  Since IPv6 specifically supports
   assigning several addresses to an interface, multicast support is
   more straightforward.

   While the early work on the concept of anycast involved IPv4
   [RFC1546], and in the IPv4 Internet, anycast is actively being used
   in particular niches [Woodcock02], anycast features are not formally
   a feature of the IPv4 standard, but are supported in the IPv6
   standard.  Technically, most unicast routing protocols can support
   anycast without any changes, since routing messages advertising
   anycast groups have similar semantics as those advertising multihomed
   sites.  However, due to the difference in nature between unicast and
   anycast communications, changes at other layers of the protocol stack
   are required to properly use anycast.  Anycast continues to be a



Eddy & Ishac            Expires November 10, 2006              [Page 11]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


   research area with several challenging topics.  Particularly it is
   not clear how IPv6 anycast will be used on a global scale [WC04].
   Given the degree of uncertainty in what the utility of anycast is,
   and how technical barriers for global use could be overcome, it does
   not seem to be possible to assess IPv4 versus IPv6 anycast features
   at this time.













































Eddy & Ishac            Expires November 10, 2006              [Page 12]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


7.  Flexibility and Growth

   Enterprise network designers have a strong desire for their networks
   to be able to grow with an organizations needs and be flexible enough
   to allow for rapid deployment of new applications and services.  IPv6
   currently seems much more capable than IPv4 in meeting these demands.
   For instance, the limited amount of space available for subnetting in
   IPv4 makes networks relatively inflexible.  Renumbering in IPv4 is a
   difficult operation that the protocol was not designed for, whereas
   IPv6's design has a number of features that allow automatic
   renumbering to be smoothly and efficiently supported [Chown04].

   As noted in the companion IPv6 maturity study [EI06], there is
   currently only one IETF working group that seems to be chartered to
   provide an IPv4-specific solution, while there are many groups
   working on IPv6-specific solutions.  This indicates that in the
   future, it is possible that a number of specific network layer
   enhancements may only be available for IPv6 networks.  It should be
   noted however, that the vast majority of IETF groups are pursuing
   solutions that work in conjunction with both IPv4 and IPv6.

   In many IPv4 end-sites, the use of NAT is popular for a number of
   reasons.  However, NAT is known to have many poor architectural
   properties [RFC2993] [RFC3027].  In IPv6, the common NAT
   functionalities that network administrators are interested in can all
   be performed without any of the negative repercusions [VHDCK05].  The
   ability to deploy new applications without any concern for
   application layer gateways in the NAT, or complex tunneling
   mechanisms [RFC3489] [RFC4380] alone is large practical benefit of
   IPv6.





















Eddy & Ishac            Expires November 10, 2006              [Page 13]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


8.  Security Considerations

   This informational document only contains informational text about
   IPv6 and IPv4 features.  There are no new security considerations
   raised by this material.














































Eddy & Ishac            Expires November 10, 2006              [Page 14]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


9.  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 of NASA contributed useful comments on this
   document.

10.  Informative References

   [Chown04]  Chown, T., "Things to Think About When Renumbering an IPv6
              Network",
              draft-chown-v6ops-renumber-thinkabout-00 Internet-Draft
              (expired), October 2004.

   [EI06]     Eddy, W. and W. Ivancic, "Assessment of IPv6 Maturity",
              draft-eddy-ipv6-maturity-00 Internet-Draft (work in
              progress), May 2006.

   [Eddy06]   Eddy, W., "Comparison of IPv4 and IPv6 Header Overhead",
              draft-eddy-ip-overhead-00 Internet-Draft (work in
              progress), May 2006.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC1519]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
              Inter-Domain Routing (CIDR): an Address Assignment and
              Aggregation Strategy", RFC 1519, September 1993.

   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
              Anycasting Service", RFC 1546, November 1993.

   [RFC1624]  Rijsinghani, A., "Computation of the Internet Checksum via
              Incremental Update", RFC 1624, May 1994.

   [RFC1825]  Atkinson, R., "Security Architecture for the Internet
              Protocol", RFC 1825, August 1995.

   [RFC1828]  Metzger, P. and W. Simpson, "IP Authentication using Keyed
              MD5", RFC 1828, August 1995.

   [RFC1936]  Touch, J. and B. Parham, "Implementing the Internet



Eddy & Ishac            Expires November 10, 2006              [Page 15]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


              Checksum in Hardware", RFC 1936, April 1996.

   [RFC2050]  Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
              J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
              BCP 12, RFC 2050, November 1996.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3027]  Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027,
              January 2001.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
              September 2002.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support



Eddy & Ishac            Expires November 10, 2006              [Page 16]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


              in IPv6", RFC 3775, June 2004.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
              April 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4489]  Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
              Generating Link-Scoped IPv6 Multicast Addresses",
              RFC 4489, April 2006.

   [VHDCK05]  de Velde, G., Hain, T., Droms, R., Carpenter, B., and E.
              Klein, "IPv6 Network Architecture Protection",
              draft-ietf-v6ops-nap-02 Internet-Draft (work in progress),
              October 2005.

   [WC04]     Weber, S. and L. Cheng, "A Survey of Anycast in IPv6
              Networks", IEEE Communications Magazine , January 2004.

   [Woodcock02]
              Woodcock, B., "Best Practices in IPv4 Anycast Routing",



Eddy & Ishac            Expires November 10, 2006              [Page 17]


Internet-Draft        IPv6-IPv4 Feature Comparison              May 2006


              presentation slides version 0.9, August 2002.


Authors' Addresses

   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


   Joseph Ishac
   NASA Glenn Research Center
   21000 Brookpark Rd, MS 54-5
   Cleveland, OH  44135

   Phone: 216-433-3494
   Email: jishac@grc.nasa.gov






























Eddy & Ishac            Expires November 10, 2006              [Page 18]


Internet-Draft        IPv6-IPv4 Feature Comparison              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 & Ishac            Expires November 10, 2006              [Page 19]