rfc1710.txt

中、英文RFC文档大全打包下载完全版 .

   to merge and concentrate their efforts.  The chairs of the new SIP
   working group were Steve Deering and Robert Hinden.

   In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded
   a working group to develop the "P" Internet Protocol (Pip).  Pip was
   a new internet protocol based on a new architecture.  The motivation
   behind Pip was that the opportunity for introducing a new internet
   protocol does not come very often and given that opportunity
   important new features should be introduced.  Pip supported variable
   length addressing in 16-bit units, separation of addresses from
   identifiers, support for provider selection, mobility, and efficient



Hinden                                                          [Page 6]

RFC 1710                 SIPP IPng White Paper              October 1994


   forwarding.  It included a transition scheme similar to IPAE.

   After considerable discussion among the leaders of the Pip and SIP
   working groups, they came to realize that the advanced features in
   Pip could be accomplished in SIP without changing the base SIP
   protocol as well as keeping the IPAE transition mechanisms.  In
   essence it was possible to keep the best features of each protocol.
   Based on this the groups decided to merge their efforts.  The new
   protocol was called Simple Internet Protocol Plus (SIPP).  The chairs
   of the merged working group are Steve Deering, Paul Francis, and
   Robert Hinden.

4. SIPP Overview

   SIPP is a new version of the Internet Protocol, designed as a
   successor to IP version 4 [IPV4].  SIPP is assigned IP version number
   6.

   SIPP was designed to take an evolutionary step from IPv4.  It was not
   a design goal to take a radical step away from IPv4.  Functions which
   work in IPv4 were kept in SIPP.  Functions which didn't work were
   removed.  The changes from IPv4 to SIPP fall primarily into the
   following categories:

      o  Expanded Routing and Addressing Capabilities

        SIPP increases the IP address size from 32 bits to 64 bits, to
        support more levels of addressing hierarchy and a much greater
        number of addressable nodes.  SIPP addressing can be further
        extended, in units of 64 bits, by a facility equivalent to
        IPv4's Loose Source and Record Route option, in combination
        with a new address type called "cluster addresses" which
        identify topological regions rather than individual nodes.
        The scaleability of multicast routing is improved by adding
        a "scope" field to multicast addresses.

     o Header Format Simplification

        Some IPv4 header fields have been dropped or made optional, to
        reduce the common-case processing cost of packet handling and to
        keep the bandwidth cost of the SIPP header almost as low as that
        of IPv4, despite the increased size of the addresses.  The basic
        SIPP header is only four bytes longer than IPv4.








Hinden                                                          [Page 7]

RFC 1710                 SIPP IPng White Paper              October 1994


     o Improved Support for Options

        Changes in the way IP header options are encoded allows for more
        efficient forwarding, less stringent limits on the length of
        options, and greater flexibility for introducing new options in
        the future.

     o Quality-of-Service Capabilities

        A new capability is added to enable the labeling of packets
        belonging to particular traffic "flows" for which the sender
        requests special handling, such as non-default quality of
        service or "real-time" service.

     o Authentication and Privacy Capabilities

        SIPP includes the definition of extensions which provide support
        for authentication, data integrity, and confidentiality.  This
        is included as a basic element of SIPP.

   The SIPP protocol consists of two parts, the basic SIPP header and
   SIPP Options.

4.1  SIPP Header Format

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|                       Flow Label                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Payload Length        |  Payload Type |   Hop Limit   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Source Address                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Destination Address                      +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Version              4-bit Internet Protocol version number = 6.

      Flow Label           28-bit field.  See SIPP Quality of Service
                           section.

      Payload Length       16-bit unsigned integer.  Length of payload,
                           i.e., the rest of the packet following the
                           SIPP header, in octets.



Hinden                                                          [Page 8]

RFC 1710                 SIPP IPng White Paper              October 1994


      Payload Type         8-bit selector.  Identifies the type of
                           header immediately following the SIPP
                           header.  Uses the same values as the IPv4
                           Protocol field [STD 2, RFC 1700].

      Hop Limit            8-bit unsigned integer.  Decremented by 1
                           by each node that forwards the packet.
                           The packet is discarded if Hop Limit is
                           decremented to zero.

      Source Address       64 bits.  An address of the initial sender of
                           the packet.  See [ROUT] for details.

      Destination Address  64 bits.  An address of the intended
                           recipient of the packet (possibly not the
                           ultimate recipient, if an optional Routing
                           Header is present).

4.2 SIPP Options

   SIPP includes an improved option mechanism over IPv4.  SIPP options
   are placed in separate headers that are located between the SIPP
   header and the transport-layer header in a packet.  Most SIPP option
   headers are not examined or processed by any router along a packet's
   delivery path until it arrives at its final destination.  This
   facilitates a major improvement in router performance for packets
   containing options. In IPv4 the presence of any options requires the
   router to examine all options.  The other improvement is that unlike
   IPv4, SIPP options can be of arbitrary length and the total amount of
   options carried in a packet is not limited to 40 bytes.  This feature
   plus the manner in which they are processed, permits SIPP options to
   be used for functions which were not practical in IPv4.  A good
   example of this is the SIPP Authentication and Security Encapsulation
   options.

   In order to improve the performance when handling subsequent option
   headers and the transport protocol which follows, SIPP options are
   always an integer multiple of 8 octets long, in order to retain this
   alignment for subsequent headers.












Hinden                                                          [Page 9]

RFC 1710                 SIPP IPng White Paper              October 1994


   The SIPP option headers which are currently defined are:

     Option                     Function
     ---------------            ---------------------------------------
     Routing                    Extended Routing (like IPv4 loose source
                                route)
     Fragmentation              Fragmentation and Reassembly
     Authentication             Integrity and Authentication
     Security Encapsulation     Confidentiality
     Hop-by-Hop Option          Special options which require hop by hop
                                processing

4.3 SIPP Addressing

   SIPP addresses are 64-bits long and are identifiers for individual
   nodes and sets of nodes.  There are three types of SIPP addresses.
   These are unicast, cluster, and multicast.  Unicast addresses
   identify a single node.  Cluster addresses identify a group of nodes,
   that share a common address prefix, such that a packet sent to a
   cluster address will be delivered to one member of the group.
   Multicast addresses identify a group of nodes, such that a packet
   sent to a multicast address is delivered to all of the nodes in the
   group.

   SIPP supports addresses which are twice the number of bits as IPv4
   addresses.  These addresses support an address space which is four
   billion (2^^32) times the size of IPv4 addresses (2^^32).  Another
   way to say this is that SIPP supports four billion internets each the
   size of the maximum IPv4 internet.  That is enough to allow each
   person on the planet to have their own internet.  Even with several
   layers of hierarchy (with assignment utilization similar to IPv4)
   this would allow for each person on the planet to have their own
   internet each holding several thousand hosts.

   In addition, SIPP supports extended addresses using the routing
   option.  This capability allows the address space to grow to 128-
   bits, 192-bits (or even larger) while still keeping the address units
   in manageable 64-bit units.  This permits the addresses to grow while
   keeping the routing algorithms efficient because they continue to
   operate using 64- bit units.

4.3.1 Unicast Addresses

   There are several forms of unicast address assignment in SIPP. These
   are global hierarchical unicast addresses, local-use addresses, and
   IPv4- only host addresses.  The assignment plan for unicast addresses
   is described in [ADDR].




Hinden                                                         [Page 10]

RFC 1710                 SIPP IPng White Paper              October 1994


4.3.1.1 Global Unicast Addresses

   Global unicast addresses are used for global communication.  They are
   the most common SIPP address and are similar in function to IPv4
   addresses.  Their format is:

     |1|      n bits       |        m bits       |   p bits  | 63-n-m-p|
     +-+-------------------+---------------------+-----------+---------+
     |C|    PROVIDER ID    |    SUBSCRIBER ID    | SUBNET ID | NODE ID |
     +-+-------------------+---------------------+-----------+---------+

   The first bit is the IPv4 compatibility bit, or C-bit.  It indicates
   whether the node represented by the address is IPv4 or SIPP.  SIPP
   addresses are provider-oriented.  That is, the high-order part of the
   address is assigned to internet service providers, which then assign
   portions of the address space to subscribers, etc.  This usage is
   similar to assignment of IP addresses under CIDR.  The SUBSCRIBER ID
   distinguishes among multiple subscribers attached to the provider
   identified by the PROVIDER ID.  The SUBNET ID identifies a
   topologically connected group of nodes within the subscriber network
   identified by the subscriber prefix.  The NODE ID identifies a single
   node among the group of nodes identified by the subnet prefix.

4.3.1.2 Local-Use Address

   A local-use address is a unicast address that has only local
   routability scope (within the subnet or within a subscriber network),
   and may have local or global uniqueness scope.  They are intended for
   use inside of a site for "plug and play" local communication, for
   bootstrapping up to a single global addresses, and as part of an
   address sequence for global communication.  Their format is:

     | 4  |
     |bits|    12 bits    |                 48 bits                    |
     +----+---------------+--------------------------------------------+
     |0110|   SUBNET ID   |                 NODE ID                    |
     +----+---------------+--------------------------------------------+

   The NODE ID is an identifier which much be unique in the domain in
   which it is being used.  In most cases these will use a node's IEEE-
   802 48bit address.  The SUBNET ID identifies a specific subnet in a
   site.  The combination of the SUBNET ID and the NODE ID to form a
   local use address allows a large private internet to be constructed
   without any other address allocation.

   Local-use addresses have two primary benefits.  First, for sites or
   organizations that are not (yet) connected to the global Internet,
   there is no need to request an address prefix from the global



Hinden                                                         [Page 11]

RFC 1710                 SIPP IPng White Paper              October 1994


   Internet address space.  Local-use addresses can be used instead.  If
   the organization connects to the global Internet, it can use it's
   local use addresses to communicate with a server (e.g., using the
   Dynamic Host Configuration Protocol [DHCP]) to have a global address
   automatically assigned.

   The second benefit of local-use addresses is that they can hold much
   larger NODE IDs, which makes possible a very simple form of auto-
   configuration of addresses.  In particular, a node may discover a
   SUBNET ID by listening to a Router Advertisement messages on its
   attached link(s), and then fabricating a SIPP address for itself by
   using its link-level address as the NODE ID on that subnet.

   An auto-configured local-use address may be used by a node as its own
   identification for communication within the local domain, possibly
   including communication with a local address server to obtain a
   global SIPP address.  The details of host auto-configuration are
   described in [DHCP].

4.3.1.3 IPv4-Only Addresses

   SIPP unicast addresses are assigned to IPv4-only hosts as part of the
   IPAE scheme for transition from IPv4 to SIPP.  Such addresses have
   the following form: