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.