home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1710 < prev    next >
Text File  |  1994-11-17  |  57KB  |  1,292 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group:                                         R. Hinden
  8. Request for Comments: 1710                              Sun Microsystems
  9. Category: Informational                                     October 1994
  10.  
  11.  
  12.                Simple Internet Protocol Plus White Paper
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the author and/or the sipp@sunroof.eng.sun.com mailing
  26.    list.
  27.  
  28. 1. Introduction
  29.  
  30.    This white paper presents an overview of the Simple Internet Protocol
  31.    plus (SIPP) which is one of the candidates being considered in the
  32.    Internet Engineering Task Force (IETF) for the next version of the
  33.    Internet Protocol (the current version is usually referred to as
  34.    IPv4).  This white paper is not intended to be a detailed
  35.    presentation of all of the features and motivation for SIPP, but is
  36.    intended to give the reader an overview of the proposal.  It is also
  37.    not intended that this be an implementation specification, but given
  38.    the simplicity of the central core of SIPP, an implementor familiar
  39.    with IPv4 could probably construct a basic working SIPP
  40.    implementation from reading this overview.
  41.  
  42.    SIPP is a new version of IP which is designed to be an evolutionary
  43.    step from IPv4.  It is a natural increment to IPv4.  It can be
  44.    installed as a normal software upgrade in internet devices and is
  45.    interoperable with the current IPv4.  Its deployment strategy was
  46.    designed to not have any "flag" days.  SIPP is designed to run well
  47.    on high performance networks (e.g., ATM) and at the same time is
  48.    still efficient for low bandwidth networks (e.g., wireless).  In
  49.    addition, it provides a platform for new internet functionality that
  50.    will be required in the near future.
  51.  
  52.    This white paper describes the work of IETF SIPP working group.
  53.    Several individuals deserve specific recognition.  These include
  54.    Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan, Bill
  55.  
  56.  
  57.  
  58. Hinden                                                          [Page 1]
  59.  
  60. RFC 1710                 SIPP IPng White Paper              October 1994
  61.  
  62.  
  63.    Simpson, Ran Atkinson, Bill Fink, Erik Nordmark, Christian Huitema,
  64.    Sue Thompson, and Ramesh Govindan.
  65.  
  66. 2. Key Issues for the Next Generation of IP
  67.  
  68.    There are several key issues that should be used in the evaluation of
  69.    any next generation internet protocol.  Some are very
  70.    straightforward.  For example the new protocol must be able to
  71.    support large global internetworks.  Others are less obvious.  There
  72.    must be a clear way to transition the current installed base of IP
  73.    systems.  It doesn't matter how good a new protocol is if there isn't
  74.    a practical way to transition the current operational systems running
  75.    IPv4 to the new protocol.
  76.  
  77. 2.1 Growth
  78.  
  79.    Growth is the basic issue which caused there to be a need for a next
  80.    generation IP.  If anything is to be learned from our experience with
  81.    IPv4 it is that the addressing and routing must be capable of
  82.    handling reasonable scenarios of future growth.  It is important that
  83.    we have an understanding of the past growth and where the future
  84.    growth will come from.
  85.  
  86.    Currently IPv4 serves what could be called the computer market.  The
  87.    computer market has been the driver of the growth of the Internet.
  88.    It comprises the current Internet and countless other smaller
  89.    internets which are not connected to the Internet.  Its focus is to
  90.    connect computers together in the large business, government, and
  91.    university education markets.  This market has been growing at an
  92.    exponential rate.  One measure of this is that the number of networks
  93.    in current Internet (23,494 as of 1/28/94) is doubling approximately
  94.    every 12 months.  The computers which are used at the endpoints of
  95.    internet communications range from PC's to Supercomputers.  Most are
  96.    attached to Local Area Networks (LANs) and the vast majority are not
  97.    mobile.
  98.  
  99.    The next phase of growth will probably not be driven by the computer
  100.    market.  While the computer market will continue to grow at
  101.    significant rates due to expansion into other areas such as schools
  102.    (elementary through high school) and small businesses, it is doubtful
  103.    it will continue to grow at an exponential rate.  What is likely to
  104.    happen is that other kinds of markets will develop.  These markets
  105.    will fall into several areas.  They all have the characteristic that
  106.    they are extremely large.  They also bring with them a new set of
  107.    requirements which were not as evident in the early stages of IPv4
  108.    deployment.  The new markets are also likely to happen in parallel
  109.    with other.  It may turn out that we will look back on the last ten
  110.    years of Internet growth as the time when the Internet was small and
  111.  
  112.  
  113.  
  114. Hinden                                                          [Page 2]
  115.  
  116. RFC 1710                 SIPP IPng White Paper              October 1994
  117.  
  118.  
  119.    only doubling every year.  The challenge for an IPng is to provide a
  120.    solution which solves todays problems and is attractive in these
  121.    emerging markets.
  122.  
  123.    Nomadic personal computing devices seem certain to become ubiquitous
  124.    as their prices drop and their capabilities increase.  A key
  125.    capability is that they will be networked.  Unlike the majority of
  126.    todays networked computers they will support a variety of types of
  127.    network attachments.  When disconnected they will use RF wireless
  128.    networks, when used in networked facilities they will use infrared
  129.    attachment, and when docked they will use physical wires.  This makes
  130.    them an ideal candidate for internetworking technology as they will
  131.    need a common protocol which can work over a variety of physical
  132.    networks.  These types of devices will become consumer devices and
  133.    will replace the current generation of cellular phones, pagers, and
  134.    personal digital assistants.  In addition to the obvious requirement
  135.    of an internet protocol which can support large scale routing and
  136.    addressing, they will require an internet protocol which imposes a
  137.    low overhead and supports auto configuration and mobility as a basic
  138.    element.  The nature of nomadic computing requires an internet
  139.    protocol to have built in authentication and confidentiality.  It
  140.    also goes without saying that these devices will need to communicate
  141.    with the current generation of computers.  The requirement for low
  142.    overhead comes from the wireless media.  Unlike LAN's which will be
  143.    very high speed, the wireless media will be several orders of
  144.    magnitude slower due to constraints on available frequencies,
  145.    spectrum allocation, and power consumption.
  146.  
  147.    Another market is networked entertainment.  The first signs of this
  148.    emerging market are the proposals being discussed for 500 channels of
  149.    television, video on demand, etc.  This is clearly a consumer market.
  150.    The possibility is that every television set will become an Internet
  151.    host.  As the world of digital high definition television approaches,
  152.    the differences between a computer and a television will diminish.
  153.    As in the previous market, this market will require an Internet
  154.    protocol which supports large scale routing and addressing, and auto
  155.    configuration.  This market also requires a protocol suite which
  156.    imposes the minimum overhead to get the job done.  Cost will be the
  157.    major factor in the selection of a technology to use.
  158.  
  159.    Another market which could use the next generation IP is device
  160.    control.  This consists of the control of everyday devices such as
  161.    lighting equipment, heating and cooling equipment, motors, and other
  162.    types of equipment which are currently controlled via analog switches
  163.    and in aggregate consume considerable amounts of power.  The size of
  164.    this market is enormous and requires solutions which are simple,
  165.    robust, easy to use, and very low cost.
  166.  
  167.  
  168.  
  169.  
  170. Hinden                                                          [Page 3]
  171.  
  172. RFC 1710                 SIPP IPng White Paper              October 1994
  173.  
  174.  
  175.    The challenge for the IETF in the selection of an IPng is to pick a
  176.    protocol which meets today's requirements and also matches the
  177.    requirements of these emerging markets.  These markets will happen
  178.    with or without an IETF IPng.  If the IETF IPng is a good match for
  179.    these new markets it is likely to be used.  If not, these markets
  180.    will develop something else.  They will not wait for an IETF
  181.    solution.  If this should happen it is probable that because of the
  182.    size and scale of the new markets the IETF protocol would be
  183.    supplanted.  If the IETF IPng is not appropriate for use in these
  184.    markets, it is also probable that they will each develop their own
  185.    protocols, perhaps proprietary.  These new protocols would not
  186.    interoperate with each other.  The opportunity for the IETF is to
  187.    select an IPng which has a reasonable chance to be used in these
  188.    emerging markets.  This would have the very desirable outcome of
  189.    creating an immense, interoperable, world-wide information
  190.    infrastructure created with open protocols.  The alternative is a
  191.    world of disjoint networks with protocols controlled by individual
  192.    vendors.
  193.  
  194. 2.2. Transition
  195.  
  196.    At some point in the next three to seven years the Internet will
  197.    require a deployed new version of the Internet protocol.  Two factors
  198.    are driving this: routing and addressing.  Global internet routing
  199.    based on the on 32-bit addresses of IPv4 is becoming increasingly
  200.    strained.  IPv4 address do not provide enough flexibility to
  201.    construct efficient hierarchies which can be aggregated.  The
  202.    deployment of Classless Inter-Domain Routing [CIDR] is extending the
  203.    life time of IPv4 routing routing by a number of years, the effort to
  204.    manage the routing will continue to increase.  Even if the IPv4
  205.    routing can be scaled to support a full IPv4 Internet, the Internet
  206.    will eventually run out of network numbers.  There is no question
  207.    that an IPng is needed, but only a question of when.
  208.  
  209.    The challenge for an IPng is for its transition to be complete before
  210.    IPv4 routing and addressing break.  The transition will be much
  211.    easier if IPv4 address are still globally unique.  The two transition
  212.    requirements which are the most important are flexibility of
  213.    deployment and the ability for IPv4 hosts to communicate with IPng
  214.    hosts.  There will be IPng-only hosts, just as there will be IPv4-
  215.    only hosts.  The capability must exist for IPng-only hosts to
  216.    communicate with IPv4-only hosts globally while IPv4 addresses are
  217.    globally unique.
  218.  
  219.    The deployment strategy for an IPng must be as flexible as possible.
  220.    The Internet is too large for any kind of controlled rollout to be
  221.    successful.  The importance of flexibility in an IPng and the need
  222.    for interoperability between IPv4 and IPng was well stated in a
  223.  
  224.  
  225.  
  226. Hinden                                                          [Page 4]
  227.  
  228. RFC 1710                 SIPP IPng White Paper              October 1994
  229.  
  230.  
  231.    message to the sipp mailing list by Bill Fink, who is responsible for
  232.    a portion of NASA's operational internet.  In his message he said:
  233.  
  234.       "Being a network manager and thereby representing the interests of
  235.       a significant number of users, from my perspective it's safe to
  236.       say that the transition and interoperation aspects of any IPng is
  237.       *the* key first element, without which any other significant
  238.       advantages won't be able to be integrated into the user's network
  239.       environment.  I also don't think it wise to think of the
  240.       transition as just a painful phase we'll have to endure en route
  241.       to a pure IPng environment, since the transition/coexistence
  242.       period undoubtedly will last at least a decade and may very well
  243.       continue for the entire lifetime of IPng, until it's replaced with
  244.       IPngng and a new transition.  I might wish it was otherwise but I
  245.       fear they are facts of life given the immense installed base.
  246.  
  247.       "Given this situation, and the reality that it won't be feasible
  248.       to coordinate all the infrastructure changes even at the national
  249.       and regional levels, it is imperative that the transition
  250.       capabilities support the ability to deploy the IPng in the
  251.       piecemeal fashion...  with no requirement to need to coordinate
  252.       local changes with other changes elsewhere in the Internet...
  253.  
  254.       "I realize that support for the transition and coexistence
  255.       capabilities may be a major part of the IPng effort and may cause
  256.       some headaches for the designers and developers, but I think it is
  257.       a duty that can't be shirked and the necessary price that must be
  258.       paid to provide as seamless an environment as possible to the end
  259.       user and his basic network services such as e-mail, ftp, gopher,
  260.       X-Window clients, etc...
  261.  
  262.       "The bottom line for me is that we must have interoperability
  263.       during the extended transition period for the base IPv4
  264.       functionality..."
  265.  
  266.    Another way to think about the requirement for compatibility with
  267.    IPv4 is to look at other product areas.  In the product world,
  268.    backwards compatability is very important.  Vendors who do not
  269.    provide backward compatibility for their customers usually find they
  270.    do not have many customers left.  For example, chip makers put
  271.    considerable effort into making sure that new versions of their
  272.    processor always run all of the software that ran on the previous
  273.    model.  It is unlikely that Intel would develop a new processor in
  274.    the X86 family that did not run DOS and the tens of thousands of
  275.    applications which run on the current versions of X86's.
  276.  
  277.    Operating system vendors go to great lengths to make sure new
  278.    versions of their operating systems are binary compatible with their
  279.  
  280.  
  281.  
  282. Hinden                                                          [Page 5]
  283.  
  284. RFC 1710                 SIPP IPng White Paper              October 1994
  285.  
  286.  
  287.    old version.  For example the labels on most PC or MAC software
  288.    usually indicate that they require OS version XX or greater.  It
  289.    would be foolish for Microsoft come out with a new version of Windows
  290.    which did not run the applications which ran on the previous version.
  291.    Microsoft even provides the ability for windows applications to run
  292.    on their new OS NT.  This is an important feature.  They understand
  293.    that it was very important to make sure that the applications which
  294.    run on Windows also run on NT.
  295.  
  296.    The same requirement is also true for IPng.  The Internet has a large
  297.    installed base.  Features need to be designed into an IPng to make
  298.    the transition as easy as possible.  As with processors and operating
  299.    systems, it must be backwards compatible with IPv4.  Other protocols
  300.    have tried to replace TCP/IP, for example XTP and OSI.  One element
  301.    in their failure to reach widespread acceptance was that neither had
  302.    any transition strategy other than running in parallel (sometimes
  303.    called dual stack).  New features alone are not adequate to motivate
  304.    users to deploy new protocols.  IPng must have a great transition
  305.    strategy and new features.
  306.  
  307. 3. History of the SIPP Effort
  308.  
  309.    The SIPP working group represents the evolution of three different
  310.    IETF working groups focused on developing an IPng.  The first was
  311.    called IP Address Encapsulation (IPAE) and was chaired by Dave
  312.    Crocker and Robert Hinden.  It proposed extensions to IPv4 which
  313.    would carry larger addresses.  Much of its work was focused on
  314.    developing transition mechanisms.
  315.  
  316.    Somewhat later Steve Deering proposed a new protocol evolved from
  317.    IPv4 called the Simple Internet Protocol (SIP).  A working group was
  318.    formed to work on this proposal which was chaired by Steve Deering
  319.    and Christian Huitema.  SIP had 64-bit addresses, a simplified
  320.    header, and options in separate extension headers.  After lengthly
  321.    interaction between the two working groups and the realization that
  322.    IPAE and SIP had a number of common elements and the transition
  323.    mechanisms developed for IPAE would apply to SIP, the groups decided
  324.    to merge and concentrate their efforts.  The chairs of the new SIP
  325.    working group were Steve Deering and Robert Hinden.
  326.  
  327.    In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded
  328.    a working group to develop the "P" Internet Protocol (Pip).  Pip was
  329.    a new internet protocol based on a new architecture.  The motivation
  330.    behind Pip was that the opportunity for introducing a new internet
  331.    protocol does not come very often and given that opportunity
  332.    important new features should be introduced.  Pip supported variable
  333.    length addressing in 16-bit units, separation of addresses from
  334.    identifiers, support for provider selection, mobility, and efficient
  335.  
  336.  
  337.  
  338. Hinden                                                          [Page 6]
  339.  
  340. RFC 1710                 SIPP IPng White Paper              October 1994
  341.  
  342.  
  343.    forwarding.  It included a transition scheme similar to IPAE.
  344.  
  345.    After considerable discussion among the leaders of the Pip and SIP
  346.    working groups, they came to realize that the advanced features in
  347.    Pip could be accomplished in SIP without changing the base SIP
  348.    protocol as well as keeping the IPAE transition mechanisms.  In
  349.    essence it was possible to keep the best features of each protocol.
  350.    Based on this the groups decided to merge their efforts.  The new
  351.    protocol was called Simple Internet Protocol Plus (SIPP).  The chairs
  352.    of the merged working group are Steve Deering, Paul Francis, and
  353.    Robert Hinden.
  354.  
  355. 4. SIPP Overview
  356.  
  357.    SIPP is a new version of the Internet Protocol, designed as a
  358.    successor to IP version 4 [IPV4].  SIPP is assigned IP version number
  359.    6.
  360.  
  361.    SIPP was designed to take an evolutionary step from IPv4.  It was not
  362.    a design goal to take a radical step away from IPv4.  Functions which
  363.    work in IPv4 were kept in SIPP.  Functions which didn't work were
  364.    removed.  The changes from IPv4 to SIPP fall primarily into the
  365.    following categories:
  366.  
  367.       o  Expanded Routing and Addressing Capabilities
  368.  
  369.         SIPP increases the IP address size from 32 bits to 64 bits, to
  370.         support more levels of addressing hierarchy and a much greater
  371.         number of addressable nodes.  SIPP addressing can be further
  372.         extended, in units of 64 bits, by a facility equivalent to
  373.         IPv4's Loose Source and Record Route option, in combination
  374.         with a new address type called "cluster addresses" which
  375.         identify topological regions rather than individual nodes.
  376.         The scaleability of multicast routing is improved by adding
  377.         a "scope" field to multicast addresses.
  378.  
  379.      o Header Format Simplification
  380.  
  381.         Some IPv4 header fields have been dropped or made optional, to
  382.         reduce the common-case processing cost of packet handling and to
  383.         keep the bandwidth cost of the SIPP header almost as low as that
  384.         of IPv4, despite the increased size of the addresses.  The basic
  385.         SIPP header is only four bytes longer than IPv4.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Hinden                                                          [Page 7]
  395.  
  396. RFC 1710                 SIPP IPng White Paper              October 1994
  397.  
  398.  
  399.      o Improved Support for Options
  400.  
  401.         Changes in the way IP header options are encoded allows for more
  402.         efficient forwarding, less stringent limits on the length of
  403.         options, and greater flexibility for introducing new options in
  404.         the future.
  405.  
  406.      o Quality-of-Service Capabilities
  407.  
  408.         A new capability is added to enable the labeling of packets
  409.         belonging to particular traffic "flows" for which the sender
  410.         requests special handling, such as non-default quality of
  411.         service or "real-time" service.
  412.  
  413.      o Authentication and Privacy Capabilities
  414.  
  415.         SIPP includes the definition of extensions which provide support
  416.         for authentication, data integrity, and confidentiality.  This
  417.         is included as a basic element of SIPP.
  418.  
  419.    The SIPP protocol consists of two parts, the basic SIPP header and
  420.    SIPP Options.
  421.  
  422. 4.1  SIPP Header Format
  423.  
  424.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425.       |Version|                       Flow Label                      |
  426.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427.       |         Payload Length        |  Payload Type |   Hop Limit   |
  428.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  429.       |                                                               |
  430.       +                         Source Address                        +
  431.       |                                                               |
  432.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  433.       |                                                               |
  434.       +                      Destination Address                      +
  435.       |                                                               |
  436.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  437.  
  438.  
  439.       Version              4-bit Internet Protocol version number = 6.
  440.  
  441.       Flow Label           28-bit field.  See SIPP Quality of Service
  442.                            section.
  443.  
  444.       Payload Length       16-bit unsigned integer.  Length of payload,
  445.                            i.e., the rest of the packet following the
  446.                            SIPP header, in octets.
  447.  
  448.  
  449.  
  450. Hinden                                                          [Page 8]
  451.  
  452. RFC 1710                 SIPP IPng White Paper              October 1994
  453.  
  454.  
  455.       Payload Type         8-bit selector.  Identifies the type of
  456.                            header immediately following the SIPP
  457.                            header.  Uses the same values as the IPv4
  458.                            Protocol field [STD 2, RFC 1700].
  459.  
  460.       Hop Limit            8-bit unsigned integer.  Decremented by 1
  461.                            by each node that forwards the packet.
  462.                            The packet is discarded if Hop Limit is
  463.                            decremented to zero.
  464.  
  465.       Source Address       64 bits.  An address of the initial sender of
  466.                            the packet.  See [ROUT] for details.
  467.  
  468.       Destination Address  64 bits.  An address of the intended
  469.                            recipient of the packet (possibly not the
  470.                            ultimate recipient, if an optional Routing
  471.                            Header is present).
  472.  
  473. 4.2 SIPP Options
  474.  
  475.    SIPP includes an improved option mechanism over IPv4.  SIPP options
  476.    are placed in separate headers that are located between the SIPP
  477.    header and the transport-layer header in a packet.  Most SIPP option
  478.    headers are not examined or processed by any router along a packet's
  479.    delivery path until it arrives at its final destination.  This
  480.    facilitates a major improvement in router performance for packets
  481.    containing options. In IPv4 the presence of any options requires the
  482.    router to examine all options.  The other improvement is that unlike
  483.    IPv4, SIPP options can be of arbitrary length and the total amount of
  484.    options carried in a packet is not limited to 40 bytes.  This feature
  485.    plus the manner in which they are processed, permits SIPP options to
  486.    be used for functions which were not practical in IPv4.  A good
  487.    example of this is the SIPP Authentication and Security Encapsulation
  488.    options.
  489.  
  490.    In order to improve the performance when handling subsequent option
  491.    headers and the transport protocol which follows, SIPP options are
  492.    always an integer multiple of 8 octets long, in order to retain this
  493.    alignment for subsequent headers.
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Hinden                                                          [Page 9]
  507.  
  508. RFC 1710                 SIPP IPng White Paper              October 1994
  509.  
  510.  
  511.    The SIPP option headers which are currently defined are:
  512.  
  513.      Option                     Function
  514.      ---------------            ---------------------------------------
  515.      Routing                    Extended Routing (like IPv4 loose source
  516.                                 route)
  517.      Fragmentation              Fragmentation and Reassembly
  518.      Authentication             Integrity and Authentication
  519.      Security Encapsulation     Confidentiality
  520.      Hop-by-Hop Option          Special options which require hop by hop
  521.                                 processing
  522.  
  523. 4.3 SIPP Addressing
  524.  
  525.    SIPP addresses are 64-bits long and are identifiers for individual
  526.    nodes and sets of nodes.  There are three types of SIPP addresses.
  527.    These are unicast, cluster, and multicast.  Unicast addresses
  528.    identify a single node.  Cluster addresses identify a group of nodes,
  529.    that share a common address prefix, such that a packet sent to a
  530.    cluster address will be delivered to one member of the group.
  531.    Multicast addresses identify a group of nodes, such that a packet
  532.    sent to a multicast address is delivered to all of the nodes in the
  533.    group.
  534.  
  535.    SIPP supports addresses which are twice the number of bits as IPv4
  536.    addresses.  These addresses support an address space which is four
  537.    billion (2^^32) times the size of IPv4 addresses (2^^32).  Another
  538.    way to say this is that SIPP supports four billion internets each the
  539.    size of the maximum IPv4 internet.  That is enough to allow each
  540.    person on the planet to have their own internet.  Even with several
  541.    layers of hierarchy (with assignment utilization similar to IPv4)
  542.    this would allow for each person on the planet to have their own
  543.    internet each holding several thousand hosts.
  544.  
  545.    In addition, SIPP supports extended addresses using the routing
  546.    option.  This capability allows the address space to grow to 128-
  547.    bits, 192-bits (or even larger) while still keeping the address units
  548.    in manageable 64-bit units.  This permits the addresses to grow while
  549.    keeping the routing algorithms efficient because they continue to
  550.    operate using 64- bit units.
  551.  
  552. 4.3.1 Unicast Addresses
  553.  
  554.    There are several forms of unicast address assignment in SIPP. These
  555.    are global hierarchical unicast addresses, local-use addresses, and
  556.    IPv4- only host addresses.  The assignment plan for unicast addresses
  557.    is described in [ADDR].
  558.  
  559.  
  560.  
  561.  
  562. Hinden                                                         [Page 10]
  563.  
  564. RFC 1710                 SIPP IPng White Paper              October 1994
  565.  
  566.  
  567. 4.3.1.1 Global Unicast Addresses
  568.  
  569.    Global unicast addresses are used for global communication.  They are
  570.    the most common SIPP address and are similar in function to IPv4
  571.    addresses.  Their format is:
  572.  
  573.      |1|      n bits       |        m bits       |   p bits  | 63-n-m-p|
  574.      +-+-------------------+---------------------+-----------+---------+
  575.      |C|    PROVIDER ID    |    SUBSCRIBER ID    | SUBNET ID | NODE ID |
  576.      +-+-------------------+---------------------+-----------+---------+
  577.  
  578.    The first bit is the IPv4 compatibility bit, or C-bit.  It indicates
  579.    whether the node represented by the address is IPv4 or SIPP.  SIPP
  580.    addresses are provider-oriented.  That is, the high-order part of the
  581.    address is assigned to internet service providers, which then assign
  582.    portions of the address space to subscribers, etc.  This usage is
  583.    similar to assignment of IP addresses under CIDR.  The SUBSCRIBER ID
  584.    distinguishes among multiple subscribers attached to the provider
  585.    identified by the PROVIDER ID.  The SUBNET ID identifies a
  586.    topologically connected group of nodes within the subscriber network
  587.    identified by the subscriber prefix.  The NODE ID identifies a single
  588.    node among the group of nodes identified by the subnet prefix.
  589.  
  590. 4.3.1.2 Local-Use Address
  591.  
  592.    A local-use address is a unicast address that has only local
  593.    routability scope (within the subnet or within a subscriber network),
  594.    and may have local or global uniqueness scope.  They are intended for
  595.    use inside of a site for "plug and play" local communication, for
  596.    bootstrapping up to a single global addresses, and as part of an
  597.    address sequence for global communication.  Their format is:
  598.  
  599.      | 4  |
  600.      |bits|    12 bits    |                 48 bits                    |
  601.      +----+---------------+--------------------------------------------+
  602.      |0110|   SUBNET ID   |                 NODE ID                    |
  603.      +----+---------------+--------------------------------------------+
  604.  
  605.    The NODE ID is an identifier which much be unique in the domain in
  606.    which it is being used.  In most cases these will use a node's IEEE-
  607.    802 48bit address.  The SUBNET ID identifies a specific subnet in a
  608.    site.  The combination of the SUBNET ID and the NODE ID to form a
  609.    local use address allows a large private internet to be constructed
  610.    without any other address allocation.
  611.  
  612.    Local-use addresses have two primary benefits.  First, for sites or
  613.    organizations that are not (yet) connected to the global Internet,
  614.    there is no need to request an address prefix from the global
  615.  
  616.  
  617.  
  618. Hinden                                                         [Page 11]
  619.  
  620. RFC 1710                 SIPP IPng White Paper              October 1994
  621.  
  622.  
  623.    Internet address space.  Local-use addresses can be used instead.  If
  624.    the organization connects to the global Internet, it can use it's
  625.    local use addresses to communicate with a server (e.g., using the
  626.    Dynamic Host Configuration Protocol [DHCP]) to have a global address
  627.    automatically assigned.
  628.  
  629.    The second benefit of local-use addresses is that they can hold much
  630.    larger NODE IDs, which makes possible a very simple form of auto-
  631.    configuration of addresses.  In particular, a node may discover a
  632.    SUBNET ID by listening to a Router Advertisement messages on its
  633.    attached link(s), and then fabricating a SIPP address for itself by
  634.    using its link-level address as the NODE ID on that subnet.
  635.  
  636.    An auto-configured local-use address may be used by a node as its own
  637.    identification for communication within the local domain, possibly
  638.    including communication with a local address server to obtain a
  639.    global SIPP address.  The details of host auto-configuration are
  640.    described in [DHCP].
  641.  
  642. 4.3.1.3 IPv4-Only Addresses
  643.  
  644.    SIPP unicast addresses are assigned to IPv4-only hosts as part of the
  645.    IPAE scheme for transition from IPv4 to SIPP.  Such addresses have
  646.    the following form:
  647.  
  648.      |1|            31 bits           |             32 bits            |
  649.      +-+------------------------------+--------------------------------+
  650.      |1|   HIGHER-ORDER SIPP PREFIX   |          IPv4 ADDRESS          |
  651.      +-+------------------------------+--------------------------------+
  652.  
  653.    The highest-order bit of a SIPP address is called the IPv4
  654.    compatibility bit or the C bit. A C bit value of 1 identifies an
  655.    address as belonging to an IPv4-only node.
  656.  
  657.    The IPv4 node's 32-bit IPv4 address is carried in the low-order 32
  658.    bits of the SIPP address.  The remaining 31 bits are used to carry
  659.    HIGHER- ORDER SIPP PREFIX, such as a service-provider ID.
  660.  
  661. 4.3.2  Cluster Addresses
  662.  
  663.    Cluster addresses are unicast addresses that are used to reach the
  664.    "nearest" one (according to unicast routing's notion of nearest) of
  665.    the set of boundary routers of a cluster of nodes identified by a
  666.    common prefix in the SIPP unicast routing hierarchy.  These are used
  667.    to identify a set of nodes.  The cluster address, when used as part
  668.    of an address sequence, permits a node to select which of several
  669.    providers it wants to carry its traffic.  A cluster address can only
  670.    be used as a destination address.  In this example there would be a
  671.  
  672.  
  673.  
  674. Hinden                                                         [Page 12]
  675.  
  676. RFC 1710                 SIPP IPng White Paper              October 1994
  677.  
  678.  
  679.    cluster address for each provider.  This capability is sometimes
  680.    called "source selected policies".  Cluster addresses have the
  681.    general form:
  682.  
  683.      |              n bits             |           64-n bits           |
  684.      +---------------------------------+-------------------------------+
  685.      |          CLUSTER PREFIX         |0000000000000000000000000000000|
  686.      +---------------------------------+-------------------------------+
  687.  
  688. 4.3.3  Multicast Addresses
  689.  
  690.    A SIPP multicast address is an identifier for a group of nodes.  A
  691.    node may belong to any number of multicast groups.  Multicast
  692.    addresses have the following format:
  693.  
  694.  
  695.      |1|   7   |  4 |  4 |                  48 bits                    |
  696.      +-+-------+----+----+---------------------------------------------+
  697.      |C|1111111|FLGS|SCOP|                  GROUP ID                   |
  698.      +-+-------+----+----+---------------------------------------------+
  699.  
  700.    Where:
  701.  
  702.      C = IPv4 compatibility bit.
  703.  
  704.      1111111 in the rest of the first octet identifies the address as
  705.      being a multicast address.
  706.  
  707.                                    +-+-+-+-+
  708.      FLGS is a set of 4 flags:     |0|0|0|T|
  709.                                    +-+-+-+-+
  710.  
  711.      The high-order 3 flags are reserved, and must be initialized to 0.
  712.  
  713.      T = 0 indicates a permanently-assigned ("well-known") multicast
  714.            address, assigned by the global internet numbering authority.
  715.  
  716.      T = 1 indicates a non-permanently-assigned ("transient") multicast
  717.            address.
  718.  
  719.      SCOP is a 4-bit multicast scope value used to limit the scope of
  720.      the multicast group.  The values are:
  721.  
  722.         0  reserved                  8  intra-organization scope
  723.         1  intra-node scope          9  (unassigned)
  724.         2  intra-link scope          10  (unassigned)
  725.         3  (unassigned)              11  intra-community scope
  726.         4  (unassigned)              12  (unassigned)
  727.  
  728.  
  729.  
  730. Hinden                                                         [Page 13]
  731.  
  732. RFC 1710                 SIPP IPng White Paper              October 1994
  733.  
  734.  
  735.         5  intra-site scope          13  (unassigned)
  736.         6  (unassigned)              14  global scope
  737.         7  (unassigned)              15  reserved
  738.  
  739.      GROUP ID identifies the multicast group, either permanent or
  740.      transient, within the given scope.
  741.  
  742. 4.4 SIPP Routing
  743.  
  744.    Routing in SIPP is almost identical to IPv4 routing under CIDR except
  745.    that the addresses are 64-bit SIPP addresses instead of 32-bit IPv4
  746.    addresses.  This is true even when extended addresses are being used.
  747.    With very straightforward extensions, all of IPv4's routing
  748.    algorithms (OSPF, BGP, RIP, IDRP, etc.) can used to route SIPP [OSPF]
  749.    [RIP2] [IDRP].
  750.  
  751.    SIPP also includes simple routing extensions which support powerful
  752.    new routing functionality.  These capabilities include:
  753.  
  754.         Provider Selection (based on policy, performance, cost, etc.)
  755.         Host Mobility (route to current location)
  756.         Auto-Readdressing (route to new address)
  757.         Extended Addressing (route to "sub-cloud")
  758.  
  759.    The new routing functionality is obtained by creating sequences of
  760.    SIPP addresses using the SIPP Routing option.  The routing option is
  761.    used by a SIPP source to list one or more intermediate nodes (or
  762.    topological clusters) to be "visited" on the way to a packet's
  763.    destination.  This function is very similar in function to IPv4's
  764.    Loose Source and Record Route option.  A node would publish its
  765.    address sequence in the Domain Name System [DNS].
  766.  
  767.    The identification of a specific transport connection is done by only
  768.    using the first (source) and last (destination) address in the
  769.    sequence.  These identifying addresses (i.e., first and last
  770.    addresses of a route sequence) are required to be unique within the
  771.    scope over which they are used.  This permits the middle addresses in
  772.    the address sequence to change (in the cases of mobility, provider
  773.    changes, site readdressing, etc.) without disrupting the transport
  774.    connection.
  775.  
  776.    In order to make address sequences a general function, SIPP hosts are
  777.    required to reverse routes in a packet it receives containing address
  778.    sequences in order to return the packet to its originator.  This
  779.    approach is taken to make SIPP host implementations from the start
  780.    support the handling and reversal of source routes.  This is the key
  781.    for allowing them to work with hosts which implement the new features
  782.    such as provider selection or extended addresses.
  783.  
  784.  
  785.  
  786. Hinden                                                         [Page 14]
  787.  
  788. RFC 1710                 SIPP IPng White Paper              October 1994
  789.  
  790.  
  791.    Three examples show how the extended addressing can be used.  In
  792.    these examples, address sequences are shown by a list of individual
  793.    addresses separated by commas.  For example:
  794.  
  795.        SRC, I1, I2, I3, DST
  796.  
  797.    Where the first address is the source address, the last address is
  798.    the destination address, and the middle addresses are intermediate
  799.    addresses.
  800.  
  801.    For these examples assume that two hosts, H1 and H2 wish to
  802.    communicate.  Assume that H1 and H2's sites are both connected to
  803.    providers P1 and P2.  A third wireless provider, PR, is connected to
  804.    both providers P1 and P2.
  805.  
  806.                            ----- P1 ------
  807.                           /       |       \
  808.                          /        |        \
  809.                        H1        PR        H2
  810.                          \        |        /
  811.                           \       |       /
  812.                            ----- P2 ------
  813.  
  814.    The simplest case (no use of address sequences) is when H1 wants to
  815.    send a packet to H2 containing the addresses:
  816.  
  817.            H1, H2
  818.  
  819.    When H2 replied it would reverse the addresses and construct a packet
  820.    containing the addresses:
  821.  
  822.            H2, H1
  823.  
  824.    In this example either provider could be used, and H1 and H2 would
  825.    not be able to select which provider traffic would be sent to and
  826.    received from.
  827.  
  828.    If H1 decides that it wants to enforce a policy that all
  829.    communication to/from H2 can only use provider P1, it would construct
  830.    a packet containing the address sequence:
  831.  
  832.            H1, P1, H2
  833.  
  834.    This ensures that when H2 replies to H1, it will reverse the route
  835.    and the reply it would also travel over P1.  The addresses in H2's
  836.    reply would look like:
  837.  
  838.            H2, P1, H1
  839.  
  840.  
  841.  
  842. Hinden                                                         [Page 15]
  843.  
  844. RFC 1710                 SIPP IPng White Paper              October 1994
  845.  
  846.  
  847.    If H1 became mobile and moved to provider PR, it could maintain (not
  848.    breaking any transport connections) communication with H2, by sending
  849.    packets that contain the address sequence:
  850.  
  851.            H1, PR, P1, H2
  852.  
  853.    This would ensure that when H2 replied it would enforce H1's policy
  854.    of exclusive use of provider P1 and send the packet to H1 new
  855.    location on provider PR.  The reversed address sequence would be:
  856.  
  857.            H2, P1, PR, H1
  858.  
  859.    The address extension facility of SIPP can be used for provider
  860.    selection, mobility, readdressing, and extended addressing.  It is a
  861.    simple but powerful capability.
  862.  
  863. 4.5 SIPP Quality-of-Service Capabilities
  864.  
  865.    The Flow Label field in the SIPP header may be used by a host to
  866.    label those packets for which it requests special handling by SIPP
  867.    routers, such as non-default quality of service or "real-time"
  868.    service.  This labeling is important in order to support applications
  869.    which require some degree of consistent throughput, delay, and/or
  870.    jitter.  The Flow Label is a 28-bit field, internally structured into
  871.    three subfields as follows:
  872.  
  873.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  874.      |R|  DP |                    Flow ID                    |
  875.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  876.  
  877.      R (Reserved)       1-bit subfield.  Initialized to zero for
  878.                         transmission; Ignored on reception.
  879.  
  880.      DP (Drop Priority) 3-bit unsigned integer.  Specifies the
  881.                         priority of the packet, relative to other
  882.                         packets from the same source, for being
  883.                         discarded by a router under conditions of
  884.                         congestion.  Larger values indicates a
  885.                         greater willingness by the sender to allow
  886.                         the packet to be discarded.
  887.  
  888.      Flow ID            24-bit subfield used to identify a
  889.                         specific flow.
  890.  
  891.    A flow is a sequence of packets sent from a particular source to a
  892.    particular (unicast or multicast) destination for which the source
  893.    desires special handling by the intervening routers.  There may be
  894.    multiple active flows from a source to a destination, as well as
  895.  
  896.  
  897.  
  898. Hinden                                                         [Page 16]
  899.  
  900. RFC 1710                 SIPP IPng White Paper              October 1994
  901.  
  902.  
  903.    traffic that is not associated with any flow.  A flow is identified
  904.    by the combination of a Source Address and a non-zero Flow ID.
  905.    Packets that do not belong to a flow carry a Flow ID of zero.
  906.  
  907.    A Flow ID is assigned to a flow by the flow's source node.  New Flow
  908.    IDs must be chosen (pseudo-)randomly and uniformly from the range 1
  909.    to FFFFFF hex.  The purpose of the random allocation is to make any
  910.    set of bits within the Flow ID suitable for use as a hash key by the
  911.    routers, for looking up the special-handling state associated with
  912.    the flow.  A Flow ID must not be re-used by a source for a new flow
  913.    while any state associated with the previous usage still exists in
  914.    any router.
  915.  
  916.    The Drop Priority subfield provides a means separate from the Flow ID
  917.    for distinguishing among packets from the same source, to allow a
  918.    source to specify which of its packets are to be discarded in
  919.    preference to others when a router cannot forward them all.  This is
  920.    useful for applications like video where it is preferable to drop
  921.    packets carrying screen updates rather than the packets carrying the
  922.    video synchronization information.
  923.  
  924. 4.6 SIPP Security
  925.  
  926.    The current Internet has a number of security problems and lacks
  927.    effective privacy and authentication mechanisms below the application
  928.    layer.  SIPP remedies these shortcomings by having two integrated
  929.    options that provide security services.  These two options may be
  930.    used singly or together to provide differing levels of security to
  931.    different users.  This is very important because different user
  932.    communities have different security needs.
  933.  
  934.    The first mechanism, called the "SIPP Authentication Header", is an
  935.    option which provides authentication and integrity (without
  936.    confidentiality) to SIPP datagrams.  While the option is algorithm-
  937.    independent and will support many different authentication
  938.    techniques, the use of keyed MD5 is proposed to help ensure
  939.    interoperability within the worldwide Internet.  This can be used to
  940.    eliminate a significant class of network attacks, including host
  941.    masquerading attacks.  The use of the SIPP Authentication Header is
  942.    particularly important when source routing is used with SIPP because
  943.    of the known risks in IP source routing.  Its placement at the
  944.    internet layer can help provide host origin authentication to those
  945.    upper layer protocols and services that currently lack meaningful
  946.    protections.  This mechanism should be exportable by vendors in the
  947.    United States and other countries with similar export restrictions
  948.    because it only provides authentication and integrity, and
  949.    specifically does not provide confidentiality.  The exportability of
  950.    the SIPP Authentication Header encourages its widespread
  951.  
  952.  
  953.  
  954. Hinden                                                         [Page 17]
  955.  
  956. RFC 1710                 SIPP IPng White Paper              October 1994
  957.  
  958.  
  959.    implementation and use.
  960.  
  961.    The second security option provided with SIPP is the "SIPP
  962.    Encapsulating Security Header".  This mechanism provides integrity
  963.    and confidentiality to SIPP datagrams.  It is simpler than some
  964.    similar security protocols (e.g., SP3D, ISO NLSP) but remains
  965.    flexible and algorithm-independent.  To achieve interoperability
  966.    within the global Internet, the use of DES CBC is proposed as the
  967.    standard algorithm for use with the SIPP Encapsulating Security
  968.    Header.
  969.  
  970. 5. SIPP Transition Mechanisms
  971.  
  972.    The two key motivations in the SIPP transition mechanisms are to
  973.    provide direct interoperability between IPv4 and SIPP hosts and to
  974.    allow the user population to adopt SIPP in an a highly diffuse
  975.    fashion.  The transition must be incremental, with few or no critical
  976.    interdependencies, if it is to succeed.  The SIPP transition allows
  977.    the users to upgrade their hosts to SIPP, and the network operators
  978.    to deploy SIPP in routers, with very little coordination between the
  979.    two.
  980.  
  981.    The mechanisms and policies of the SIPP transition are called "IPAE".
  982.    Having a separate term serves to highlight those features designed
  983.    specifically for transition.  Once an acronym for an encapsulation
  984.    technique to facilitate transition, the term "IPAE" now is mostly
  985.    historical.
  986.  
  987.    The IPAE transition is based on five key elements:
  988.  
  989.     1) A 64-bit SIPP addressing plan that encompasses the existing
  990.        32-bit IPv4 addressing plan.  The 64-bit plan will be used to
  991.        assign addresses for both SIPP and IPv4 nodes at the beginning
  992.        of the transition.  Existing IPv4 nodes will not need to change
  993.        their addresses, and IPv4 hosts being upgraded to SIPP keep their
  994.        existing IPv4 addresses as the low-order 32 bits of their SIPP
  995.        addresses.  Since the SIPP addressing plan is a superset of the
  996.        existing IPv4 plan, SIPP hosts are assigned only a single 64-bit
  997.        address, which can be used to communicate with both SIPP and IPv4
  998.        hosts.
  999.  
  1000.     2) A mechanism for encapsulating SIPP traffic within IPv4 packets so
  1001.        that the IPv4 infrastructure can be leveraged early in the
  1002.        transition.  Most of the "SIPP within IPv4 tunnels" can be
  1003.        automatically configured.
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Hinden                                                         [Page 18]
  1011.  
  1012. RFC 1710                 SIPP IPng White Paper              October 1994
  1013.  
  1014.  
  1015.     3) Algorithms in SIPP hosts that allow them to directly interoperate
  1016.        with IPv4 hosts located on the same subnet and elsewhere in the
  1017.        Internet.
  1018.  
  1019.     4) A mechanism for translating between IPv4 and SIPP headers to
  1020.        allow SIPP-only hosts to communicate with IPv4-only hosts and to
  1021.        facilitate IPv4 hosts communicating over over a SIPP-only
  1022.        backbone.
  1023.  
  1024.     5) An optional mechanism for mapping IPv4 addresses to SIPP address
  1025.        to allow improved scaling of IPv4 routing.  At the present time
  1026.        given the success of CIDR, this does not look like it will be
  1027.        needed in a transition to SIPP.  If Internet growth should
  1028.        continue beyond what CIDR can handle, it is available as an
  1029.        optional mechanism.
  1030.  
  1031.    IPAE ensures that SIPP hosts can interoperate with IPv4 hosts
  1032.    anywhere in the Internet up until the time when IPv4 addresses run
  1033.    out, and afterward allows SIPP and IPv4 hosts within a limited scope
  1034.    to interoperate indefinitely.  This feature protects for a very long
  1035.    time the huge investment users have made in IPv4.  Hosts that need
  1036.    only a limited connectivity range (e.g., printers) need never be
  1037.    upgraded to SIPP.  This feature also allows SIPP-only hosts to
  1038.    interoperate with IPv4-only hosts.
  1039.  
  1040.    The incremental upgrade features of IPAE allow the host and router
  1041.    vendors to integrate SIPP into their product lines at their own pace,
  1042.    and allows the end users and network operators to deploy SIPP on
  1043.    their own schedules.
  1044.  
  1045.    The interoperability between SIPP and IPv4 provided by IPAE also has
  1046.    the benefit of extending the lifetime of IPv4 hosts.  Given the large
  1047.    installed base of IPv4, changes to IPv4 in hosts are nearly
  1048.    impossible.  Once an IPng is chosen, most of the new feature
  1049.    development will be done on IPng.  New features in IPng will increase
  1050.    the incentives to adopt and deploy it.
  1051.  
  1052. 6. Why SIPP?
  1053.  
  1054.    There are a number of reasons why SIPP should be selected as the
  1055.    IETF's IPng.  It solves the Internet scaling problem, provides a
  1056.    flexible transition mechanism for the current Internet, and was
  1057.    designed to meet the needs of new markets such as nomadic personal
  1058.    computing devices, networked entertainment, and device control.  It
  1059.    does this in a evolutionary way which reduces the risk of
  1060.    architectural problems.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Hinden                                                         [Page 19]
  1067.  
  1068. RFC 1710                 SIPP IPng White Paper              October 1994
  1069.  
  1070.  
  1071.    Ease of transition is a key point in the design of SIPP.  It is not
  1072.    something was was added in at the end.  SIPP is designed to
  1073.    interoperate with IPv4.  Specific mechanisms (C-bit, embedded IPv4
  1074.    addresses, etc.) were built into SIPP to support transition and
  1075.    compatability with IPv4.  It was designed to permit a gradual and
  1076.    piecemeal deployment without any dependencies.
  1077.  
  1078.    SIPP supports large hierarchical addresses which will allow the
  1079.    Internet to continue to grow and provide new routing capabilities not
  1080.    built into IPv4.  It has cluster addresses which can be used for
  1081.    policy route selection and has scoped multicast addresses which
  1082.    provide improved scaleability over IPv4 multicast.  It also has local
  1083.    use addresses which provide the ability for "plug and play"
  1084.    installation.
  1085.  
  1086.    SIPP is designed to have performance better than IPv4 and work well
  1087.    in low bandwidth applications like wireless.  Its headers are less
  1088.    expensive to process than IPv4 and its 64-bit addresses are chosen to
  1089.    be well matched to the new generation of 64bit processors.  Its
  1090.    compact header minimizes bandwidth overhead which makes it ideal for
  1091.    wireless use.
  1092.  
  1093.    SIPP provides a platform for new Internet functionality.  This
  1094.    includes support for real-time flows, provider selection, host
  1095.    mobility, end-to- end security, auto-configuration, and auto-
  1096.    reconfiguration.
  1097.  
  1098.    In summary, SIPP is a new version of IP.  It can be installed as a
  1099.    normal software upgrade in internet devices.  It is interoperable
  1100.    with the current IPv4.  Its deployment strategy was designed to not
  1101.    have any "flag" days.  SIPP is designed to run well on high
  1102.    performance networks (e.g., ATM) and at the same time is still
  1103.    efficient for low bandwidth networks (e.g., wireless).  In addition,
  1104.    it provides a platform for new internet functionality that will be
  1105.    required in the near future.
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Hinden                                                         [Page 20]
  1123.  
  1124. RFC 1710                 SIPP IPng White Paper              October 1994
  1125.  
  1126.  
  1127. 7. Status of SIPP Effort
  1128.  
  1129.    There are many active participants in the SIPP working group.  Groups
  1130.    making active contributions include:
  1131.  
  1132.    Group                   Activity
  1133.    ---------------------   ----------------------------------------
  1134.    Beame & Whiteside       Implementation (PC)
  1135.    Bellcore                Implementation (SunOS), DNS and ICMP specs.
  1136.    Digital Equipment Corp. Implementation (Alpha/OSF, Open VMS)
  1137.    INRIA                   Implementation (BSD, BIND), DNS & OSPF specs.
  1138.    INESC                   Implementation (BSD/Mach/x-kernel)
  1139.    Intercon                Implementation (MAC)
  1140.    MCI                     Phone Conferences
  1141.    Merit                   IDRP for SIPP Specification
  1142.    Naval Research Lab.     Implementation (BSD) Security Design
  1143.    Network General         Implementation (Sniffer)
  1144.    SGI                     Implementation (IRIX, NetVisulizer)
  1145.    Sun                     Implementation (Solaris 2.x, Snoop)
  1146.    TGV                     Implementation (Open VMS)
  1147.    Xerox PARC              Protocol Design
  1148.    Bill Simpson            Implementation (KA9Q)
  1149.  
  1150.    As of the time this paper was written there were a number of SIPP and
  1151.    IPAE implementations.  These include:
  1152.  
  1153.    Implementation          Status
  1154.    --------------          ------------------------------------
  1155.    BSD/Mach                Completed (telnet, NFS, AFS, UDP)
  1156.    BSD/Net/2               In Progress
  1157.    Bind                    Code done
  1158.    DOS &Windows            Completed (telnet, ftp, tftp, ping)
  1159.    IRIX                    In progress (ping)
  1160.    KA9Q                    In progress (ping, TCP)
  1161.    Mac OS                  Completed (telnet, ftp, finger, ping)
  1162.    NetVisualizer           Completed (SIP & IPAE)
  1163.    Open VMS                Completed (telnet, ftp), In Progress
  1164.    OSF/1                   In Progress (ping, ICMP)
  1165.    Sniffer                 Completed (SIP & IPAE)
  1166.    Snoop                   Completed (SIP & IPAE)
  1167.    Solaris                 Completed (telnet, ftp, tftp, ping)
  1168.    Sun OS                  In Progress
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Hinden                                                         [Page 21]
  1179.  
  1180. RFC 1710                 SIPP IPng White Paper              October 1994
  1181.  
  1182.  
  1183. 8. Where to Get Additional Information
  1184.  
  1185.    The documentation listed in the reference sections can be found in
  1186.    one of the IETF internet draft directories or in the archive site for
  1187.    the SIPP working group.  This is located at:
  1188.  
  1189.            ftp.parc.xerox.com      in the /pub/sipp        directory.
  1190.  
  1191.    In addition other material relating to SIPP (such as postscript
  1192.    versions of presentations on SIPP) can also be found in the SIPP
  1193.    working group archive.
  1194.  
  1195.    To join the SIPP working group, send electronic mail to
  1196.  
  1197.            sipp-request@sunroof.eng.sun.com
  1198.  
  1199.    An archive of mail sent to this mailing list can be found in the IETF
  1200.    directories at cnri.reston.va.us.
  1201.  
  1202. 9. Security Considerations
  1203.  
  1204.    Security issues are discussed in section 4.6.
  1205.  
  1206. 10. Author's Address
  1207.  
  1208.    Robert M. Hinden
  1209.    Manager, Internet Engineering
  1210.    Sun Microsystems, Inc.
  1211.    MS MTV5-44
  1212.    2550 Garcia Ave.
  1213.    Mt. View, CA 94303
  1214.  
  1215.    Phone: (415) 336-2082
  1216.    Fax: (415) 336-6016
  1217.    EMail: hinden@eng.sun.com
  1218.  
  1219. 11. References
  1220.  
  1221.    [ADDR]  Francis, P., "Simple Internet Protocol Plus (SIPP): Unicast
  1222.            Hierarchical Address Assignment", Work in Progress, January
  1223.            1994.
  1224.  
  1225.    [AUTH]  Atkinson, R., "SIPP Authentication Payload",
  1226.            Work in Progress, January, 1994.
  1227.  
  1228.    [CIDR]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:
  1229.            an Address Assignment and Aggregation Strategy", RFC 1338,
  1230.            BARRNet, cisco, Merit, OARnet, June 1992.
  1231.  
  1232.  
  1233.  
  1234. Hinden                                                         [Page 22]
  1235.  
  1236. RFC 1710                 SIPP IPng White Paper              October 1994
  1237.  
  1238.  
  1239.    [DISC]  Simpson, W., "SIPP Neighbor Discovery", Work in Progress,
  1240.            March 1994.
  1241.  
  1242.    [DIS2]  Simpson, W., "SIPP Neighbor Discovery -- ICMP Message
  1243.            Formats", Work in Progress, March 1994.
  1244.  
  1245.    [DHCP]  Thomson, S., "Simple Internet Protocol Plus (SIPP): Automatic
  1246.            Host Address Assignment", Work in Progress, March 1994.
  1247.  
  1248.    [DNS]   Thomson, S., and C. Huitema, "DNS Extensions to Support
  1249.            Simple Internet Protocol Plus (SIPP)", Work in Progress,
  1250.            March 1994.
  1251.  
  1252.    [ICMP]  Govindan, R., and S. Deering, "ICMP and IGMP for the Simple
  1253.            Internet Protocol Plus (SIPP)", Work in Progress, March 1994.
  1254.  
  1255.    [IDRP]  Hares, S., "IDRP for SIP", Work in Progress, November 1993.
  1256.  
  1257.    [IPAE]  Gilligan, R., et al, "IPAE: The SIPP Interoperability and
  1258.            Transition Mechanism", Work in Progress, March 1994.
  1259.  
  1260.    [IPV4]  Postel, J., "Internet Protocol- DARPA Internet Program
  1261.            Protocol Specification", STD 5, RFC 791, DARPA,
  1262.            September 1981.
  1263.  
  1264.    [OSPF]  Francis, P., "OSPF for SIPP", Work in Progress, February
  1265.            1994.
  1266.  
  1267.    [RIP2]  Malkin, G., and C. Huitema, "SIP-RIP", Work in Progress,
  1268.            March 1993.
  1269.  
  1270.    [ROUT]  Deering, S., et al, "Simple Internet Protocol Plus (SIPP):
  1271.            Routing and Addressing", Work in Progress, February 1994.
  1272.  
  1273.    [SARC]  Atkinson, R., "SIPP Security Architecture", Work in Progress,
  1274.            January 1994.
  1275.  
  1276.    [SECR]  Atkinson, R., "SIPP Encapsulating Security Payload (ESP)",
  1277.            Work in Progress, January 1994.
  1278.  
  1279.    [SIPP]  Deering, S., "Simple Internet Protocol Plus (SIPP)
  1280.            Specification", Work in Progress, February 1994.
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Hinden                                                         [Page 23]
  1291.  
  1292.