The Technical Case for IPv6 2

previous 2/2 next

Unicast/Multicast/Anycast Service Types

IPv4 uses several kinds of packet transit metaphors – point-to-point, broadcast, and multicast. Point-to-point is the most common, with a single sending station and a single receiving station. Broadcast supports a single sending station but multiple recipients – where the recipients are all of the machines on a given part of the network. Multicast is a single-sender/multiple-recipient model, but the recipients can selectively “listen” to a given packet stream – where with broadcast ALL stations must listen to the packet stream. Multicast is not widely supported on v4 networks.

IPv6 supports unicast, multicast, and anycast addressing. Unicast is a single address, assigned to a single interface on a machine. Anycast supports the concept of a sending station transmitting a packet to “any” of a collection of machines (or interfaces). Multiple machines configure the anycast address, and the sending station’s packet will reach the logical “closest” of those machines. This new capability alone will lead to deployment of new applications as well as better ways to field existing applications.

Implementation of multicast addressing also streamlines the mechanisms by which stations on the same network communicate. Multicast addressing replaces broadcast addressing in v6. With IPv4, when a machine wants to exchange packets with a machine on the same network, it must first broadcast an announcement looking for the machine. Each machine on the local network must listen for and examine the announcement, although only one machine (at most) will respond. On a large busy network, that makes for a lot of extraneous packet generation. Multicast adds another advantage over broadcast.

Broadcast really only supports an “all nodes” destination model. Multicast, however, adds an expandable set of destination addresses, including “all nodes” (like broadcast”, but also supporting “all routers”, “all hosts”, “all DHCP servers”, etc.) The set of destination addresses is extensible, so it can grow and adapt as network implementations change. Streaming media applications should be a big beneficiary of v6 multicast features.

IPv6 takes a different approach. Upon system startup, and periodically thereafter, hosts and routers send announcements to known multicast addresses to discover each other. In this way, not all machines have to process all announcements – only those for which subscribe to the multicast address. On a large network segment – and remember that with v6 a single network can have 264 devices (that’s 1.85 x 1019 devices)– this alone provides a significant boost to network efficiency.


No Mid-Path Packet Fragmentation

Sometimes an IP packet passed to the network stack by an application is too large for the underlying transmission medium – as when an application requests packet transit to a distant host of a 4500 byte packet over a multi-hop network with an Ethernet (maximum packet size of 1500 byte) segment in the middle. Using IPv4, the packet will leave the sending-host intact, but when it hits the router on the near side of the Ethernet link, that router will need to “fragment” the packet – breaking it into three 1500-byte packets. The router at the far end of the Ethernet segment will re-assemble the packet and pass it along to the final destination. The smallest segment through a given path in the network is called the “Path MTU” (Path Maximum Transmission Unit).

Fragmentation is bad for network performance – both throughput and latency suffer if packets are fragmented. Imagine, for example, a network with 5 hops, where the maximum packet size supported by any segment stepped down approaching the destination, resulting in MTU’s of 5000, 4000, 3000, 2000, and 1000 bytes respectively. If the sending station sends a 5000-byte packet, it will be fragmented and reassembled 4 times on its way to the destination.

IPv6 does not allow packet fragmentation at intermediary routers. Fragmentation, if required, is only done by the sending station. The originating host uses a mechanism called “MTU Discovery” to determine the largest packet size that it can use to reach a destination given the present packet-path [PATHMTU]. In our example above, the host would determine that it must fragment its 5000-byte packet into 1000-byte fragments, and there would be no intermediary fragmentation.

This is a much more efficient and predictable method to handle packet transport.


Mobility Enhancements

IPv6 supports a more robust and updated version of the Mobile IP specification. This is the capability by which machines may move about on the network – leaving their “home” networks and temporarily joining other networks – but operate much as before [MOBILEIP]. Historically, the Internet has been a collection of mostly-stationary nodes – and as such address assignment was built to provide relatively long-lived addresses to hosts. Today – and more so as the Internet evolves - more and more nodes will be “mobile“; they will travel throughout the world attaching to the Internet at various places.

Mobile IP provides a mechanism that enables device mobility on a grand scale, and with little or no forfeit of functionality. To clarify, let’s say you are participating in a video conference call on your PDA while riding the train to work. You may be receiving “connectivity” via a wireless access point on the train, or perhaps via a cellular network. As the train moves (or you), it will most likely pass from one “network” segment to another. During the transition your device should maintain the feed to the conference call, without any loss of connection or interruption in service. This is problematic in IPv4.

Mobile IP is supported in IPv4, but there are features inherent in IPv6 (such as address autoconfiguration and inherent security) that mesh with needed capabilities for Mobile IP in such as way as to make “IPv6/Mobile IP” clearly a superior implementation. Mobile IP and IPv6 will combine to provide an enabling platform for many as-yet unimagined applications.


Quality of Service (QoS) Opportunities

In the Internet deployed today, most all packets are handled on a first-come, first-served basis, and all packets are given the same priority. An e-mail is delivered to its destination with the same urgency as a streaming media presentation is delivered to the media player. Clearly, some traffic has greater importance than other traffic, and some traffic is more perishable than other traffic. It is as though package carriers in the physical world only offered insurance for $10 packages. If one could only get $10 worth of insurance on a package regardless of the value of the contents of the package, there would be very few packages valued at $100 carried by those delivery companies.

The emerging nextgen Internet, based on IPv6, should be able to provide an improved Class of Service (CoS) and QoS. Applications like e-mail will be delivered on a best-effort basis, and applications like remote surgery – certainly an example of an application where reliability and priority traffic handling is important – will receive preferred treatment. The value of the packet payload should determine the way a packet is handled, and applications and their users should be able to request (and pay a premium for) priority treatment.

Today, the QoS paradigm for IPv6 is no better than IPv4. However, IPv6 provides 28 bits of space in each standard header to implement techniques to handle packets depending on their “traffic class” and “unique flow”. This is one way IPv6 MAY be able to possess an inherent and uniform QoS/CoS mechanism. As another option, the extension headers could be utilized much the same way they have been to create an enhanced security model. In either case, the opportunity for an improved QoS/CoS model is significantly better in IPv6.


Transition to IPv6

IPv4 will give way to IPv6 over the course of the next several years. As one would think, there will be no “global cutover” to IPv6 – it would be impossible to orchestrate such sweeping change. The IETF has developed a “toolkit” of transition mechanisms that will provide for the smooth upgrade to IPv6 on the global network. There are three main transition mechanisms – Dual Stack, Tunneling, and Translation [TRANSMECH] [TRANS].

Dual-Stack systems have both IPv4 and IPv6 addresses and capability. A machine configured in this manner has complete interoperability with any IP-based node – it simply uses v4 to communicate with v4-only machines, and v6 to communicate with v6-only nodes. As long as the intervening network fabric (the switches and routers and other devices which form the Internet) is IPv6-capable, a dual-stack machine should have any-to-any connectivity. Note that, since a dual-stack node still needs a routable IPv4-address, this mechanism does nothing to allow rapid expansion of the Internet.

Tunneling is a technique where islands of IPv6 nodes can communicate with other islands of IPv6 nodes over an intervening IPv4 network [or vice versa]. In this case, the nodes have complete end-to-end v6 capability, but as the packets travel over the predominantly IPv4 Internet (IPv6 packets encapsulated in IPv4 packets), all of the advanced features of v6 pertaining to packet transport are not available. So, this mechanism removes the requirement mentioned above – but at a cost – the lack of true IPv6 functionality. Also note that tunneling does not allow v6 nodes to talk to v4 nodes.

Translation is a mechanism where IPv6 packets are translated by an intermediate system into IPv4 packets (and vice-versa). This allows v6 and v4 machines to communicate, but as with tunneling – not all of the advanced features of IPv6 are available to the application. This will allow newly deployed IPv6-only nodes to access legacy IPv4-only machines on the Internet.

As of May 2003, it appears that entities looking to transition to IPv6 will use a number of methods in their integration process. And, depending upon the adopting entities geographic location, it may just be easier, and more cost effective to start out by building IPv6 only networks due to limited IPv4 addresses availability. Regardless of which mechanism(s) are chosen, interoperability between v4 and v6 will be a common fact of life on the Internet. Eventually however, the Internet (as well as private IP-based networks) will completely migrate to IPv6.


Conclusion and References

We’ve examined the headline advantages of IPv6 over IPv4. There are many, many more technical features that make v6 the superior protocol, and we encourage you to refer to the supporting documents and large collection of IETF RFC’s where details can be found. Also, for a look at some of the interesting applications and the business potential of IPv6, you are encouraged to read “IPv6: An Internet Evolution”, which can be found on the IPv6 Forum website (www.ipv6forum.org).

To paint a lasting image of the difference between IPv4 and IPv6, imagine a symphony being played in a world where all the performers have to keep one hand tied behind their backs. Running the Internet on today’s deployed IPv4 infrastructure is like that. The symphony can play – but they can only play Chopsticks well. People can enjoy the performance, but a vast amount of potential has been stolen from the event, and a lot of great pieces will never be written. The music will never develop to its full potential. Deploying v6 throughout the Internet is like allowing these performers to use both hands.

That’s the important message of this document. IPv6 will enable an extensive new generation of applications and services. As a foundation platform to support network innovation, IPv6 has no equal, and it promises to be the enabling technology that allows the Internet to continue to change the world we live in.


References

This paper is a compendium of a number of excellent written sources – primarily IETF documents – and collaboration among Native6’s engineering staff.

[CASEv6] “The Case for IPv6”, Internet Draft “draft-iab-case-for-ipv6-06”, Steve King, et. al.


[HISTORY] “A Brief History of the Internet”, http://www.isoc.org/internet/history/brief.html

[IETF] http://www.ietf.org/


[CIDR], RFC 1519, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy”, V. Fuller, et. al.


[V6ADDR], RFC 2373, “IP Version 6 Addressing Architecture”, J. McCann, R. Hinden ,and S. Deering


[PATHMTU], RFC 1981, “Path MTU Discovery for IP version 6”, S. Deering and J. Mogul


[MOBILEIP], RFC 2002, “IP Mobility Support”, C. Perkins

[TRANSMECH], RFC 2893, “Transition Mechanisms for IPv6 Hosts and Routers”, R. Gilligan and E. Nordmark


[TRANS], IETF Draft “draft-ietf-ngtrans-translator”, “Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication”, K. Yamamoto and M. Sumikawa

previous 2/2 next