Printer Friendly

IPv6 versus IPv4. (Internet Focus).

IPv6 is sometimes called the Next Generation Internet Protocol, or IPng. Even though the Internet is seen as a relatively new technology, the protocols and technologies that make it work were developed in the 1970s and 1980s. The current Internet and all our corporate and private intranets use IPv4. Now, with IPv6, the first major upgrade of the Internet protocol suite is on the horizon or maybe even closer. Close enough, anyway, to start taking it seriously.

The History of IPY6

The effort to develop a successor protocol to IPv4 was started in the early 1990s by the Internet Engineering Task Force (IETF). Several parallel efforts began simultaneously, all trying to solve the foreseen address space limitation as well as provide additional functionality. The IETF started the IPng area in 1993 to investigate the different proposals and to make recommendations for further procedures.

The IPng area directors of the IETF recommended the creation of Ipv6 at the Toronto IETF meeting in 1994. Their recommendation is specified in RFC 1752, "The Recommendation for the IP Next Generation Protocol." The Directors formed an Address Lifetime Expectation (ALE) working group, whose job was to determine whether the expected lifetime for IPv4 would allow the development of a protocol with new functionality or if the remaining time would only allow for developing an address space solution'. In 1994, the ALE working group projected the Ipv4 address exhaustion to occur sometime between 2005 and 2011, based on the statistics that were available at that time. For readers interested in the various proposals, here's more information. (from RFC 1752). There were four main proposals called CNAT, IP Encaps, Nimrod, and Simple CLNP. Three more proposals followed: the P Internet Protocol (PIP), the Simple Internet Protocol (SIP), and TP/IX. After the March 1992 San Diego IETF meeting, Simple CLNP evolved into TCP and UDP with Bigger Addresses (TUBA) and IP Encaps evolved into IP Address Encapsulation (IPAE). IPAE merged with PIP, and SIP and called itself Simple Internet Protocol Plus (SIPP). The TP/IX working croup changed its name to Common Architecture for the Internet (CATNIP). The main proposals were now CATNIP, TUBA, and SIPP. For a short discussion of the proposals, refer to RFC 1752.

CATNIP is specified in RFC 1707, TUBA in RFC 1347, RFC 1526, and RFC 1561, and SIPP in RFC 1710.

The Internet Engineering Steering Group approved the IPv6 recommendation and drafted a Proposed Standard on November 17, 1994. The core set of IPv6 protocols became an IETF Draft Standard on August 10, 1998.

Why, you may ask, is the new protocol not IPv5? The version number 5 could not be used because it had been allocated to an experimental stream protocol.

Overview of Functionality

IPv6 is one of the most significant network and technology upgrades in history. It will slowly migrate into the existing IPv4 infrastructure and positively impact your network.

IPv6 product development and implementation efforts are already underway all over the world. IPv6 designed as an evolutionary step from IPv4, is a natural increment to Ipv4, and can be installed as a normal software upgrade in most Internet devices, being interoperable with the current IPv4. IPv6 is designed to run well on high performance networks like Gigabit Ethernet, ATM, and others, as well as low bandwidth networks (e.g., wireless). In addition, it provides a platform for the new Internet functionality required in the near future, such as extended addressing, better security, and quality of service (QoS) features.

IPv6 includes transition and interoperability mechanisms designed to allow users to adopt and deploy IPv6 step by step as needed, and provide direct interoperability between IPv4'and IPv6 hosts. The transition to a new version of the Internet Protocol (IP) must be incremental, with few or no critical interdependencies, if it is to succeed. The IPv6 transition allows users to upgrade their hosts to IPv6 ,and network operators to deploy Ipv6 in routers, with very little coordination between the two groups.

Main Differences

The main changes from IPv4 to IPv6 can be summarized as follows:

Expanded addressing capability and autoconfiguration mechanisms

The address size for IPv6 has been increased to 128 bits. This solves the problem of the limited address space of IPv4 and offers a deeper addressing hierarchy and simpler configuration. There will come a day when users will hardly remember how it felt to have only 32 bits in an IP address. Network administrators will love the autoconfiguration mechanisms built into the protocol. Mull/cast routing has been improved, with the mull/cast address being extended by a scope field. And a new address type has be, em introduced, called Anycast address, which can send a message to the nearest single member of a group.

Simplification of the header format:

The Ipv6 header has a fixed length of 40 bytes. This actually accommodates only an 8-byte header plus two 16 byte IP addresses (source and destination address). Some fields of the IPv4 header have been removed or become optional enabling packets to be handled faster with lower processing costs.

Improved support for extensions and options

With IPv4, options were integrated into the basic Ipv4 header, whereas with Pv6, they are handled as Extension headers which are optional, and only inserted between the IPv6 header and the payload, if necessary. This way the IPv6 packet can he built very flexible and streamlined. Forwarding IPv6 packets is much more efficient. New options that will be defined in the future can be integrated easily.

Extensions for authentication and privacy

Support for authentication, and extensions for data integrity and data confidentiality, have been specified and are inherent.

Flow labeling capability

Packets belonging to the same traffic flow, requiring special handling or quality of service, can be labeled by the sender. Real-time service is an example where this would be used.

For a current list of the standardization status of IPv6, refer to http://playground.sun.com/pub/ipng/html/specs/ standards.html.

Transition Aspects

Is IPv6 worth all the migration and upgrade headaches? Will it ever become the IP of the future? Can't IPY4 extensions offer all that functionality? After all, we have Network Address Translation (NAT) to solve address space problems and IPSEC to provide security.

The 128-bit address space is the most obvious feature of the new protocol, but it is not the only important change. The IPv6 package includes important features such as higher scalability, better data integrity, QoS features, autoconfiguration mechanisms that make it manageable even for high numbers of dynamically connecting devices, improved routing aggregation in the backbone, and improved multicast routing.

Extensions for IPv4 that have been widely deployed, such as NAT, should be viewed as good solutions but only for limited short-term scenarios. In the long term, nothing can replace IPv6's features for inherent secure end-to-end connectivity. Multimedia and interactive, transaction-oriented network applications require high levels of connectivity that can only be provided by IPv6. In the future, an unforeseeable number of new devices may want to connect to our networks, including devices such as Personal Digital Assistants (PDAs), mobile phones, smart set-top boxes with integrated web browsers, home entertainment systems, coffee machines, refrigerators, and car devices. The list is endless. Only IPv6, with its extended address space and advanced autoconfiguration and mobility features, can manage such devices. There is no comparable alternative technology in sight.

IPv6 In Action

There are already a surprising number of global test networks and even commercial networks running over IPv6. In order to describe what they are doing, I use some IPv6- specific terms that are probably not familiar to you yet.

In February 2002 over 120 production networks have been allocated IPv6 address prefixes. For a current list, refer to http//lwww.dfn.de/service/ipv6/ipv6aggis.html.

The6Bone

The 6Bone started out as a network of IPv6 islands working over the existing IPv4 infrastructure of the Internet by tunneling IPv6 packets in IPv4 packets. The tunnels were mainly statically configured point-to-point links. The 6Bone became a reality in early 1996 as a result of an initiative of several research institutes. The first tunnels were established between the IPv6 laboratories of G6 in France, UNI-G in Denmark, and WIDE. in Japan.

Structure of the 6Bone

The 6Bone is structured as a hierarchical network of two or more layers. The top layer consists of a set of backbone transit providers, called pseudo Top Level Aggregators (pTLAs), which use BGP4+ as a routing protocol. The bottom layer is comprised of leaf sites connected via the 6Bone. Zero or more intermediate layers, called pseudo Next Level Aggregators (pNLAs), interconnect leaf sites and the PTLA backbone networks.

Addressing

IPv6 unicast addressing of node interfaces (for both end systems and routers) is based on RFC 2374, which covers the Aggregatable Global Unicast address format. 6Bone backbone networks play the role of experimental TLAS, called pseudo TLAs (pTLAs), and assign address space to pseudo NLAs (pNLAs) and leaf sites. The prefix assigned to the 6Bone is 3ffe::/16 (RFC 2471). These PTLA backbone networks are currently allocated 32-bit prefixes (previously, 24- and 28-bit prefixes were allocated) that must be administered according to the rules defined for pTLAs. So every PTLA plays the role of an experimental top-level ISP ,and assigns chunks of its addressing space to directly connected transit and leaf sites without breaking aggregation inside the 6Bone backbone.

Growth

The 6Bone is growing fast. In December 1997 there were 43 backbone sites and 203 leaf sites registered. In December 1998 there were 51 backbone sites and 332 leaf sites. In January 2000 there were 67 backbone sites and 505 leaf sites. 1998 there were 51 backbone sites and 332 leaf sites. In January 2000 there were 67 backbone sites and 505 leaf sites.

I gave up on trying to find a nice picture of the world with the 6Bone back bone sites on it. The 6Bone has grown too big to display it in one screen shot. If you want to get a feeling for the size and workings of the 6Bone, go to http//www.cs-ipv6.lancs.ac.uk/ipv6/6Bone and look at the maps, statistics, and tools.

At the time of this writing, the number of nodes in the 6Bone has just reached 1000 and grows daily. Find an updated list at http//www.cs-ipv6.lancs.ac.uk/ipv6/6BonelWhois/index.html#full.

Joining the 6Bone

Membership in the 6Bone is open to anyone. Reasons for joining, besides the fun of it, would be to gain early experience working with IPv6, to build the expertise necessary to make decisions about when and how to use it.

for production networks, and to have working access to IPv6 servers and resources, joining the 6Bone connects users with people who want to be on top of technology and are willing to share their experience.

The 6Bone community spans the globe and is very active and enthusiastic. By joining, you not only gain access to the network and the common experience of those in it; you can also participate and help develop protocols, programs, and procedures

For those interested in joining the 6Bone, the link is http//www.6bone.net/6bone_hookup.html

There are different ways to connect to either the 6Bone or production IPv6 networks:

* Become an end site of an existing 6Bone ISP (which means you will get your 48-bit IPv6 external routing prefix from that ISP's TLA). You can also get temporary address allocations from tunnel broker sites (see the 6Bone home page for more information).

* Apply for your own 6Bone TLA (if you are an ISP) based on the 6Bone process.

* To get your first production IPv6 address, find a production IPv6 ISP (i.e., an ISP that has a sub-TLA) from which to get your prefix. Note that you can partially qualify for a sub-TLA production prefix if you have a 6Bone PTLA prefix (at least during the early phase of production prefix allocation).

* Use the "6to4" automatic tunneling mechanism. This allows you to specify the IPv4 address of your end user site router for an IPv6-over- IPv4 tunnel to reach your end user site. Addresses of this type have the first 16 bits of 2002::/16, with the next 32 bits containing the IPv4 address of a router on your site supporting this mechanism (thus making up the entire 48-bit external routing prefix).

Now all you really need is a router and a host running IPv6 stacks. Almost all router vendors have either production stacks or beta stacks available.Refer to http://playground.sun.com/pub/ipng/html/ipng-implementations.html for a list of router and host implementations

Obviously you need an entry point into the 6Bone. Try to find one that is close to your normal IPv4 path into the Internet. You can find a good 6Bone TI-A on the 6Bone home page at http://www.6bone.net/6bone-pTLA-list html.Use traceroute to determine the closest path.

IPv6 Commercial Networks

A lot is happening in the development of IPv6. There are many production networks worldwide that have already been assigned IPv6 address prefixes. The following are four examples of companies that are offering IPv6 services.

vBNSS+

vBNS+ is a specialized US IP network that supports high-performance, high-bandwidth applications. The vBNS+ network supports both native IPv6-over-ATM connections and tunneled IPv6-in-IPv4 connections. The vBNS+ has been assigned its own sTLA from ARIN as well as a pTLA for the 6Bone, and is delegating address space under these assignments to vBNS-attached sites. For more information, refer to their site at http://www.vbns.net.

Telia Sweden

In summer 2001, Telia, in Sweden, announced its intention to build a new generation Internet based on IPv6. By the end of 2001, connection points were installed in Stockholm, Farsta, Malmoe, Gothenburg (Sweden), Vasa (Finland), Oslo, Copenhagen, and London.

I spoke with the project manager at Telia because I thought that his early adopter input might be interesting for companies that consider going into IPv6. Telia's intent was to break through the lethargy of the chicken and the egg problem: vendors do not develop because the market is not asking for it, and the market doesn't ask for it because vendors don't develop. So Telia made the decision to create a market by building an IPv6 network and opening it to the public. Telia's hope is that, through the publicity of its endeavor, other companies will follow suit, and the acceptance and development of IPv6 will increase.

At the current stage of its rollout, Telia is keeping the IPv6 network separate from the existing IPv4 infrastructure. There were different reasons for this decision:

* It was easier to start by keeping the networks separate. Telia does not have to educate all of its IPv4 engineers to use IPv6 overnight.

* If there are problems with the IPv6 network, the IPv4 network is not affected in any way.

* It is less complex to configure if the networks are separate.

The new network is primarily built as a native IPv6 network. In some instances, tunnels over IPv4 are used. Currently, Telia is offering an IPv6 transport service to a limited number of customers. It will add features and gradually open the IPv6 network as a general service for everyone. Telia uses Hitachi routers that support IPv6 in hardware (versus software implementations), everyone. Telia uses Hitachi routers that support IPv6 in hardware (versus software implementations).

After rolling out the first connection points, Telia concluded that market support for IPv6 was sufficient to get started. There are applications that will need to be ported to IPv6, but Telia recommends that companies and ISPS start right away. The foundation is here and when IPY6 is implemented on a broader range, vendors and application developers will be encouraged to speed up development.

Internet Initiative Japan

Another company that offers IPv6 transport services is Internet Initiative Japan (IIJ), Japan's leading Internet access and solutions provider, which targets high-end corporate customers. IIJ offers a trial 1Pr6 service (tunneling through IPv4) and a native IPv6 service that is independent from existing IPv4 networks. In December 2001 IIJ extended its IPv6 services to individual users connecting through IIJmio DSL/SF, an ADSL Internet service.

For information about IIJ's services, refer to http:llwww.iij. ad.jp//Pv6/index-e.html.

NTT Communications Corporation

NTT Laboratories started one of the largest global IPv6 research networks in 1996. Trials of their global IPv6 network, using official IPv6 addresses, began in December 1999. Since spring 2001, NTT Communications has offered commercial IPv6 services.

In April 2001 the company started their commercial IPv6 Gateway Service.

This native IPv6 backbone service connects sites in Japan to the NTT/VERIO Global Tierl IPv6 backbone deployed over Asia, the U.S., and Europe. Monitoring and operation continues 7 days a. week, 24 hours a day, through NTT Communications NOC in Tokyo, Japan and Verio NOC in Dallas, US. Figure 1 shows the layout of the backbone.

The IPv6 Gateway Service offers native IPv6 transport. Also shown on the picture is the IPv6 Tunneling Service that NTT has offered since June 2001. It uses the existing IPv4 network to enable NTT's partners to access the IPv6 network, using IPv6-over-IPv4 tunneling techniques via dedicated lines. The routing protocols used are BGP4+ and RIPng, IS-1S(which will be on the global backbone in the near future), and OSPFv3 (which is used at NTT's Japan domestic backbone). What NTT lacked was ICMPv6 polling in commercial operational tools. They utilize their own custom-developed router configuration tools and network management tools that support IPv6.

NTT offers Points Of Presence (POPs) all over the world, currently in London, Pale Alto, San Jose, Seattle, and Tokyo. They plan to extend their services throughout the world; the next POPs will be in Hong Kong and Australia. NTT's services include official IPv6 addresses from their sTLA block, IPv6 Internet connectivity, and DNS reverse zone delegation for the subscriber's IPv6 address space.

For an overview of NTT's global IPv6 services and how you can participate and connect, refer to http://www.v6.ntt.net/ globe/index-e.html.

Links to Other IPY6 Networks

The 6RenThere are a large number of international IPY6 test and research networks. You can find some interesting links in the following list:

The 6Ren

The 6Ren is a voluntary coordination initiative of research and education networks that provide production IPv6 transit service to facilitate high-quality, high-performance, and operationally robust IPv6 networks. Participation is free and open to all research and education networks that provide IPv6 service. Other profit and nonprofit 1Pv6 networks are also encouraged to participate. The 6Ren web site can be found at http://www.6ren.net.

The 6Net

The 6Net is a high-capacity IPv6 research network coordinated by Cisco, with more than 30 members. Their home page can be found at http://www.sixnet.org.

DRENv6

The Defense Research and Engineering Network (DREN) is a major component of the DoD High Performance Computing Modernization Program (HPCMP). Its purpose is to provide high-performance network connectivity to various communities of interest in the DoD, including research and development, modeling and simulation, and testing and evaluation. DREN also provides connectivity to other high-performance backbones and Federal networks to serve the needs of these communities. DREN is also a research network; it provides a test bed for testing new protocols and applications. DREN provides both ATM cell-based services and IP frame-based services. The DREN IPv6 net work is one of the services provided as part of DREN. The DREN web site is at http://www.v6.dren.net.

Editorial Note: The IETF

The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.

The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via Mailing-lists. The IETF holds meetings three times per year.

The IETF working groups are grouped into areas, and managed by Area Directors, or ADs. The ADs are members of the Internet Engineering Steering Group (IESG). Providing architectural oversight is the Internet Architecture Board, (IAB) The lAB also adjudicates appeals when someone complains that the IESG has failed. The LAB and IESG are chartered by the Internet Society (ISOC),_for these purposes. The General Area Director also serves as the chair of the IESG and of the IETF, and is an ex-officio member of the IAB.

The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols. The IANA is chartered by the Internet Society (ISOC) to act as the clearinghouse to assign and coordinate the use of numerous Internet protocol parameters.

First-time attendees might find it helpful to read The Tao of the IETF. This was published as RFC3160 http://www.ietf.org/overview.html

All About RFC's

If you want to understand the role of the IETF and the standardization process, if you need a list of all the organizations involved in the process and a description of what they do, or if you wish to attend an IETF meeting, there is an interesting and humorous RFC that describes the background, processes, and roles: RFC 3160, titled "The Tao of IETF-A Novice's Guide to the Internet Engineering Task Force."

`Requests for Comments' (RFCS) are written reports describing most of the information regarding TCP/IP and the architecture, protocols, and history of the Internet There are many sites on the Internet where RFCs are electronically accessible. The sites are very different, but most of them support some form of search mechanism. Find the site that best suits your preferences. A good starting point is http://www.rfc-editor.org. There is a tribute to Jon Postel, father of the Internet, who died in October, 1998. He was the RFC editor. Besides this information, there is also an overview of the RFC series and process. On the search and retrieve page of this site, there are many ways to access the wealth of information. RFCs can be viewed by number or in an index, they can be in forward or reverse chronological order, and they can be searched by author, title, number, or keyword. There is also a link to alternative RFC repositories.

RFC 2555 is an interesting overview of 30 years of RFC history and a good description of the contribution of Jon Postel's services to the Internet community. There is even more information about Jon Postel at http://www..postel.org/remembrances/

The first RFC, RFC 000 1, was published by Steve Crocker on April 7, 1969. Today the number of RFCs continues to rise quickly and has exceeded 3000. RFCs can have different statuses, such as standard, informational, experimental, and historic. A good overview of the different statuses and current level of standardization can be found at http://www.rfc-editor.org. Here's a short list of some important basic RFCs that users should be aware of:

RFC 3000, `Official Protocol Standard'

Known as the Internet Official Protocol Standard, this RFC lists only official RFC protocol standards and is therefore not a complete index. It contains the state of standardization as of October, 2001.

RFC 1700, "Assigned Numbers Document'

This RFC is now outdated. For many years, it has been a reference point, containing a summary of the assignment of protocol parameters for the Internet Protocol Suite. IANA is the central coordinator for the assignment of these parameters. RFC 1700 has been replaced by an updated list at http//www.iana.org/numbers.html.

RFCs 1122 and 1123, Host Requirements Documents

These two RFCs are known as Host Requirements Documents and cover the requirements for Internet host software. RFC 1122 covers the communications protocol layers such as link layer, IP layer, and transport layer. RFC 1123 covers the application and support protocols. Many terms widely used throughout all RFCs are defined in these two documents.

RFC 1812, "Requirements for 1Pv4 Routers'

This RFC is self-explanatory. At the time of this writing, I have not yet found an RFC including requirements for IPv6 routers. The RFCs ending on xx99 are usually a summary of a range of previous RFCs and their status. For instance, if you need a summary for the RFCs from 3000 to 3099, refer to RFC 3099.

EDITORS NOTE: The above items have been abstracted from `IPv6 Essentials' by Silvia Hagen published by O'Reilly & Assocs. ISBN 0-596-00125-8. This book is essential reading for all interested in where the near future of the Internet is going.
COPYRIGHT 2002 A.P. Publications Ltd.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2002, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

 Reader Opinion

Title:

Comment:



 

Article Details
Printer friendly Cite/link Email Feedback
Author:Hagen, Silvia
Publication:Database and Network Journal
Date:Oct 1, 2002
Words:4100
Previous Article:VorteXML Designer lowers XML costs. (Monograph).
Next Article:Hong Kong (China) and Denmark top ITU Mobile/Internet index. (Internet Focus).
Topics:


Related Articles
CISCO DELIVERS SECOND PHASE OF IPV6 FUNCTIONALITY FOR INDUSTRY'S MOST ROBUST INFRASTRUCTURE SOLUTION.
WindNet IPv6. (Internet Products).
Dynamic Threat Protection platform. (Security).
IPv6: Asia's agent of change: Northeast Asia leads the way in giving everything including the kitchen sink.
U.S. Department of Defense taps Spirent to help test deployment of next-gen Internet network.
Defining IPv6.
Intelliden to sponsor Federal IPv6 Summit 18 May 2006.
America's Quest for IPv6 - A Business Perspective.
IPv6 Transition will impact 30 percent of U.S. government IT purchasing decisions in 2007.

Terms of use | Copyright © 2014 Farlex, Inc. | Feedback | For webmasters