will complicate the use of datagrams in some cases
* configuration ease - IPng will have easy and flexible address
autoconfiguration which will support a wide variety of environments
from nodes on an isolated network to nodes deep in a complex
internet
* security - IPng includes specific mechanisms for authentication and
encryption at the internetwork layer; the security features do rely
on the presence of a yet to be defined key management system
* unique names - IPng addresses may be used as globally unique names
although they do have topological significance
* access to standards - all of the IPng standards will be published
as RFCs with unlimited distribution
* multicast support - IPng specifically includes multicast support
* extensibility - the use of extension headers and an expandable
header option feature will allow the introduction of new features
into IPng when needed in a way that minimizes the disruption of the
existing network
* service classes - the IPng header includes a Flow Label which may
be used to differentiate requested service classes
* mobility - the proposed IPv4 mobility functions will work with IPng
* control protocol - IPng includes the familiar IPv4 control protocol
features
* tunneling support - encapsulation of IPng or other protocols within
IPng is a basic capability described in the IPng specifications
11.2 IPv6
The IANA has assigned version number 6 to IPng. The protocol itself
will be called IPv6.
The remainder of this memo is used to describe IPv6 and its features.
This description is an overview snapshot. The standards documents
themselves should be referenced for definitive specifications. We
also make a number of specific recommendations concerning the details
of the proposed protocol, the procedures required to complete the
definition of the protocol, and the IETF working groups we feel are
necessary to accomplish the task.
12. IPv6 Overview
IPv6 is a new version of the Internet Protocol, it has been designed
as an evolutionary, rather than revolutionary, step from IPv4.
Functions which are generally seen as working in IPv4 were kept in
IPv6. Functions which don't work or are infrequently used were
removed or made optional. A few new features were added where the
functionality was felt to be necessary.
The important features of IPv6 include: [Hinden94c]
* expanded addressing and routing capabilities - The IP address size
is increased from 32 bits to 128 bits providing support for a much
greater number of addressable nodes, more levels of addressing
hierarchy, and simpler auto-configuration of addresses.
The scaleability of multicast routing is improved by adding a
"scope" field to multicast addresses.
A new type of address, called a "cluster address" is defined to
identify topological regions rather than individual nodes. The use
of cluster addresses in conjunction with the IPv6 source route
capability allows nodes additional control over the path their
traffic takes.
* simplified header format - 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 overhead of the IPv6
header as low as possible in spite of the increased size of the
addresses. Even though the IPv6 addresses are four time longer
than the IPv4 addresses, the IPv6 header is only twice the size of
the IPv4 header.
* support for extension headers and options - IPv6 options are placed
in separate headers that are located in the packet between the IPv6
header and the transport-layer header. Since most IPv6 option
headers are not examined or processed by any router along a
packet's delivery path until it arrives at its final destination,
this organization facilitates a major improvement in router
performance for packets containing options. Another improvement is
that unlike IPv4, IPv6 options can be of arbitrary length and not
limited to 40 bytes. This feature plus the manner in which they are
processed, permits IPv6 options to be used for functions which were
not practical in IPv4.
A key extensibility feature of IPv6 is the ability to encode,
within an option, the action which a router or host should perform
if the option is unknown. This permits the incremental deployment
of additional functionality into an operational network with a
minimal danger of disruption.
* support for authentication and privacy - IPv6 includes the
definition of an extension which provides support for
authentication and data integrity. This extension is included as a
basic element of IPv6 and support for it will be required in all
implementations.
IPv6 also includes the definition of an extension to support
confidentiality by means of encryption. Support for this extension
will be strongly encouraged in all implementations.
* support for autoconfiguration - IPv6 supports multiple forms of
autoconfiguration, from "plug and play" configuration of node
addresses on an isolated network to the full-featured facilities
offered by DHCP.
* support for source routes - IPv6 includes an extended function
source routing header designed to support the Source Demand Routing
Protocol (SDRP). The purpose of SDRP is to support source-initiated
selection of routes to complement the route selection provided by
existing routing protocols for both inter-domain and intra-domain
routes. [Estrin94b]
* simple and flexible transition from IPv4 - The IPv6 transition plan
is aimed at meeting four basic requirements: [Gillig94a]
- Incremental upgrade. Existing installed IPv4 hosts and routers
may be upgraded to IPv6 at any time without being dependent on
any other hosts or routers being upgraded.
- Incremental deployment. New IPv6 hosts and routers can be
installed at any time without any prerequisites.
- Easy Addressing. When existing installed IPv4 hosts or routers
are upgraded to IPv6, they may continue to use their existing
address. They do not need to be assigned new addresses.
- Low start-up costs. Little or no preparation work is needed in
order to upgrade existing IPv4 systems to IPv6, or to deploy new
IPv6 systems.
* quality of service capabilities - A new capability is added to
enable the labeling of packets belonging to particular traffic
"flows" for which the sender has requested special handling, such
as non-default quality of service or "real-time" service.
12.1 IPv6 Header Format
The IPv6 header, although longer than the IPv4 header, is
considerably simplified. A number of functions that were in the IPv4
header have been relocated in extension headers or dropped.
[Deering94b]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Version - Internet Protocol version number. IPng has been assigned
version number 6. (4-bit field)
* Flow Label - This field may be used by a host to label those
packets for which it is requesting special handling by routers
within a network, such as non-default quality of service or "real-
time" service. (28-bit field)
* Payload Length - Length of the remainder of the packet following
the IPv6 header, in octets. To permit payloads of greater than 64K
bytes, if the value in this field is 0 the actual packet length
will be found in an Hop-by-Hop option. (16-bit unsigned integer)
* Next Header - Identifies the type of header immediately following
the IPv6 header. The Next Header field uses the same values as the
IPv4 Protocol field (8-bit selector field)
* Hop Limit - Used to limit the impact of routing loops. The Hop
Limit field is decremented by 1 by each node that forwards the
packet. The packet is discarded if Hop Limit is decremented to
zero. (8-bit unsigned integer)
* Source Address - An address of the initial sender of the packet.
(128 bit field)
* Destination Address - An address of the intended recipient of the
packet (possibly not the ultimate recipient, if an optional Routing
Header is present). (128 bit field)
12.2 Extension Headers
In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the
transport-layer header in a packet. There are a small number of such
extension headers, each identified by a distinct Next Header value.
[From a number of the documents listed in Appendix C.]
12.2.1 Hop-by-Hop Option Header
The Hop-by-Hop Options header is used to carry optional
information that must be examined by every node along a packet's
delivery path. The Hop-by-Hop Options header is identified by a
Next Header value of 0 in the IPv6 header, and has the following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Hop-by-Hop Options header. Uses the same values
as the IPv4 Protocol field. (8-bit selector)
* Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet
units, not including the first 8 octets. (8-bit unsigned
integer)
* Options - Contains one or more TLV-encoded options. (Variable-
length field, of length such that the complete Hop-by-Hop
Options header is an integer multiple of 8 octets long.)
12.2.2 IPv6 Header Options
Two of the currently-defined extension headers -- the Hop-by-Hop
Options header and the End-to-End Options header -- may carry a
variable number of Type-Length-Value (TLV) encoded "options", of
the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
* Option Type - identifier of the type of option (8-bit field)
* Opt Data Len - Length of the Option Data field of this option,
in octets. (8-bit unsigned integer)
* Option Data - Option-Type-specific data. (Variable-length field)
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if
the processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header
01 - discard the packet
10 - discard the packet and send an ICMP Unrecognized Type message
to the packet's Source Address, pointing to the unrecognized
Option Type
11 - undefined.
In the case of Hop-by-Hop options only, the third-highest-order
bit of the Option Type specifies whether or not the Option Data of
this option shall be included in the integrity assurance
computation performed when an Authentication header is present.
Option data that changes en route must be excluded from that
computation.
12.2.3 Routing Header
The Routing header is used by an IPv6 source to list one or more
intermediate nodes (or topological clusters) to be "visited" on
the way to a packet's destination. This particular form of the
Routing Header is designed to support SDRP. [Estrin94b]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |Routing Type=1 |M|F| Reserved | SrcRouteLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NextHopPtr | Strict/Loose Bit Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Source Route .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Routing Header. Uses the same values as the IPv4
Protocol field. (8-bit selector)
* Routing Type - Indicates the type of routing supported by this
header. Value must be 1.
* MRE flag - Must Report Errors. If this bit is set to 1, and a
router can not further forward a packet (with an incompletely
traversed source route), as specified in the Source Route, the
router must generate an ICMP error message. If this bit is set
to 0, and a router can not further forward a packet (with an
incompletely traversed source route), as specified in the Source
Route, the router should not generate an ICMP error message.
* F flag - Failure of Source Route Behavior. If this bit it set
to 1, it indicates that if a router can not further forward a
packet (with an incompletely traversed source route), as
specified in the Source Route, the router must set the value of
the Next Hop Pointer field to the value of the Source Route
Length field, so that the subsequent forwarding will be based
solely on the destination address. If this bit is set to 0, it
indicates that if a router can not further forward a packet
(with an incompletely traversed source route), as specified in
the Source Route, the router must discard the packet.
* Reserved - Initialized to zero for transmission; ignored on
reception.
* SrcRouteLen - Source Route Length - Number of source route
elements/hops in the SDRP Routing header. Length of SDRP
routing header can be calculated from this value (length =
SrcRouteLen * 16 + 8) This field may not exceed a value of 24.
(8 bit unsigned integer)
* NextHopPtr - Next Hop Pointer- Index of next element/hop to be
processed; initialized to 0 to point to first element/hop in the
source route. When Next Hop Pointer is equal to Source Route
Length then the Source Route is completed. (8 bit unsigned
integer)
* Strict/Loose Bit Mask - The Strict/Loose Bit Mask is used when
making a forwarding decision. If the value of the Next Hop
Pointer field is N, and the N-th bit in the Strict/Loose Bit
Mask field is set to 1, it indicates that the next hop is a
Strict Source Route Hop. If this bit is set to 0, it indicates
that the next hop is a Loose Source Route Hop. (24 bit
bitpattern)
* Source Route - A list of IPv6 addresses indicating the path that
this packet should follow. A Source Route can contain an
arbitrary intermix of unicast and cluster addresses. (integral
multiple of 128 bits)
12.2.4 Fragment Header
The Fragment header is used by an IPv6 source to send payloads
larger than would fit in the path MTU to their destinations.
(Note: unlike IPv4, fragmentation in IPv6 is performed only by
source nodes, not by routers along a packet's delivery path) The
Fragment header is identified by a Next Header value of 44 in the
immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Fragment header. Uses the same values as the IPv4
Protocol field. (8 bit selector)
* Reserved, Res - Initialized to zero for transmission; ignored on
reception.
* Fragment Offset - The offset, in 8-octet units, of the following
payload, relative to the start of the original, unfragmented
payload. (13-bit unsigned integer)
* M flag - 1 = more fragments; 0 = last fragment.
* Identification - A value assigned to the original payload that
is different than that of any other fragmented payload sent
recently with the same IPv6 Source Address, IPv6 Destination
Address, and Fragment Next Header value. (If a Routing header
is present, the IPv6 Destination Address is that of the final
destination.) The Identification value is carried in the
Fragment header of all of the original payload's fragments, and
is used by the destination to identify all fragments belonging
to the same original payload. (32 bit field)
12.2.5 Authentication Header
The Authentication header is used to provide authentication and
integrity assurance for IPv6 packets. Non-repudiation may be
provided by an authentication algorithm used with the
Authentication header, but it is not provided with all
authentication algorithms that might be used with this header.
The Authentication header is identified by a Next Header value of
51 in the immediately preceding header, and has the following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Auth Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Authentication Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Authentication header. Uses the same values as
the IPv4 Protocol field. (8-bit selector)
* Auth Data Len - Length of the Authentication Data field in 8-
octet units. (8-bit unsigned integer)
* Reserved - Initialized to zero for transmission; ignored on
reception.
* Security Assoc. ID - When combined with the IPv6 Source Address,
identifies to the receiver(s) the pre-established security
association to which this packet belongs. (32 bit field)
* Authentication Data - Algorithm-specific information required
to authenticate the source of the packet and assure its
integrity, as specified for the pre-established security
association. (Variable-length field, an integer multiple of 8
octets long.)
12.2.6 Privacy Header
The Privacy Header seeks to provide confidentiality and integrity
by encrypting data to be protected and placing the encrypted data
in the data portion of the Privacy Header. Either a transport-
layer (e.g., UDP or TCP) frame may be encrypted or an entire IPv6
datagram may be encrypted, depending on the user's security
requirements. This encapsulating approach is necessary to provide
confidentiality for the entire original datagram. If present, the
Privacy Header is always the last non-encrypted field in a packet.
The Privacy Header works between hosts, between a host and a
security gateway, or between security gateways. This support for
security gateways permits trustworthy networks to exist without
the performance and monetary costs of security, while providing
security for traffic transiting untrustworthy network segments.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association Identifier (SAID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Initialization Vector .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header* | Length* | Reserved* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Protected Data* +-+-+-+-+-+-+-+-+-+-+
| | trailer* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*encrypted
* Security Association Identifier (SAID) - Identifies the security
association for this datagram. If no security association has
been established, the value of this field shall be 0x0000. A
security association is normally one-way. An authenticated
communications session between two hosts will normally have two
SAIDs in use (one in each direction). The receiving host uses
the combination of SAID value and originating address to
distinguish the correct association. (32 bit value)
* Initialization Vector - This field is optional and its value
depends on the SAID in use. For example, the field may contain
cryptographic synchronization data for a block oriented
encryption algorithm. It may also be used to contain a
cryptographic initialization vector. A Privacy Header
implementation will normally use the SAID value to determine
whether this field is present and, if it is, the field's size
and use. (presence and length dependent on SAID)
* Next Header - encrypted - Identifies the type of header
immediately following the Privacy header. Uses the same values
as the IPv4 Protocol field. (8 bit selector)
* Reserved - encrypted - Ignored on reception.
* Length - encrypted - Length of the Privacy Header in 8-octet
units, not including the first 8 octets. (8-bit unsigned
integer)
* Protected Data - encrypted - This field may contain an entire
encapsulated IPv6 datagram, including the IPv6 header, a
sequence of zero or more IPv6 options, and a transport-layer
payload, or it may just be a sequence of zero or more IPv6
options followed by a transport-layer payload. (variable
length)
* trailer (Algorithm-dependent Trailer) - encrypted - A field
present to support some algorithms which need to have padding
(e.g., to a full cryptographic block size for block-oriented
encryption algorithms) or for storage of authentication data for
use with a encryption algorithm that provides confidentiality
without authentication. It is present only when the algorithm
in use requires such a field. (presence and length dependent on
SAID)
12.2.7 End-to-End Option Header
The End-to-End Options header is used to carry optional
information that needs to be examined only by a packet's
destination node(s). The End-to-End Options header is identified
by a Next Header value of TBD in the immediately preceding header,
and has the same format as the Hop-by-Hop Option Header except for
the ability to exclude an option from the authentication integrity
assurance computation.
13. IPng Working Group
We recommend that a new IPng Working Group be formed to produce
specifications for the core functionality of the IPv6 protocol suite.
The working group will carry out the recommendations of the IPng Area
Directors as outlined at the July 1994 IETF and in this memo. We
recommend that this working group be chaired by Steve Deering of
Xerox PARC and Ross Callon of Wellfleet.
The primary task of the working group is to produce a set of
documents that define the basic functions, interactions, assumptions,
and packet formats for IPv6. We recommend that Robert Hinden of Sun
Microsystems be the editor for these documents. The documents listed
in Appendix C will be used by the working group to form the basis of
the final document set.
The work of the IPng Working Group includes:
* complete the IPv6 overview document
* complete the IPv6 detailed operational specification
* complete the IPv6 Addressing Architecture specification
* produce specifications for IPv6 encapsulations over various media
* complete specifications for the support of packets larger than 64KB
* complete specifications of the DNS enhancements required to support
IPv6
* complete specification of ICMP, IGMP and router discovery for
support of IPv6.
* complete specification of path MTU discovery for IPv6
* complete specifications of IPv6 in IPv6 tunneling
* complete the suggested address format and assignment plan
* coordinate with the Address Autoconfiguration Working Group
* coordinate with the NGTRANS and TACIT Working Groups
* complete specifications of authentication and privacy support
headers
The working group should also consider a few selected enhancements
including:
* consider ways to compress the IPv6 header in the contexts of native
IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6
* consider specifying support for a larger minimum MTU
14. IPng Reviewer
Currently it is the task of the IPng Area Directors, the IPng
Directorate and the chairs of the proposed ipng working group to
coordinate the activities of the many parallel efforts currently
directed towards different aspects of IPng. While this is possible
and currently seems to be working well it can not be maintained over
the long run because, among other reasons, the IPng Area will be
dissolved eventually and its Directorate disbanded. It will also
become much more difficult as IPng related activities start up in
other IETF areas.
We recommend that an IPng Reviewer be appointed to be specifically
responsible for ensuring that a consistent view of IPv6 is maintained
across the related working groups. We feel that this function is
required due to the complex nature of the interactions between the
parts of the IPng effort and due to the distribution of the IPng
related work amongst a number of IETF areas. We recommend that Dave
Clark of MIT be offered this appointment.
This would be a long-term task involving the review of on-going
activities. The aim is not for the IPng Reviewer to make
architectural decisions since that is the work of the various working
groups, the IAB, and the IETF as a whole.. The aim is to spot gaps or
misunderstandings before they reach the point where functionality or
interworkability is threatened.
15. Address Autoconfiguration
As data networks become more complex the need to be able to bypass at
least some of the complexity and move towards "plug and play" becomes
ever more acute. The user can not be expected to be able to
understand the details of the network architecture or know how to
configure the network software in their host. In the ideal case, a
user should be able to unpack a new computer, plug it into the local
network and "just" have it work without requiring the entering of any
special information. Security concerns may restrict the ability to
offer this level of transparent address autoconfiguration in some
environments but the mechanisms must be in place to support whatever
level of automation which the local environment feels comfortable
with.
The basic requirement of "plug and play" operation is that a host
must be able to acquire an address dynamically, either when attaching
to a network for the first time or when the host needs to be
readdressed because the host moved or because the identity of the
network has changed. There are many other functions required to
support a full "plug and play" environment. [Berk94] Most of these
must be addressed outside of the IPv6 Area but a focused effort to
define a host address autoconfiguration protocol is part of the IPv6
process.
We recommend that a new Address Autoconfiguration Working Group
(addrconf) be formed with Dave Katz of Cisco Systems and Sue Thomson
of Bellcore as co-chairs. The purpose of this working group is to
design and specify a protocol for allocating addresses dynamically to
IPv6 hosts. The address configuration protocol must be suitable for
a wide range of network topologies, from a simple isolated network to
a sophisticated globally connected network. It should also allow for
varying levels of administrative control, from completely automated
operation to very tight oversight.
The scope of this working group is to propose a host address
autoconfiguration protocol which supports the full range of
topological and administrative environments in which IPv6 will be
used. It is the intention that, together with IPv6 system discovery,
the address autoconfiguration protocol will provide the minimal
bootstrapping information necessary to enable hosts to acquire
further configuration information (such as that provided by DHCP in
IPv4). The scope does not include router configuration or any other
host configuration functions. However, it is within the scope of the
working group to investigate and document the interactions between
this work and related functions including system discovery, DNS
autoregistration, service discovery, and broader host configuration
issues, to facilitate the smooth integration of these functions.
[Katz94a]
The working group is expected to complete its work around the end of
1994 and disband at that time. The group will use "IPv6 Address
Autoconfiguration Architecture" [Katz94b] draft document as the basis
of their work.
16. Transition
The transition of the Internet from IPv4 to IPv6 has to meet two
separate needs. There is a short term need to define specific
technologies and methods to transition IPv4 networks, including the
Internet, into IPv6 networks and an IPv6 Internet. There is also a
long term need to do broad-based operational planning for transition,
including developing methods to allow decentralized migration
strategies, understanding the ramifications of a long period of
coexistence when both protocols are part of the basic infrastructure,
developing an understanding of the type and scope of architectural
and interoperability testing that will be required to ensure a
reliable and manageable Internet in the future.
16.1 Transition - Short Term
Any IPng transition plan must take into account the realities of what
types of devices vendors will build and network managers will deploy.
The IPng transition plan must define the procedures required to
successfully implement the functions which vendors will be likely to
include in their devices. This is the case even if there are good
arguments to recommend against a particular function, header
translation for example. If products will exist it is better to have
them interoperate than not.
We recommend that a new IPng Transition (NGTRANS) Working Group be
formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co-
chairs to design the mechanisms and procedures to support the
transition of the Internet from IPv4 to IPv6 and to give advice on
what procedures and techniques are preferred.
The work of the group will fall into three areas:
* Define the processes by which the Internet will make the transition
from IPv4 to IPv6. As part of this effort, the group will produce
a document explaining to the general Internet community what
mechanisms will be employed in the transition, how the transition
will work, the assumptions about infrastructure deployment inherent
in the operation of these mechanisms, and the types of
functionality that applications developers will be able to assume
as the protocol mix changes over time.
* Define and specify the mandatory and optional mechanisms that
vendors should implement in hosts, routers, and other components of
the Internet in order for the transition to be carried out. Dual-
stack, encapsulation and header translation mechanisms must all be
defined, as well as the interaction between hosts using different
combinations of these mechanisms. The specifications produced will
be used by people implementing these IPv6 systems.
* Articulate a concrete operational plan for the Internet to make the
transition from IPv4 to IPv6. The result of this work will be a
transition plan for the Internet that network operators and
Internet subscribers can execute.
[Gillig94c]
The working group is expected to complete its work around the end of
1994 and disband at that time. The group will use the "Simple SIPP
Transition (SST)" [Gilig94a] overview document as the starting point
for its work.
16.2 Transition - Long Term
There are a number of transition related topics in addition to
defining the specific IPv4 to IPv6 mechanisms and their deployment,
operation and interaction. The ramifications and procedures of
migrating to a new technology or to a new version of an existing
technology must be fully understood.
We recommend that the Transition and Coexistence Including Testing
(TACIT) Working Group, which was started a few months ago, explore
some of the basic issues associated with the deployment of new
technology into an established Internet. The TACIT Working Group
will focus on the generic issues of transition and will not limit
itself to the upcoming transition to IPv6 because, over time,
enhancements to IPv6 (IPv6ng) will be developed and accepted. At
that point they will need to be deployed into the then existing
Internet. The TACIT Working Group will be more operationally
oriented than the NGTRANS Working Group and will continue well into
the actual IPv6 transition.
The main areas of exploration are:
* Make the transition from a currently deployed protocol to a new
protocol while accommodating heterogeneity and decentralized
management.
* Since it is often difficult or impossible to replace all legacy
systems or software, it is important to understand the
characteristics and operation of a long period of coexistence
between a new protocol and the existing protocol.
* The Internet must now be considered a utility. We are far removed
from a time when a new technology could be deployed to see if it
would work in large scale situations. Rigorous architectural and
interoperability testing must be part of the predeployment phase of
any proposed software for the Internet. Testing the scaling up
behaviors and robustness of a new protocol will offer particular
challenges. The WG should determine if there are lessons to be
learned from: OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2
transition, DECnet Phase 4 to Phase 5 planning and transition,
among others.
The TACIT Working Group will explore each of these facets of the
deployment of new technology and develop a number of documents to
help guide users and managers of affected data networks and provide
to the IETF:
* Detailed descriptions of problem areas in transition and
coexistence, both predicted, based on lessons learned, and observed
as the IPv6 process progresses.
* Recommendations for specific testing procedures.
* Recommendations for coexistence operations procedures
* Recommendations for the smoothing of decentralized transition
planning.
[Huston94]
17. Other Address Families
There are many environments in which there are one or more network
protocols already deployed or where a significant planning effort has
been undertaken to create a comprehensive network addressing plan. In
such cases there may be a temptation to integrate IPv6 into the
environment by making use of an existing addressing plan to define
all or part of the IPv6 addresses. The advantage of doing this is
that it permits unified management of address space among multiple
protocol families. The use of common addresses can help facilitate
transition from other protocols to IPv6.
If the existing addresses are globally unique and assigned with
regard to network topology this may be a reasonable idea. The IETF
should work with other organizations to develop algorithms that could
be used to map addresses between IPv6 and other environments. The
goal for any such mapping must be to provide an unambiguous 1 to 1
map between individual addresses.
Suggestions have been made to develop mapping algorithms for Novell
IPX addresses, some types of OSI NSAPs, E164 addresses and SNA
addresses. Each of these possibilities should be carefully examined
to ensure that use of such an algorithm solves more problems than it
creates. In some cases it may be better to recommend either that a
native IPng addressing plan be developed instead, or that an IPv6
address be used within the non-IP environment. [Carpen94b]
We recommend that, in conjunction with other organizations,
recommendations about the use of non-IPv6 addresses in IPv6
environments and IPv6 addresses in non-IPv6 environments be
developed.
18. Impact on Other IETF Standards
Many current IETF standards are affected by IPv6. At least 27 of the
current 51 full Internet Standards must be revised for IPv6, along
with at least 6 of the 20 Draft Standards and at least 25 of the 130
Proposed Standards. [Postel94]
In some cases the revisions consist of simple changes to the text,
for example, in a number of RFCs an IP address is referred to in
passing as a "32 bit IP address" even though IP addresses are not
directly used in the protocol being defined. All of the standards
track documents will have to be checked to see if they contain such
references.
In most of the rest of the cases revisions to the protocols,
including packet formats, will be required. In many of these cases
the address is just being carried as a data element and a revised
format with a larger field for the address will have no effect on the
functional paradigm.
In the remaining cases some facet of the operation of the protocol
will be changed as a result of IPv6. For example, the security and
source route mechanisms are fundamentally changed from IPv4 with
IPv6. Protocols and applications that relied on the IPv4
functionality will have to be redesigned or rethought to use the
equivalent function in IPv6.
In a few cases this opportunity should be used to determine if some
of the RFCs should be moved to historic, for example EGP [Mills84]
and IP over ARCNET. [Provan91]
The base IPng Working Group will address some of these, existing IETF
working groups can work on others, while new working groups must be
formed to deal with a few of them. The IPng Working Group will be
responsible for defining new versions of ICMP, ARP/RARP, and UDP. It
will also review RFC1639, "FTP Operation Over Big Address Records
(FOOBAR)" [Piscit94] and RFC1191 "Path MTU Discovery" [Mogul90]
Existing working groups will examine revisions for some of the
routing protocols: RIPv2, IS-IS, IDRP and SDRP. A new working group
may be required for OSPF.
The existing DHCP Working Group may be able to revise DHCP and
examine BOOTP.
A TCPng Working Group will be formed soon, and new working groups
will have to be formed to deal with standards such as SNMP, DNS, NTP,
NETbios, OSI over TCP, Host Requirements, and Kerberos as well as
reviewing most of the RFCs that define IP usage over various media.
In addition to the standards track RFCs mentioned above there are
many Informational and Experimental RFCs which would be affected as
well as numerous Internet Drafts (and those standards track RFCs that
we missed).
We recommend that the IESG commission a review of all standards track
RFCs to ensure that a full list of affected documents is compiled. We
recommend that the IESG charge current IETF working groups with the
task of understanding the impact of IPv6 on their proposals and,
where appropriate, revise the documents to include support for IPv6.
We recommend that the IESG charter new working groups where required
to revise other standards RFCs.
19. Impact on non-IETF standards and on products
Many products and user applications which rely on the size or
structure of IPv4 addresses will need to be modified to work with
IPv6. While the IETF can facilitate an investigation of the impacts
of IPv6 on non-IETF standards and products, the primary
responsibility for doing so resides in the other standards bodies and
the vendors.
Examples of non-IETF standards that are effected by IPv6 include the
POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun
ONC, the Andrew File System and MIT's Kerberos. Most products that
provide specialized network security including firewall-type devices
are among those that must be extended to support IPv6.
20. APIs
It is traditional to state that the IETF does not "do" APIs. While
there are many reasons for this, the one most commonly referenced is
that there are too many environments where TCP/IP is used, too many
different operating systems, programming languages, and platforms.
The feeling is that the IETF should not get involved in attempting to
define a language and operating system independent interface in the
face of such complexity.
We feel that this historical tendency for the IETF to avoid dealing
with APIs should be reexamined in the case of IPv6. We feel that in
a few specific cases the prevalence of a particular type of API is
such that a single common solution for the modifications made
necessary by IPv6 should be documented.
We recommend that Informational RFCs be solicited or developed for
these few cases. In particular, the Berkeley-style sockets
interface, the UNIX TLI and XTI interfaces, and the WINSOCK
interfaces should be targeted. A draft document exists which could
be developed into the sockets API description. [Gillig94b]
21. Future of the IPng Area and Working Groups
In our presentation at the Houston IETF meeting we stated that the
existing IPng proposal working groups would not be forced to close
down after the recommendation was made. Each of them has been
working on technologies that may have applications in addition to
their IPng proposal and these technologies should not be lost.
Since the Toronto IETF meeting the existing IPng working groups have
been returned to the Internet Area. The group members may decide to
close down the working groups or to continue some of their efforts.
The charters of the working groups must be revised if they choose to
continue since they would no longer be proposing an IPng candidate.
In Toronto the chairs of the SIPP Working Group requested that the
SIPP Working Group be concluded. The chairs of the TUBA Working
Group requested that the TUBA working group be understood to be in
hiatus until a number of the documents in process were completed, at
which time they would request that the working group be concluded.
We recommend that the IPng Area and its Directorate continue until
the basic documents have entered the standards track in late 1994 or
early 1995 and that after such time the area be dissolved and those
IPng Area working groups still active be moved to their normal IETF
areas.
22. Security Considerations
The security of the Internet has long been questioned. It has been
the topic of much press coverage, many conferences and workshops.
Almost all of this attention has been negative, pointing out the many
places where the level of possible security is far less than that
deemed necessary for the current and future uses of the Internet. A
number of the RFC1550 White Papers specifically pointed out the
requirement to improve the level of security available [Adam94,
Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the
Information Future". [Nat94]
In February of 1994, the IAB convened a workshop on security in the
Internet architecture. The report of this workshop [IAB94] includes
an exploration of many of the security problem areas and makes a
number of recommendations to improve the level of security that the
Internet offers its users.
We feel that an improvement in the basic level of security in the
Internet is vital to its continued success. Users must be able to
assume that their exchanges are safe from tampering, diversion and
exposure. Organizations that wish to use the Internet to conduct
business must be able to have a high level of confidence in the
identity of their correspondents and in the security of their
communications. The goal is to provide strong protection as a matter
of course throughout the Internet.
As the IAB report points out, many of the necessary tools are not a
function of the internetworking layer of the protocol. These higher
level tools could make use of strong security features in the
internetworking layer if they were present. While we expect that
there will be a number of special high-level security packages
available for specific Internet constituencies, support for basic
packet-level authentication will provide for the adoption of a much
needed, widespread, security infrastructure throughout the Internet.
It is best to separate the support for authentication from the
support for encryption. One should be able to use the two functions
independently. There are some applications in which authentication
of a corespondent is sufficient and others where the data exchanged
must be kept private.
It is our recommendation that IPv6 support packet authentication as a
basic and required function. Applications should be able to rely on
support for this feature in every IPv6 implementation. Support for a
specific authentication algorithm should also be mandated while
support for additional algorithms should be optional.
Thus we recommend that support for the Authentication Header be
required in all compliant IPv6 implementations.
We recommend that support for a specific authentication algorithm be
required. The specific algorithm should be determined by the time
the IPv6 documents are offered as Proposed Standards.
We recommend that support for the Privacy Header be required in IPv6
implementations.
We recommend that support for a privacy authentication algorithm be
required. The specific algorithm should be determined by the time the
IPv6 documents are offered as Proposed Standards.
Clearly, a key management infrastructure will be required in order to
enable the use of the authentication and encryption headers.
However, defining such an infrastructure is outside the scope of the
IPv6 effort. We do note that there are on-going IETF activities in
this area. The IPv6 transition working groups must coordinate with
these activities.
Just as clearly, the use of authentication and encryption may add to
the cost and impact the performance of systems but the more secure
infrastructure is worth the penalty. Whatever penalty there is
should also decrease in time with improved software and hardware
assistance.
The use of firewalls is increasing on the Internet. We hope that the
presence of the authentication and privacy features in IPv6 will
reduce the need for firewalls, but we do understand that they will
continue to be used for the foreseeable future. In this light, we
feel that clear guidance should be given to the developers of
firewalls on the best ways to design and configure them when working
in an IPv6 environment.
We recommend that an "IPv6 framework for firewalls" be developed.
This framework should explore the ways in which the Authentication
Header can be used to strengthen firewall technology and detail how
the IPv6 packet should be analyzed by a firewall.
Some aspects of security require additional study. For example, it
has been pointed out [Vecchi94] that, even in non-military
situations, there are places where procedures to thwart traffic
analysis will be required. This could be done by the use of
encrypted encapsulation, but this and other similar requirements must
be addressed on an on-going basis by the Security Area of the IETF.
The design of IPv6 must be flexible enough to support the later
addition of such security features.
We believe that IPv6 with its inherent security features will provide
the foundation upon which the Internet can continue to expand its
functionality and user base.
23. Authors' Addresses
Scott Bradner
Harvard University
10 Ware St.
Cambridge, MA 02138
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Allison Mankin
USC/Information Sciences Institute
4350 North Fairfax Drive, Suite 400
Arlington, VA 22303
Phone: +1 703-807-0132
EMail: mankin@isi.edu
Appendix A - Summary of Recommendations
5.3 Address Assignment Policy Recommendations
changes in address assignment policies are not recommended
reclamation of underutilized assigned addresses is not currently
recommended
efforts to renumber significant portions of the Internet are not
currently recommended
recommend consideration of assigning CIDR-type address blocks out
of unassigned Class A addressees
11. IPng Recommendation
recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128
bit ver)" [Deering94b] be adopted as the basis for IPng