rfc1710.txt

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

     |1|            31 bits           |             32 bits            |
     +-+------------------------------+--------------------------------+
     |1|   HIGHER-ORDER SIPP PREFIX   |          IPv4 ADDRESS          |
     +-+------------------------------+--------------------------------+

   The highest-order bit of a SIPP address is called the IPv4
   compatibility bit or the C bit. A C bit value of 1 identifies an
   address as belonging to an IPv4-only node.

   The IPv4 node's 32-bit IPv4 address is carried in the low-order 32
   bits of the SIPP address.  The remaining 31 bits are used to carry
   HIGHER- ORDER SIPP PREFIX, such as a service-provider ID.

4.3.2  Cluster Addresses

   Cluster addresses are unicast addresses that are used to reach the
   "nearest" one (according to unicast routing's notion of nearest) of
   the set of boundary routers of a cluster of nodes identified by a
   common prefix in the SIPP unicast routing hierarchy.  These are used
   to identify a set of nodes.  The cluster address, when used as part
   of an address sequence, permits a node to select which of several
   providers it wants to carry its traffic.  A cluster address can only
   be used as a destination address.  In this example there would be a



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


   cluster address for each provider.  This capability is sometimes
   called "source selected policies".  Cluster addresses have the
   general form:

     |              n bits             |           64-n bits           |
     +---------------------------------+-------------------------------+
     |          CLUSTER PREFIX         |0000000000000000000000000000000|
     +---------------------------------+-------------------------------+

4.3.3  Multicast Addresses

   A SIPP multicast address is an identifier for a group of nodes.  A
   node may belong to any number of multicast groups.  Multicast
   addresses have the following format:


     |1|   7   |  4 |  4 |                  48 bits                    |
     +-+-------+----+----+---------------------------------------------+
     |C|1111111|FLGS|SCOP|                  GROUP ID                   |
     +-+-------+----+----+---------------------------------------------+

   Where:

     C = IPv4 compatibility bit.

     1111111 in the rest of the first octet identifies the address as
     being a multicast address.

                                   +-+-+-+-+
     FLGS is a set of 4 flags:     |0|0|0|T|
                                   +-+-+-+-+

     The high-order 3 flags are reserved, and must be initialized to 0.

     T = 0 indicates a permanently-assigned ("well-known") multicast
           address, assigned by the global internet numbering authority.

     T = 1 indicates a non-permanently-assigned ("transient") multicast
           address.

     SCOP is a 4-bit multicast scope value used to limit the scope of
     the multicast group.  The values are:

        0  reserved                  8  intra-organization scope
        1  intra-node scope          9  (unassigned)
        2  intra-link scope          10  (unassigned)
        3  (unassigned)              11  intra-community scope
        4  (unassigned)              12  (unassigned)



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


        5  intra-site scope          13  (unassigned)
        6  (unassigned)              14  global scope
        7  (unassigned)              15  reserved

     GROUP ID identifies the multicast group, either permanent or
     transient, within the given scope.

4.4 SIPP Routing

   Routing in SIPP is almost identical to IPv4 routing under CIDR except
   that the addresses are 64-bit SIPP addresses instead of 32-bit IPv4
   addresses.  This is true even when extended addresses are being used.
   With very straightforward extensions, all of IPv4's routing
   algorithms (OSPF, BGP, RIP, IDRP, etc.) can used to route SIPP [OSPF]
   [RIP2] [IDRP].

   SIPP also includes simple routing extensions which support powerful
   new routing functionality.  These capabilities include:

        Provider Selection (based on policy, performance, cost, etc.)
        Host Mobility (route to current location)
        Auto-Readdressing (route to new address)
        Extended Addressing (route to "sub-cloud")

   The new routing functionality is obtained by creating sequences of
   SIPP addresses using the SIPP Routing option.  The routing option is
   used by a SIPP source to list one or more intermediate nodes (or
   topological clusters) to be "visited" on the way to a packet's
   destination.  This function is very similar in function to IPv4's
   Loose Source and Record Route option.  A node would publish its
   address sequence in the Domain Name System [DNS].

   The identification of a specific transport connection is done by only
   using the first (source) and last (destination) address in the
   sequence.  These identifying addresses (i.e., first and last
   addresses of a route sequence) are required to be unique within the
   scope over which they are used.  This permits the middle addresses in
   the address sequence to change (in the cases of mobility, provider
   changes, site readdressing, etc.) without disrupting the transport
   connection.

   In order to make address sequences a general function, SIPP hosts are
   required to reverse routes in a packet it receives containing address
   sequences in order to return the packet to its originator.  This
   approach is taken to make SIPP host implementations from the start
   support the handling and reversal of source routes.  This is the key
   for allowing them to work with hosts which implement the new features
   such as provider selection or extended addresses.



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


   Three examples show how the extended addressing can be used.  In
   these examples, address sequences are shown by a list of individual
   addresses separated by commas.  For example:

       SRC, I1, I2, I3, DST

   Where the first address is the source address, the last address is
   the destination address, and the middle addresses are intermediate
   addresses.

   For these examples assume that two hosts, H1 and H2 wish to
   communicate.  Assume that H1 and H2's sites are both connected to
   providers P1 and P2.  A third wireless provider, PR, is connected to
   both providers P1 and P2.

                           ----- P1 ------
                          /       |       \
                         /        |        \
                       H1        PR        H2
                         \        |        /
                          \       |       /
                           ----- P2 ------

   The simplest case (no use of address sequences) is when H1 wants to
   send a packet to H2 containing the addresses:

           H1, H2

   When H2 replied it would reverse the addresses and construct a packet
   containing the addresses:

           H2, H1

   In this example either provider could be used, and H1 and H2 would
   not be able to select which provider traffic would be sent to and
   received from.

   If H1 decides that it wants to enforce a policy that all
   communication to/from H2 can only use provider P1, it would construct
   a packet containing the address sequence:

           H1, P1, H2

   This ensures that when H2 replies to H1, it will reverse the route
   and the reply it would also travel over P1.  The addresses in H2's
   reply would look like:

           H2, P1, H1



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


   If H1 became mobile and moved to provider PR, it could maintain (not
   breaking any transport connections) communication with H2, by sending
   packets that contain the address sequence:

           H1, PR, P1, H2

   This would ensure that when H2 replied it would enforce H1's policy
   of exclusive use of provider P1 and send the packet to H1 new
   location on provider PR.  The reversed address sequence would be:

           H2, P1, PR, H1

   The address extension facility of SIPP can be used for provider
   selection, mobility, readdressing, and extended addressing.  It is a
   simple but powerful capability.

4.5 SIPP Quality-of-Service Capabilities

   The Flow Label field in the SIPP header may be used by a host to
   label those packets for which it requests special handling by SIPP
   routers, such as non-default quality of service or "real-time"
   service.  This labeling is important in order to support applications
   which require some degree of consistent throughput, delay, and/or
   jitter.  The Flow Label is a 28-bit field, internally structured into
   three subfields as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|  DP |                    Flow ID                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     R (Reserved)       1-bit subfield.  Initialized to zero for
                        transmission; Ignored on reception.

     DP (Drop Priority) 3-bit unsigned integer.  Specifies the
                        priority of the packet, relative to other
                        packets from the same source, for being
                        discarded by a router under conditions of
                        congestion.  Larger values indicates a
                        greater willingness by the sender to allow
                        the packet to be discarded.

     Flow ID            24-bit subfield used to identify a
                        specific flow.

   A flow is a sequence of packets sent from a particular source to a
   particular (unicast or multicast) destination for which the source
   desires special handling by the intervening routers.  There may be
   multiple active flows from a source to a destination, as well as



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


   traffic that is not associated with any flow.  A flow is identified
   by the combination of a Source Address and a non-zero Flow ID.
   Packets that do not belong to a flow carry a Flow ID of zero.

   A Flow ID is assigned to a flow by the flow's source node.  New Flow
   IDs must be chosen (pseudo-)randomly and uniformly from the range 1
   to FFFFFF hex.  The purpose of the random allocation is to make any
   set of bits within the Flow ID suitable for use as a hash key by the
   routers, for looking up the special-handling state associated with
   the flow.  A Flow ID must not be re-used by a source for a new flow
   while any state associated with the previous usage still exists in
   any router.

   The Drop Priority subfield provides a means separate from the Flow ID
   for distinguishing among packets from the same source, to allow a
   source to specify which of its packets are to be discarded in
   preference to others when a router cannot forward them all.  This is
   useful for applications like video where it is preferable to drop
   packets carrying screen updates rather than the packets carrying the
   video synchronization information.

4.6 SIPP Security

   The current Internet has a number of security problems and lacks
   effective privacy and authentication mechanisms below the application
   layer.  SIPP remedies these shortcomings by having two integrated
   options that provide security services.  These two options may be
   used singly or together to provide differing levels of security to
   different users.  This is very important because different user
   communities have different security needs.

   The first mechanism, called the "SIPP Authentication Header", is an
   option which provides authentication and integrity (without
   confidentiality) to SIPP datagrams.  While the option is algorithm-
   independent and will support many different authentication
   techniques, the use of keyed MD5 is proposed to help ensure
   interoperability within the worldwide Internet.  This can be used to
   eliminate a significant class of network attacks, including host
   masquerading attacks.  The use of the SIPP Authentication Header is
   particularly important when source routing is used with SIPP because
   of the known risks in IP source routing.  Its placement at the
   internet layer can help provide host origin authentication to those
   upper layer protocols and services that currently lack meaningful
   protections.  This mechanism should be exportable by vendors in the
   United States and other countries with similar export restrictions
   because it only provides authentication and integrity, and
   specifically does not provide confidentiality.  The exportability of
   the SIPP Authentication Header encourages its widespread



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


   implementation and use.

   The second security option provided with SIPP is the "SIPP
   Encapsulating Security Header".  This mechanism provides integrity
   and confidentiality to SIPP datagrams.  It is simpler than some
   similar security protocols (e.g., SP3D, ISO NLSP) but remains
   flexible and algorithm-independent.  To achieve interoperability
   within the global Internet, the use of DES CBC is proposed as the
   standard algorithm for use with the SIPP Encapsulating Security
   Header.