Internet DRAFT - draft-eddy-ipv6-ip4-comparison
draft-eddy-ipv6-ip4-comparison
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]
