|
|
TCP/IP limitations undone
Addressing, routing, and security improve with IPv6
|
 January 1997 ![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
Three of the most significant limitations of the Internet Protocol soon will be history as IP Next Generation overcomes addressing, routing, and security limitations. Changes to the IP will be significant. We show you what IP version 6 will look like. (2,700 words)
 Mail this article to a friend |
A new IP, dubbed IP Next Generation (IPng), is under development to resolve the protocol's failings. Early implementations already are available on several platforms, including Solaris 2. Production implementations are expected within the year.
Why a new IP?
As the single, essential component of any TCP/IP intranet and the
Internet, IP was, and is principally a proof-of-concept
technology. Now, intranet and Internet operations require
commercial-grade service. But IP lacks two critical
attributes needed for life in the real world: scalability and security.
As one industry watcher once commented, "IP's out of the lab -- we're not in Kansas anymore!"
IP's scalability problems center around three key issues: address allocation, backbone routing table growth, and host configuration.
Perhaps IP's most widely reported deficiency is its limited addressing architecture. IP's "Class A, B, C" address allocation architecture is fundamentally inefficient. Given historical Internet growth trends, unassigned addresses are expected to be exhausted by 2005, give or take five years.
However, until recently, the most critical problem facing the Internet community was the growing size of the backbone routing tables. Prior to the adoption of Classless Interdomain Routing (CIDR) described in RFCs 1380, 1517, 1518, and 1519 (links to these RFCs can be found in Resources), routing tables on the Internet's backbone routers were growing 1.5 times faster then RAM capacity. With most Class A and B addresses already assigned, the prospect of even a small portion of the potential 221 (2,097,152) routing entries seemed ominous.
This problem is known as "address aggregation." When various branch subnetworks all attach to the first network in their numeric sequence, the backbone routing table only needs the network address of the first network -- all the rest can be reached from it. With class-based address allocation, addresses are assigned in sequential order by applicant to the InterNic without aggregating them to a common connection path to the backbone.
For example, consider networks 199.200.201.0, 199.200.202.0, ... 199.200.254.0. CIDR would seek to link all networks 199.200.202.0 through 199.200.254.0 to network 199.200.201.0, then the backbone would only need to know how to route a packet to network 199.200.201.0. Thus all the networks 199.200.201.0 to 199.200.254.0 are said to be aggregated into network 199.200.201.0. Without address aggregation, the routing tables need 54 separate entries. Scale it up to the Internet and this rapidly becomes unmanageable. Even sites with a limited number of multiple, non-contiguous Class C networks find managing their routing tables burdensome.
The current solution for address aggregation is CIDR. It also helped to slow down the rate at which addresses were being exhausted by encouraging the practice of ISP-based address allocation. ISP-based addressing allows for the more complete disbursement of under-utilized Class B and Class A subnets, therefore releasing more networks for new sites to connect to the 'Net.
But CIDR only magnifies the third scalability weakness of IP: host address configuration. Every time a site changes ISPs, all its hosts must be readdressed, a decidedly non-trivial job for most sites and one that could have a significant impact on a company's personnel resources.
Finally, IP fails in the real world because it lacks the ability to guarantee that a packet comes from where it claims to come from, or that the information it contains will remain private. IP lacks authentication and confidentiality controls. IP's ease of compromise is well documented and is regularly exploited. The Kevin Mitnick penetration of the San Diego Supercomputing Center's (SDSC) network is a classic example of IP's authentication holes. E-mail privacy, or more correctly the lack there of, illustrates the 'Net's privacy pitfalls.
|
|
|
|
|
The IPv6 proposal
By January 1995, the Internet Engineering Task Force's IPng Working
Group was well under way with formal recommendations for replacing IP.
The new protocol would be the sixth version of IP, or more commonly
IPv6 (the current IP is version 4, IPv4; IPv5 was an experimental
version). The design objective: serve today's demands and those of
the foreseeable future.
IPv6 is an evolutionary step from IPv4. Functions that worked in IPv4 were kept in IPv6; those that didn't were removed. The primary changes from IPv4 to IPv6 fall into the following categories:
Addressing
IP addresses jump from 32-bits to 128 bits in IPv6. This is an address
space of 4 billion times 4 billion times 4 billion times the size of
the IPv4 address space (232 x 232 x
232 x 232). This provides a theoretical
340,282,366,920,938,463,463,374,607,431,768,211,456 possible
addresses. As one IPng working group paper calculated: "This is
approximately 665,570,793,348,866,943,898,599 addresses per square
meter of the surface of the planet Earth (assuming the earth surface is
511,263,971,197,990 square meters)." The expanded address is an
integral part of IPv6's simplified header format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To be practical, the demands of routing requires the creation of addressing hierarchies that reduce the efficiency of the address space's usage. But IPv6 breaks with IPv4's inefficient Class A, B, C addressing scheme.
The initial IPv6 proposal identified several differing addressing types in RFC 1884, Section 2.3. The intention was to provide the widest range of functionality while combining a simplified mechanism to "autoconfigure" a host's address.
The idea behind auto-configure is to divide the IP address into two distinct parts: network identifier and a unique host identifier. A popular proposal has been to use a host's IEEE-802 48-bit MAC address. This approach states that as soon as the host's IP software knows the network address, it is attached. This way, the software can automatically complete its full Internet address (network address + IEEE 802 address).
However, typical of many standards development projects, the IPv6 working group produced some early RFCs that strived for the greatest flexibility. But sometimes increased "flexibility" actually translates into "implementation uncertainty," and a standard's adoption is delayed. This appears to have occurred with part of IPv6's addressing scheme.
The early RFCs discussed address structures on variable-defined
bit boundaries. For example, RFC 1884 discusses using the
IEEE 802 address in conjunction with variable length network and subnetwork
boundaries that described a IPv6 address in terms
of
INTERNET_SERVICE_PROVIDER_ID (high-order bits, on the left)
plus
ISP_NETWORK_ID (mid-order bits, includes subnet number)
plus
HOST_IEEE-802_ADDRESS (low-order 48-bits, on the right):
| n bits | 80-n bits | 48 bits | +--------------------------------+-----------+--------------------+ | ISP IDENTIFIER | SUBNET ID | IEEE-802 ID | +--------------------------------+-----------+--------------------+
A number of other addressing format structures using existing IPv4, IPX, ISO NSAP, and other host identifiers have been proposed. However, the multitude of options as to where to demarcate the ISP and its network(s) from the final customer limits the network's ability to aggregate address routes. As the 128-bit address space makes the possible number of network addresses so numerous, many of the largest ISP vendors are convinced that the complexity of backbone routing tables will once again return to the unsustainable state they were in before CIDR. This has, of course, made them a bit skittish about how they will be able to field IPv6 to their marketplace and/or in their physical topology. This could derail IPv6's ultimate implementation if left unresolved.
8+8 topology
A proposal to simply allocate half the address to managing the "public
topology" and the other half to managing a "private topology" might
provide a satisfactory resolution. The "8+8" Internet Draft proposes
using the high-order 64 bits (8 bytes) to locate a site's private
topology in the Internet. The low-order 64 bits (the second 8 bytes
in "8+8") uniquely identifies each individual host in the Internet, as
well as its location within a site's private topology.
The public topology is the transit infrastructure that carries traffic from one site to another. It is composed of the various carrier, reseller, and regional networks that we know today. 8+8 defines a "routing goop" (the draft's author didn't want to be saddled with any term that might convey some other concept and thereby confuse the reader) as a locator to encode information about the way a site (containing a private topology) is connected to the public topology of the transit networks. Backbone service providers are particularly interested the routing goop's ability to encode topology information with high degrees of address aggregation.
To facilitate a host's autoconfiguration, the 8+8 approach envisions principally using a host's 48-bit, IEEE-802 address as a globally unique "identity token" (although other "unique" identification, such as officially assigned IPv4 addresses, could be used for hosts lacking an 802 identification). Using a globally unique identification token that is independent of a network location identifier, also potentially simplifies many other network activities. It may be possible for calculations for IPv6 authentication or confidentially controls to omit routing goop data, thereby increasing throughput. Similarly TCP pseudoheader checksums and TCP associations need only include the port number with the identity token. The ability to dynamically insert the routing goop into source addresses by site boundary routers when a packet leaves a site and enters the public topology could further simplify host configuration, as this information would only have to be configured on the site's (relatively few) external routers.
Bit-level structure of Routing Goop (RG):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|xxxxx| 13 bits "Large" ISP ID | Upper bits of "Routing Goop" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 4 5 6
2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bottom 32 bits of "Routing Goop" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
End System Designator (ESD) for the Private Topology:
6 7 8 9
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Topology Partition |M| top 16 bits of Identity Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1
9 0 1 2
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bottom 32 bits of Identity Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bits 64-78: 15-bit Private Topology Partition (PTP) provides
for 32768 distinct partitions in the Private Topology
Bit 79: Identity Token Mode Indicator
0 => 48-bit Identity Token
1 => Mode in upper bits of Identity Token
Bits 80-127: 48-bit Identity Token
Identity Tokens are formed as follows:
Mode 0 ESDs: (Bit 79: 0)
Identity Token is 48-bits of IEEE MAC Address
Bits 80-127: IEEE 48-bit MAC Address
Mode 1 ESDs: (Bits 79-82: 1001)
Identity Token is 45 bit "IETF NodeID" integer
which are assigned densely starting with 1.
Bits 83-127: IETF NodeID
Mode 2 ESDs: (Bits 79-82: 1010)
Identity Token is 32 bit officially-assigned public
IPv4 address (i.e., NOT an RFC-1918 private-use
address), zero padded
Bits 83-95: must be zero
Bits 96-127: valid IPv4 Address
Mode 3 through Mode 7 ESDs (Bits 83-95: 1011 - 1111)
RESERVED
For interfaces with IEEE-assigned, 48-bit MAC addresses, a Mode-0 ESD
(End System Designator) is the most natural ESD for that particular
interface. On the other hand, a point-to-point interface with no other
naturally-occurring MAC address could be labeled using a Mode-1 ESD.
Mode-2 ESDs provide for exploiting an already widely deployed
identifier space for easing the transition to 8+8. Links with MAC
addresses larger than 6 bytes can use Mode-2 ESDs and IPv6 dynamic
configuration support with Neighbor Discovery.
Sun and other vendors expect to release 8+8-compliant systems within a few months if the proposal is finalized and accepted in February.
Security controls
IPv6 establishes three important security services: packet
authentication, packet integrity, and packet confidentiality. All
security functions are achieved using IPv6's optional extension header,
which is discussed in RFC 1883. The authentication header (AH)
provides cryptographic authentication and/or integrity validation. By
default, it uses a keyed MD5 digest algorithm, but any implementation
can choose to use any appropriate algorithm. Sun's soon-to-be-released
v.6.0 IPv6 Prototype supports MD5 Authentication Headers.
Confidentiality protection is achieved using an encapsulating security payload ("ESP") extension header. Two modes of operation are specified: tunnel mode and transport mode. In tunnel-mode ESP, the original IP datagram is converted to cyphertext. It then becomes the encapsulating security payload and that entire ESP frame is placed within an IP datagram with unencrypted IP headers. The information in the unencrypted IP headers is used to route the secure datagram from origin to destination.
In transport-mode ESP, the ESP contains the encrypted transport-layer protocol header (e.g., TCP, UDP, or ICMP). Bandwidth is conserved because there are no encrypted IP headers or IP options. The Data Encryption Standard running in Cipher Block Chaining (DES-CBC) is the default crypto-algorithm and will be required in any valid implementation. Any other appropriate crypto-algorithm, such as that from RSA, can be incorporated at the developer's description (national laws permitting, of course).
IP datagram with the Authentication Header. +------------+-------------------+------------+-------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol| +------------+-------------------+------------+-------+---------------+ IP datagram with the Encapsulating Security Payload Header. |<-- Unencrypted -->|<---- Encrypted ------>| +-------------+------------------+------------+--------------------+ | IPv6 Header | Other IP Headers | ESP Header | encrypted data | +-------------+------------------+------------+--------------------+
Fun in the Sun
Sun Microsystems SunSoft Internet Engineering Group has produced
several prototype releases of the IPv6 product available for SPARC and
x86 Solaris systems for the purposes of evaluation and
experimentation. The current release is version 5.0, with version 6.0
due in a few months. To use release 5.0, you must be running
Solaris 2.5 or 2.5.1.
The IPv6 for Solaris home page maintains instructions and links for
downloading the product, information on bug fixes, manual pages, and a
group mailing list.
|
|
Resources
About the author
Bob Melford (bob.melford@sunworld.com) is a consulting IT networking and security analyst in Mission Viejo, CA, and chairman of the IEEE-USA Supercomputing Policy Committee.
Reach Bob at bob.melford@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright97.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-01-1997/swol-01-ipv6.html
Last modified: