Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1752

The Recommendation for the IP Next Generation Protocol

Pages: 52
Proposed Standard
Part 2 of 3 – Pages 17 to 34
First   Prev   Next

Top   ToC   RFC1752 - Page 17   prevText
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")

   * 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."
Top   ToC   RFC1752 - Page 18
   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
Top   ToC   RFC1752 - Page 19
   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

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.
Top   ToC   RFC1752 - Page 20
   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

   * 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
   * transition - the IPng transition plan is simple and realistically
     covers the transition methods that will be present in the
   * 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
   * security - IPng includes specific mechanisms for authentication and
     encryption at the internetwork layer; the security features do rely
Top   ToC   RFC1752 - Page 21
     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
   * 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.
Top   ToC   RFC1752 - Page 22
     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

     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.
Top   ToC   RFC1752 - Page 23
   * 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.
Top   ToC   RFC1752 - Page 24
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.

   |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)
Top   ToC   RFC1752 - Page 25
   * 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

      |  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
Top   ToC   RFC1752 - Page 26
      * 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
Top   ToC   RFC1752 - Page 27
   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.
Top   ToC   RFC1752 - Page 28
      * Reserved - Initialized to zero for transmission; ignored on

      * 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

      * 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

      * 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)
Top   ToC   RFC1752 - Page 29
      * Reserved, Res - Initialized to zero for transmission; ignored on

      * 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

      |  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)
Top   ToC   RFC1752 - Page 30
      * Reserved - Initialized to zero for transmission; ignored on

      * 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*      |

Top   ToC   RFC1752 - Page 31
      * 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

      * 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

      * 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
Top   ToC   RFC1752 - Page 32
   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
   * 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
Top   ToC   RFC1752 - Page 33
   The working group should also consider a few selected enhancements

   * 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
Top   ToC   RFC1752 - Page 34
   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

   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.

   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)

Next Section