ISP Column

In drafting an introductory paragraph to this response, I was going to note that one of the major differences between the study of mathematics and the study of technology is that there is invariably room for debate within technology, while formal mathematics attempts to work within a more rigid framework of logic and decideability. Technology is often defined through a sequence of deliberate design decisions, and within that process there is ample room for consideration of alternative approaches and perspectives. For me that is what makes technology such an absorbing area to work in. However, thanks to work in the first half of the 20th century, most noteably that of the Austrian mathematician Kurt Gödel, not even formal mathematics possesses that elusive quality of absolute determinism. Even in this area of study there is room for the undecideable, or, to put it another way, there is room for more than proveably right or wrong. To present a different perspective on IP version 6 debate, the IPv6 Forum has prepared a response to the "Waiting for IP version 6" column, and it is presented here. Thanks to Latif Ladid and Jim Bound for preparing this response.

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 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.

GH: 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.

IPv6: 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).

GH:
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.

IPv6: The
selection of the protocol for IPv6 was for many reasons see RFC 1752 (http://ietf.org/rfc/rfc1752.txt?number=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)

GH: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".

IPv6: 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.

GH: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.

IPv6: 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. The advantage listed in the beginning section of the Mobile IPv6 specification were possible because of the new features in the architecture of IPv6.

GH: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.

IPv6: 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" ftp://ftp.rfc-editor.org/in-notes/rfc2993.txt
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.

GH: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: 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.

GH: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.

IPv6: 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.

GH: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.

IPv6: 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).

GH: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.

IPv6: 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" (ftp://ftp.rfc-editor.org/in-notes/rfc2894.txt), 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.

GH: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.

IPv6: 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" (http://ietf.org/rfc/rfc3178.txt?number=3178) 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.

GH: 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. 41% 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.

IPv6: The IPv6 Forum believes there is only 36% percent of the address space left and support RFC 3194 "H-Density Ratio" rationale (ftp://ftp.rfc-editor.org/in-notes/rfc3194.txt). 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.

GH: 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.

IPv6: The IPv6 Forum agrees with the article's 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. 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.

IPv6 Forum 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)