Internet Protocol Header Format For Essay

Posted on by Mak

IPv6: The Next Generation Internet Protocol

Gary C. Kessler
February 1997


An edited version of an early draft this paper appeared in the Handbook on Local Area Networks, published by Auerbach in August 1997. © Auerbach, 1997. Various additions have been made over time...


The Internet is historically linked to the ARPANET, the pioneering packet switched network built for the U.S. Department of Defense in 1969. Starting with four nodes that year, the ARPANET slowly grew to encompass many systems across the U.S., and connecting to hosts in Europe and Asia by the end of the 1970s. By the early 1980s, there were many regional and national networks across the globe that started to become interconnected, and their common communications protocols were based on the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. But even by the later-1980s, the number of host systems on these primarily academic and R&D networks could be counted in the hundreds or thousands. In addition, most of the traffic was supporting simple text-based applications, such as electronic-mail, file transfers, and remote login.

By the 1990s, however, commercial users discovered the Internet and commercial use, previously prohibited or constrained on the Internet, was actively encouraged. Since the beginning of this decade, new host systems are being added to the Internet at rates of up to 10% per month, and the Internet has been doubling in size every 10-12 months for several years; by January 1997, the number of hosts on the Internet was over 16 million, ranging from PC-class systems to supercomputers, on more than 100,000 networks worldwide.

The number of connected hosts is but one measure of the Internet's growth. Another way to quantify the change, however, is in the changing applications. On today's Internet, it is common to see hypermedia, audio, video, animation, and other types of traffic that were once thought to be anathema to a packet switching environment. As the Internet provides better type-of-service support, new applications will spark even more growth and changing demographics. In addition, nomadic access has become a major issue with the increased use of laptop computers, and security concerns have growth with the increased amount of sensitive information accessible via the Internet and the number of attacks launched from the Net.

IPv6 BACKGROUND AND FEATURE OVERVIEW

The Internet Protocol was introduced in the ARPANET in the mid-1970s. The version of IP in common use today is IP version 4 (IPv4), described in Request for Comments (RFC) 791 (September 1981). Although several protocol suites (including Open System Interconnection) have been proposed over the years to replace IPv4, none have succeeded because of IPv4's large, and continually growing, installed base. Nevertheless, IPv4 was never intended for the Internet that we have today, either in terms of the number of hosts, types of applications, or security concerns.

In the early 1990s, the Internet Engineering Task Force (IETF) recognized that the only way to cope with these changes was to design a new version of IP to become the successor to IPv4. The IETF formed the IP next generation (IPng) Working Group to define this transitional protocol to ensure long-term compatibility between the current and new IP versions, and support for current and emerging IP-based applications.

Work started on IPng in 1991 and several IPng proposeals were subsequently drafted. The result of this effort was IP version 6 (IPv6), described in RFCs 1883-1886; these four RFCs were officially entered into the Internet Standards Track in December 1995.1

IPv6 is designed as an evolution from IPv4 rather than as a radical change. Useful features of IPv4 were carried over in IPv6 and less useful features were dropped. According to the IPv6 specification, the changes from IPv4 to IPv6 fall primarily into the following categories:

  • Expanded Addressing Capabilities: The IP address size is increased from 32 bits to 128 bits in IPv6, supporting a much greater number of addressable nodes, more levels of addressing hierarchy, and simpler autoconfiguration of addresses for remote users. The scalability of multicast routing is improved by adding a Scope field to multicast addresses. A new type of address, called anycast, is also defined.
  • Header Format Simplification: Some IPv4 header fields have been dropped or made optional to reduce the necessary amount of packet processing and to limit the bandwidth cost of the IPv6 header.
  • Improved Support for Extensions and Options: IPv6 header options are encoded in such a way to allow for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. Some fields of an IPv4 header have been made optional in IPv6.
  • Flow Labeling Capability: A new quality-of-service (QOS) capability has been added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as real-time service.
  • Authentication and Privacy Capabilities: Extensions to support security options, such as authentication, data integrity, and data confidentiality, are built-in to IPv6.

IPv6 also introduces and formalizes terminology that, in the IPv4 environment, are loosely defined, ill-defined, or undefined. The new and improved terminology includes:

  • Packet: An IPv6 protocol data unit (PDU), comprising a header and the associated payload. In IPv4, this would have been termed packet or datagram.
  • Node: A device that implements IPv6.
  • Router: An IPv6 node that forwards packets, based on the IP address, not explicitly addressed to itself. In former TCP/IP terminology, this device was often referred to as a gateway.
  • Host: Any node that is not a router; these are typically end-user systems.
  • Link: A medium over which nodes communicate with each other at the Data Link Layer (such as an ATM, frame relay, or SMDS wide area network, or an Ethernet or token ring LAN).
  • Neighbors: Nodes attached to the same link.

IPv6 HEADER FORMAT

The format of an IPv6 header is shown in Figure 1. Note that although IPv6 addresses are four times the size of IPv4 addresses, the basic IPv6 header is only twice the size of an IPv4 header, thus decreasing the impact of the larger address fields. The fields of the IPv6 header are:

  • Version: IP version number (4 bits). This field's value is 6 for IPv6 (and 4 for IPv4). Note that this field is in the same location as the Version field in the IPv4 header, making it simple for an IP node to quickly distinguish an IPv4 packet from an IPv6 packet.
  • Priority: Enables a source to identify the desired delivery priority of this packet (4 bits).
  • Flow Label: Used by a source to identify associated packets needing the same type of special handling, such as a real-time service between a pair of hosts (24 bits).
  • Payload Length: Length of the payload (the portion of the packet following the header), in octets (16 bits). The maximum value in this field is 65,535; if this field contains zero, it means that the packet contains a payload larger than 64KB and the actual payload length value is carried in a Jumbo Payload hop-by-hop option.
  • Next Header: Identifies the type of header immediately following the IPv6 header; uses the same values as the IPv4 Protocol field, where applicable (8 bits). The Next Header field can indicate an options header, higher layer protocol, or no protocol above IP. Sample values are listed in Table 1.
  • Hop Limit: Specifies the maximum number of hops that a packet may take before it is discarded (8 bits). This value is set by the source and decremented by 1 by each node that forwards the packet; the packet is discarded if the Hop Limit reaches zero. The comparable field in IPv4 is the Time to Live (TTL) field; it was renamed for IPv6 because the value limits the number of hops, not the amount of time that a packet can stay in the network.
  • Source Address: IPv6 address of the originator of the packet (128 bits).
  • Destination Address: IPv6 address of the intended recipient(s) of the packet (128 bits).

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FIGURE 1. IPv6 Header Format (from RFC 1883).


ValueContents of the next header
1Internet Control Message Protocol (ICMP)
6Transmission Control Protocol (TCP)
17User Datagram Protocol (UDP)
43Routing header
44Fragment header
58Internet Control Message Protocol version 6 (ICMPv6)
59nothing; this is the final header
60Destination Options header
89Open Shortest Path First (OSPF)


IPv6 ADDRESSES

To accommodate almost unlimited growth, and a variety of addressing formats, IPv6 addresses are 128 bits in length. This address space is probably sufficient to uniquely address every molecule in the solar system!

IPv6 defines three types of addresses. A unicast address specifies a single host. An anycast address is one that is assigned to more than a single interface, usually belonging to different IPv6 nodes, such as a set of routers belonging to an ISP. A packet sent to an anycast address is delivered to one of the routers identified by that address, usually the "closest" one as defined by the routing protocol. A multicast address also identifies a set of hosts; a packet sent to a multicast address is delivered to all of the hosts in the group. Note that there is no broadcast address in IPv6 as in IPv4, since that function is provided by multicast addresses.

IPv4 addresses are written in dotted decimal notation, where the decimal value of each of the four address bytes is separated by dots. The preferred, or regular, form of an IPv6 address is to write the hexadecimal value of the eight 16-bit blocks of the address, separated by colons (:), such as FF04:19:5:ABD4:187:2C:754:2B1. Note that leading zeros do not have to be written and that each field must have some value.

IPv6 addresses will often contain long strings of zeros because of the way in which addresses are allocated. A shorthand, or compressed, address form uses a double colon (::) to indicate multiple 16-bit blocks of zeros; for example, the address FF01:0:0:0:0:0:0:5A could be written as FF01::5A. To avoid ambiguity, the "::" can only appear once in an address.

Finally, an alternative, hybrid address format has been defined to make it more convenient to represent an IPv4 address in an IPv6 environment. In this scheme, the first 96 address bits (six groups of 16) are represented in the regular IPv6 format and the remaining 32 address bits are represented in common IPv4 dotted decimal; for example, 0:0:0:0:0:0:199.182.20.17 (or ::199.182.20.17).


ALLOCATIONPrefix
(binary)
Fraction of
Address Space
Reserved0000 00001/256
Unassigned0000 00011/256
Reserved for NSAP Allocation0000 0011/128
Reserved for IPX Allocation0000 0101/128
Unassigned0000 0111/128
Unassigned0000 11/32
Unassigned00011/16
Unassigned0011/8
Provider-Based Unicast Address0101/8
Unassigned0111/8
Reserved for Geographic-Based
Unicast Addresses
1001/8
Unassigned1011/8
Unassigned1101/8
Unassigned11101/16
Unassigned1111 01/32
Unassigned1111 101/64
Unassigned1111 1101/128
Unassigned1111 1110 01/512
Link Local Use Addresses1111 1110 101/1024
Site Local Use Addresses1111 1110 111/1024
Multicast Addresses1111 11111/256


One of the goals of the IPv6 address format is to accommodate many different types of addresses. The beginning of an address contains a three- to ten-bit Format Prefix defining the general address type (Table 2); the remaining bits contain the actual host address, in a format specific to the indicated address type.


| 3 | 5 bits | n bits | 56-n bits | 64 bits | +---+------------+------------+--------------+------------------+ |010| RegistryID | ProviderID | SubscriberID | Intra-Subscriber | +---+------------+------------+--------------+------------------+ FIGURE 2. Provider-Based Unicast Address Format (from RFC 1884).


For example, the Provider-Based Unicast Address is an IPv6 address that might be assigned by an Internet service provider (ISP) to a customer. This type of address contains a number of subfields, including (Figure 2):

  • Format Prefix: Indicates type of address as Provider-Based Unicast. Always 3 bits, coded "010."
  • Registry Identifier: Identifies the Internet address registry from which this ISP obtains addresses. A 5-bit value indicating the IANA Internet Assigned Number Authority or one of the three Regional Registries, namely the Internet Network Information Center (InterNIC), Rèseaux IP Europèens Network Coordination Center (RIPE NCC), or Asia-Pacific Network Information Center (APNIC). In the future, national registries may also be accommodated.
  • Provider Identifier: Identifies the ISP; this field contains the address block assigned to this ISP by the address registry authority.
  • Subscriber Identifier: Identifies the ISP's subscriber; this field contains the address assigned to this subscriber by the ISP. The ProviderID and SubscriberID fields together are 56 bits in length.
  • Intra-Subscriber: Contains the portion of the address assigned and managed by the subscriber. A 64-bit value, suggested to comprise a 16-bit subnetwork identifier and a 48-bit interface identifier (such as an IEEE MAC address).

Another particularly important address type is the one that indicates an IPv4 address. With over sixteen million hosts using 32-bit addresses, the public Internet must continue to accommodate IPv4 addresses even as it slowly migrates to IPv6 and IPv6 addressing,

IPv4 addresses are carried in a 128-bit IPv6 address that begins with 80 zeros (0:0:0:0:0). The next 16-bit block contains the compatibility bits, which indicate the way in which the host/router handles IPv4 and IPv6 addresses. If the device can handle either IPv4 or IPv6 addresses, the compatibility bits are all set to zero (0) and this is termed an IPv4-compatible IPv6 address; if the address represents an IPv4-only node, the compatibility bits are all set to one (0xFFFF) and the address is termed an IPv4-mapped IPv6 address. The final 32 bits contain a 32-bit IPv4 address in dotted decimal form.

Finally, IPv6 multicast addresses provide an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses may not be used as a source address in IPv6 packets or appear in any routing header.


| 8 | 4 | 4 | 112 bits | +--------+----+----+--------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+--------------------------------------------+ FIGURE 3. Multicast Address Format (from RFC 1884).


All multicast addresses, as shown in Figure 3, begin with eight ones (0xFF). The next four bits are a set of flag bits (flgs); the three high-order bits are set to zero and the fourth bit (T-bit) indicates a permanently assigned ("well-known") multicast address (T=0) or a nonpermanently assigned ("transient") multicast address (T=1). The next four bits indicate the scope of the address (scop), or the part of the network for which this multicast address is relevant; options include node-local (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), or global (0xE). The remaining 112 bits are the Group Identifier, which identifies the multicast group, either permanent or transient, within the given scope. The interpretation of a permanently assigned multicast address is independent of the scope value; for example, if the "Internet video servers group" is assigned a permanent multicast address with a group identifier of 0x77, then:

  • FF01:0:0:0:0:0:0:77 would refer to all video servers on the same node as the sender.
  • FF02:0:0:0:0:0:0:77 would refer to all video servers on the same link as the sender.
  • FF05:0:0:0:0:0:0:77 would refer to all video servers at the same site as the sender.
  • FF0E:0:0:0:0:0:0:77 would refer to all video servers in the Internet.

Finally, a number of well-known multicast addresses are predefined, including:

  • Reserved Multicast Addresses are reserved and are never assigned to any multicast group. These addresses have the form FF0x:0:0:0:0:0:0:0, where x is any hexadecimal digit.
  • All Nodes Addresses identify the group of all IPv6 nodes within the given scope. These addresses are of the form FF0t:0:0:0:0:0:0:1, where t =1 (node-local) or 2 (link-local).
  • All Routers Addresses identify the group of all IPv6 routers within the given scope. These addresses are of the form FF0t:0:0:0:0:0:0:2, where t =1 (node-local) or 2 (link-local).
  • The DHCP Server/Relay-Agent address identifies the group of all IPv6 Dynamic Host Configuration Protocol (DHCP) Servers and Relay Agents with the link-local scope; this address is FF02:0:0:0:0:0:0:C.

IPv6 EXTENSION HEADERS AND OPTIONS

In IPv6, optional IP Layer information is encoded in separate extension headers that are placed between the IPv6 basic header and the higher layer protocol header. An IPv6 packet may carry zero, one, or more such extension headers, each identified by the Next Header field of the preceding header and each containing an even multiple of 64 bits (Figure 4). A fully compliant implementation of IPv6 includes support for the following extension headers and corresponding options:

  • The Hop-by-Hop Options header is used to carry information that must be examined by every node along a packet's path. Three options are included in this category. The Pad1 option is used to insert a single octet of padding into the Options area of a header for 64-bit alignment, while the PadN option is used to insert two or more octets of padding. The Jumbo Payload option is used to indicate the length of the packet when the payload portion is longer than 65,535 octets (this option is employed when the Payload Length field is set to zero).

  • The Routing header is used by an IPv6 source to list one or more intermediate nodes that must be visited as part of the packet's path to the destination; this option is functionally similar to IPv4's Loose and Strict Source Route options. This header contains a list of addresses and an indication of whether each address is strict or loose. If an address is marked strict, it means that this node must be a neighbor of the previously addressed node; if an address is marked loose, this node does not have to be a neighbor of the previous node.

  • The Fragment header is used by an IPv6 source to send packets that are larger than the maximum transmission unit (MTU) on the path to the destination. This header will contain a packet identifier, fragment offset, and final fragment indicator. Unlike IPv4, where fragmentation information is carried in every packet header, IPv6 only carries fragmentation/reassembly information in those packets that are fragmented. In another departure from IPv4, fragmentation in IPv6 is performed only by the source and not by the routers along a packet's path. All IPv6 hosts and routers must support an MTU of 576 octets; it is recommended that path MTU discovery procedures (per RFC 1981) be invoked to discover, and take advantage of, those paths with a larger MTU.

  • The Destination Options header is used to carry optional information that has to be examined only by a packet's destination node(s). The only destination options defined so far are Pad1 and PadN, as described above.

  • The IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) are IPv6 security mechanisms (see IPv6 Security below).

<--- 32 bits ---> <--- 32 bits ---> <--- 32 bits ---> +---------------+ +---------------+ +---------------+ | IPv6 header | | IPv6 header | | IPv6 header | | | | | | | | Next Header = | | Next Header = | | Next Header = | | TCP | | Routing | | Routing | +---------------+ +---------------+ +---------------+ | TCP header | |Routing header | |Routing header | | + | | | | | | data | | Next Header = | | Next Header = | | | | TCP | | Fragment | +---------------+ +---------------+ +---------------+ | TCP header | |Fragment header| | + | | | | data | | Next Header = | | | | TCP | +---------------+ +---------------+ | TCP header | | + | | data | | | +---------------+ FIGURE 4. IPv6 Extension Header examples. TCP segment encapsulated
in IP without additional options (left); TCP segment following a Routing
header (middle); and TCP segment fragment following a Fragment header
following a Routing header (right) (inspired from RFC 1883).


With the exception of the Hop-by-Hop Option, extension headers are only examined or processed by the intended destination node(s). The contents of each extension header determine whether or not to proceed to the next header and, therefore, extension headers must be processed in the order they appear in the packet.

IPv6 QUALITY-OF-SERVICE PARAMETERS

The Priority and Flow Label fields in the IPv6 header are used by a source to identify packets needing special handling by network routers. The concept of a flow in IP is a major departure from IPv4 and most other connectionless protocols; some have called flows a form of connectionless virtual circuits since all packets with the same flow label are treated similarly and the network views them as associated entities.

Special handling for non-default quality-of-service is an important capability in order to support applications that require guaranteed throughput, end-to-end delay, and/or jitter, such as multimedia or real-time communication. These QOS parameters are an extension of IPv4's Type of Service (TOS) capability.

The Priority field allows the source to identify the desired priority of a packet. Values 0-7 are used for congestion-controlled traffic, or traffic that backs off in response to network congestion, such as TCP segments. For this type of traffic, the following priority values are recommended:

    0) Uncharacterized traffic
    1) "Filler" traffic (e.g., Netnews)
    2) Unattended data transfer (e.g., e-mail)
    3) (reserved)
    4) Attended bulk transfer (e.g., FTP, HTTP, NFS)
    5) (reserved)
    6) Interactive traffic (e.g., Telnet, X)
    7) Internet control traffic (e.g., routing protocols, SNMP)

Values 8-15 are defined for noncongestion-controlled traffic, or traffic that does not back off in response to network congestion, such as real-time packets being sent at a constant rate. For this type of traffic, the lowest priority value (8) should be used for packets that the sender is most willing to have discarded under congestion conditions (e.g., high-fidelity video traffic) and the highest value (15) should be used for those packets that the sender is least willing to have discarded (e.g., low-fidelity audio traffic).2

The Flow Label is used by a source to identify packets needing nondefault QOS. The nature of the special handling might be conveyed to the network routers by a control protocol, such as the Resource Reservation Protocol (RSVP), or by information within the flow packets themselves, such as a hop-by-hop option. There may be multiple active flows from a source to a destination, as well as traffic that is not associated with any flow (i.e., Flow Label = 0). A flow is uniquely identified by the combination of a source address and a nonzero flow label. This aspect of IPv6 is still in the experimental stage and future definition is expected.

IPv6 SECURITY

In the early days of TCP/IP, the ARPANET user community was small and close, and security mechanisms were not of primary concern. As the number of TCP/IP hosts grew, and the user community became one of strangers (some nefarious) rather than friends, security became more important. As critical and sensitive data travels on today's Internet, security is of paramount concern.

Although many of today's TCP/IP applications have their own security mechanisms, many would argue that security should be implemented at the lowest possible protocol layer. IPv4 had few, if any, security mechanisms, and authentication and privacy mechanisms at lower protocol layers is largely absent. IPv6 builds two security schemes into the basic protocol.

The first mechanism is the IP Authentication Header (RFC 1826), an extension header that can provide integrity3 and authentication4 for IP packets. Although many different authentication techniques will be supported, use of the keyed Message Digest 5 (MD5, described in RFC 1321) algorithm is required to ensure interoperability. Use of this option can eliminate a large number of network attacks, such as IP address spoofing; this will also be an important addition to overcoming some of the security weaknesses of IP source routing. IPv4 provides no host authentication; all IPv4 can do is to supply the sending host's address as advertised by the sending host in the IP datagram. Placing host authentication information at the Internet Layer in IPv6 provides significant protection to higher layer protocols and services that currently lack meaningful authentication processes.

The second mechanism is the IP Encapsulating Security Payload (ESP, described in RFC 1827), an extension header that can provide integrity and confidentiality5 for IP packets. Although the ESP definition is algorithm-independent, the Data Encryption Standard using cipher block chaining mode (DES-CBC) is specified as the standard encryption scheme to ensure interoperability. The ESP mechanism can be used to encrypt an entire IP packet (tunnel-mode ESP) or just the higher layer portion of the payload (transport-mode ESP).

These features will add to the secure nature of IP traffic while actually reducing the security effort; authentication performed on an end-to-end basis during session establishment will provide more secure communications even in the absence of firewall routers. Some have suggested that the need for firewalls will be obviated by widespread use of IPv6, although there is no evidence to that effect yet.

ICMPv6

The Internet Control Message Protocol (ICMP) provides error and information messages that are beyond the scope of IP. ICMP for IPv6 (ICMPv6) is functionally similar to ICMP for IPv4 and uses a similar message format, and forms an integral part of IPv6. ICMPv6 messages are carried in an IPv6 datagram with a Next Header field value of 58.

ICMPv6 error messages are:

  • Destination Unreachable: Sent when a packet cannot be delivered to its destination address for reasons other than congestion
  • Packet Too Big: Sent by a router when it has a packet that it cannot forward because the packet is larger than the MTU of the outgoing link
  • Time Exceeded: Sent by a router that when the packet's Hop Limit reaches zero or if all fragments of a datagram are not received within the fragment reassembly time
  • Parameter Problem: Sent by a node that finds some problem in a field in the packet header that results in an inability to process the header).

ICMPv6 informational messages are Echo Request and Echo Reply (used by IPv6 nodes for diagnostic purposes), as well as Group Membership Query, Group Membership Report, and Group Membership Reduction (all used to convey information about multicast group membership from nodes to their neighboring routers).

MIGRATION TO IPv6

The transition to IPv6 has already started even though most Internet and TCP/IP users have not yet seen new software on their local systems nor local networks. Before IPv6 can be widely deployed, the network infrastructure must be upgraded to employ software that accommodates the new protocol.

In addition, the new address format must be accommodated by every TCP/IP protocol that uses addresses. The Domain Name System (DNS), for example, has defined an AAAA resource record for IPv6 128-bit addresses (IPv4's 32-bit addresses use an A record) and the IP6.INT address domain (IPv4 uses the ARPA address domain). Other protocols that must be modified for IPv6 include DHCP, the Address Resolution Protocol (ARP) family, and IP routing protocols such as the Routing Information Protocol (RIP), Open Shortest Path First (OSPF) protocol, and the Border Gateway Protocol (BGP). Only after the routers and the backbones are upgraded will hosts start to transition to the new protocol and applications be modified to take advantage of IPv6's capabilities.

When IPv4 became the official ARPANET standard in 1983, use of previous protocols ceased and there was no planned interoperability between the old and the new. This will not — can not — be the case with the introduction of IPv6. Although IPv6 trials started in 1996 and initial rollout of IPv6 in the Internet backbone is expected in 1997, there is no scheduled — or desired — date of a flash cut from one to the other; coexistence of IPv4 and IPv6 is anticipated for many years to come. The simple fact of the sheer number of hosts using IPv4 today suggests that no other policy even begins to make sense. While IPv6 will appear in the large ISP backbones sooner rather than later, some smaller service providers and local network administrators will not make the conversion quickly unless they perceive some benefit from IPv6.


(-----) ------------- (-----) ------------- (-----) ( IPv6 ) | IPv4/IPv6 | ( IPv4 ) | IPv4/IPv6 | ( IPv6 ) ( network )---| router |---( network )---| router |---( network ) ( ) ------------- ( ) ------------- ( ) (-----) (-----) (-----) FIGURE 5. Common short-term scenario where an IPv4 network interconnects IPv6 networks.


The coexistence of IPv4 and IPv6 in the network means that different protocols and procedures will need to be accommodated. In one common short-term scenario, IPv6 networks will be interconnected via an IPv4 backbone (Figure 5). The boundary routers will be IPv4-compatible IPv6 nodes and the routers' interfaces will be given IPv4-compatible IPv6 addresses. The IPv6 packet is transported over the IPv4 network by encapsulating the packet in an IPv4 header; this process is called tunneling. Tunneling can also be performed when an organization has converted a part of its subnet to IPv6. This process can be used on host-host, router-router, or host-router links.

Although the introduction of IPv6 is inevitable, many of the market pressures for its development have been somewhat obviated because of parallel developments that enhance the capabilities of IPv4. The address limitations of IPv4, for example, are minimized by use of Classless Interdomain Routing (CIDR). Nomadic user address allocation can be managed by the Dynamic Host Configuration Protocol (DHCP). Quality of service management can be handled by the Resource Reservation Protocol (RSVP). And the IP Authentication Header and Encapsulating Security Payload procedures can be applied to IPv4 as well as IPv6.

This is not meant to suggest that IP vendors are waiting. IPv6 has already started to appear in real products and production networks. Support for IPv6 on several versions of UNIX have been announced by such organizations as Digital Equipment Corporation, IBM, INRIA (Institut National De Recherche En Informatique Et En Automatique, or The French National Institute for Research in Computer Science and Control), Japan's WIDE Project, Sun Microsystems, the Swedish Institute of Computer Science (SICS), and the U.S. Naval Research Laboratory. Other companies have announced support for IPv6 in other operating environments, including Apple Computer (MacOS), FTP Software (DOS/Windows), Mentat (STREAMS), Novell (NetWare), Pacific Softworks, and Siemens Nixdorf (BS2000). Major router vendors that have announced support for IPv6 include Bay Networks, Cisco Systems, Digital Equipment Corporation, Ipsilon Networks, Penril Datability Networks, and Telebit Communications.

One of the important proving grounds of IPv6 is the 6bone, a testbed network spanning North America, Europe, and Japan that began operation in 1996. The 6bone is a virtual network built on top of portions of today's IPv4-based Internet, designed specifically to route IPv6 packets. The goal of this collaborative trial is to test IPv6 implementations and to define early policies and procedures that will be necessary to support IPv6 in the future. In addition, it will demonstrate IPv6's new capabilities and will provide a basis for user confidence in the new protocol.

For most users, the transition from IPv4 to IPv6 will occur when the version of their host's operating system software is updated; in some cases, it will mean running dual-stacked systems with both versions of IP. For larger user networks, it may make sense to follow the model of the larger global Internet; in particular, pre-design the IPv6 network topology and addressing scheme, build a testbed IPv6 network with routers and a DNS, and then slowly migrate applications, users, and subnetworks to the new backbone. The lessons learned from the 6bone activity will be useful for individual networks as well as the Internet backbone.

REFERENCES AND FURTHER READING

Bradner, S. and A. Mankin. IPng: Internet Protocol Next Generation. Reading (MA): Addison-Wesley, 1996.

Deering, S. "SIP: Simple Internet Protocol." IEEE Network, May 1993.

Feit, S. TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security, 2nd ed. New York: McGraw-Hill, 1997.

Francis, P. "A Near-Term Architecture for Deploying Pip." IEEE Network, May 1993.

Hinden, R.M. "IP Next Generation Overview." Communications of the ACM, June 1996.

Huitema, C. IPv6: The New Internet Protocol. Upper Saddle River (NJ): Prentice-Hall, 1996.

IETF IPng Working Group Home Page. URL: http://www.ietf.org/html.charters/ipngwg-charter.html. Last accessed: 29 January 1997.

IP Next Generation Web Page. URL: http://playground.sun.com/pub/ipng/html. Last accessed: 29 January 1997.

Katz, D. and P.S. Ford. "TUBA: Replacing IP with CLNP." IEEE Network, May 1993.

Kessler, G.C. An Overview of TCP/IP Protocols and the Internet. URL: http://www.sover.net/library/tcpip.html. Last accessed: 1 February 1997.

Miller, M. "Making the Move: The path for an orderly transition from IPv4 to IPv6." Network World, January 20, 1997.

Schneier, B. Applied Cryptography, 2/e. New York: John Wiley & Sons, 1996.

6bone Web Page. URL: http://www-6bone.lbl.gov/6bone. Last accessed: 29 January 1997.

Stallings, W. "IPv6: The New Internet Protocol." IEEE Communications Magazine, July 1996. (Also: URL: http://www.ieee.org/comsoc/stallings.html. Last accessed: December 10, 1996.)

Thomas, S. IPng and the TCP/IP Protocols. New York: John Wiley & Sons, 1996.


ABOUT THE AUTHOR: At the time of this paper's publication, Gary C. Kessler was Director of Information Technology at Hill Associates, a telecommunications training and education firm located in Colchester, Vermont. He is the co-author of ISDN, 4/e (McGraw-Hill), author of more than 50 articles, and frequent speaker at industry conferences. He can be reached via e-mail at kumquat@sover.net.


APPENDIX: THE IP VERSION 6 SPECIFICATIONS

IPv6 is specified in a number of RFCs. The core description of IPv6 and related protocols can be found in:

  • RFC 1883: Internet Protocol, Version 6 (IPv6) Specification
  • RFC 1884: IP Version 6 Addressing Architecture
  • RFC 1885: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
  • RFC 1886: DNS Extensions to support IP version 6

Other related RFCs include:

  • RFC 1550: IP: Next Generation (IPng) White Paper Solicitation
  • RFC 1726: Technical Criteria for Choosing IP: The Next Generation (IPng)
  • RFC 1752: The Recommendation for the IP Next Generation Protocol
  • RFC 1825: Security Architecture for the Internet Protocol
  • RFC 1826: IP Authentication Header
  • RFC 1827: IP Encapsulating Security Protocol (ESP)
  • RFC 1828: IP Authentication uysing Keyed MD5
  • RFC 1829: The ESP DES-CBC Transform
  • RFC 1881: IPv6 Address Allocation Management
  • RFC 1887: An Architecture for IPv6 Unicast Address Allocation
  • RFC 1888: OSI NSAPs and IPv6
  • RFC 1897: IPv6 Testing Address Allocation
  • RFC 1970: Neighbor Discovery for IP Version 6 (IPv6)
  • RFC 1971: IPv6 Stateless Address Autoconfiguration
  • RFC 1972: A Method for the Transmission of IPv6 Packets over Ethernet Networks
  • RFC 1981: Path MTU Discovery for IP version 6
  • RFC 2002: IP Mobility Support
  • RFC 2003: IP Encapsulation within IP
  • RFC 2019: Transmission of IPv6 Packets Over FDDI
  • RFC 2023: IP Version 6 over PPP
  • RFC 2073: IPv6 Provider-Based Unicast Address Format
  • RFC 2080: RIPng for IPv6
  • RFC 2081: RIPng Protocol Applicability Statement

RFCs may be obtained over the Internet via anonymous FTP from ftp://ds.internic.net/rfc. For additions sites and mechanisms to obtain RFCs, send e-mail to rfc-info@isi.edu and put help: ways_to_get_rfcs in the message body.

[Back to main text]


Footnotes

  1. Version 5 of IP is assigned to the experimental Internet Stream Protocol Version 2 (ST-2), described in RFC 1819. [Back to main text]

  2. This example, taken from the IPv6 specification, is counter-intuitive to many people. Low-fidelity audio, such as a telephone conversation, would probably be given a high priority because data loss is audible to the users as beeps and clicks. High-fidelity audio, on the other hand, such as CD-quality stereo, would probably be assigned a lower priority because these data streams usually contain redundant information and can, therefore, tolerate some information loss. [Back to main text]

  3. In this context, integrity refers to the assurance that the message has not been altered in transit, and that the contents of the received message are identical to the contents of the transmitted message. [Back to main text]

  4. In this context, authentication refers to the mechanism that one party uses to ensure that the other party really is who they claim to be. [Back to main text]

  5. In this context, confidentiality, or privacy, refers to keeping the contents of a message secret from a third-party. [Back to main text]



























[Docs] [txt|pdf] [draft-ietf-sipp...] [Tracker] [Diff1] [Diff2]

INFORMATIONAL

Network Working Group: R. Hinden Request for Comments: 1710 Sun Microsystems Category: Informational October 1994 Simple Internet Protocol Plus White Paper Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list. 1. Introduction This white paper presents an overview of the Simple Internet Protocol plus (SIPP) which is one of the candidates being considered in the Internet Engineering Task Force (IETF) for the next version of the Internet Protocol (the current version is usually referred to as IPv4). This white paper is not intended to be a detailed presentation of all of the features and motivation for SIPP, but is intended to give the reader an overview of the proposal. It is also not intended that this be an implementation specification, but given the simplicity of the central core of SIPP, an implementor familiar with IPv4 could probably construct a basic working SIPP implementation from reading this overview. SIPP is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. It can be installed as a normal software upgrade in internet devices and is interoperable with the current IPv4. Its deployment strategy was designed to not have any "flag" days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future. This white paper describes the work of IETF SIPP working group. Several individuals deserve specific recognition. These include Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan, Bill Hinden [Page 1]
RFC 1710 SIPP IPng White Paper October 1994 Simpson, Ran Atkinson, Bill Fink, Erik Nordmark, Christian Huitema, Sue Thompson, and Ramesh Govindan. 2. Key Issues for the Next Generation of IP There are several key issues that should be used in the evaluation of any next generation internet protocol. Some are very straightforward. For example the new protocol must be able to support large global internetworks. Others are less obvious. There must be a clear way to transition the current installed base of IP systems. It doesn't matter how good a new protocol is if there isn't a practical way to transition the current operational systems running IPv4 to the new protocol. 2.1 Growth Growth is the basic issue which caused there to be a need for a next generation IP. If anything is to be learned from our experience with IPv4 it is that the addressing and routing must be capable of handling reasonable scenarios of future growth. It is important that we have an understanding of the past growth and where the future growth will come from. Currently IPv4 serves what could be called the computer market. The computer market has been the driver of the growth of the Internet. It comprises the current Internet and countless other smaller internets which are not connected to the Internet. Its focus is to connect computers together in the large business, government, and university education markets. This market has been growing at an exponential rate. One measure of this is that the number of networks in current Internet (23,494 as of 1/28/94) is doubling approximately every 12 months. The computers which are used at the endpoints of internet communications range from PC's to Supercomputers. Most are attached to Local Area Networks (LANs) and the vast majority are not mobile. The next phase of growth will probably not be driven by the computer market. While the computer market will continue to grow at significant rates due to expansion into other areas such as schools (elementary through high school) and small businesses, it is doubtful it will continue to grow at an exponential rate. What is likely to happen is that other kinds of markets will develop. These markets will fall into several areas. They all have the characteristic that they are extremely large. They also bring with them a new set of requirements which were not as evident in the early stages of IPv4 deployment. The new markets are also likely to happen in parallel with other. It may turn out that we will look back on the last ten years of Internet growth as the time when the Internet was small and Hinden [Page 2]
RFC 1710 SIPP IPng White Paper October 1994 only doubling every year. The challenge for an IPng is to provide a solution which solves todays problems and is attractive in these emerging markets. Nomadic personal computing devices seem certain to become ubiquitous as their prices drop and their capabilities increase. A key capability is that they will be networked. Unlike the majority of todays networked computers they will support a variety of types of network attachments. When disconnected they will use RF wireless networks, when used in networked facilities they will use infrared attachment, and when docked they will use physical wires. This makes them an ideal candidate for internetworking technology as they will need a common protocol which can work over a variety of physical networks. These types of devices will become consumer devices and will replace the current generation of cellular phones, pagers, and personal digital assistants. In addition to the obvious requirement of an internet protocol which can support large scale routing and addressing, they will require an internet protocol which imposes a low overhead and supports auto configuration and mobility as a basic element. The nature of nomadic computing requires an internet protocol to have built in authentication and confidentiality. It also goes without saying that these devices will need to communicate with the current generation of computers. The requirement for low overhead comes from the wireless media. Unlike LAN's which will be very high speed, the wireless media will be several orders of magnitude slower due to constraints on available frequencies, spectrum allocation, and power consumption. Another market is networked entertainment. The first signs of this emerging market are the proposals being discussed for 500 channels of television, video on demand, etc. This is clearly a consumer market. The possibility is that every television set will become an Internet host. As the world of digital high definition television approaches, the differences between a computer and a television will diminish. As in the previous market, this market will require an Internet protocol which supports large scale routing and addressing, and auto configuration. This market also requires a protocol suite which imposes the minimum overhead to get the job done. Cost will be the major factor in the selection of a technology to use. Another market which could use the next generation IP is device control. This consists of the control of everyday devices such as lighting equipment, heating and cooling equipment, motors, and other types of equipment which are currently controlled via analog switches and in aggregate consume considerable amounts of power. The size of this market is enormous and requires solutions which are simple, robust, easy to use, and very low cost. Hinden [Page 3]
RFC 1710 SIPP IPng White Paper October 1994 The challenge for the IETF in the selection of an IPng is to pick a protocol which meets today's requirements and also matches the requirements of these emerging markets. These markets will happen with or without an IETF IPng. If the IETF IPng is a good match for these new markets it is likely to be used. If not, these markets will develop something else. They will not wait for an IETF solution. If this should happen it is probable that because of the size and scale of the new markets the IETF protocol would be supplanted. If the IETF IPng is not appropriate for use in these markets, it is also probable that they will each develop their own protocols, perhaps proprietary. These new protocols would not interoperate with each other. The opportunity for the IETF is to select an IPng which has a reasonable chance to be used in these emerging markets. This would have the very desirable outcome of creating an immense, interoperable, world-wide information infrastructure created with open protocols. The alternative is a world of disjoint networks with protocols controlled by individual vendors. 2.2. Transition At some point in the next three to seven years the Internet will require a deployed new version of the Internet protocol. Two factors are driving this: routing and addressing. Global internet routing based on the on 32-bit addresses of IPv4 is becoming increasingly strained. IPv4 address do not provide enough flexibility to construct efficient hierarchies which can be aggregated. The deployment of Classless Inter-Domain Routing [CIDR] is extending the life time of IPv4 routing routing by a number of years, the effort to manage the routing will continue to increase. Even if the IPv4 routing can be scaled to support a full IPv4 Internet, the Internet will eventually run out of network numbers. There is no question that an IPng is needed, but only a question of when. The challenge for an IPng is for its transition to be complete before IPv4 routing and addressing break. The transition will be much easier if IPv4 address are still globally unique. The two transition requirements which are the most important are flexibility of deployment and the ability for IPv4 hosts to communicate with IPng hosts. There will be IPng-only hosts, just as there will be IPv4- only hosts. The capability must exist for IPng-only hosts to communicate with IPv4-only hosts globally while IPv4 addresses are globally unique. The deployment strategy for an IPng must be as flexible as possible. The Internet is too large for any kind of controlled rollout to be successful. The importance of flexibility in an IPng and the need for interoperability between IPv4 and IPng was well stated in a Hinden [Page 4]
RFC 1710 SIPP IPng White Paper October 1994 message to the sipp mailing list by Bill Fink, who is responsible for a portion of NASA's operational internet. In his message he said: "Being a network manager and thereby representing the interests of a significant number of users, from my perspective it's safe to say that the transition and interoperation aspects of any IPng is *the* key first element, without which any other significant advantages won't be able to be integrated into the user's network environment. I also don't think it wise to think of the transition as just a painful phase we'll have to endure en route to a pure IPng environment, since the transition/coexistence period undoubtedly will last at least a decade and may very well continue for the entire lifetime of IPng, until it's replaced with IPngng and a new transition. I might wish it was otherwise but I fear they are facts of life given the immense installed base. "Given this situation, and the reality that it won't be feasible to coordinate all the infrastructure changes even at the national and regional levels, it is imperative that the transition capabilities support the ability to deploy the IPng in the piecemeal fashion... with no requirement to need to coordinate local changes with other changes elsewhere in the Internet... "I realize that support for the transition and coexistence capabilities may be a major part of the IPng effort and may cause some headaches for the designers and developers, but I think it is a duty that can't be shirked and the necessary price that must be paid to provide as seamless an environment as possible to the end user and his basic network services such as e-mail, ftp, gopher, X-Window clients, etc... "The bottom line for me is that we must have interoperability during the extended transition period for the base IPv4 functionality..." Another way to think about the requirement for compatibility with IPv4 is to look at other product areas. In the product world, backwards compatability is very important. Vendors who do not provide backward compatibility for their customers usually find they do not have many customers left. For example, chip makers put considerable effort into making sure that new versions of their processor always run all of the software that ran on the previous model. It is unlikely that Intel would develop a new processor in the X86 family that did not run DOS and the tens of thousands of applications which run on the current versions of X86's. Operating system vendors go to great lengths to make sure new versions of their operating systems are binary compatible with their Hinden [Page 5]
RFC 1710 SIPP IPng White Paper October 1994 old version. For example the labels on most PC or MAC software usually indicate that they require OS version XX or greater. It would be foolish for Microsoft come out with a new version of Windows which did not run the applications which ran on the previous version. Microsoft even provides the ability for windows applications to run on their new OS NT. This is an important feature. They understand that it was very important to make sure that the applications which run on Windows also run on NT. The same requirement is also true for IPng. The Internet has a large installed base. Features need to be designed into an IPng to make the transition as easy as possible. As with processors and operating systems, it must be backwards compatible with IPv4. Other protocols have tried to replace TCP/IP, for example XTP and OSI. One element in their failure to reach widespread acceptance was that neither had any transition strategy other than running in parallel (sometimes called dual stack). New features alone are not adequate to motivate users to deploy new protocols. IPng must have a great transition strategy and new features. 3. History of the SIPP Effort The SIPP working group represents the evolution of three different IETF working groups focused on developing an IPng. The first was called IP Address Encapsulation (IPAE) and was chaired by Dave Crocker and Robert Hinden. It proposed extensions to IPv4 which would carry larger addresses. Much of its work was focused on developing transition mechanisms. Somewhat later Steve Deering proposed a new protocol evolved from IPv4 called the Simple Internet Protocol (SIP). A working group was formed to work on this proposal which was chaired by Steve Deering and Christian Huitema. SIP had 64-bit addresses, a simplified header, and options in separate extension headers. After lengthly interaction between the two working groups and the realization that IPAE and SIP had a number of common elements and the transition mechanisms developed for IPAE would apply to SIP, the groups decided to merge and concentrate their efforts. The chairs of the new SIP working group were Steve Deering and Robert Hinden. In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded a working group to develop the "P" Internet Protocol (Pip). Pip was a new internet protocol based on a new architecture. The motivation behind Pip was that the opportunity for introducing a new internet protocol does not come very often and given that opportunity important new features should be introduced. Pip supported variable length addressing in 16-bit units, separation of addresses from identifiers, support for provider selection, mobility, and efficient Hinden [Page 6]
RFC 1710 SIPP IPng White Paper October 1994 forwarding. It included a transition scheme similar to IPAE. After considerable discussion among the leaders of the Pip and SIP working groups, they came to realize that the advanced features in Pip could be accomplished in SIP without changing the base SIP protocol as well as keeping the IPAE transition mechanisms. In essence it was possible to keep the best features of each protocol. Based on this the groups decided to merge their efforts. The new protocol was called Simple Internet Protocol Plus (SIPP). The chairs of the merged working group are Steve Deering, Paul Francis, and Robert Hinden. 4. SIPP Overview SIPP is a new version of the Internet Protocol, designed as a successor to IP version 4 [IPV4]. SIPP is assigned IP version number 6. SIPP was designed to take an evolutionary step from IPv4. It was not a design goal to take a radical step away from IPv4. Functions which work in IPv4 were kept in SIPP. Functions which didn't work were removed. The changes from IPv4 to SIPP fall primarily into the following categories: o Expanded Routing and Addressing Capabilities SIPP increases the IP address size from 32 bits to 64 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes. SIPP addressing can be further extended, in units of 64 bits, by a facility equivalent to IPv4's Loose Source and Record Route option, in combination with a new address type called "cluster addresses" which identify topological regions rather than individual nodes. The scaleability of multicast routing is improved by adding a "scope" field to multicast addresses. o Header Format Simplification Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to keep the bandwidth cost of the SIPP header almost as low as that of IPv4, despite the increased size of the addresses. The basic SIPP header is only four bytes longer than IPv4. Hinden [Page 7]
RFC 1710 SIPP IPng White Paper October 1994 o Improved Support for Options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. o Quality-of-Service Capabilities A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real-time" service. o Authentication and Privacy Capabilities SIPP includes the definition of extensions which provide support for authentication, data integrity, and confidentiality. This is included as a basic element of SIPP. The SIPP protocol consists of two parts, the basic SIPP header and SIPP Options. 4.1 SIPP Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Payload Type | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 4-bit Internet Protocol version number = 6. Flow Label 28-bit field. See SIPP Quality of Service section. Payload Length 16-bit unsigned integer. Length of payload, i.e., the rest of the packet following the SIPP header, in octets. Hinden [Page 8]
RFC 1710 SIPP IPng White Paper October 1994 Payload Type 8-bit selector. Identifies the type of header immediately following the SIPP header. Uses the same values as the IPv4 Protocol field [STD 2, RFC 1700]. Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. Source Address 64 bits. An address of the initial sender of the packet. See [ROUT] for details. Destination Address 64 bits. An address of the intended recipient of the packet (possibly not the ultimate recipient, if an optional Routing Header is present). 4.2 SIPP Options SIPP includes an improved option mechanism over IPv4. SIPP options are placed in separate headers that are located between the SIPP header and the transport-layer header in a packet. Most SIPP option headers are not examined or processed by any router along a packet's delivery path until it arrives at its final destination. This facilitates a major improvement in router performance for packets containing options. In IPv4 the presence of any options requires the router to examine all options. The other improvement is that unlike IPv4, SIPP options can be of arbitrary length and the total amount of options carried in a packet is not limited to 40 bytes. This feature plus the manner in which they are processed, permits SIPP options to be used for functions which were not practical in IPv4. A good example of this is the SIPP Authentication and Security Encapsulation options. In order to improve the performance when handling subsequent option headers and the transport protocol which follows, SIPP options are always an integer multiple of 8 octets long, in order to retain this alignment for subsequent headers. Hinden [Page 9]
RFC 1710 SIPP IPng White Paper October 1994 The SIPP option headers which are currently defined are: Option Function --------------- --------------------------------------- Routing Extended Routing (like IPv4 loose source route) Fragmentation Fragmentation and Reassembly Authentication Integrity and Authentication Security Encapsulation Confidentiality Hop-by-Hop Option Special options which require hop by hop processing 4.3 SIPP Addressing SIPP addresses are 64-bits long and are identifiers for individual nodes and sets of nodes. There are three types of SIPP addresses. These are unicast, cluster, and multicast. Unicast addresses identify a single node. Cluster addresses identify a group of nodes, that share a common address prefix, such that a packet sent to a cluster address will be delivered to one member of the group. Multicast addresses identify a group of nodes, such that a packet sent to a multicast address is delivered to all of the nodes in the group. SIPP supports addresses which are twice the number of bits as IPv4 addresses. These addresses support an address space which is four billion (2^^32) times the size of IPv4 addresses (2^^32). Another way to say this is that SIPP supports four billion internets each the size of the maximum IPv4 internet. That is enough to allow each person on the planet to have their own internet. Even with several layers of hierarchy (with assignment utilization similar to IPv4) this would allow for each person on the planet to have their own internet each holding several thousand hosts. In addition, SIPP supports extended addresses using the routing option. This capability allows the address space to grow to 128- bits, 192-bits (or even larger) while still keeping the address units in manageable 64-bit units. This permits the addresses to grow while keeping the routing algorithms efficient because they continue to operate using 64- bit units. 4.3.1 Unicast Addresses There are several forms of unicast address assignment in SIPP. These are global hierarchical unicast addresses, local-use addresses, and IPv4- only host addresses. The assignment plan for unicast addresses is described in [ADDR]. Hinden [Page 10]
RFC 1710 SIPP IPng White Paper October 19944.3.1.1 Global Unicast Addresses Global unicast addresses are used for global communication. They are the most common SIPP address and are similar in function to IPv4 addresses. Their format is: |1| n bits | m bits | p bits | 63-n-m-p| +-+-------------------+---------------------+-----------+---------+ |C| PROVIDER ID | SUBSCRIBER ID | SUBNET ID | NODE ID | +-+-------------------+---------------------+-----------+---------+ The first bit is the IPv4 compatibility bit, or C-bit. It indicates whether the node represented by the address is IPv4 or SIPP. SIPP addresses are provider-oriented. That is, the high-order part of the address is assigned to internet service providers, which then assign portions of the address space to subscribers, etc. This usage is similar to assignment of IP addresses under CIDR. The SUBSCRIBER ID distinguishes among multiple subscribers attached to the provider identified by the PROVIDER ID. The SUBNET ID identifies a topologically connected group of nodes within the subscriber network identified by the subscriber prefix. The NODE ID identifies a single node among the group of nodes identified by the subnet prefix. 4.3.1.2 Local-Use Address A local-use address is a unicast address that has only local routability scope (within the subnet or within a subscriber network), and may have local or global uniqueness scope. They are intended for use inside of a site for "plug and play" local communication, for bootstrapping up to a single global addresses, and as part of an address sequence for global communication. Their format is: | 4 | |bits| 12 bits | 48 bits | +----+---------------+--------------------------------------------+ |0110| SUBNET ID | NODE ID | +----+---------------+--------------------------------------------+ The NODE ID is an identifier which much be unique in the domain in which it is being used. In most cases these will use a node's IEEE- 802 48bit address. The SUBNET ID identifies a specific subnet in a site. The combination of the SUBNET ID and the NODE ID to form a local use address allows a large private internet to be constructed without any other address allocation. Local-use addresses have two primary benefits. First, for sites or organizations that are not (yet) connected to the global Internet, there is no need to request an address prefix from the global Hinden [Page 11]
RFC 1710 SIPP IPng White Paper October 1994 Internet address space. Local-use addresses can be used instead. If the organization connects to the global Internet, it can use it's local use addresses to communicate with a server (e.g., using the Dynamic Host Configuration Protocol [DHCP]) to have a global address automatically assigned. The second benefit of local-use addresses is that they can hold much larger NODE IDs, which makes possible a very simple form of auto- configuration of addresses. In particular, a node may discover a SUBNET ID by listening to a Router Advertisement messages on its attached link(s), and then fabricating a SIPP address for itself by using its link-level address as the NODE ID on that subnet. An auto-configured local-use address may be used by a node as its own identification for communication within the local domain, possibly including communication with a local address server to obtain a global SIPP address. The details of host auto-configuration are described in [DHCP]. 4.3.1.3 IPv4-Only Addresses SIPP unicast addresses are assigned to IPv4-only hosts as part of the IPAE scheme for transition from IPv4 to SIPP. Such addresses have the following form: |1| 31 bits | 32 bits | +-+------------------------------+--------------------------------+ |1| HIGHER-ORDER SIPP PREFIX | IPv4 ADDRESS | +-+------------------------------+--------------------------------+ The highest-order bit of a SIPP address is called the IPv4 compatibility bit or the C bit. A C bit value of 1 identifies an address as belonging to an IPv4-only node. The IPv4 node's 32-bit IPv4 address is carried in the low-order 32 bits of the SIPP address. The remaining 31 bits are used to carry HIGHER- ORDER SIPP PREFIX, such as a service-provider ID. 4.3.2 Cluster Addresses Cluster addresses are unicast addresses that are used to reach the "nearest" one (according to unicast routing's notion of nearest) of the set of boundary routers of a cluster of nodes identified by a common prefix in the SIPP unicast routing hierarchy. These are used to identify a set of nodes. The cluster address, when used as part of an address sequence, permits a node to select which of several providers it wants to carry its traffic. A cluster address can only be used as a destination address. In this example there would be a Hinden [Page 12]
RFC 1710 SIPP IPng White Paper October 1994 cluster address for each provider. This capability is sometimes called "source selected policies". Cluster addresses have the general form: | n bits | 64-n bits | +---------------------------------+-------------------------------+ | CLUSTER PREFIX |0000000000000000000000000000000| +---------------------------------+-------------------------------+ 4.3.3 Multicast Addresses A SIPP multicast address is an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses have the following format: |1| 7 | 4 | 4 | 48 bits | +-+-------+----+----+---------------------------------------------+ |C|1111111|FLGS|SCOP| GROUP ID | +-+-------+----+----+---------------------------------------------+ Where: C = IPv4 compatibility bit. 1111111 in the rest of the first octet identifies the address as being a multicast address. +-+-+-+-+ FLGS is a set of 4 flags: |0|0|0|T| +-+-+-+-+ The high-order 3 flags are reserved, and must be initialized to 0. T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the global internet numbering authority. T = 1 indicates a non-permanently-assigned ("transient") multicast address. SCOP is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 reserved 8 intra-organization scope 1 intra-node scope 9 (unassigned) 2 intra-link scope 10 (unassigned) 3 (unassigned) 11 intra-community scope 4 (unassigned) 12 (unassigned) Hinden [Page 13]
RFC 1710 SIPP IPng White Paper October 1994 5 intra-site scope 13 (unassigned) 6 (unassigned) 14 global scope 7 (unassigned) 15 reserved GROUP ID identifies the multicast group, either permanent or transient, within the given scope. 4.4 SIPP Routing Routing in SIPP is almost identical to IPv4 routing under CIDR except that the addresses are 64-bit SIPP addresses instead of 32-bit IPv4 addresses. This is true even when extended addresses are being used. With very straightforward extensions, all of IPv4's routing algorithms (OSPF, BGP, RIP, IDRP, etc.) can used to route SIPP [OSPF] [RIP2] [IDRP]. SIPP also includes simple routing extensions which support powerful new routing functionality. These capabilities include: Provider Selection (based on policy, performance, cost, etc.) Host Mobility (route to current location) Auto-Readdressing (route to new address) Extended Addressing (route to "sub-cloud") The new routing functionality is obtained by creating sequences of SIPP addresses using the SIPP Routing option. The routing option is used by a SIPP source to list one or more intermediate nodes (or topological clusters) to be "visited" on the way to a packet's destination. This function is very similar in function to IPv4's Loose Source and Record Route option. A node would publish its address sequence in the Domain Name System [DNS]. The identification of a specific transport connection is done by only using the first (source) and last (destination) address in the sequence. These identifying addresses (i.e., first and last addresses of a route sequence) are required to be unique within the scope over which they are used. This permits the middle addresses in the address sequence to change (in the cases of mobility, provider changes, site readdressing, etc.) without disrupting the transport connection. In order to make address sequences a general function, SIPP hosts are required to reverse routes in a packet it receives containing address sequences in order to return the packet to its originator. This approach is taken to make SIPP host implementations from the start support the handling and reversal of source routes. This is the key for allowing them to work with hosts which implement the new features such as provider selection or extended addresses. Hinden [Page 14]
RFC 1710 SIPP IPng White Paper October 1994 Three examples show how the extended addressing can be used. In these examples, address sequences are shown by a list of individual addresses separated by commas. For example: SRC, I1, I2, I3, DST Where the first address is the source address, the last address is the destination address, and the middle addresses are intermediate addresses. For these examples assume that two hosts, H1 and H2 wish to communicate. Assume that H1 and H2's sites are both connected to providers P1 and P2. A third wireless provider, PR, is connected to both providers P1 and P2. ----- P1 ------ / | \ / | \ H1 PR H2 \ | / \ | / ----- P2 ------ The simplest case (no use of address sequences) is when H1 wants to send a packet to H2 containing the addresses: H1, H2 When H2 replied it would reverse the addresses and construct a packet containing the addresses: H2, H1 In this example either provider could be used, and H1 and H2 would not be able to select which provider traffic would be sent to and received from. If H1 decides that it wants to enforce a policy that all communication to/from H2 can only use provider P1, it would construct a packet containing the address sequence: H1, P1, H2 This ensures that when H2 replies to H1, it will reverse the route and the reply it would also travel over P1. The addresses in H2's reply would look like: H2, P1, H1 Hinden [Page 15]
RFC 1710 SIPP IPng White Paper October 1994 If H1 became mobile and moved to provider PR, it could maintain (not breaking any transport connections) communication with H2, by sending packets that contain the address sequence: H1, PR, P1, H2 This would ensure that when H2 replied it would enforce H1's policy of exclusive use of provider P1 and send the packet to H1 new location on provider PR. The reversed address sequence would be: H2, P1, PR, H1 The address extension facility of SIPP can be used for provider selection, mobility, readdressing, and extended addressing. It is a simple but powerful capability. 4.5 SIPP Quality-of-Service Capabilities The Flow Label field in the SIPP header may be used by a host to label those packets for which it requests special handling by SIPP routers, such as non-default quality of service or "real-time" service. This labeling is important in order to support applications which require some degree of consistent throughput, delay, and/or jitter. The Flow Label is a 28-bit field, internally structured into three subfields as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| DP | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (Reserved) 1-bit subfield. Initialized to zero for transmission; Ignored on reception. DP (Drop Priority) 3-bit unsigned integer. Specifies the priority of the packet, relative to other packets from the same source, for being discarded by a router under conditions of congestion. Larger values indicates a greater willingness by the sender to allow the packet to be discarded. Flow ID 24-bit subfield used to identify a specific flow. A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. There may be multiple active flows from a source to a destination, as well as Hinden [Page 16]
RFC 1710 SIPP IPng White Paper October 1994 traffic that is not associated with any flow. A flow is identified by the combination of a Source Address and a non-zero Flow ID. Packets that do not belong to a flow carry a Flow ID of zero. A Flow ID is assigned to a flow by the flow's source node. New Flow IDs must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow ID suitable for use as a hash key by the routers, for looking up the special-handling state associated with the flow. A Flow ID must not be re-used by a source for a new flow while any state associated with the previous usage still exists in any router. The Drop Priority subfield provides a means separate from the Flow ID for distinguishing among packets from the same source, to allow a source to specify which of its packets are to be discarded in preference to others when a router cannot forward them all. This is useful for applications like video where it is preferable to drop packets carrying screen updates rather than the packets carrying the video synchronization information. 4.6 SIPP Security The current Internet has a number of security problems and lacks effective privacy and authentication mechanisms below the application layer. SIPP remedies these shortcomings by having two integrated options that provide security services. These two options may be used singly or together to provide differing levels of security to different users. This is very important because different user communities have different security needs. The first mechanism, called the "SIPP Authentication Header", is an option which provides authentication and integrity (without confidentiality) to SIPP datagrams. While the option is algorithm- independent and will support many different authentication techniques, the use of keyed MD5 is proposed to help ensure interoperability within the worldwide Internet. This can be used to eliminate a significant class of network attacks, including host masquerading attacks. The use of the SIPP Authentication Header is particularly important when source routing is used with SIPP because of the known risks in IP source routing. Its placement at the internet layer can help provide host origin authentication to those upper layer protocols and services that currently lack meaningful protections. This mechanism should be exportable by vendors in the United States and other countries with similar export restrictions because it only provides authentication and integrity, and specifically does not provide confidentiality. The exportability of the SIPP Authentication Header encourages its widespread Hinden [Page 17]
RFC 1710 SIPP IPng White Paper October 1994 implementation and use. The second security option provided with SIPP is the "SIPP Encapsulating Security Header". This mechanism provides integrity and confidentiality to SIPP datagrams. It is simpler than some similar security protocols (e.g., SP3D, ISO NLSP) but remains flexible and algorithm-independent. To achieve interoperability within the global Internet, the use of DES CBC is proposed as the standard algorithm for use with the SIPP Encapsulating Security Header. 5. SIPP Transition Mechanisms The two key motivations in the SIPP transition mechanisms are to provide direct interoperability between IPv4 and SIPP hosts and to allow the user population to adopt SIPP in an a highly diffuse fashion. The transition must be incremental, with few or no critical interdependencies, if it is to succeed. The SIPP transition allows the users to upgrade their hosts to SIPP, and the network operators to deploy SIPP in routers, with very little coordination between the two. The mechanisms and policies of the SIPP transition are called "IPAE". Having a separate term serves to highlight those features designed specifically for transition. Once an acronym for an encapsulation technique to facilitate transition, the term "IPAE" now is mostly historical. The IPAE transition is based on five key elements: 1) A 64-bit SIPP addressing plan that encompasses the existing 32-bit IPv4 addressing plan. The 64-bit plan will be used to assign addresses for both SIPP and IPv4 nodes at the beginning of the transition. Existing IPv4 nodes will not need to change their addresses, and IPv4 hosts being upgraded to SIPP keep their existing IPv4 addresses as the low-order 32 bits of their SIPP addresses. Since the SIPP addressing plan is a superset of the existing IPv4 plan, SIPP hosts are assigned only a single 64-bit address, which can be used to communicate with both SIPP and IPv4 hosts. 2) A mechanism for encapsulating SIPP traffic within IPv4 packets so that the IPv4 infrastructure can be leveraged early in the transition. Most of the "SIPP within IPv4 tunnels" can be automatically configured. Hinden [Page 18]
RFC 1710 SIPP IPng White Paper October 1994 3) Algorithms in SIPP hosts that allow them to directly interoperate with IPv4 hosts located on the same subnet and elsewhere in the Internet. 4) A mechanism for translating between IPv4 and SIPP headers to allow SIPP-only hosts to communicate with IPv4-only hosts and to facilitate IPv4 hosts communicating over over a SIPP-only backbone. 5) An optional mechanism for mapping IPv4 addresses to SIPP address to allow improved scaling of IPv4 routing. At the present time given the success of CIDR, this does not look like it will be needed in a transition to SIPP. If Internet growth should continue beyond what CIDR can handle, it is available as an optional mechanism. IPAE ensures that SIPP hosts can interoperate with IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses run out, and afterward allows SIPP and IPv4 hosts within a limited scope to interoperate indefinitely. This feature protects for a very long time the huge investment users have made in IPv4. Hosts that need only a limited connectivity range (e.g., printers) need never be upgraded to SIPP. This feature also allows SIPP-only hosts to interoperate with IPv4-only hosts. The incremental upgrade features of IPAE allow the host and router vendors to integrate SIPP into their product lines at their own pace, and allows the end users and network operators to deploy SIPP on their own schedules. The interoperability between SIPP and IPv4 provided by IPAE also has the benefit of extending the lifetime of IPv4 hosts. Given the large installed base of IPv4, changes to IPv4 in hosts are nearly impossible. Once an IPng is chosen, most of the new feature development will be done on IPng. New features in IPng will increase the incentives to adopt and deploy it. 6. Why SIPP? There are a number of reasons why SIPP should be selected as the IETF's IPng. It solves the Internet scaling problem, provides a flexible transition mechanism for the current Internet, and was designed to meet the needs of new markets such as nomadic personal computing devices, networked entertainment, and device control. It does this in a evolutionary way which reduces the risk of architectural problems. Hinden [Page 19]
RFC 1710 SIPP IPng White Paper October 1994 Ease of transition is a key point in the design of SIPP. It is not something was was added in at the end. SIPP is designed to interoperate with IPv4. Specific mechanisms (C-bit, embedded IPv4 addresses, etc.) were built into SIPP to support transition and compatability with IPv4. It was designed to permit a gradual and piecemeal deployment without any dependencies. SIPP supports large hierarchical addresses which will allow the Internet to continue to grow and provide new routing capabilities not built into IPv4. It has cluster addresses which can be used for policy route selection and has scoped multicast addresses which provide improved scaleability over IPv4 multicast. It also has local use addresses which provide the ability for "plug and play" installation. SIPP is designed to have performance better than IPv4 and work well in low bandwidth applications like wireless. Its headers are less expensive to process than IPv4 and its 64-bit addresses are chosen to be well matched to the new generation of 64bit processors. Its compact header minimizes bandwidth overhead which makes it ideal for wireless use. SIPP provides a platform for new Internet functionality. This includes support for real-time flows, provider selection, host mobility, end-to- end security, auto-configuration, and auto- reconfiguration. In summary, SIPP is a new version of IP. It can be installed as a normal software upgrade in internet devices. It is interoperable with the current IPv4. Its deployment strategy was designed to not have any "flag" days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future. Hinden [Page 20]
RFC 1710 SIPP IPng White Paper October 19947. Status of SIPP Effort There are many active participants in the SIPP working group. Groups making active contributions include: Group Activity --------------------- ---------------------------------------- Beame & Whiteside Implementation (PC) Bellcore Implementation (SunOS), DNS and ICMP specs. Digital Equipment Corp. Implementation (Alpha/OSF, Open VMS) INRIA Implementation (BSD, BIND), DNS & OSPF specs. INESC Implementation (BSD/Mach/x-kernel) Intercon Implementation (MAC) MCI Phone Conferences Merit IDRP for SIPP Specification Naval Research Lab. Implementation (BSD) Security Design Network General Implementation (Sniffer) SGI Implementation (IRIX, NetVisulizer) Sun Implementation (Solaris 2.x, Snoop) TGV Implementation (Open VMS) Xerox PARC Protocol Design Bill Simpson Implementation (KA9Q) As of the time this paper was written there were a number of SIPP and IPAE implementations. These include: Implementation Status -------------- ------------------------------------ BSD/Mach Completed (telnet, NFS, AFS, UDP) BSD/Net/2 In Progress Bind Code done DOS &Windows Completed (telnet, ftp, tftp, ping) IRIX In progress (ping) KA9Q In progress (ping, TCP) Mac OS Completed (telnet, ftp, finger, ping) NetVisualizer Completed (SIP & IPAE) Open VMS Completed (telnet, ftp), In Progress OSF/1 In Progress (ping, ICMP) Sniffer Completed (SIP & IPAE) Snoop Completed (SIP & IPAE) Solaris Completed (telnet, ftp, tftp, ping) Sun OS In Progress Hinden [Page 21]
RFC 1710 SIPP IPng White Paper October 19948. Where to Get Additional Information The documentation listed in the reference sections can be found in one of the IETF internet draft directories or in the archive site for the SIPP working group. This is located at: ftp.parc.xerox.com in the /pub/sipp directory. In addition other material relating to SIPP (such as postscript versions of presentations on SIPP) can also be found in the SIPP working group archive. To join the SIPP working group, send electronic mail to sipp-request@sunroof.eng.sun.com An archive of mail sent to this mailing list can be found in the IETF directories at cnri.reston.va.us. 9. Security Considerations Security issues are discussed in section 4.6. 10. Author's Address Robert M. Hinden Manager, Internet Engineering Sun Microsystems, Inc. MS MTV5-44 2550 Garcia Ave. Mt. View, CA 94303 Phone: (415) 336-2082 Fax: (415) 336-6016 EMail: hinden@eng.sun.com 11. References [ADDR] Francis, P., "Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment", Work in Progress, January 1994. [AUTH] Atkinson, R., "SIPP Authentication Payload", Work in Progress, January, 1994. [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992. Hinden [Page 22]
RFC 1710 SIPP IPng White Paper October 1994 [DISC] Simpson, W., "SIPP Neighbor Discovery", Work in Progress, March 1994. [DIS2] Simpson, W., "SIPP Neighbor Discovery -- ICMP Message Formats", Work in Progress, March 1994. [DHCP] Thomson, S., "Simple Internet Protocol Plus (SIPP): Automatic Host Address Assignment", Work in Progress, March 1994. [DNS] Thomson, S., and C. Huitema, "DNS Extensions to Support Simple Internet Protocol Plus (SIPP)", Work in Progress, March 1994. [ICMP] Govindan, R., and S. Deering, "ICMP and IGMP for the Simple Internet Protocol Plus (SIPP)", Work in Progress, March 1994. [IDRP] Hares, S., "IDRP for SIP", Work in Progress, November 1993. [IPAE] Gilligan, R., et al, "IPAE: The SIPP Interoperability and Transition Mechanism", Work in Progress, March 1994. [IPV4] Postel, J., "Internet Protocol- DARPA Internet Program Protocol Specification", STD 5, RFC 791, DARPA, September 1981. [OSPF] Francis, P., "OSPF for SIPP", Work in Progress, February 1994. [RIP2] Malkin, G., and C. Huitema, "SIP-RIP", Work in Progress, March 1993. [ROUT] Deering, S., et al, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Work in Progress, February 1994. [SARC] Atkinson, R., "SIPP Security Architecture", Work in Progress, January 1994. [SECR] Atkinson, R., "SIPP Encapsulating Security Payload (ESP)", Work in Progress, January 1994. [SIPP] Deering, S., "Simple Internet Protocol Plus (SIPP) Specification", Work in Progress, February 1994. Hinden [Page 23]
Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/
Categories: 1

0 Replies to “Internet Protocol Header Format For Essay”

Leave a comment

L'indirizzo email non verrĂ  pubblicato. I campi obbligatori sono contrassegnati *