The ISP Column
A monthly column on all things Internet
|
|
|
|
|
ISP Column Home
|
|
|
|
|
A Response from the IPv6 Forum
January 2003
Latif Ladid and Jim Bound
"Waiting for IP version
6" by Geoff Huston:
The year has only just started and already I can see the event calendar
filling up with a steady stream of IP version 6 summits, workshops and
forums, all clamoring for attention. No doubt the claim will be made
sooner or later that 2003 will be the year for IPv6. Such a claim may
have a little more credibility if it was a novel one, but after hearing
the same claim made at the start of each of the least five years or so,
it's starting to wear a bit thin for me, and with many others I suspect.
So will IPv6 ever come, or are we to be left waiting indefinitely?
IPv6 Forum Response:
IPv6 summits, such as the IPv6 Forum summits, are well intentioned educational,
promotional, and technology events for the industry to assist with the deployment
of IPv6 worldwide. The IPv6 Forum, as a leading body for IPv6, is not aware
of any summit or other events that have declared IPv6 will deploy in the next
year. Clearly, test beds for IPv6 will continue to grow yearly and are the first
early adopter deployments. Also, the claims of IPv6 deployment vary within each
geography, depending on their need for IPv6. The IPv6 Forum summits range from
global worldwide summits to IPv6 Forum regional task force summits, which are
emerging around the world. The IPv6 Forum as one body has never declared at
any point in time "this is the year of IPv6", and for any body to do so would
be inappropriate today. The IPv6 Forum works on the evolution of IPv6 deployment
daily as a business, a technology, and an awareness promotional effort worldwide
with members from different backgrounds within our global society and industry.
It would be good if in the future claims about IPv6 summits or events also listed
the exact owner and location of those summits. If such claims at mentioned summits
or events are marketing "myths", the IPv6 Forum would help to correct the problem.
The IPv6 Forum believes the article presents the
"theoretical" form as a perspective, and not the "practical deployment"
form as a perspective. An example of the practical view is IPv4-NAT
cannot support peer-to-peer applications and security, which is a
requirement for the users and businesses of the Internet, for which IPv6
is the only solution. It is important to differentiate IPv6 advantages
over the current IPv4-NAT wide deployment, in addition to the IPv6
advantages without IPv4-NAT. The IPv6 Forum also believes that IPv4-NAT
is far more predominant than IPv4 without NAT and the deployment problem
for the Internet, which IPv6 resolves.
In 1994 the IETF Next Generation protocol design team defined the core IPv6 protocol. The essential characteristic of the protocol was that of an evolutionary refinement of the version 4 protocol, rather than a revolutionary departure from V4 to an entirely different architectural approach.
The IETF formed an Internet Protocol Next Generation (IPng)
Directorate in 1994, who selected the IPv6 Protocol from a set of
proposals, is a more accurate account of what happened. There were
multiple proposals from within the Internet community presented to the
IETF. The proposal selected to begin IPv6 work in the IETF was designed
by Dr. Steve Deering (Cisco Fellow), was named "SIP" (Simple IP
Protocol).
The major strength of the IPv6 protocol is the use of fixed length 128 bit address fields. Other packet header changes include the dropping of the fragmentation control fields from the IP header, dropping the header checksum and length, and altering the structure of packet options within the header and adding a flow label. But it is the extended address length that is the critical change with IPv6. A 128 bit address field allows an addressable range of 2 to the 128th power, and 2 to the power of 128 is an exceptionally large number. On the other hand if we are talking about a world that is currently capable of manufacturing more than a billion silicon chips every year, and recognizing that even a 10-3 density ration would be a real achievement, then maybe its not all that large a number after all. There is not doubt that such a protocol has the ability to encompass a network that spans billions of devices, which is a network attribute that is looking more and more necessary in the coming years.
The selection of the protocol for IPv6 was for many
reasons see RFC 1752.
The IPng Directorate deliberated on many features from all the
proposals. IPv6 also improves upon the way nodes are discovered, how
routing headers are defined, mandated IPsec as IP security protocol, and
the IETF designed within IPv6 the ability to provide a stateless model
of IPv6 for autoconfiguration of nodes and the option of building
stateless networks for cases where that is a benefit to the users.
There are other advantages of IPv6 from an implementers perspective too,
but that is not appropriate in this response to discuss (e.g. How bits
were aligned in fields)
IPv6 is More Secure
A common claim is that IPv6 is more "secure" than IPv4. It's more
accurate to indicate that IPv6 is no more or less secure that IPv4.
Both IPv4 and IPv6 offer the potential to undertake secure
transactions across the network, and both protocols are potentially
superior than attempting to undertake highly secure transactions in
the face of various forms of active middleware such as NATs. Yes,
the IPv6 specification includes as mandatory support for
Authentication and Encapsulating Security Payload extension
headers, but no, there is no 'mandatory to use" sticker associated
with these extension headers, and, like IPv4 IPSEC, it is let to
the application and the user to determine whether to deploy
security measures at the network transport level. So, to claim that
V6 is somehow implicitly superior to V4 is an overly enthusiastic
claim that falls into the category of "IPv6 myth".
The IPv6 Forum would like all myths to cease to exist, and
do not support such myths. What the IPv6 Forum claims is that IPv4-NAT,
which is the reality for most using the Internet today, is not
acceptable for large scale use by the global populous or industry today
or for tomorrow. IPv4-NAT cannot support peer-to-peer applications or
security. With the IPv6 larger address space and mandatory IPsec as
part of IPv6, the opportunity for peer-to-peer applications and security
to become the norm for Internet users is possible with IPv6. IPv4-NAT
removes many of the security features required for a secure Internet and
the IPv6 Forum points out those missing features and will continue to do
so. In addition the IPv6 Forum points out how those features can be
available with IPv6 deployment.
IPv6 is Required for Mobility
It is also claimed that only IPv6 supports mobility. If one is
talking about a world of tens of billions of mobile devices, then
the larger V6 address fields are entirely appropriate for such
large scale deployments. But if the claim is more about the
technology to support mobility rather than the number of mobile
devices, then this claim also falls short. The key issue with
mobility is that mobility at a network layer requires the network
to separate identity and network location, so that as a device
"moves" within the network its identity remains constant while its
location is changing. V4 overloaded the semantics of an address to
include both identity and locality within an address, and V6 did
not alter this architectural decision. In this respect IPv4 and
IPv6 offer the same levels of support for mobility. Both protocols
require an additional header field to support a decoupled network
identity, commonly referred to as the "home address", and then
concentrate on the manner of the way in which the home agent
maintains a trustable and accurate copy of the mobile node or
network's current location. This topic remains the subject of
activity within the IETF in both V4 and V6.
The IPv6 Forum believes that for large scale deployment of
Mobile IP that IPv6 is required. We also do claim that IPv6 contains
inherent features within the IPv6 architecture to support Mobile IPv6.
That advantage comes from the stateless autoconfiguration model
permitted in IPv6 and the extended new Neighbor Discovery mechanisms
that are used for node discovery on a network in IPv6. In addition the
IPv6 Forum believes the IPv6 architecture permits a superior method to
provide options with the Next Header and Destination Options format and
afforded Mobile IPv6 the ability to provide a better design of Mobility
with IPv6 over IPv4. In addition the Mobile IPv6 Routing Optimization
is far superior to that available with Mobile IPv4. Readers should go
to the IETF page and see the benefits listed in the Mobile IPv6
specification over Mobile IPv4
(http://ietf.org/html.charters/mobileip-charter.html). The advantage
listed in the beginning section of the Mobile IPv6 specification were
possible because of the new features in the architecture of IPv6.
IPv6 is Better for Wireless Networks
Mobility is often associated with wireless, and again there has
been the claim that somehow IPv6 is better suited for wireless
environments than IPv4. Again this is well in the realm of myth.
Wireless environments differ from wireline environments in a number
of ways. One of the more critical differences is that a wireless
environment may experience bursts of significant levels of bit
error corruption, which in turn will lead to periods of non-
congestion-based packet loss within the network. A TCP transport
session is prone to interpreting such packet loss as being the
outcome of network-level congestion. The TCP response is not only
retransmission of the corrupted packets, but also an unnecessary
reduction of the sending rate at the same time. Neither IPv4 nor
IPv6 have explicit signaling mechanisms to detect corruption-based
packet loss, and in this respect the protocols are similarly
equipped, or ill-equipped as in this case, to optimize the carriage
efficiency and performance of a wireless communications subnet.
The IPv6 Forum believes the address space of IPv6 will
permit more users and without IPv4-NAT so that peer-to-peer can
re-continue on the Internet. See RFC 2993 "Architectural Implications of
NAT" or information at the
IPv6 Forum web site. This benefit means that the ability to deploy
billions of wireless devices that may have multiple addresses is only
possible with IPv6.
IPv6 offers better QoS
Another consistent assertion is that V6 offers "bundled" support
for differentiated Quality of Service (QoS), whereas V4 does not.
The justification for this claim often points to the 20-bit flow
label in the IPv6 header as some kind of instant solution to QoS.
This conveniently omits to note that the flow identification field
in the V6 header still has no practical application in large scale
network environments. Both IPv4 and IPv6 support an 8 bit traffic
class field, which includes the same 6 bit field for differentiated
service code points, and both protocols offer the same fields to an
Integrated Services packet classifier. From this perspective QoS
deployment issues are neither helped nor hindered by the use of
IPv4 or IPv6. Here, again, it's a case of nothing has changed.
IPv6 has no QOS advantage over IPv4 today. The IPv6 Forum
does believe IPv6 with the Flow Label in the header has the potential to
extend QOS beyond IPv4 today, and our members work within the IETF to
support the development of the flow label to extend QOS with IPv6.
Only IPv6 supports Auto-Configuration
Only IPv6 offer plug and plug auto-configuration is another common
claim. Again this is an over-enthusiastic statement given the
widespread use of the Dynamic Host Configuration Protocol (DHCP) in
IPv4 networks these days. Both protocol environments support some
level of "plug and play" auto-configuration capability and in this
respect the situation is pretty much the same for both V4 and V6.
The IPv6 Forum believes an IPv6 advantage is the ability to
support stateless autoconfiguration in the inherent IPv6 architecture,
and that has been proven with the current commercial products today
shipping IPv6 stateless autoconfiguration, which cannot be done with
IPv4.
IPv6 Solves Routing Scaling
It would be good if IPv6 included some novel approach that solved,
or even mitigated to some extent, the routing scaling issues.
Unfortunately, this is simply not the case, and the same techniques
of address aggregation using provider hierarchies apply as much to
IPv6 as IPv4. The complexity of routing is an expression of the
product of the topology of the network, the policies used by
routing entities and the dynamic behaviour of the network, and not
the protocol being routed. The larger address space does little to
improve on capability to structure the address space in order to
decrease the routing load. In this respect V6 does not make IP
routing any easier, nor any more scaleable.
Routing scaling requires many parts besides the IP layer of
IPv4 or IPv6, as the article states. The IPv6 Forum does believe the
aggregated address space properties of IPv6 are inherent, not an after
thought as band-aid, which is the case with IPv4. This will permit a
much better address space for Routing Scaling efforts with IPv6 as core
IP layer protocol than IPv4 with band-aids. Thus, IPv6 has an advantage
here over IPv4 (no band-aids).
IPv6 provides better support for Rapid Prefix Renumbering
If provider-based addressing is to remain an aspect of the deployed
IPv6 network, then one way to undertake provider switching for
multi- homed end networks is to allow rapid renumbering of a
network common prefix. Again, it has been claimed that IPv6 offers
the capability to undertake rapid renumbering within a network to
switch to a new common address prefix. Again V6 performs no
differently from V4 in this regard. As long as "rapid" refers to a
period of hours or days then, yes, IPv4 and IPv6 both support
"rapid" local renumbering. For a shorter timeframe for "rapid",
such as a few seconds or even a few milliseconds, this is not
really the case.
The IPv6 Forum, as one case, does not list this as an
advantage, but does state that automatic renumbering on a local area
network does work today with multiple interoperable commercial
implementations and is a by-product advantage of stateless
autoconfiguration. The IPv6 Forum members do work within the IETF to
support router renumbering like
RFC 2894 "Router Renumbering for IPv6", which will assist with
prefix renumbering and to promote adoption of router renumbering with
vendor members and use by end users. At some point in time the IPv6
Forum believes that IPv6 will provide support for renumbering of
networks in an efficient and expedient manner, in addition to local area
networks. In IPv4 there are no inherent mechanism as in IPv6 to support
this future requirement. But, the current capabilities of IPv6
stateless autoconfiguration have been clearly seen and in test bed mode
by enterprises, government, providers, and the military.
IPv6 provides better support for Multi-Homed sites
This leads on to the more general claim that IPv6 supports multi-
homing and dynamic provider selection. Again this is an optimistic
claim, and the reality is a little more tempered. Multi-homing is
relatively easy if you are allowed to globally announce the
network's address prefix without recourse to any form of provider-
based address aggregation. But this is a case of achieving a local
objective at a common cost of the scaleability of the entire global
routing system, and this is not a supportable cost. The objective
here is to support some form of multi-homing of local networks
where any incremental routing load is strictly limited in its
radius of propagation. This remains an active area of consideration
for the IETF and clear answers, in IPv4 or IPv6, are not available
at present. So at best this claim is premature and more likely the
claim will again fall into the category of myth rather than firm
reality.
The IPv6 Forum does not list this as an advantage. The
IPv6 Forum members are working within the IETF to support the work on
Multi-sited and Multi-homed network solutions for IPv6 tomorrow
(http://ietf.org/html.charters/multi6-charter.html). The IPv6 Forum
does recommend the use of
RFC 3178 "IPv6 Multihoming Support at Site
Exit Routers"
for initial deployment of
IPv6 for this problem, which exists with IPv4 too. RFC 3178 can provide
a solution for initial IPv6 deployment, until we develop a more robust
solution within the IETF community.
IPv4 has run out of addresses
Again, this is in the category of myth rather than reality. of the total IPv4
space some 6% is reserved and another 6% is used for multicast. 51% of the space
has already been allocated, and the remaining 37% (or some 1.5 billion addresses)
is yet to be allocated. Prior to 1994 some 36% of the address space had been
allocated. Since that time, and this includes the entire Internet boom period,
a further 15% of the available address space was allocated. With a continuation
of current policies it would appear that IPv4 address space will be available
for many years yet.
The IPv6 Forum believes there is only 36% percent of the
address space left and support
RFC 3194 "H-Density Ratio" rationale.
We also state China
alone could use up the entire IPv4 address space left or Mobile IPv6
device deployment in one year. The IPv6 Forum's position is that the
IPv4 address space is a scarce resource and the Internet is in jeopardy
and needs to begin moving towards IPv6 deployment now, and begin the
evolution to IPv6 as the core IP layer of the Internet global
infrastructure.
So Why IPv6 Anyway?
The general observation is that V6 is not a "feature-based" revision of IPv4
- there is no outstanding capability of IPv6 that does not have a fully functional
counterpart in IPv4. Nor is there a pressing urgency to deploy IPv6 because
we are about to run out of available IPv4 address space in the next few months
or even years within what we regards as the "conventional" Internet. It would
appear that the real drivers lurk in the device world. We are seeing the various
wireless technologies, ranging from Bluetooth for personal networking through
the increasingly pervasive 802.11 hot-spot networking to the expectations arising
from various forms of 3G large radius services being combined with consumer
devices, control systems, identification systems and various other forms of
embedded dedicated function devices. The silicon industry achieves its greatest
leverage through sheer volume of production, and it is the combination of Internet
utility with the production volumes of the silicon industry that we will see
demands for networking that encompasses tens, if not hundreds, of billions of
devices. This is the world where IPv6 can and will come into its own, and I
suspect that it is in this device and utility mode of communications that we
will see the fundamental drivers that will lead to widespread deployment of
IPv6 support networks.
The IPv6 Forum agrees with the articles assessment of billions of devices requiring IPv6, but we believe there are other reasons for IPv6 and that is a strong disagreement between the IPv6 Forum and the article. Please see "IPv6 - An Internet Evolution"" and in addition we believe IPv4-NAT is unacceptable for continued growth of the Internet. We disagree with this article's assumption that the band-aids done for IPv4 are equivalent to the features of IPv6. Clearly, the band-aids taken from the inherent design of IPv6 were a good band-aid set for IPv4 to implement as add-on, but pale in comparison with these features inherent in the IPv6 protocol, by an order of magnitude for practical deployment.
The IPv6 Forum believes this article to be an incorrect view of the the benefits of IPv6. The IPv6 assumptions in our response can be better understood by attending our events, reading our papers, or viewing our web pages worldwide for IPv6 (www.ipv6forum.com)
Disclaimer
The above views do not necessarily represent the views of the Internet Society.
About the Author
Latif Ladid is the President of the IPv6 Forum. Latif has worked in various managerial and marketing positions at Nixdorf Computers in Germany, and Hewlett-Packard in the Middle East, as International Sales Manager at ComputerLand Europe in Luxembourg, and as Managing Director of ComputerLand Switzerland. Served as Vice President at Canadian Internet specialist Develcon. Latif joined IPv6-pioneer Telebit as Vice President (In June 1999, Ericsson acquired a major share in Telebit, creating Ericsson Telebit A/S). With strong support from the IETF Next Generation NG -IPv6 & NG Transition Working Groups and the IPv6 Deployment group, Latif initiated the foundation of the IPv6 Forum in May 1999. Served, from 1996 to 1998, as chairman of Global-ISDN. Included in 1998 as International Who’ s Who Professional. Researcher on multiple European Commission IST Projects ( 6INIT, 6WINIT, ..) on Internet Infrastructure and Next Generation Technologies. Co-Founder of the Next Generation Networks Initiative (NGNi,) funded by the European Commission to kick-off Jan 1, 2001. Member of 3GPP Project Co-ordination Group. He holds an ESCAE (France), and a Post-Graduate Diploma in business and administration in the UK. He is currently serving as a member of the Board of Trustees of the Internet Society.
Jim Bound is the Chair of the IPv6 Forum Technical Directorate. Jim is a Staff Fellow at Hewlett Packard and provides technical direction within the HP-UX Networking Group. Jim was a member of the Internet Protocol Next Generation (IPng) Directorate within the Internet Engineering Task Force (IETF), which selected IPv6, among several proposals, to become the basis of the IETF's work on an IPng in 1994. Jim has been a key designer and implementer of IPv6 (demonstrating the first IPv6 stack in the industry) and contributor to most core IPv6 specifications. Jim is also a co-author of several Internet specifications and works in progress regarding the interoperation of IPv4 and IPv6 for deployment. Jim founded the ad-hoc IPv6 Deployment Group working with implementers across the Internet, which became the IPv6 Forum, where Jim is now Chair of the IPv6 Forum Technical Directorate. Jim is a member of the Internet Society and Institute of Electronics, Electrical Engineers (IEEE). Jim in July 2001 received from the IPv6 Forum the Internet IPv6 Pioneer Award as the IPv6 Forums "Lead Plumber". Evolution of The Internet Technology, Beijing, China, May 2002