The most obvious change to the Internet protocols will be room for far more a
ddresses than are currently supported. IPv4 has 32 bits for addressing. IPv6 will use 128 bits -- enough to assign 665 septillion (665 x 10
24
) addresses per square meter of the surface of the earth.
While this is far more room than we can expect to need in the distant future, in reality, 128 bits of addressing will provide only a paltry few hundred million addresses per square meter. The remaining space will be used for routing and other administrative purposes. Still, this is an expansion of the space to dimensions far exceeding our needs.
Multicasting: Making Multirecipient Flows More Efficient
The next change to the protocols will be support for data multicasting. This is a facility that lets a producer of information send only one copy out to the network, no matter how many recipients exist. The network will copy this one instance of data as needed, routing it to those hosts that require it.
Multicasting is presently being done on the Internet on a virtual subnet, the
Multicast Backbone (Mbone). However, because it's within the context of IPv4 and the Internet's relatively limited speed, this is only a hint of what can and will be done with multicasting in a next-generation Internet environment.
Security: Battening Down the Virtual Hatches
Network and data security are critical issues of the next Internet. We are already seeing the effects of the current lack of strong security in such practices as e-mail and Usenet spamming, and IP address spoofing.
The IPng protocols will include two features designed to provide a higher level of communications security: an authentication header and an encapsulating security header.
The authentication header will provide a guarantee that a message has originated from a known, trustworthy source and that once in the network, you can trace the message back to its originating source. In other words, the authentication header will identify both the source of the message and the fact that the source is known and tr
usted. This first feature knows nothing of the content of messages, only their source.
The encapsulating security header provides a means to guarantee that messages travel intact from source to sink and that the contents of messages can be kept from the prying eyes of would-be hackers. The definition of this header supports multiple possible formats and algorithms. It is intended to be a flexible means of protecting data security and integrity, so that when new security measures become available, you can easily incorporate them into the existing model.
Quality of Service: At the Core and at the Edge
Until recently, the Internet has never had any choices in terms of quality of service (QoS) offered from providers, or that users could request -- and pay correspondingly more or less for -- on a basis such as per application, session, time, or parties involved. For example, there's never been a "Charge me more, give me better service" icon on-screen, nor a way to say, "Give me guaranteed toll
-quality voice and video for all calls from my thesis advisor, but only low-grade, cheap quality for calls from friends unless they're paying for it." Individual ISPs such as Uunet and BBN/GTE are beginning to offer some forms of guaranteed service, but a lot's still not possible with today's protocols.
Different types of applications and different circumstances have different priorities in terms of QoS. For example, real-time voice can tolerate some loss of the signal better than delay, while real-time data may tolerate either some or no "jitter" -- varying delay -- but usually needs 100 percent accurate delivery.
As packets flow to their destinations, several characteristics must be guaranteeable and controllable, including:
- Capacity -- If an application requires 10 Mbps from point to point, it must be able to reserve network capacity in support of its needs.
- Managing packet loss -- If packet loss cannot be avoided, what level is acceptable to the application's needs?
- Packet timing -- When must the packet become available for the application? What timing constraints are acceptable?
Similarly, when packets arrive at their destinations, what characteristics must be controlled?
- Admission control -- What packets are allowed to enter the edge? At what layers does this become an issue?
- Packet discrimination -- Are some packets more important than others? Can we route packets to application destinations based on their contents?
- Accounting and billing -- Who will pay for packet transfer, and how will we track usage?
The State of IPng
The Internet Engineering Task Force is developing IPng. The IETF is a loose confederation of computer researchers and other interested parties, and is the source of all official Internet standards. It will deploy IPng, in one form or another, sometime after 1999. The problems this poses are not small.
There has been much consideration of a phased rollout, where the underlying backbones are conver
ted to IPng before the rest of the network. If this happens, the current computers at the edge of the network will communicate through IPv4 tunnels in the new IPng network.
The largest current test-bed for the IPng protocols is a network of research and commercial sites in 29 countries called the 6-Bone. In the U.S., IPng is also being run on VBNS.
Robert Raisch is an on-line business strategist (
raisch@internautics.com
).
Technology the Next Internet Needs
