RFC 1752
The Recommendation for the IP Next Generation Protocol
Pages: 52
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 17 to 34
9. A Revised Proposal As mentioned above, there was considerable discussion of the strengths and weaknesses of the various IPng proposals during the IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b] After this retreat Steve Deering and Paul Francis, two of the co-chairs of the SIPP Working Group, sent a message to the sipp mailing list detailing the discussions at the retreat and proposing some changes in SIPP. [Deering94a] The message noted "The recurring (and unsurprising) concerns about SIPP were: (1) complexity/manageability/feasibility of IPAE, and (2) adequacy/correctness/limitations of SIPP's addressing and routing model, especially the use of loose source routing to accomplish 'extended addressing'". They "proposed to address these concerns by changing SIPP as follows: * Change address size from 8 bytes to 16 bytes (fixed-length). * Specify optional use of serverless autoconfiguration of the 16-byte address by using IEEE 802 address as the low-order ("node ID") part. * For higher-layer protocols that use internet-layer addresses as part of connection identifiers (e.g., TCP), require that they use the entire 16-byte addresses. * Do *not* use Route Header for extended addressing."
After considerable discussion on the sipp and big-internet mailing lists about these proposed changes, the SIPP working group published a revised version of SIPP [Deering94b], a new addressing architecture [Francis94], and a simplified transition mechanism [Gillig94a]. These were submitted to the IPng Directorate for their consideration. This proposal represents a synthesis of multiple IETF efforts with much of the basic protocol coming from the SIPP effort, the autoconfiguration and transition portions influenced by TUBA, the addressing structure is based on the CIDR work and the routing header evolving out of the SDRP deliberations. 10. Assumptions 10.1 Criteria Document and Timing of Recommendation In making the following recommendations we are making two assumptions of community consensus; that the IPng criteria document represents the reasonable set of requirements for an IPng, and that a specific recommendation should be made now and that from this point on the IETF should proceed with a single IPng effort. As described above, the IPng Technical Criteria document [Kasten94] was developed in a open manner and was the topic of extensive discussions on a number of mailing lists. We believe that there is a strong consensus that this document accurately reflects the community's set of technical requirements which an IPng should be able to meet. A prime topic of discussion on the big-internet mailing list this spring as well as during the open IPng directorate meeting in Seattle, was the need to make a specific IPng recommendation at this time. Some people felt that additional research would help resolve some of the issues that are currently unresolved. While others argued that selecting a single protocol to work on would clarify the picture for the community, focus the resources of the IETF on finalizing its details, and, since the argument that there were open research items could be made at any point in history, there might never be a 'right' time. Our reading of the community is that there is a consensus that a specific recommendation should be made now. This is consistent with the views expressed during the ipdecide BOF in Amsterdam [Gross94] and in some of the RFC 1550 white papers [Carpen94a]. There is no particular reason to think that the basic recommendation would be significantly different if we waited for another six months or a year. Clearly some details which are currently unresolved could
be filled in if the recommendation were to be delayed, but the current fragmentation of the IETF's energies limits the efficiency of this type of detail resolution. Concentrating the resources of the IETF behind a single effort seems to us to be a more efficient way to proceed. 10.2 Address Length One of the most hotly discussed aspects of the IPng design possibilities was address size and format. During the IPng process four distinct views were expressed about these issues: 1. The view that 8 bytes of address are enough to meet the current and future needs of the Internet (squaring the size of the IP address space). More would waste bandwidth, promote inefficient assignment, and cause problems in some networks (such as mobiles and other low speed links). 2. The view that 16 bytes is about right. That length supports easy auto-configuration as well as organizations with complex internal routing topologies in conjunction with the global routing topology now and well into the future. 3. The view that 20 byte OSI NSAPs should be used in the interests of global harmonization. 4. The view that variable length addresses which might be smaller or larger than 16 bytes should be used to embrace all the above options and more, so that the size of the address could be adjusted to the demands of the particular environment, and to ensure the ability to meet any future networking requirements. Good technical and engineering arguments were made for and against all of these views. Unanimity was not achieved, but we feel that a clear majority view emerged that the use of 16 byte fixed length addresses was the best compromise between efficiency, functionality, flexibility, and global applicability. [Mankin94] 11. IPng Recommendation After a great deal of discussion in many forums and with the consensus of the IPng Directorate, we recommend that the protocol described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [Deering94b] be adopted as the basis for IPng, the next generation of the Internet Protocol. We also recommend that the other documents listed in Appendix C be adopted as the basis of specific features of this protocol.
This proposal resolves most of the perceived problems, particularly in the areas of addressing, routing, transition and address autoconfiguration. It includes the broad base of the SIPP proposal effort, flexible address autoconfiguration features, and a merged transition strategy. We believe that it meets the requirements outlined in the IPng Criteria document and provides the framework to fully meet the needs of the greater Internet community for the foreseeable future. 11.1 IPng Criteria Document and IPng A detailed review of how IPng meets the requirements set down in the IPng Criteria document [Kasten94] will soon be published. Following is our feelings about the extent to which IPng is responsive to the criteria. * complete specification - the base specifications for IPng are complete but transition and address autoconfiguration do remain to be finalized * architectural simplicity - the protocol is simple, easy to explain and uses well established paradigms * scale - an address size of 128 bits easily meets the need to address 10**9 networks even in the face of the inherent inefficiency of address allocation for efficient routing * topological flexibility - the IPng design places no constraints on network topology except for the limit of 255 hops * performance - the simplicity of processing, the alignment of the fields in the headers, and the elimination of the header checksum will allow for high performance handling of IPng data streams * robust service - IPng includes no inhibitors to robust service and the addition of packet-level authentication allows the securing of control and routing protocols without having to have separate procedures * transition - the IPng transition plan is simple and realistically covers the transition methods that will be present in the marketplace * media independence - IPng retains IPv4's media independence, it may be possible to make use of IPng's Flow Label in some connection- oriented media such as ATM * datagram service - IPng preserves datagram service as its basic operational mode, it is possible that the use of path MTU discovery 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.
(page 34 continued on part 3)