home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1752 < prev    next >
Text File  |  1995-01-13  |  128KB  |  2,916 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         S. Bradner
  8. Request for Comments: 1752                            Harvard University
  9. Category: Standards Track                                      A. Mankin
  10.                                                                      ISI
  11.                                                             January 1995
  12.  
  13.  
  14.          The Recommendation for the IP Next Generation Protocol
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document presents the recommendation of the IPng Area Directors
  27.    on what should be used to replace the current version of the Internet
  28.    Protocol.  This recommendation was accepted by the Internet
  29.    Engineering Steering Group (IESG).
  30.  
  31. Table of Contents
  32.  
  33.    1.        Summary. . . . . . . . . . . . . . . . . . . . . . . . .  2
  34.    2.        Background . . . . . . . . . . . . . . . . . . . . . . .  4
  35.    3.        A Direction for IPng . . . . . . . . . . . . . . . . . .  5
  36.    4.        IPng Area. . . . . . . . . . . . . . . . . . . . . . . .  6
  37.    5.        ALE Working Group. . . . . . . . . . . . . . . . . . . .  6
  38.      5.1     ALE Projections. . . . . . . . . . . . . . . . . . . . .  7
  39.      5.2     Routing Table Size . . . . . . . . . . . . . . . . . . .  7
  40.      5.3     Address Assignment Policy Recommendations. . . . . . . .  8
  41.    6.        IPng Technical Requirements. . . . . . . . . . . . . . .  8
  42.      6.1     The IPng Technical Criteria document . . . . . . . . . .  9
  43.    7.        IPng Proposals . . . . . . . . . . . . . . . . . . . . . 11
  44.      7.1     CATNIP. . .  . . . . . . . . . . . . . . . . . . . . . . 11
  45.      7.2     SIPP. . . .  . . . . . . . . . . . . . . . . . . . . . . 12
  46.      7.3     TUBA. . . .  . . . . . . . . . . . . . . . . . . . . . . 13
  47.    8.        IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 13
  48.      8.1     CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 14
  49.      8.2     SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 15
  50.      8.3     TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 16
  51.      8.4     Summary of Proposal Reviews. . . . . . . . . . . . . . . 17
  52.    9.        A Revised Proposal . . . . . . . . . . . . . . . . . . . 17
  53.    10        Assumptions .  . . . . . . . . . . . . . . . . . . . . . 18
  54.      10.1    Criteria Document and Timing of Recommendation . . . . . 18
  55.  
  56.  
  57.  
  58. Bradner & Mankin                                                [Page 1]
  59.  
  60. RFC 1752                Recommendation for IPng             January 1995
  61.  
  62.  
  63.      10.2    Address Length . . . . . . . . . . . . . . . . . . . . . 19
  64.    11.       IPng Recommendation. . . . . . . . . . . . . . . . . . . 19
  65.      11.1    IPng Criteria Document and IPng. . . . . . . . . . . . . 20
  66.      11.2    IPv6. . . . .  . . . . . . . . . . . . . . . . . . . . . 21
  67.    12.       IPv6 Overview  . . . . . . . . . . . . . . . . . . . . . 21
  68.      12.1    IPv6 Header Format . . . . . . . . . . . . . . . . . . . 24
  69.      12.2    Extension Headers. . . . . . . . . . . . . . . . . . . . 25
  70.      12.2.1  Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 25
  71.      12.2.2  IPv6 Header Options. . . . . . . . . . . . . . . . . . . 26
  72.      12.2.3  Routing Header . . . . . . . . . . . . . . . . . . . . . 27
  73.      12.2.4  Fragment Header. . . . . . . . . . . . . . . . . . . . . 28
  74.      12.2.5  Authentication Header. . . . . . . . . . . . . . . . . . 29
  75.      12.2.6  Privacy Header . . . . . . . . . . . . . . . . . . . . . 30
  76.      12.2.7  End-to-End Option Header . . . . . . . . . . . . . . . . 32
  77.    13.       IPng Working Group . . . . . . . . . . . . . . . . . . . 32
  78.    14.       IPng Reviewer  . . . . . . . . . . . . . . . . . . . . . 33
  79.    15.       Address Autoconfiguration. . . . . . . . . . . . . . . . 33
  80.    16.       Transition . . . . . . . . . . . . . . . . . . . . . . . 34
  81.      16.1    Transition - Short Term. . . . . . . . . . . . . . . . . 35
  82.      16.2    Transition - Long Term . . . . . . . . . . . . . . . . . 36
  83.    17.       Other Address Families . . . . . . . . . . . . . . . . . 37
  84.    18.       Impact on Other IETF Standards . . . . . . . . . . . . . 38
  85.    19.       Impact on non-IETF standards and on products . . . . . . 39
  86.    20.       APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39
  87.    21.       Future of the IPng Area and Working Groups . . . . . . . 40
  88.    22.       Security Considerations. . . . . . . . . . . . . . . . . 40
  89.    23.       Authors' Addresses . . . . . . . . . . . . . . . . . . . 43
  90.  
  91.    Appendix A    Summary of Recommendations . . . . . . . . . . . . . 44
  92.    Appendix B    IPng Area Directorate. . . . . . . . . . . . . . . . 45
  93.    Appendix C    Documents Referred to the IPng Working Groups. . . . 46
  94.    Appendix D    IPng Proposal Overviews. . . . . . . . . . . . . . . 46
  95.    Appendix E    RFC 1550 White Papers. . . . . . . . . . . . . . . . 47
  96.    Appendix F    Additional References. . . . . . . . . . . . . . . . 48
  97.    Appendix G    Acknowledgments. . . . . . . . . . . . . . . . . . . 52
  98.  
  99. 1. Summary
  100.  
  101.    The IETF started its effort to select a successor to IPv4 in late
  102.    1990 when projections indicated that the Internet address space would
  103.    become an increasingly limiting resource.  Several parallel efforts
  104.    then started exploring ways to resolve these address limitations
  105.    while at the same time providing additional functionality.  The IETF
  106.    formed the IPng Area in late 1993 to investigate the various
  107.    proposals and recommend how to proceed.  We developed an IPng
  108.    technical criteria document and evaluated the various proposals
  109.    against it.  All were found wanting to some degree.  After this
  110.    evaluation, a revised proposal was offered by one of the working
  111.  
  112.  
  113.  
  114. Bradner & Mankin                                                [Page 2]
  115.  
  116. RFC 1752                Recommendation for IPng             January 1995
  117.  
  118.  
  119.    groups that resolved many of the problems in the previous proposals.
  120.    The IPng Area Directors recommend that the IETF designate this
  121.    revised proposal as the IPng and focus its energy on bringing a set
  122.    of documents defining the IPng to Proposed Standard status with all
  123.    deliberate speed.
  124.  
  125.    This protocol recommendation includes a simplified header with a
  126.    hierarchical address structure that permits rigorous route
  127.    aggregation and is also large enough to meet the needs of the
  128.    Internet for the foreseeable future. The protocol also includes
  129.    packet-level authentication and encryption along with plug and play
  130.    autoconfiguration.  The design changes the way IP header options are
  131.    encoded to increase the flexibility of introducing new options in the
  132.    future while improving performance. It also includes the ability to
  133.    label traffic flows.
  134.  
  135.    Specific recommendations include:
  136.  
  137.    * current address assignment policies are adequate
  138.    * there is no current need to reclaim underutilized assigned network
  139.      numbers
  140.    * there is no current need to renumber major portions of the Internet
  141.    * CIDR-style assignments of parts of unassigned Class A address space
  142.      should be considered
  143.    * "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)"
  144.      [Deering94b] be adopted as the basis for IPng
  145.    * the documents listed in Appendix C be the foundation of the IPng
  146.      effort
  147.    * an IPng Working Group be formed, chaired by Steve Deering and Ross
  148.      Callon
  149.    * Robert Hinden be the document editor for the IPng effort
  150.    * an IPng Reviewer be appointed and that Dave Clark be the reviewer
  151.    * an Address Autoconfiguration Working Group be formed, chaired by
  152.      Dave Katz and Sue Thomson
  153.    * an IPng Transition Working Group be formed, chaired by Bob Gilligan
  154.      and TBA
  155.    * the Transition and Coexistence Including Testing Working Group be
  156.      chartered
  157.    * recommendations about the use of non-IPv6 addresses in IPv6
  158.      environments and IPv6 addresses in non-IPv6 environments be
  159.      developed
  160.    * the IESG commission a review of all IETF standards documents for
  161.      IPng implications
  162.    * the IESG task current IETF working groups to take IPng into account
  163.    * the IESG charter new working groups where needed to revise old
  164.      standards documents
  165.    * Informational RFCs be solicited or developed describing a few
  166.      specific IPng APIs
  167.  
  168.  
  169.  
  170. Bradner & Mankin                                                [Page 3]
  171.  
  172. RFC 1752                Recommendation for IPng             January 1995
  173.  
  174.  
  175.    * the IPng Area and Area Directorate continue until main documents
  176.      are offered as Proposed Standards in late 1994
  177.    * support for the Authentication Header be required
  178.    * support for a specific authentication algorithm be required
  179.    * support for the Privacy Header be required
  180.    * support for a specific privacy algorithm be required
  181.    * an "IPng framework for firewalls" be developed
  182.  
  183. 2. Background
  184.  
  185.    Even the most farseeing of the developers of TCP/IP in the early
  186.    1980s did not imagine the dilemma of scale that the Internet faces
  187.    today.  1987 estimates projected a need to address as many as 100,000
  188.    networks at some vague point in the future. [Callon87]  We will reach
  189.    that mark by 1996.  There are many realistic projections of many
  190.    millions of interconnected networks in the not too distant future.
  191.    [Vecchi94, Taylor94]
  192.  
  193.    Further, even though the current 32 bit IPv4 address structure can
  194.    enumerate over 4 billion hosts on as many as 16.7 million networks,
  195.    the actual address assignment efficiency is far less than that, even
  196.    on a theoretical basis. [Huitema94]  This inefficiency is exacerbated
  197.    by the granularity of assignments using Class A, B and C addresses.
  198.  
  199.    In August 1990 during the Vancouver IETF meeting, Frank Solensky,
  200.    Phill Gross and Sue Hares projected that the current rate of
  201.    assignment would exhaust the Class B space by March of 1994.
  202.  
  203.    The then obvious remedy of assigning multiple Class C addresses in
  204.    place of Class B addresses introduced its own problem by further
  205.    expanding the size of the routing tables in the backbone routers
  206.    already growing at an alarming rate.
  207.  
  208.    We faced the dilemma of choosing between accepting either limiting
  209.    the rate of growth and ultimate size of the Internet, or disrupting
  210.    the network by changing to new techniques or technologies.
  211.  
  212.    The IETF formed the Routing and Addressing (ROAD) group in November
  213.    1991 at the Santa Fe IETF meeting to explore this dilemma and guide
  214.    the IETF on the issues.  The ROAD group reported their work in March
  215.    1992 at the San Diego IETF meeting.  [Gross92]  The impact of the
  216.    recommendations ranged from "immediate" to "long term" and included
  217.    adopting the CIDR route aggregation proposal [Fuller93] for reducing
  218.    the rate of routing table growth and recommending a call for
  219.    proposals "to form working groups to explore separate approaches for
  220.    bigger Internet addresses."
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bradner & Mankin                                                [Page 4]
  227.  
  228. RFC 1752                Recommendation for IPng             January 1995
  229.  
  230.  
  231.    In the late spring of 1992 the IAB issued "IP version 7" [IAB92],
  232.    concurring in the ROAD group's endorsement of CIDR and also
  233.    recommending "an immediate IETF effort to prepare a detailed and
  234.    organizational plan for using CLNP as the basis for IPv7." After
  235.    spirited discussion, the IETF decided to reject the IAB's
  236.    recommendation and issue the call for  proposals recommended by the
  237.    ROAD group.  This call was issued in July 1992 at the Boston IETF
  238.    meeting and a number of working groups were formed in response
  239.  
  240.    During the July 1993 Amsterdam IETF meeting an IPng (IP Next
  241.    Generation) Decision Process (ipdecide) BOF was held.  This BOF "was
  242.    intended to help re-focus attention on the very important topic of
  243.    making a decision between the candidates for IPng. The BOF focused on
  244.    the issues of who should take the lead in making the recommendation
  245.    to the community and what criteria should be used to reach the
  246.    recommendation." [Carpen93]
  247.  
  248. 3. A Direction for IPng
  249.  
  250.    In September 1993 Phill Gross, chair of the IESG issued "A Direction
  251.    for IPng".  [Gross94]  In this memo he summarized the results of the
  252.    ipdecide BOF and open IESG plenary in Amsterdam.
  253.  
  254.    * The IETF needs to move toward closure on IPng.
  255.    * The IESG has the responsibility for developing an IPng
  256.      recommendation for the Internet community.
  257.    * The procedures of the recommendation-making process should be open
  258.      and published well in advance by the IESG.
  259.    * As part of this process, the IPng WGs may be given new milestones
  260.      and other guidance to aid the IESG.
  261.    * There should be ample opportunity for community comment prior to
  262.      final IESG recommendation.
  263.  
  264.    The memo also announced "a temporary, ad hoc, 'area' to deal
  265.    specifically with IPng issues."  Phill asked two of the current IESG
  266.    members, Allison Mankin (Transport Services Area) and Scott Bradner
  267.    (Operational Requirements Area), to act as Directors for the new
  268.    area. The Area Directors were given a specific charge on how to
  269.    investigate the various IPng proposals and how to base their
  270.    recommendation to the IETF.  It was also requested that a specific
  271.    recommendation be made.
  272.  
  273.    * Establish an IPng directorate.
  274.    * Ensure that a completely open process is followed.
  275.    * Develop an understanding of the level of urgency and the time
  276.      constraints imposed by the rate of address assignment and rate of
  277.      growth in the routing tables.
  278.    * Recommend the adoption of assignment policy changes if warranted.
  279.  
  280.  
  281.  
  282. Bradner & Mankin                                                [Page 5]
  283.  
  284. RFC 1752                Recommendation for IPng             January 1995
  285.  
  286.  
  287.    * Define the scope of the IPng effort based on the understanding of
  288.      the time constraints.
  289.    * Develop a clear and concise set of technical requirements and
  290.      decision criteria for IPng.
  291.    * Develop a recommendation about which of the current IPng candidates
  292.      to accept, if any.
  293.  
  294. 4. IPng Area
  295.  
  296.    After the IPng Area was formed, we recruited a directorate. (Appendix
  297.    B) The members of the directorate were chosen both for their general
  298.    and specific technical expertise.  The individuals were then asked to
  299.    have their management authorize this participation in the process and
  300.    confirm that they understood the IETF process.
  301.  
  302.    We took great care to ensure the inclusion of a wide spectrum of
  303.    knowledge. The directors are experts in security, routing, the needs
  304.    of large users, end system manufacturers, Unix and non-Unix
  305.    platforms, router manufacturers, theoretical researchers, protocol
  306.    architecture, and the operating regional, national, and international
  307.    networks.  Additionally, several members of the directorate were
  308.    deeply involved in each of the IPng proposal working groups.
  309.  
  310.    The directorate functions as a direction-setting and preliminary
  311.    review body as requested by the charge to the area.  The directorate
  312.    engages in biweekly conference calls, participates in an internal
  313.    mailing list and corresponds actively on the Big-Internet mailing
  314.    list. The directorate held open meetings during the March 1994
  315.    Seattle and July 1994 Toronto IETF meetings as well as two additional
  316.    multi-day retreats.  To ensure that the IPng process was as open as
  317.    possible, we took minutes during these meetings and then published
  318.    them. Additionally, we placed the archives of the internal IPng
  319.    mailing list on an anonymous ftp site. (Hsdndev.harvard.edu:
  320.    pub/ipng.)
  321.  
  322. 5. ALE Working Group
  323.  
  324.    We needed a reasonable estimate of the time remaining before we
  325.    exhausted the IPv4 address space in order to determine the scope of
  326.    the IPng effort.  If the time remaining was about the same needed to
  327.    deploy a replacement, then we would have select the IPng which would
  328.    only fix the address limitations since we would not have enough time
  329.    to develop any other features.  If more time seemed available, we
  330.    could consider additional improvements.
  331.  
  332.    The IETF formed an Address Lifetime Expectations (ALE) Working Group
  333.    in 1993 "to develop an estimate for the remaining lifetime of the
  334.    IPv4 address space based on currently known and available
  335.  
  336.  
  337.  
  338. Bradner & Mankin                                                [Page 6]
  339.  
  340. RFC 1752                Recommendation for IPng             January 1995
  341.  
  342.  
  343.    technologies." [Solens93a]  Tony Li of Cisco Systems and Frank
  344.    Solensky of FTP Software are the co-chairs.  The IETF also charged
  345.    the working group to consider if developing more stringent address
  346.    allocation and utilization policies might provide more time for the
  347.    transition.
  348.  
  349. 5.1 ALE Projections
  350.  
  351.    The ALE Working Group met during the November 1993 Houston,
  352.    [Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto
  353.    [Solens94] IETF meetings.  They projected at the Seattle meeting,
  354.    later confirmed at the Toronto meeting that, using the current
  355.    allocation statistics, the Internet would exhaust the IPv4 address
  356.    space between 2005 and 2011.
  357.  
  358.    Some members of the ipv4-ale and big-internet mailing lists called
  359.    into question the reliability of this projection.  It has been
  360.    criticized as both too optimistic and as too pessimistic.
  361.  
  362.    Some people pointed out that this type of projection makes an
  363.    assumption of no paradigm shifts in IP usage.  If someone were to
  364.    develop a new 'killer application', (for example cable-TV set top
  365.    boxes.)  The resultant rise in the demand for IP addresses could make
  366.    this an over-estimate of the time available.
  367.  
  368.    There may also be a problem with the data used to make the
  369.    projection.  The InterNIC allocates IP addresses in large chunks to
  370.    regional Network Information Centers (NICs) and network providers.
  371.    The NICs and the providers then re-allocate addresses to their
  372.    customers.  The ALE projections used the InterNIC assignments without
  373.    regard to the actual rate of assignment of addresses to the end
  374.    users.  They did the projection this way since the accuracy of the
  375.    data seems quite a bit higher.  While using this once-removed data
  376.    may add a level of over-estimation since it assumes the rate of large
  377.    block allocation will continue, this may not be the case.
  378.  
  379.    These factors reduce the reliability of the ALE estimates but, in
  380.    general, they seem to indicate enough time remaining in the IPv4
  381.    address space to consider adding features in an IPng besides just
  382.    expanding the address size even when considering time required for
  383.    development, testing, and deployment.
  384.  
  385. 5.2 Routing Table Size
  386.  
  387.    Another issue in Internet scaling is the increasing size of the
  388.    routing tables required in the backbone routers.  Adopting the CIDR
  389.    block address assignment and aggregating routes reduced the size of
  390.    the tables for awhile but they are now expanding again. Providers now
  391.  
  392.  
  393.  
  394. Bradner & Mankin                                                [Page 7]
  395.  
  396. RFC 1752                Recommendation for IPng             January 1995
  397.  
  398.  
  399.    need to more aggressively advertise their routes only in aggregates.
  400.    Providers must also advise their new customers to renumber their
  401.    networks in the best interest of the entire Internet community.
  402.  
  403.    The problem of exhausting the IPv4 address space may be moot if this
  404.    issue is ignored and if routers cannot be found that can keep up with
  405.    the table size growth.  Before implementing CIDR the backbone routing
  406.    table was growing at a rate about 1.5 times as fast as memory
  407.    technology.
  408.  
  409.    We should also note that even though IPng addresses are designed with
  410.    aggregation in mind switching to IPng will not solve the routing
  411.    table size problem unless the addresses are assigned rigorously to
  412.    maximize the affect of such aggregation.  This efficient advertising
  413.    of routes can be maintained since IPng includes address
  414.    autoconfiguration mechanisms to allow easy renumbering if a customer
  415.    decides to switch providers.  Customers who receive service from more
  416.    than one provider may limit the ultimate efficiency of any route
  417.    aggregation. [Rekhter94]
  418.  
  419. 5.3 Address Assignment Policy Recommendations
  420.  
  421.    The IESG Chair charged the IPng Area to consider recommending more
  422.    stringent assignment policies, reclaiming some addresses already
  423.    assigned, or making a serious effort to renumber significant portions
  424.    of the Internet. [Gross94]
  425.  
  426.    The IPng Area Directors endorse the current address assignment
  427.    policies in view of the ALE projections.  We do not feel that anyone
  428.    should take specific efforts to reclaim underutilized addresses
  429.    already assigned or to renumber forcefully major portions of the
  430.    Internet.  We do however feel that we should all encourage network
  431.    service providers to assist new customers in renumbering their
  432.    networks to conform to the provider's CIDR assignments.
  433.  
  434.    The ALE Working Group recommends that we consider assigning CIDR-type
  435.    address blocks out of the unassigned Class A address space.  The IPng
  436.    Area Directors concur with this recommendation.
  437.  
  438. 6. IPng Technical Requirements
  439.  
  440.    The IESG provided an outline in RFC 1380 [Gross92] of the type of
  441.    criteria we should use to determine the suitability of an IPng
  442.    proposal.  The IETF further refined this understanding of the
  443.    appropriate criteria with the recommendations of a Selection Criteria
  444.    BOF held during the November 1992 IETF meeting in Washington D.C.
  445.    [Almqu92]  We felt we needed to get additional input for determining
  446.    the requirements and issued a call for white papers. [Bradner93] This
  447.  
  448.  
  449.  
  450. Bradner & Mankin                                                [Page 8]
  451.  
  452. RFC 1752                Recommendation for IPng             January 1995
  453.  
  454.  
  455.    call, issued as RFC 1550, intended to reach both inside and outside
  456.    the traditional IETF constituency to get the broadest possible
  457.    understanding of the requirements for a data networking protocol with
  458.    the broadest possible application.
  459.  
  460.    We received twenty one white papers in response to the RFC 1550
  461.    solicitation. ( Appendix E)  We received responses from the
  462.    industries that many feel will be the major providers of data
  463.    networking services in the future; the cable TV industry [Vecchi94],
  464.    the cellular industry [Taylor94], and the electric power industry
  465.    [Skelton94].  In addition, we received papers that dealt with
  466.    military applications [Adam94, Syming94, Green94], ATM [Brazd94],
  467.    mobility [Simpson94], accounting [Brown94], routing [Estrin94a,
  468.    Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94,
  469.    Flei94], large corporate networking [Britt94, Fleisch94], transition
  470.    [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host
  471.    implementations [Bound94], as well as a number of other issues.
  472.    [Bello94a, Clark94, Ghisel94]
  473.  
  474.    These white papers, a Next Generation Requirements (ngreq) BOF
  475.    (chaired by Jon Crowcroft and Frank Kastenholz) held during the March
  476.    1994 Seattle IETF meeting, discussions within the IPng Area
  477.    Directorate and considerable discussion on the big-internet mailing
  478.    list were all used by Frank Kastenholz and Craig Partridge in
  479.    revising their earlier criteria draft [Kasten92] to produce
  480.    "Technical Criteria for Choosing IP The Next Generation (IPng)."
  481.    [Kasten94]  This document is the "clear and concise set of technical
  482.    requirements and decision criteria for IPng" called for in the charge
  483.    from the IESG Chair.  We used this document as the basic guideline
  484.    while evaluating the IPng proposals.
  485.  
  486. 6.1 The IPng Technical Criteria document
  487.  
  488.    The criteria described in this document include: (from Kasten94)
  489.  
  490.    * complete specification - The proposal must completely describe the
  491.      proposed protocol.  We must select an IPng by referencing specific
  492.      documents, not to future work.
  493.    * architectural simplicity - The IP-layer protocol should be as
  494.      simple as possible with functions located elsewhere that are more
  495.      appropriately performed at protocol layers other than the IP layer.
  496.    * scale - The IPng Protocol must allow identifying and addressing at
  497.      least 10**9 leaf-networks (and preferably much more)
  498.    * topological flexibility - The routing architecture and protocols
  499.      ofIPng must allow for many different network topologies.  They must
  500.      not assume that the network's physical structure is a tree.
  501.    * performance - A state of the art, commercial grade router must be
  502.      able to process and forward IPng traffic at speeds capable of fully
  503.  
  504.  
  505.  
  506. Bradner & Mankin                                                [Page 9]
  507.  
  508. RFC 1752                Recommendation for IPng             January 1995
  509.  
  510.  
  511.      utilizing common, commercially available, high-speed media at the
  512.      time.
  513.    * robust service - The network service and its associated routing and
  514.      control protocols must be robust.
  515.    * transition -  The protocol must have a straightforward transition
  516.      plan from IPv4.
  517.    * media independence -  The protocol must work across an internetwork
  518.      of many different LAN, MAN, and WAN media, with individual link
  519.      speeds ranging from a ones-of-bits per second to hundreds of
  520.      gigabits per second.
  521.    * datagram service - The protocol must support an unreliable datagram
  522.      delivery service.
  523.    * configuration ease -  The protocol must permit easy and largely
  524.      distributed configuration and operation. Automatic configuration of
  525.      hosts and routers is required.
  526.    * security - IPng must provide a secure network layer.
  527.    * unique names - IPng must assign unique names to all IP-Layer
  528.      objects in the global, ubiquitous, Internet.  These names may or
  529.      may not have any location, topology, or routing significance.
  530.    * access to standards -  The protocols that define IPng and its
  531.      associated protocols should be as freely available and
  532.      redistributable as the IPv4 and related RFCs.  There must be no
  533.      specification-related licensing fees for implementing or selling
  534.      IPng software.
  535.    * multicast support - The protocol must support both unicast and
  536.      multicast packet transmission.   Dynamic and automatic routing of
  537.      multicasts is also required.
  538.    * extensibility -  The protocol must be extensible; it must be able
  539.      to evolve to meet the future service needs of the Internet. This
  540.      evolution must be achievable without requiring network-wide
  541.      software upgrades.
  542.    * service classes - The protocol must allow network devices to
  543.      associate packets with particular service classes and provide them
  544.      with the  services specified by those classes.
  545.    * mobility - The protocol must support mobile hosts, networks and
  546.      internetworks.
  547.    * control protocol - The protocol must include elementary support for
  548.      testing and debugging networks. (e.g., ping and traceroute)
  549.    * tunneling support -  IPng must allow users to build private
  550.      internetworks on top of the basic Internet Infrastructure.  Both
  551.      private IP-based internetworks and private non-IP-based (e.g., CLNP
  552.      or AppleTalk) internetworks must be supported.
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Bradner & Mankin                                               [Page 10]
  563.  
  564. RFC 1752                Recommendation for IPng             January 1995
  565.  
  566.  
  567. 7. IPng Proposals
  568.  
  569.    By the time that the IPng Area was formed, the IETF had already aimed
  570.    a considerable amount of IETF effort at solving the addressing and
  571.    routing problems of the Internet.  Several proposals had been made
  572.    and some of these reached the level of having a working group
  573.    chartered.  A number of these groups subsequently merged forming
  574.    groups with a larger consensus.  These efforts represented different
  575.    views on the issues which confront us and sought to optimize
  576.    different aspects of the possible solutions.
  577.  
  578.    By February 1992 the Internet community developed four separate
  579.    proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps"
  580.    [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b].  By
  581.    December 1992 three more proposals followed; "The P Internet
  582.    Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP)
  583.    [Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego
  584.    IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger
  585.    Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP
  586.    Address Encapsulation" (IPAE) [Hinden92b].
  587.  
  588.    By November 1993, IPAE merged with SIP while still maintaining the
  589.    name SIP. This group then merged with PIP and the resulting working
  590.    group called themselves "Simple Internet Protocol Plus" (SIPP).  At
  591.    the same time the TP/IX Working Group changed its name to "Common
  592.    Architecture for the Internet" (CATNIP).
  593.  
  594.    None of these proposals were wrong nor were others right.  All of the
  595.    proposals would work in some ways providing a path to overcome the
  596.    obstacles we face as the Internet expands. The task of the IPng Area
  597.    was to ensure that the IETF understand the offered proposals, learn
  598.    from the proposals and provide a recommendation on what path best
  599.    resolves the basic issues while providing the best foundation upon
  600.    which to build for the future.
  601.  
  602.    The IPng Area evaluated three IPng proposals as they were described
  603.    in their RFC 1550 white papers: CATNIP [McGovern94] , SIPP
  604.    [Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much
  605.    of a research project for consideration as an IPng candidate.  Since
  606.    Nimrod represents one possible future Internet routing strategy we
  607.    solicited a paper describing any requirements Nimrod would put on an
  608.    IPng to add to the requirements process. [Chiappa94]
  609.  
  610. 7.1 CATNIP
  611.  
  612.    "Common Architecture for the Internet (CATNIP) was conceived as a
  613.    convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP
  614.    design provides for any of the transport layer protocols in use, for
  615.  
  616.  
  617.  
  618. Bradner & Mankin                                               [Page 11]
  619.  
  620. RFC 1752                Recommendation for IPng             January 1995
  621.  
  622.  
  623.    example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the
  624.    network layer protocol formats: CLNP, IP (version 4), IPX, and
  625.    CATNIP.  With some attention paid to details, it is possible for a
  626.    transport layer protocol (such as TCP) to operate properly with one
  627.    end system using one network layer (e.g., IP version 4) and the other
  628.    using some other network protocol, such as CLNP." [McGovern94]
  629.  
  630.    "The objective is to provide common ground between the Internet, OSI,
  631.    and the Novell protocols, as well as to advance the Internet
  632.    technology to the scale and performance of the next generation of
  633.    internetwork technology."
  634.  
  635.    "CATNIP supports OSI Network Service Access Point (NSAP) format
  636.    addresses.  It also uses cache handles to provide both rapid
  637.    identification of the next hop in high performance routing as well as
  638.    abbreviation of the network header by permitting the addresses to be
  639.    omitted when a valid cache handle is available. The fixed part of the
  640.    network layer header carries the cache handles." [Sukonnik94]
  641.  
  642. 7.2 SIPP
  643.  
  644.    "Simple Internet Protocol Plus (SIPP) is a new version of IP which is
  645.    designed to be an evolutionary step from IPv4.  It is a natural
  646.    increment to IPv4.  It was not a design goal to take a radical step
  647.    away from IPv4.  Functions which work in IPv4 were kept in SIPP.
  648.    Functions which didn't work were removed. It can be installed as a
  649.    normal software upgrade in internet devices and is interoperable with
  650.    the current IPv4.  Its deployment strategy was designed to not have
  651.    any 'flag' days.  SIPP is designed to run well on high performance
  652.    networks (e.g., ATM) and at the same time is still efficient for low
  653.    bandwidth networks (e.g., wireless).  In addition, it provides a
  654.    platform for new internet functionality that will be required in the
  655.    near future." [Hinden94b]
  656.  
  657.    "SIPP increases the IP address size from 32 bits to 64 bits, to
  658.    support more levels of addressing hierarchy and a much greater number
  659.    of addressable nodes.  SIPP addressing can be further extended, in
  660.    units of 64 bits, by a facility equivalent to IPv4's Loose Source and
  661.    Record Route option, in combination with a new address type called
  662.    'cluster addresses' which identify topological regions rather than
  663.    individual nodes."
  664.  
  665.    "SIPP changes in the way IP header options are encoded allows for
  666.    more efficient forwarding, less stringent limits on the length of
  667.    options, and greater flexibility for introducing new options in the
  668.    future. A new capability is added to enable the labeling of packets
  669.    belonging to particular traffic 'flows' for which the sender requests
  670.    special handling, such as non-default quality of service or 'real-
  671.  
  672.  
  673.  
  674. Bradner & Mankin                                               [Page 12]
  675.  
  676. RFC 1752                Recommendation for IPng             January 1995
  677.  
  678.  
  679.    time' service." [Hinden94a]
  680.  
  681. 7.3 TUBA
  682.  
  683.    "The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to
  684.    minimize the risk associated with migration to a new IP address
  685.    space. In addition, this proposal is motivated by the requirement to
  686.    allow the Internet to scale, which implies use of Internet
  687.    applications in a very large ubiquitous worldwide Internet. It is
  688.    therefore proposed that existing Internet transport and application
  689.    protocols continue to operate unchanged, except for the replacement
  690.    of 32-bit IP addresses with larger addresses.  TUBA does not mean
  691.    having to move over to OSI completely. It would mean only replacing
  692.    IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would
  693.    run on top of CLNP." [Callon92c]
  694.  
  695.    "The TUBA effort will expand the ability to route Internet packets by
  696.    using addresses which support more hierarchy than the current
  697.    Internet Protocol (IP) address space. TUBA specifies the continued
  698.    use of Internet transport protocols, in particular TCP and UDP, but
  699.    specifies their encapsulation in ISO 8473 (CLNP) packets.  This will
  700.    allow the continued use of Internet application protocols such as
  701.    FTP, SMTP, TELNET, etc.   TUBA seeks to upgrade the current system by
  702.    a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the
  703.    corresponding large Network Service Access Point (NSAP) address
  704.    space." [Knopper94]
  705.  
  706.    "The TUBA proposal makes use of a simple long-term migration proposal
  707.    based on a gradual update of Internet Hosts (to run Internet
  708.    applications over CLNP) and DNS servers (to return larger addresses).
  709.    This proposal requires routers to be updated to support forwarding of
  710.    CLNP (in addition to IP). However, this proposal does not require
  711.    encapsulation nor translation of packets nor address mapping. IP
  712.    addresses and NSAP addresses may be assigned and used independently
  713.    during the migration period. Routing and forwarding of IP and CLNP
  714.    packets may be done independently." ([Callon92c]
  715.  
  716. 8. IPng Proposal Reviews
  717.  
  718.    The IPng Directorate discussed and reviewed the candidate proposals
  719.    during its biweekly teleconferences and through its mailing list.  In
  720.    addition, members of the Big-Internet mailing list discussed many of
  721.    the aspects of the proposals, particularly when the Area Directors
  722.    posted several specific questions to stimulate discussion. [Big]
  723.  
  724.    The directorate members were requested to each evaluate the proposals
  725.    in preparation for a two day retreat held near Chicago on May 19th
  726.    and 20th 1994.  The retreat opened with a roundtable airing of the
  727.  
  728.  
  729.  
  730. Bradner & Mankin                                               [Page 13]
  731.  
  732. RFC 1752                Recommendation for IPng             January 1995
  733.  
  734.  
  735.    views of each of the participants, including the Area Directors, the
  736.    Directorate and a number of guests invited by the working group
  737.    chairs for each for the proposals. [Knopper94b]  We will publish
  738.    these reviews as well as a more detailed compendium review of each of
  739.    the proposals as companion memos.
  740.  
  741.    The following table summarizes each of the three proposals reviewed
  742.    against the requirements in the IPng Criteria document.  They do not
  743.    necessarily reflect the views of the Area Directors.  "Yes" means the
  744.    reviewers mainly felt the proposal met the specific criterion.  "No"
  745.    means the reviewers mainly felt the proposal did not meet the
  746.    criterion.  "Mixed" means that the reviewers had mixed reviews with
  747.    none dominating. "Unknown" means that the reviewers mainly felt the
  748.    documentation did not address the criterion.
  749.  
  750.                            CATNIP          SIPP            TUBA
  751.                            ------          ----            ----
  752.    complete spec           no              yes             mostly
  753.    simplicity              no              no              no
  754.    scale                   yes             yes             yes
  755.    topological flex        yes             yes             yes
  756.    performance             mixed           mixed           mixed
  757.    robust service          mixed           mixed           yes
  758.    transition              mixed           no              mixed
  759.    media indepdnt          yes             yes             yes
  760.    datagram                yes             yes             yes
  761.    config. ease            unknown         mixed           mixed
  762.    security                unknown         mixed           mixed
  763.    unique names            mixed           mixed           mixed
  764.    access to stds          yes             yes             mixed
  765.    multicast               unknown         yes             mixed
  766.    extensibility           unknown         mixed           mixed
  767.    service classes         unknown         yes             mixed
  768.    mobility                unknown         mixed           mixed
  769.    control proto           unknown         yes             mixed
  770.    tunneling               unknown         yes             mixed
  771.  
  772. 8.1 CATNIP Reviews
  773.  
  774.    All the reviewers felt that CATNIP is not completely specified.
  775.    However, many of the ideas in CATNIP are innovative and a number of
  776.    reviewers felt CATNIP shows the best vision of all of the proposals.
  777.    The use of Network Service Attachment Point Addresses (NSAPs) is well
  778.    thought out and the routing handles are innovative.
  779.  
  780.    While the goal of uniting three major protocol families, IP, ISO-CLNP
  781.    and Novell IPX is laudable our consensus was that the developers had
  782.    not developed detailed enough plans to support realizing that goal.
  783.  
  784.  
  785.  
  786. Bradner & Mankin                                               [Page 14]
  787.  
  788. RFC 1752                Recommendation for IPng             January 1995
  789.  
  790.  
  791.    The plans they do describe suffer from the complexity of trying to be
  792.    the union of a number of existing network protocols.  Some reviewers
  793.    felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into
  794.    NSAPs and, as such, does not deal with the routing problems of the
  795.    current and future Internet.
  796.  
  797.    Additionally the reviewers felt that CATNIP has poor support for
  798.    multicasting and mobility and does not specifically deal with such
  799.    important topics as security and autoconfiguration.
  800.  
  801. 8.2 SIPP Reviews
  802.  
  803.    Most of the reviewers, including those predisposed to other
  804.    proposals, felt as one reviewer put it, that SIPP is an
  805.    "aesthetically beautiful protocol well tailored to compactly satisfy
  806.    today's known network requirements."  The SIPP Working Group has been
  807.    the most dynamic over the last year, producing a myriad of
  808.    documentation detailing almost all of the aspects necessary to
  809.    produce a complete protocol description.
  810.  
  811.    The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
  812.    transition plan.  The overwhelming feeling was that IPAE is fatally
  813.    flawed and could not be made to work reliably in an operational
  814.    Internet.
  815.  
  816.    There was significant disagreement about the adequacy of the SIPP 64
  817.    bit address size.  Although you can enumerate 10**15 end nodes in 64
  818.    bits people have different views about how much inefficiency real-
  819.    world routing plans introduce. [Huitema94]  The majority felt that 64
  820.    bit addresses do not provide adequate space for the hierarchy
  821.    required to meet the needs of the future Internet. In addition since
  822.    no one has any experience with extended addressing and routing
  823.    concepts of the type proposed in SIPP, the reviewers generally felt
  824.    quite uncomfortable with this methodology.  The reviewers also felt
  825.    that the design introduces some significant security issues.
  826.  
  827.    A number of reviewers felt that SIPP did not address the routing
  828.    issue in any useful way.  In particular, there has been no serious
  829.    attempt made at developing ways to abstract topology information or
  830.    to aggregate information about areas of the network.
  831.  
  832.    Finally, most of the reviewers questioned the level of complexity in
  833.    the SIPP autoconfiguration plans as well as in SIPP in general, other
  834.    than the header itself.
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Bradner & Mankin                                               [Page 15]
  843.  
  844. RFC 1752                Recommendation for IPng             January 1995
  845.  
  846.  
  847. 8.3 TUBA Reviews
  848.  
  849.    The reviewers generally felt that the most important thing that TUBA
  850.    has offers is that it is based on CLNP and there is significant
  851.    deployment of CLNP-capable routers throughout the Internet.  There
  852.    was considerably less agreement that there was significant deployment
  853.    of CLNP-capable hosts or actual networks running CLNP.  Another
  854.    strong positive for TUBA is the potential for convergence of ISO and
  855.    IETF networking standards.  A number of reviewers pointed out that,
  856.    if TUBA were to be based on a changed CLNP then the advantage of an
  857.    existing deployed infrastructure would be lost and that the
  858.    convergence potential would be reduced.
  859.  
  860.    A number of aspects of CLNP were felt to be a problem by the
  861.    reviewers including the inefficiencies introduced by the lack of any
  862.    particular word alignment of the header fields, CLNP source route,
  863.    the lack of a flow ID field, the lack of a protocol ID field, and the
  864.    use of CLNP error messages in TUBA. The CLNP packet format or
  865.    procedures would have to be modified to resolve at least some of
  866.    these issues.
  867.  
  868.    There seems to be a profound disagreement within the TUBA community
  869.    over the question of the ability of the IETF to modify the CLNP
  870.    standards.  In our presentation in Houston we said that we felt that
  871.    "clone and run" was a legitimate process.  This is also what the IAB
  872.    proposed in "IP version 7". [IAB92]  The TUBA community has not
  873.    reached consensus that this view is reasonable.  While many,
  874.    including a number of the CLNP document authors, are adamant that
  875.    this is not an issue and the IETF can make modifications to the base
  876.    standards, many others are just as adamant that the standards can
  877.    only be changed through the ISO standards process.  Since the
  878.    overwhelming feeling within the IETF is that the IETF must 'own' the
  879.    standards on which it is basing its future, this disagreement within
  880.    the TUBA community was disquieting.
  881.  
  882.    For a number of reasons, unfortunately including prejudice in a few
  883.    cases, the reviews of the TUBA proposals were much more mixed than
  884.    for SIPP or CATNIP. Clearly TUBA meets the requirements for the
  885.    ability to scale to large numbers of hosts, supports flexible
  886.    topologies, is media independent and is a datagram protocol.  To the
  887.    reviewers, it was less clear that TUBA met the other IPng
  888.    requirements and these views varied widely.
  889.  
  890.    There was also disagreement over the advisability of using NSAPs for
  891.    routing given the wide variety of NSAP allocation plans.  The
  892.    Internet would have to restrict the use of NSAPs to those which are
  893.    allocated with the actual underlying network topology in mind if the
  894.    required degree of aggregation of routing information is to be
  895.  
  896.  
  897.  
  898. Bradner & Mankin                                               [Page 16]
  899.  
  900. RFC 1752                Recommendation for IPng             January 1995
  901.  
  902.  
  903.    achieved.
  904.  
  905. 8.4 Summary of Proposal Reviews
  906.  
  907.    To summarize, significant problems were seen in all three of the
  908.    proposals. The feeling was that, to one degree or another, both SIPP
  909.    and TUBA would work in the Internet context but each exhibited its
  910.    own problems.  Some of these problems would have to be rectified
  911.    before either one would be ready to replace IPv4, much less be the
  912.    vehicle to carry the Internet into the future.  Other problems could
  913.    be addressed over time.  CATNIP was felt to be too incomplete to be
  914.    considered.
  915.  
  916. 9. A Revised Proposal
  917.  
  918.    As mentioned above, there was considerable discussion of the
  919.    strengths and weaknesses of the various IPng proposals during the
  920.    IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b]  After
  921.    this retreat Steve Deering and Paul Francis, two of the co-chairs of
  922.    the SIPP Working Group, sent a message to the sipp mailing list
  923.    detailing the discussions at the retreat and proposing some changes
  924.    in SIPP. [Deering94a]
  925.  
  926.    The message noted "The recurring (and unsurprising) concerns about
  927.    SIPP were:
  928.  
  929.    (1) complexity/manageability/feasibility of IPAE, and
  930.  
  931.    (2) adequacy/correctness/limitations of SIPP's addressing and routing
  932.        model, especially the use of loose source routing to accomplish
  933.        'extended addressing'".
  934.  
  935.    They "proposed to address these concerns by changing SIPP as follows:
  936.  
  937.    * Change address size from 8 bytes to 16 bytes (fixed-length).
  938.  
  939.    * Specify optional use of serverless autoconfiguration of the 16-byte
  940.      address by using IEEE 802 address as the low-order ("node ID")
  941.      part.
  942.  
  943.    * For higher-layer protocols that use internet-layer addresses as
  944.      part of connection identifiers (e.g., TCP), require that they use
  945.      the entire 16-byte addresses.
  946.  
  947.    * Do *not* use Route Header for extended addressing."
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Bradner & Mankin                                               [Page 17]
  955.  
  956. RFC 1752                Recommendation for IPng             January 1995
  957.  
  958.  
  959.    After considerable discussion on the sipp and big-internet mailing
  960.    lists about these proposed changes, the SIPP working group published
  961.    a revised version of SIPP [Deering94b], a new addressing architecture
  962.    [Francis94], and a simplified transition mechanism [Gillig94a].
  963.    These were submitted to the IPng Directorate for their consideration.
  964.  
  965.    This proposal represents a synthesis of multiple IETF efforts with
  966.    much of the basic protocol coming from the SIPP effort, the
  967.    autoconfiguration and transition portions influenced by TUBA, the
  968.    addressing structure is based on the CIDR work and the routing header
  969.    evolving out of the SDRP deliberations.
  970.  
  971. 10. Assumptions
  972.  
  973. 10.1 Criteria Document and Timing of Recommendation
  974.  
  975.    In making the following recommendations we are making two assumptions
  976.    of community consensus; that the IPng criteria document represents
  977.    the reasonable set of requirements for an IPng, and that a specific
  978.    recommendation should be made now and that from this point on the
  979.    IETF should proceed with a single IPng effort.
  980.  
  981.    As described above, the IPng Technical Criteria document [Kasten94]
  982.    was developed in a open manner and was the topic of extensive
  983.    discussions on a number of mailing lists.  We believe that there is a
  984.    strong consensus that this document accurately reflects the
  985.    community's set of technical requirements which an IPng should be
  986.    able to meet.
  987.  
  988.    A prime topic of discussion on the big-internet mailing list this
  989.    spring as well as during the open IPng directorate meeting in
  990.    Seattle, was the need to make a specific IPng recommendation at this
  991.    time.  Some people felt that additional research would help resolve
  992.    some of the issues that are currently unresolved.  While others
  993.    argued that selecting a single protocol to work on would clarify the
  994.    picture for the community, focus the resources of the IETF on
  995.    finalizing its details, and, since the argument that there were open
  996.    research items could be made at any point in history, there might
  997.    never be a 'right' time.
  998.  
  999.    Our reading of the community is that there is a consensus that a
  1000.    specific recommendation should be made now.  This is consistent with
  1001.    the views expressed during the ipdecide BOF in Amsterdam [Gross94]
  1002.    and in some of the RFC 1550 white papers [Carpen94a].
  1003.  
  1004.    There is no particular reason to think that the basic recommendation
  1005.    would be significantly different if we waited for another six months
  1006.    or a year.  Clearly some details which are currently unresolved could
  1007.  
  1008.  
  1009.  
  1010. Bradner & Mankin                                               [Page 18]
  1011.  
  1012. RFC 1752                Recommendation for IPng             January 1995
  1013.  
  1014.  
  1015.    be filled in if the recommendation were to be delayed, but the
  1016.    current fragmentation of the IETF's energies limits the efficiency of
  1017.    this type of detail resolution. Concentrating the resources of the
  1018.    IETF behind a single effort seems to us to be a more efficient way to
  1019.    proceed.
  1020.  
  1021. 10.2 Address Length
  1022.  
  1023.    One of the most hotly discussed aspects of the IPng design
  1024.    possibilities was address size and format.  During the IPng process
  1025.    four distinct views were expressed about these issues:
  1026.  
  1027.    1. The view that 8 bytes of address are enough to meet the current
  1028.       and future needs of the Internet (squaring the size of the IP
  1029.       address space).  More would waste bandwidth, promote inefficient
  1030.       assignment, and cause problems in some networks (such as mobiles
  1031.       and other low speed links).
  1032.  
  1033.    2. The view that 16 bytes is about right.  That length supports easy
  1034.       auto-configuration as well as organizations with complex internal
  1035.       routing topologies in conjunction with the global routing topology
  1036.       now and well into the future.
  1037.  
  1038.    3. The view that 20 byte OSI NSAPs should be used in the interests of
  1039.       global harmonization.
  1040.  
  1041.    4. The view that variable length addresses which might be smaller or
  1042.       larger than 16 bytes should be used to embrace all the above
  1043.       options and more, so that the size of the address could be
  1044.       adjusted to the demands of the particular environment, and to
  1045.       ensure the ability to meet any future networking requirements.
  1046.  
  1047.    Good technical and engineering arguments were made for and against
  1048.    all of these views. Unanimity was not achieved, but we feel that a
  1049.    clear majority view emerged that the use of 16 byte fixed length
  1050.    addresses was the best compromise between efficiency, functionality,
  1051.    flexibility, and global applicability. [Mankin94]
  1052.  
  1053. 11. IPng Recommendation
  1054.  
  1055.    After a great deal of discussion in many forums and with the
  1056.    consensus of the IPng Directorate, we recommend that the protocol
  1057.    described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit
  1058.    ver)" [Deering94b] be adopted as the basis for IPng, the next
  1059.    generation of the Internet Protocol.  We also recommend that the
  1060.    other documents listed in Appendix C be adopted as the basis of
  1061.    specific features of this protocol.
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Bradner & Mankin                                               [Page 19]
  1067.  
  1068. RFC 1752                Recommendation for IPng             January 1995
  1069.  
  1070.  
  1071.    This proposal resolves most of the perceived problems, particularly
  1072.    in the areas of addressing, routing, transition and address
  1073.    autoconfiguration.  It includes the broad base of the SIPP proposal
  1074.    effort, flexible address autoconfiguration features, and a merged
  1075.    transition strategy.  We believe that it meets the requirements
  1076.    outlined in the IPng Criteria document and provides the framework to
  1077.    fully meet the needs of the greater Internet community for the
  1078.    foreseeable future.
  1079.  
  1080. 11.1 IPng Criteria Document and IPng
  1081.  
  1082.    A detailed review of how IPng meets the requirements set down in the
  1083.    IPng Criteria document [Kasten94] will soon be published.  Following
  1084.    is our feelings about the extent to which IPng is responsive to the
  1085.    criteria.
  1086.  
  1087.    * complete specification - the base specifications for IPng are
  1088.      complete but transition and address autoconfiguration do remain to
  1089.      be finalized
  1090.    * architectural simplicity - the protocol is simple, easy to explain
  1091.      and uses well established paradigms
  1092.    * scale - an address size of 128 bits easily meets the need to
  1093.      address 10**9 networks even in the face of the inherent
  1094.      inefficiency of address allocation for efficient routing
  1095.    * topological flexibility - the IPng design places no constraints on
  1096.      network topology except for the limit of 255 hops
  1097.    * performance - the simplicity of processing, the alignment of the
  1098.      fields in the headers, and the elimination of the header checksum
  1099.      will allow for high performance handling of IPng data streams
  1100.    * robust service - IPng includes no inhibitors to robust service and
  1101.      the addition of packet-level authentication allows the securing of
  1102.      control and routing protocols without having to have separate
  1103.      procedures
  1104.    * transition - the IPng transition plan is simple and realistically
  1105.      covers the transition methods that will be present in the
  1106.      marketplace
  1107.    * media independence - IPng retains IPv4's media independence, it may
  1108.      be possible to make use of IPng's Flow Label in some connection-
  1109.      oriented media such as ATM
  1110.    * datagram service - IPng preserves datagram service as its basic
  1111.      operational mode, it is possible that the use of path MTU discovery
  1112.      will complicate the use of datagrams in some cases
  1113.    * configuration ease - IPng will have easy and flexible address
  1114.      autoconfiguration which will support a wide variety of environments
  1115.      from nodes on an isolated network to nodes deep in a complex
  1116.      internet
  1117.    * security - IPng includes specific mechanisms for authentication and
  1118.      encryption at the internetwork layer; the security features do rely
  1119.  
  1120.  
  1121.  
  1122. Bradner & Mankin                                               [Page 20]
  1123.  
  1124. RFC 1752                Recommendation for IPng             January 1995
  1125.  
  1126.  
  1127.      on the presence of a yet to be defined key management system
  1128.    * unique names - IPng addresses may be used as globally unique names
  1129.      although they do have topological significance
  1130.    * access to standards - all of the IPng standards will be published
  1131.      as RFCs with unlimited distribution
  1132.    * multicast support - IPng specifically includes multicast support
  1133.    * extensibility - the use of extension headers and an expandable
  1134.      header option feature will allow the introduction of new features
  1135.      into IPng when needed in a way that minimizes the disruption of the
  1136.      existing network
  1137.    * service classes - the IPng header includes a Flow Label which may
  1138.      be used to differentiate requested service classes
  1139.    * mobility - the proposed IPv4 mobility functions will work with IPng
  1140.    * control protocol - IPng includes the familiar IPv4 control protocol
  1141.      features
  1142.    * tunneling support - encapsulation of IPng or other protocols within
  1143.      IPng is a basic capability described in the IPng specifications
  1144.  
  1145. 11.2 IPv6
  1146.  
  1147.    The IANA has assigned version number 6 to IPng.  The protocol itself
  1148.    will be called IPv6.
  1149.  
  1150.    The remainder of this memo is used to describe IPv6 and its features.
  1151.    This description is an overview snapshot.  The standards documents
  1152.    themselves should be referenced for definitive specifications.  We
  1153.    also make a number of specific recommendations concerning the details
  1154.    of the proposed protocol, the procedures required to complete the
  1155.    definition of the protocol, and the IETF working groups we feel are
  1156.    necessary to accomplish the task.
  1157.  
  1158. 12. IPv6 Overview
  1159.  
  1160.    IPv6 is a new version of the Internet Protocol, it has been designed
  1161.    as an evolutionary, rather than revolutionary, step from IPv4.
  1162.    Functions which are generally seen as working in IPv4 were kept in
  1163.    IPv6.  Functions which don't work or are infrequently used were
  1164.    removed or made optional.  A few new features were added where the
  1165.    functionality was felt to be necessary.
  1166.  
  1167.    The important features of IPv6 include: [Hinden94c]
  1168.  
  1169.    * expanded addressing and routing capabilities - The IP address size
  1170.      is increased from 32 bits to 128 bits providing support for a much
  1171.      greater number of addressable nodes, more levels of addressing
  1172.      hierarchy, and simpler auto-configuration of addresses.
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Bradner & Mankin                                               [Page 21]
  1179.  
  1180. RFC 1752                Recommendation for IPng             January 1995
  1181.  
  1182.  
  1183.      The scaleability of multicast routing is improved by adding a
  1184.      "scope" field to multicast addresses.
  1185.  
  1186.      A new type of address, called a "cluster address" is defined to
  1187.      identify topological regions rather than individual nodes.  The use
  1188.      of cluster addresses in conjunction with the IPv6 source route
  1189.      capability allows nodes additional control over the path their
  1190.      traffic takes.
  1191.  
  1192.    * simplified header format - Some IPv4 header fields have been
  1193.      dropped or made optional to reduce the common-case processing cost
  1194.      of packet handling and to keep the bandwidth overhead of the IPv6
  1195.      header as low as possible in spite of the increased size of the
  1196.      addresses.  Even though the IPv6 addresses are four time longer
  1197.      than the IPv4 addresses, the IPv6 header is only twice the size of
  1198.      the IPv4 header.
  1199.  
  1200.    * support for extension headers and options - IPv6 options are placed
  1201.      in separate headers that are located in the packet between the IPv6
  1202.      header and the transport-layer header.  Since most IPv6 option
  1203.      headers are not examined or processed by any router along a
  1204.      packet's delivery path until it arrives at its final destination,
  1205.      this organization facilitates a major improvement in router
  1206.      performance for packets containing options.  Another improvement is
  1207.      that unlike IPv4, IPv6 options can be of arbitrary length and not
  1208.      limited to 40 bytes. This feature plus the manner in which they are
  1209.      processed, permits IPv6 options to be used for functions which were
  1210.      not practical in IPv4.
  1211.  
  1212.      A key extensibility feature of IPv6 is the ability to encode,
  1213.      within an option, the action which a router or host should perform
  1214.      if the option is unknown. This permits the incremental deployment
  1215.      of additional functionality into an operational network with a
  1216.      minimal danger of disruption.
  1217.  
  1218.    * support for authentication and privacy - IPv6 includes the
  1219.      definition of an extension which provides support for
  1220.      authentication and data integrity. This extension is included as a
  1221.      basic element of IPv6 and support for it will be required in all
  1222.      implementations.
  1223.  
  1224.      IPv6 also includes the definition of an extension to support
  1225.      confidentiality by means of encryption.  Support for this extension
  1226.      will be strongly encouraged in all implementations.
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Bradner & Mankin                                               [Page 22]
  1235.  
  1236. RFC 1752                Recommendation for IPng             January 1995
  1237.  
  1238.  
  1239.    * support for autoconfiguration - IPv6 supports multiple forms of
  1240.      autoconfiguration, from "plug and play" configuration of node
  1241.      addresses on an isolated network to the full-featured facilities
  1242.      offered by DHCP.
  1243.  
  1244.    * support for source routes - IPv6 includes an extended function
  1245.      source routing header designed to support the Source Demand Routing
  1246.      Protocol (SDRP). The purpose of SDRP is to support source-initiated
  1247.      selection of routes to complement the route selection provided by
  1248.      existing routing protocols for both inter-domain and intra-domain
  1249.      routes. [Estrin94b]
  1250.  
  1251.    * simple and flexible transition from IPv4 - The IPv6 transition plan
  1252.      is aimed at meeting four basic requirements: [Gillig94a]
  1253.  
  1254.      - Incremental upgrade.  Existing installed IPv4 hosts and routers
  1255.        may be upgraded to IPv6 at any time without being dependent on
  1256.        any other hosts or routers being upgraded.
  1257.      - Incremental deployment.  New IPv6 hosts and routers can be
  1258.        installed at any time without any prerequisites.
  1259.      - Easy Addressing.  When existing installed IPv4 hosts or routers
  1260.        are upgraded to IPv6, they may continue to use their existing
  1261.        address.  They do not need to be assigned new addresses.
  1262.      - Low start-up costs.  Little or no preparation work is needed in
  1263.        order to upgrade existing IPv4 systems to IPv6, or to deploy new
  1264.        IPv6 systems.
  1265.  
  1266.    * quality of service capabilities - A new capability is added to
  1267.      enable the labeling of packets belonging to particular traffic
  1268.      "flows" for which the sender has requested special handling, such
  1269.      as non-default quality of service or "real-time" service.
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Bradner & Mankin                                               [Page 23]
  1291.  
  1292. RFC 1752                Recommendation for IPng             January 1995
  1293.  
  1294.  
  1295. 12.1 IPv6 Header Format
  1296.  
  1297.    The IPv6 header, although longer than the IPv4 header, is
  1298.    considerably simplified.  A number of functions that were in the IPv4
  1299.    header have been relocated in extension headers or dropped.
  1300.    [Deering94b]
  1301.  
  1302.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1303.    |Version|                       Flow Label                      |
  1304.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1305.    |         Payload Length        |  Next Header  |   Hop Limit   |
  1306.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1307.    |                                                               |
  1308.    +                                                               +
  1309.    |                                                               |
  1310.    +                         Source Address                        +
  1311.    |                                                               |
  1312.    +                                                               +
  1313.    |                                                               |
  1314.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1315.    |                                                               |
  1316.    +                                                               +
  1317.    |                                                               |
  1318.    +                      Destination Address                      +
  1319.    |                                                               |
  1320.    +                                                               +
  1321.    |                                                               |
  1322.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1323.  
  1324.    * Version - Internet Protocol version number. IPng has been assigned
  1325.      version number 6. (4-bit field)
  1326.  
  1327.    * Flow Label - This field may be used by a host to label those
  1328.      packets for which it is requesting special handling by routers
  1329.      within a network, such as non-default quality of service or "real-
  1330.      time" service. (28-bit field)
  1331.  
  1332.    * Payload Length - Length of the remainder of the packet following
  1333.      the IPv6 header, in octets. To permit payloads of greater than 64K
  1334.      bytes, if the value in this field is 0 the actual packet length
  1335.      will be found in an Hop-by-Hop option. (16-bit unsigned integer)
  1336.  
  1337.    * Next Header - Identifies the type of header immediately following
  1338.      the IPv6 header.  The Next Header field uses the same values as the
  1339.      IPv4 Protocol field (8-bit selector field)
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Bradner & Mankin                                               [Page 24]
  1347.  
  1348. RFC 1752                Recommendation for IPng             January 1995
  1349.  
  1350.  
  1351.    * Hop Limit - Used to limit the impact of routing loops. The Hop
  1352.      Limit field is decremented by 1 by each node that forwards the
  1353.      packet.  The packet is discarded if Hop Limit is decremented to
  1354.      zero. (8-bit unsigned integer)
  1355.  
  1356.    * Source Address - An address of the initial sender of the packet.
  1357.      (128 bit field)
  1358.  
  1359.    * Destination Address - An address of the intended recipient of the
  1360.      packet (possibly not the ultimate recipient, if an optional Routing
  1361.      Header is present). (128 bit field)
  1362.  
  1363. 12.2 Extension Headers
  1364.  
  1365.    In IPv6, optional internet-layer information is encoded in separate
  1366.    headers that may be placed between the IPv6 header and the
  1367.    transport-layer header in a packet.  There are a small number of such
  1368.    extension headers, each identified by a distinct Next Header value.
  1369.    [From a number of the documents listed in Appendix C.]
  1370.  
  1371.    12.2.1 Hop-by-Hop Option Header
  1372.  
  1373.       The Hop-by-Hop Options header is used to carry optional
  1374.       information that must be examined by every node along a packet's
  1375.       delivery path.  The Hop-by-Hop Options header is identified by a
  1376.       Next Header value of 0 in the IPv6 header, and has the following
  1377.       format:
  1378.  
  1379.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1380.       |  Next Header  |  Hdr Ext Len  |                               |
  1381.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  1382.       |                                                               |
  1383.       .                                                               .
  1384.       .                            Options                            .
  1385.       .                                                               .
  1386.       |                                                               |
  1387.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1388.  
  1389.       * Next Header - Identifies the type of header immediately
  1390.         following the Hop-by-Hop Options header.  Uses the same values
  1391.         as the IPv4 Protocol field. (8-bit selector)
  1392.  
  1393.       * Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet
  1394.         units, not including the first 8 octets. (8-bit unsigned
  1395.         integer)
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Bradner & Mankin                                               [Page 25]
  1403.  
  1404. RFC 1752                Recommendation for IPng             January 1995
  1405.  
  1406.  
  1407.       * Options - Contains one or more TLV-encoded options. (Variable-
  1408.         length field, of length such that the complete Hop-by-Hop
  1409.         Options header is an integer multiple of 8 octets long.)
  1410.  
  1411.    12.2.2 IPv6 Header Options
  1412.  
  1413.       Two of the currently-defined extension headers -- the Hop-by-Hop
  1414.       Options header and the End-to-End Options header -- may carry a
  1415.       variable number of Type-Length-Value (TLV) encoded "options", of
  1416.       the following format:
  1417.  
  1418.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
  1419.       |  Option Type  |  Opt Data Len |  Option Data
  1420.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
  1421.  
  1422.       * Option Type - identifier of the type of option (8-bit field)
  1423.  
  1424.       * Opt Data Len - Length of the Option Data field of this option,
  1425.         in octets. (8-bit unsigned integer)
  1426.  
  1427.       * Option Data - Option-Type-specific data. (Variable-length field)
  1428.  
  1429.       The Option Type identifiers are internally encoded such that their
  1430.       highest-order two bits specify the action that must be taken if
  1431.       the processing IPv6 node does not recognize the Option Type:
  1432.  
  1433.       00 - skip over this option and continue processing the header
  1434.       01 - discard the packet
  1435.       10 - discard the packet and send an ICMP Unrecognized Type message
  1436.             to the packet's Source Address, pointing to the unrecognized
  1437.             Option Type
  1438.       11 - undefined.
  1439.  
  1440.       In the case of Hop-by-Hop options only, the third-highest-order
  1441.       bit of the Option Type specifies whether or not the Option Data of
  1442.       this option shall be included in the integrity assurance
  1443.       computation performed when an Authentication header is present.
  1444.       Option data that changes en route must be excluded from that
  1445.       computation.
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Bradner & Mankin                                               [Page 26]
  1459.  
  1460. RFC 1752                Recommendation for IPng             January 1995
  1461.  
  1462.  
  1463.    12.2.3 Routing Header
  1464.  
  1465.       The Routing header is used by an IPv6 source to list one or more
  1466.       intermediate nodes (or topological clusters) to be "visited" on
  1467.       the way to a packet's destination.  This particular form of the
  1468.       Routing Header is designed to support SDRP. [Estrin94b]
  1469.  
  1470.       0                   1                   2                   3
  1471.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1472.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1473.       | Next Header   |Routing Type=1 |M|F| Reserved   | SrcRouteLen  |
  1474.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1475.       | NextHopPtr    |            Strict/Loose Bit Mask              |
  1476.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1477.       |                                                               |
  1478.       .                                                               .
  1479.       .                         Source Route                          .
  1480.       .                                                               .
  1481.       |                                                               |
  1482.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1483.  
  1484.       * Next Header - Identifies the type of header immediately
  1485.         following the Routing Header.  Uses the same values as the IPv4
  1486.         Protocol field. (8-bit selector)
  1487.  
  1488.       * Routing Type - Indicates the type of routing supported by this
  1489.         header.  Value must be 1.
  1490.  
  1491.       * MRE flag - Must Report Errors. If this bit is set to 1, and a
  1492.         router can not further forward a packet (with an incompletely
  1493.         traversed source route), as specified in the Source Route, the
  1494.         router must generate an ICMP error message. If this bit is set
  1495.         to 0, and a router can not further forward a packet (with an
  1496.         incompletely traversed source route), as specified in the Source
  1497.         Route, the router should not generate an ICMP error message.
  1498.  
  1499.       * F flag -  Failure of Source Route Behavior.  If this bit it set
  1500.         to 1, it indicates that if a router can not further forward a
  1501.         packet (with an incompletely traversed source route), as
  1502.         specified in the Source Route, the router must set the value of
  1503.         the Next Hop Pointer field to the value of the Source Route
  1504.         Length field, so that the subsequent forwarding will be based
  1505.         solely on the destination address. If this bit is set to 0, it
  1506.         indicates that if a router can not further forward a packet
  1507.         (with an incompletely traversed source route), as specified in
  1508.         the Source Route, the router must discard the packet.
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Bradner & Mankin                                               [Page 27]
  1515.  
  1516. RFC 1752                Recommendation for IPng             January 1995
  1517.  
  1518.  
  1519.       * Reserved - Initialized to zero for transmission; ignored on
  1520.         reception.
  1521.  
  1522.       * SrcRouteLen - Source Route Length - Number of source route
  1523.         elements/hops in the SDRP Routing header.  Length of SDRP
  1524.         routing header can be calculated from this value (length =
  1525.         SrcRouteLen * 16 + 8) This field may not exceed a value of 24.
  1526.         (8 bit unsigned integer)
  1527.  
  1528.       * NextHopPtr - Next Hop Pointer- Index of next element/hop to be
  1529.         processed; initialized to 0 to point to first element/hop in the
  1530.         source route.  When Next Hop Pointer is equal to Source Route
  1531.         Length then the Source Route is completed.  (8 bit unsigned
  1532.         integer)
  1533.  
  1534.       * Strict/Loose Bit Mask - The Strict/Loose Bit Mask is used when
  1535.         making a forwarding decision. If the value of the Next Hop
  1536.         Pointer field is N, and the N-th bit in the Strict/Loose Bit
  1537.         Mask field is set to 1, it indicates that the next hop is a
  1538.         Strict Source Route Hop. If this bit is set to 0, it indicates
  1539.         that the next hop is a Loose Source Route Hop. (24 bit
  1540.         bitpattern)
  1541.  
  1542.       * Source Route - A list of IPv6 addresses indicating the path that
  1543.         this packet should follow.  A Source Route can contain an
  1544.         arbitrary intermix of unicast and cluster addresses. (integral
  1545.         multiple of 128 bits)
  1546.  
  1547.    12.2.4 Fragment Header
  1548.  
  1549.       The Fragment header is used by an IPv6 source to send payloads
  1550.       larger than would fit in the path MTU to their destinations.
  1551.       (Note: unlike IPv4, fragmentation in IPv6 is performed only by
  1552.       source nodes, not by routers along a packet's delivery path)  The
  1553.       Fragment header is identified by a Next Header value of 44 in the
  1554.       immediately preceding header, and has the following format:
  1555.  
  1556.  
  1557.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1558.       |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
  1559.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1560.       |                         Identification                        |
  1561.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1562.  
  1563.       * Next Header - Identifies the type of header immediately
  1564.         following the Fragment header.  Uses the same values as the IPv4
  1565.         Protocol field. (8 bit selector)
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Bradner & Mankin                                               [Page 28]
  1571.  
  1572. RFC 1752                Recommendation for IPng             January 1995
  1573.  
  1574.  
  1575.       * Reserved, Res - Initialized to zero for transmission; ignored on
  1576.         reception.
  1577.  
  1578.       * Fragment Offset - The offset, in 8-octet units, of the following
  1579.         payload, relative to the start of the original, unfragmented
  1580.         payload. (13-bit unsigned integer)
  1581.  
  1582.       * M flag - 1 = more fragments; 0 = last fragment.
  1583.  
  1584.       * Identification - A value assigned to the original payload that
  1585.         is different than that of any other fragmented payload sent
  1586.         recently with the same IPv6 Source Address, IPv6 Destination
  1587.         Address, and Fragment Next Header value.  (If a Routing header
  1588.         is present, the IPv6 Destination Address is that of the final
  1589.         destination.)  The Identification value is carried in the
  1590.         Fragment header of all of the original payload's fragments, and
  1591.         is used by the destination to identify all fragments belonging
  1592.         to the same original payload.  (32 bit field)
  1593.  
  1594.    12.2.5 Authentication Header
  1595.  
  1596.       The Authentication header is used to provide authentication and
  1597.       integrity assurance for IPv6 packets.  Non-repudiation may be
  1598.       provided by an authentication algorithm used with the
  1599.       Authentication header, but it is not provided with all
  1600.       authentication algorithms that might be used with this header.
  1601.       The Authentication header is identified by a Next Header value of
  1602.       51 in the immediately preceding header, and has the following
  1603.       format:
  1604.  
  1605.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1606.       |  Next Header  | Auth Data Len |            Reserved           |
  1607.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1608.       |                     Security Association ID                   |
  1609.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1610.       |                                                               |
  1611.       .                                                               .
  1612.       .                      Authentication Data                      .
  1613.       .                                                               .
  1614.       |                                                               |
  1615.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1616.  
  1617.       * Next Header - Identifies the type of header immediately
  1618.         following the Authentication header.  Uses the same values as
  1619.         the IPv4 Protocol field. (8-bit selector)
  1620.  
  1621.       * Auth Data Len - Length of the Authentication Data field in 8-
  1622.         octet units. (8-bit unsigned integer)
  1623.  
  1624.  
  1625.  
  1626. Bradner & Mankin                                               [Page 29]
  1627.  
  1628. RFC 1752                Recommendation for IPng             January 1995
  1629.  
  1630.  
  1631.       * Reserved - Initialized to zero for transmission; ignored on
  1632.         reception.
  1633.  
  1634.       * Security Assoc. ID - When combined with the IPv6 Source Address,
  1635.         identifies to the receiver(s) the pre-established security
  1636.         association to which this packet belongs. (32 bit field)
  1637.  
  1638.       * Authentication Data -   Algorithm-specific information required
  1639.         to authenticate the source of the packet and assure its
  1640.         integrity, as specified for the pre-established security
  1641.         association. (Variable-length field, an integer multiple of 8
  1642.         octets long.)
  1643.  
  1644.    12.2.6 Privacy Header
  1645.  
  1646.       The Privacy Header seeks to provide confidentiality and integrity
  1647.       by encrypting data to be protected and placing the encrypted data
  1648.       in the data portion of the Privacy Header.  Either a transport-
  1649.       layer (e.g., UDP or TCP) frame may be encrypted or an entire IPv6
  1650.       datagram may be encrypted, depending on the user's security
  1651.       requirements.  This encapsulating approach is necessary to provide
  1652.       confidentiality for the entire original datagram.  If present, the
  1653.       Privacy Header is always the last non-encrypted field in a packet.
  1654.  
  1655.       The Privacy Header works between hosts, between a host and a
  1656.       security gateway, or between security gateways.  This support for
  1657.       security gateways permits trustworthy networks to exist without
  1658.       the performance  and monetary costs of security, while providing
  1659.       security for traffic transiting untrustworthy network segments.
  1660.  
  1661.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1662.       |             Security Association Identifier (SAID)            |
  1663.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1664.       |                                                               |
  1665.       .                    Initialization Vector                      .
  1666.       |                                                               |
  1667.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1668.       |  Next Header* |   Length*   |          Reserved*              |
  1669.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1670.       |                                                               |
  1671.       |                       Protected Data*     +-+-+-+-+-+-+-+-+-+-+
  1672.       |                                           |     trailer*      |
  1673.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1674.  
  1675.                                                              *encrypted
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Bradner & Mankin                                               [Page 30]
  1683.  
  1684. RFC 1752                Recommendation for IPng             January 1995
  1685.  
  1686.  
  1687.       * Security Association Identifier (SAID) - Identifies the security
  1688.         association for this datagram.  If no security association has
  1689.         been established, the value of this field shall be 0x0000.  A
  1690.         security  association is normally one-way. An authenticated
  1691.         communications session between two hosts will normally have two
  1692.         SAIDs in use (one in each direction).  The receiving host uses
  1693.         the combination of SAID value and originating address to
  1694.         distinguish the correct association. (32 bit value)
  1695.  
  1696.       * Initialization Vector -  This field is optional and its value
  1697.         depends on the SAID in use.  For example, the field may contain
  1698.         cryptographic synchronization data for a block oriented
  1699.         encryption algorithm. It may also be used to contain a
  1700.         cryptographic initialization vector.  A Privacy Header
  1701.         implementation will normally use the SAID value to determine
  1702.         whether this field is present and, if it is, the field's size
  1703.         and use. (presence and length dependent on SAID)
  1704.  
  1705.       * Next Header - encrypted - Identifies the type of header
  1706.         immediately following the Privacy header.  Uses the same values
  1707.         as the IPv4 Protocol field. (8 bit selector)
  1708.  
  1709.       * Reserved - encrypted - Ignored on reception.
  1710.  
  1711.       * Length - encrypted - Length of the Privacy Header in 8-octet
  1712.         units, not including the first 8 octets. (8-bit unsigned
  1713.         integer)
  1714.  
  1715.       * Protected Data - encrypted -  This field may contain an entire
  1716.         encapsulated IPv6 datagram, including the IPv6 header, a
  1717.         sequence of zero or more IPv6 options, and a transport-layer
  1718.         payload, or it may just be a sequence of zero or more IPv6
  1719.         options followed by a transport-layer payload.  (variable
  1720.         length)
  1721.  
  1722.       * trailer (Algorithm-dependent Trailer) - encrypted - A field
  1723.         present to support some algorithms which need to have padding
  1724.         (e.g., to a full cryptographic block size for block-oriented
  1725.         encryption algorithms) or for storage of authentication data for
  1726.         use with a encryption algorithm that provides confidentiality
  1727.         without authentication.  It is present only when the algorithm
  1728.         in use requires such a field. (presence and length dependent on
  1729.         SAID)
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Bradner & Mankin                                               [Page 31]
  1739.  
  1740. RFC 1752                Recommendation for IPng             January 1995
  1741.  
  1742.  
  1743.    12.2.7 End-to-End Option Header
  1744.  
  1745.       The End-to-End Options header is used to carry optional
  1746.       information that needs to be examined only by a packet's
  1747.       destination node(s).  The End-to-End Options header is identified
  1748.       by a Next Header value of TBD in the immediately preceding header,
  1749.       and has the same format as the Hop-by-Hop Option Header except for
  1750.       the ability to exclude an option from the authentication integrity
  1751.       assurance computation.
  1752.  
  1753. 13. IPng Working Group
  1754.  
  1755.    We recommend that a new IPng Working Group be formed to produce
  1756.    specifications for the core functionality of the IPv6 protocol suite.
  1757.    The working group will carry out the recommendations of the IPng Area
  1758.    Directors as outlined at the July 1994 IETF and in this memo.  We
  1759.    recommend that this working group be chaired by Steve Deering of
  1760.    Xerox PARC and Ross Callon of Wellfleet.
  1761.  
  1762.    The primary task of the working group is to produce a set of
  1763.    documents that define the basic functions, interactions, assumptions,
  1764.    and packet formats for IPv6.  We recommend that Robert Hinden of Sun
  1765.    Microsystems be the editor for these documents.  The documents listed
  1766.    in Appendix C will be used by the working group to form the basis of
  1767.    the final document set.
  1768.  
  1769.    The work of the IPng Working Group includes:
  1770.  
  1771.    * complete the IPv6 overview document
  1772.    * complete the IPv6 detailed operational specification
  1773.    * complete the IPv6 Addressing Architecture specification
  1774.    * produce specifications for IPv6 encapsulations over various media
  1775.    * complete specifications for the support of packets larger than 64KB
  1776.    * complete specifications of the DNS enhancements required to support
  1777.      IPv6
  1778.    * complete specification of ICMP, IGMP and router discovery for
  1779.      support of IPv6.
  1780.    * complete specification of path MTU discovery for IPv6
  1781.    * complete specifications of IPv6 in IPv6 tunneling
  1782.    * complete the suggested address format and assignment plan
  1783.    * coordinate with the Address Autoconfiguration Working Group
  1784.    * coordinate with the NGTRANS and TACIT Working Groups
  1785.    * complete specifications of authentication and privacy support
  1786.      headers
  1787.  
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Bradner & Mankin                                               [Page 32]
  1795.  
  1796. RFC 1752                Recommendation for IPng             January 1995
  1797.  
  1798.  
  1799.    The working group should also consider a few selected enhancements
  1800.    including:
  1801.  
  1802.    * consider ways to compress the IPv6 header in the contexts of native
  1803.      IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6
  1804.    * consider specifying support for a larger minimum MTU
  1805.  
  1806. 14. IPng Reviewer
  1807.  
  1808.    Currently it is the task of the IPng Area Directors, the IPng
  1809.    Directorate and the chairs of the proposed ipng working group to
  1810.    coordinate the activities of the many parallel efforts currently
  1811.    directed towards different aspects of IPng.  While this is possible
  1812.    and currently seems to be working well it can not be maintained over
  1813.    the long run because, among other reasons, the IPng Area will be
  1814.    dissolved eventually and its Directorate disbanded.  It will also
  1815.    become much more difficult as IPng related activities start up in
  1816.    other IETF areas.
  1817.  
  1818.    We recommend that an IPng Reviewer be appointed to be specifically
  1819.    responsible for ensuring that a consistent view of IPv6 is maintained
  1820.    across the related working groups.  We feel that this function is
  1821.    required due to the complex nature of the interactions between the
  1822.    parts of the IPng effort and due to the distribution of the IPng
  1823.    related work amongst a number of IETF areas.  We recommend that Dave
  1824.    Clark of MIT be offered this appointment.
  1825.  
  1826.    This would be a long-term task involving the review of on-going
  1827.    activities. The aim is not for the IPng Reviewer to make
  1828.    architectural decisions since that is the work of the various working
  1829.    groups, the IAB, and the IETF as a whole.. The aim is to spot gaps or
  1830.    misunderstandings before they reach the point where functionality or
  1831.    interworkability is threatened.
  1832.  
  1833. 15. Address Autoconfiguration
  1834.  
  1835.    As data networks become more complex the need to be able to bypass at
  1836.    least some of the complexity and move towards "plug and play" becomes
  1837.    ever more acute.  The user can not be expected to be able to
  1838.    understand the details of the network architecture or know how to
  1839.    configure the network software in their host.  In the ideal case, a
  1840.    user should be able to unpack a new computer, plug it into the local
  1841.    network and "just" have it work without requiring the entering of any
  1842.    special information.  Security concerns may restrict the ability to
  1843.    offer this level of transparent address autoconfiguration in some
  1844.    environments but the mechanisms must be in place to support whatever
  1845.    level of automation which the local environment feels comfortable
  1846.    with.
  1847.  
  1848.  
  1849.  
  1850. Bradner & Mankin                                               [Page 33]
  1851.  
  1852. RFC 1752                Recommendation for IPng             January 1995
  1853.  
  1854.  
  1855.    The basic requirement of "plug and play" operation is that a host
  1856.    must be able to acquire an address dynamically, either when attaching
  1857.    to a network for the first time or when the host needs to be
  1858.    readdressed because the host moved or because the identity of the
  1859.    network has changed.  There are many other functions required to
  1860.    support a full "plug and play" environment. [Berk94] Most of these
  1861.    must be addressed outside of the IPv6 Area but a focused effort to
  1862.    define a host address autoconfiguration protocol is part of the IPv6
  1863.    process.
  1864.  
  1865.    We recommend that a new Address Autoconfiguration Working Group
  1866.    (addrconf) be formed with Dave Katz of Cisco Systems and Sue Thomson
  1867.    of Bellcore as co-chairs. The purpose of this working group is to
  1868.    design and specify a protocol for allocating addresses dynamically to
  1869.    IPv6 hosts.  The address configuration protocol must be suitable for
  1870.    a wide range of network topologies, from a simple isolated network to
  1871.    a sophisticated globally connected network. It should also allow for
  1872.    varying levels of administrative control, from completely automated
  1873.    operation to very tight oversight.
  1874.  
  1875.    The scope of this working group is to propose a host address
  1876.    autoconfiguration protocol which supports the full range of
  1877.    topological and administrative environments in which IPv6 will be
  1878.    used.  It is the intention that, together with IPv6 system discovery,
  1879.    the address autoconfiguration protocol will provide the minimal
  1880.    bootstrapping information necessary to enable hosts to acquire
  1881.    further configuration information (such as that provided by DHCP in
  1882.    IPv4). The scope does not include router configuration or any other
  1883.    host configuration functions. However, it is within the scope of the
  1884.    working group to investigate and document the interactions between
  1885.    this work and related functions including system discovery, DNS
  1886.    autoregistration, service discovery, and broader host configuration
  1887.    issues, to facilitate the smooth integration of these functions.
  1888.    [Katz94a]
  1889.  
  1890.    The working group is expected to complete its work around the end of
  1891.    1994 and disband at that time.  The group will use "IPv6 Address
  1892.    Autoconfiguration Architecture" [Katz94b] draft document as the basis
  1893.    of their work.
  1894.  
  1895. 16. Transition
  1896.  
  1897.    The transition of the Internet from IPv4 to IPv6 has to meet two
  1898.    separate needs.  There is a short term need to define specific
  1899.    technologies and methods to transition IPv4 networks, including the
  1900.    Internet, into IPv6 networks and an IPv6 Internet.  There is also a
  1901.    long term need to do broad-based operational planning for transition,
  1902.    including developing methods to allow decentralized migration
  1903.  
  1904.  
  1905.  
  1906. Bradner & Mankin                                               [Page 34]
  1907.  
  1908. RFC 1752                Recommendation for IPng             January 1995
  1909.  
  1910.  
  1911.    strategies, understanding the ramifications of a long period of
  1912.    coexistence when both protocols are part of the basic infrastructure,
  1913.    developing an understanding of the type and scope of architectural
  1914.    and interoperability testing that will be required to ensure a
  1915.    reliable and manageable Internet in the future.
  1916.  
  1917. 16.1 Transition - Short Term
  1918.  
  1919.    Any IPng transition plan must take into account the realities of what
  1920.    types of devices vendors will build and network managers will deploy.
  1921.    The IPng transition plan must define the procedures required to
  1922.    successfully implement the functions which vendors will be likely to
  1923.    include in their devices.  This is the case even if there are good
  1924.    arguments to recommend against a particular function, header
  1925.    translation for example.  If products will exist it is better to have
  1926.    them interoperate than not.
  1927.  
  1928.    We recommend that a new IPng Transition (NGTRANS) Working Group be
  1929.    formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co-
  1930.    chairs to design the mechanisms and procedures to support the
  1931.    transition of the Internet from IPv4 to IPv6 and to give advice on
  1932.    what procedures and techniques are preferred.
  1933.  
  1934.    The work of the group will fall into three areas:
  1935.  
  1936.    * Define the processes by which the Internet will make the transition
  1937.      from IPv4 to IPv6.  As part of this effort, the group will produce
  1938.      a document explaining to the general Internet community what
  1939.      mechanisms will be employed in the transition, how the transition
  1940.      will work, the assumptions about infrastructure deployment inherent
  1941.      in the operation of these mechanisms, and the types of
  1942.      functionality that applications developers will be able to assume
  1943.      as the protocol mix changes over time.
  1944.    * Define and specify the mandatory and optional mechanisms that
  1945.      vendors should implement in hosts, routers, and other components of
  1946.      the Internet in order for the transition to be carried out. Dual-
  1947.      stack, encapsulation and header translation mechanisms must all be
  1948.      defined, as well as the interaction between hosts using different
  1949.      combinations of these mechanisms.  The specifications produced will
  1950.      be used by people implementing these IPv6 systems.
  1951.    * Articulate a concrete operational plan for the Internet to make the
  1952.      transition from IPv4 to IPv6.  The result of this work will be a
  1953.      transition plan for the Internet that network operators and
  1954.      Internet subscribers can execute.
  1955.                                                              [Gillig94c]
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Bradner & Mankin                                               [Page 35]
  1963.  
  1964. RFC 1752                Recommendation for IPng             January 1995
  1965.  
  1966.  
  1967.    The working group is expected to complete its work around the end of
  1968.    1994 and disband at that time.  The group will use the "Simple SIPP
  1969.    Transition (SST)" [Gilig94a] overview document as the starting point
  1970.    for its work.
  1971.  
  1972. 16.2 Transition - Long Term
  1973.  
  1974.    There are a number of transition related topics in addition to
  1975.    defining the specific IPv4 to IPv6 mechanisms and their deployment,
  1976.    operation and interaction.  The ramifications and procedures of
  1977.    migrating to a new technology or to a new version of an existing
  1978.    technology must be fully understood.
  1979.  
  1980.    We recommend that the Transition and Coexistence Including Testing
  1981.    (TACIT) Working Group, which was started a few months ago, explore
  1982.    some of the basic issues associated with the deployment of new
  1983.    technology into an established Internet.  The TACIT Working Group
  1984.    will focus on the generic issues of transition and will not limit
  1985.    itself to the upcoming transition to IPv6 because, over time,
  1986.    enhancements to IPv6 (IPv6ng) will be developed and accepted.  At
  1987.    that point they will need to be deployed into the then existing
  1988.    Internet.  The TACIT Working Group will be more operationally
  1989.    oriented than the NGTRANS Working Group and will continue well into
  1990.    the actual IPv6 transition.
  1991.  
  1992.    The main areas of exploration are:
  1993.  
  1994.    * Make the transition from a currently deployed protocol to a new
  1995.      protocol while accommodating heterogeneity and decentralized
  1996.      management.
  1997.    * Since it is often difficult or impossible to replace all legacy
  1998.      systems or software, it is important to understand the
  1999.      characteristics and operation of a long period of coexistence
  2000.      between a new protocol and the existing protocol.
  2001.    * The Internet must now be considered a utility.  We are far removed
  2002.      from a time when a new technology could be deployed to see if it
  2003.      would work in large scale situations.  Rigorous architectural and
  2004.      interoperability testing must be part of the predeployment phase of
  2005.      any proposed software for the Internet. Testing the scaling up
  2006.      behaviors and robustness of a new protocol will offer particular
  2007.      challenges. The WG should determine if there are lessons to be
  2008.      learned from:  OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2
  2009.      transition, DECnet Phase 4 to Phase 5 planning and transition,
  2010.      among others.
  2011.  
  2012.  
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Bradner & Mankin                                               [Page 36]
  2019.  
  2020. RFC 1752                Recommendation for IPng             January 1995
  2021.  
  2022.  
  2023.    The TACIT Working Group will explore each of these facets of the
  2024.    deployment of new technology and develop a number of documents to
  2025.    help guide users and managers of affected data networks and provide
  2026.    to the IETF:
  2027.  
  2028.    * Detailed descriptions of problem areas in transition and
  2029.      coexistence, both predicted, based on lessons learned, and observed
  2030.      as the IPv6 process progresses.
  2031.    * Recommendations for specific testing procedures.
  2032.    * Recommendations for coexistence operations procedures
  2033.    * Recommendations for the smoothing of decentralized transition
  2034.      planning.
  2035.                                                          [Huston94]
  2036.  
  2037. 17. Other Address Families
  2038.  
  2039.    There are many environments in which there are one or more network
  2040.    protocols already deployed or where a significant planning effort has
  2041.    been undertaken to create a comprehensive network addressing plan. In
  2042.    such cases there may be a temptation to integrate IPv6 into the
  2043.    environment by making use of an existing addressing plan to define
  2044.    all or part of the IPv6 addresses.  The advantage of doing this is
  2045.    that it permits unified management of address space among multiple
  2046.    protocol families.  The use of common addresses can help facilitate
  2047.    transition from other protocols to IPv6.
  2048.  
  2049.    If the existing addresses are globally unique and assigned with
  2050.    regard to network topology this may be a reasonable idea.  The IETF
  2051.    should work with other organizations to develop algorithms that could
  2052.    be used to map addresses between IPv6 and other environments.  The
  2053.    goal for any such mapping must be to provide an unambiguous 1 to 1
  2054.    map between individual addresses.
  2055.  
  2056.    Suggestions have been made to develop mapping algorithms for Novell
  2057.    IPX addresses, some types of OSI NSAPs, E164 addresses and SNA
  2058.    addresses.  Each of these possibilities should be carefully examined
  2059.    to ensure that use of such an algorithm solves more problems than it
  2060.    creates.  In some cases it may be better to recommend either that a
  2061.    native IPng addressing plan be developed instead, or that an IPv6
  2062.    address be used within the non-IP environment. [Carpen94b]
  2063.  
  2064.    We recommend that, in conjunction with other organizations,
  2065.    recommendations about the use of non-IPv6 addresses in IPv6
  2066.    environments and IPv6 addresses in non-IPv6 environments be
  2067.    developed.
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Bradner & Mankin                                               [Page 37]
  2075.  
  2076. RFC 1752                Recommendation for IPng             January 1995
  2077.  
  2078.  
  2079. 18. Impact on Other IETF Standards
  2080.  
  2081.    Many current IETF standards are affected by IPv6.  At least 27 of the
  2082.    current 51 full Internet Standards must be revised for IPv6, along
  2083.    with at least 6 of the 20 Draft Standards and at least 25 of the 130
  2084.    Proposed Standards. [Postel94]
  2085.  
  2086.    In some cases the revisions consist of simple changes to the text,
  2087.    for example, in a number of RFCs an IP address is referred to in
  2088.    passing as a "32 bit IP address" even though IP addresses are not
  2089.    directly used in the protocol being defined.  All of the standards
  2090.    track documents will have to be checked to see if they contain such
  2091.    references.
  2092.  
  2093.    In most of the rest of the cases revisions to the protocols,
  2094.    including packet formats, will be required.  In many of these cases
  2095.    the address is just being carried as a data element and a revised
  2096.    format with a larger field for the address will have no effect on the
  2097.    functional paradigm.
  2098.  
  2099.    In the remaining cases some facet of the operation of the protocol
  2100.    will be changed as a result of IPv6.  For example, the security and
  2101.    source route mechanisms are fundamentally changed from IPv4 with
  2102.    IPv6.  Protocols and applications that relied on the IPv4
  2103.    functionality will have to be redesigned or rethought to use the
  2104.    equivalent function in IPv6.
  2105.  
  2106.    In a few cases this opportunity should be used to determine if some
  2107.    of the RFCs should be moved to historic, for example EGP [Mills84]
  2108.    and IP over ARCNET. [Provan91]
  2109.  
  2110.    The base IPng Working Group will address some of these, existing IETF
  2111.    working groups can work on others, while new working groups must be
  2112.    formed to deal with a few of them. The IPng Working Group will be
  2113.    responsible for defining new versions of ICMP, ARP/RARP, and UDP.  It
  2114.    will also review RFC 1639, "FTP Operation Over Big Address Records
  2115.    (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90]
  2116.  
  2117.    Existing working groups will examine revisions for some of the
  2118.    routing protocols: RIPv2, IS-IS, IDRP and SDRP.  A new working group
  2119.    may be required for OSPF.
  2120.  
  2121.    The existing DHCP Working Group may be able to revise DHCP and
  2122.    examine BOOTP.
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Bradner & Mankin                                               [Page 38]
  2131.  
  2132. RFC 1752                Recommendation for IPng             January 1995
  2133.  
  2134.  
  2135.    A TCPng Working Group will be formed soon, and new working groups
  2136.    will have to be formed to deal with standards such as SNMP, DNS, NTP,
  2137.    NETbios, OSI over TCP, Host Requirements, and Kerberos as well as
  2138.    reviewing most of the RFCs that define IP usage over various media.
  2139.  
  2140.    In addition to the standards track RFCs mentioned above there are
  2141.    many Informational and Experimental RFCs which would be affected as
  2142.    well as numerous Internet Drafts (and those standards track RFCs that
  2143.    we missed).
  2144.  
  2145.    We recommend that the IESG commission a review of all standards track
  2146.    RFCs to ensure that a full list of affected documents is compiled. We
  2147.    recommend that the IESG charge current IETF working groups with the
  2148.    task of understanding the impact of IPv6 on their proposals and,
  2149.    where appropriate, revise the documents to include support for IPv6.
  2150.  
  2151.    We recommend that the IESG charter new working groups where required
  2152.    to revise other standards RFCs.
  2153.  
  2154. 19. Impact on non-IETF standards and on products
  2155.  
  2156.    Many products and user applications which rely on the size or
  2157.    structure of IPv4 addresses will need to be modified to work with
  2158.    IPv6.  While the IETF can facilitate an investigation of the impacts
  2159.    of IPv6 on non-IETF standards and products, the primary
  2160.    responsibility for doing so resides in the other standards bodies and
  2161.    the vendors.
  2162.  
  2163.    Examples of non-IETF standards that are effected by IPv6 include the
  2164.    POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun
  2165.    ONC, the Andrew File System and MIT's Kerberos.  Most products that
  2166.    provide specialized network security including firewall-type devices
  2167.    are among those that must be extended to support IPv6.
  2168.  
  2169. 20. APIs
  2170.  
  2171.    It is traditional to state that the IETF does not "do" APIs.  While
  2172.    there are many reasons for this, the one most commonly referenced is
  2173.    that there are too many environments where TCP/IP is used, too many
  2174.    different operating systems, programming languages, and platforms.
  2175.    The feeling is that the IETF should not get involved in attempting to
  2176.    define a language and operating system independent interface in the
  2177.    face of such complexity.
  2178.  
  2179.    We feel that this historical tendency for the IETF to avoid dealing
  2180.    with APIs should be reexamined in the case of IPv6.  We feel that in
  2181.    a few specific cases the prevalence of a particular type of API is
  2182.    such that  a single common solution for the modifications made
  2183.  
  2184.  
  2185.  
  2186. Bradner & Mankin                                               [Page 39]
  2187.  
  2188. RFC 1752                Recommendation for IPng             January 1995
  2189.  
  2190.  
  2191.    necessary by IPv6 should be documented.
  2192.  
  2193.    We recommend that Informational RFCs be solicited or developed for
  2194.    these few cases.  In particular, the Berkeley-style sockets
  2195.    interface, the UNIX TLI and XTI interfaces, and the WINSOCK
  2196.    interfaces should be targeted.  A draft document exists which could
  2197.    be developed into the sockets API description. [Gillig94b]
  2198.  
  2199. 21. Future of the IPng Area and Working Groups
  2200.  
  2201.    In our presentation at the Houston IETF meeting we stated that the
  2202.    existing IPng proposal working groups would not be forced to close
  2203.    down after the recommendation was made.  Each of them has been
  2204.    working on technologies that may have applications in addition to
  2205.    their IPng proposal and these technologies should not be lost.
  2206.  
  2207.    Since the Toronto IETF meeting the existing IPng working groups have
  2208.    been returned to the Internet Area.  The group members may decide to
  2209.    close down the working groups or to continue some of their efforts.
  2210.    The charters of the working groups must be revised if they choose to
  2211.    continue since they would no longer be proposing an IPng candidate.
  2212.  
  2213.    In Toronto the chairs of the SIPP Working Group requested that the
  2214.    SIPP Working Group be concluded.  The chairs of the TUBA Working
  2215.    Group requested that the TUBA working group be understood to be in
  2216.    hiatus until a number of the documents in process were completed, at
  2217.    which time they would request that the working group be concluded.
  2218.  
  2219.    We recommend that the IPng Area and its Directorate continue until
  2220.    the basic documents have entered the standards track in late 1994 or
  2221.    early 1995 and that after such time the area be dissolved and those
  2222.    IPng Area working groups still active be moved to their normal IETF
  2223.    areas.
  2224.  
  2225. 22. Security Considerations
  2226.  
  2227.    The security of the Internet has long been questioned.  It has been
  2228.    the topic of much press coverage, many conferences and workshops.
  2229.    Almost all of this attention has been negative, pointing out the many
  2230.    places where the level of possible security is far less than that
  2231.    deemed necessary for the current and future uses of the Internet. A
  2232.    number of the RFC 1550 White Papers specifically pointed out the
  2233.    requirement to improve the level of security available [Adam94,
  2234.    Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the
  2235.    Information Future". [Nat94]
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Bradner & Mankin                                               [Page 40]
  2243.  
  2244. RFC 1752                Recommendation for IPng             January 1995
  2245.  
  2246.  
  2247.    In February of 1994, the IAB convened a workshop on security in the
  2248.    Internet architecture.  The report of this workshop [IAB94] includes
  2249.    an exploration of many of the security problem areas and makes a
  2250.    number of recommendations to improve the level of security that the
  2251.    Internet offers its users.
  2252.  
  2253.    We feel that an improvement in the basic level of security in the
  2254.    Internet is vital to its continued success.  Users must be able to
  2255.    assume that their exchanges are safe from tampering, diversion and
  2256.    exposure.  Organizations that wish to use the Internet to conduct
  2257.    business must be able to have a high level of confidence in the
  2258.    identity of their correspondents and in the security of their
  2259.    communications.  The goal is to provide strong protection as a matter
  2260.    of course throughout the Internet.
  2261.  
  2262.    As the IAB report points out, many of the necessary tools are not a
  2263.    function of the internetworking layer of the protocol.  These higher
  2264.    level tools could make use of strong security features in the
  2265.    internetworking layer if they were present. While we expect that
  2266.    there will be a number of special high-level security packages
  2267.    available for specific Internet constituencies, support for basic
  2268.    packet-level authentication will provide for the adoption of a much
  2269.    needed, widespread, security infrastructure throughout the Internet.
  2270.  
  2271.    It is best to separate the support for authentication from the
  2272.    support for encryption.  One should be able to use the two functions
  2273.    independently.  There are some applications in which authentication
  2274.    of a corespondent is sufficient and others where the data exchanged
  2275.    must be kept private.
  2276.  
  2277.    It is our recommendation that IPv6 support packet authentication as a
  2278.    basic and required function.  Applications should be able to rely on
  2279.    support for this feature in every IPv6 implementation.  Support for a
  2280.    specific authentication algorithm should also be mandated while
  2281.    support for additional algorithms should be optional.
  2282.  
  2283.    Thus we recommend that support for the Authentication Header be
  2284.    required in all compliant IPv6 implementations.
  2285.  
  2286.    We recommend that support for a specific authentication algorithm be
  2287.    required.  The specific algorithm should be determined by the time
  2288.    the IPv6 documents are offered as Proposed Standards.
  2289.  
  2290.    We recommend that support for the Privacy Header be required in IPv6
  2291.    implementations.
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Bradner & Mankin                                               [Page 41]
  2299.  
  2300. RFC 1752                Recommendation for IPng             January 1995
  2301.  
  2302.  
  2303.    We recommend that support for a privacy authentication algorithm be
  2304.    required. The specific algorithm should be determined by the time the
  2305.    IPv6 documents are offered as Proposed Standards.
  2306.  
  2307.    Clearly, a key management infrastructure will be required in order to
  2308.    enable the use of the authentication and encryption headers.
  2309.    However, defining such an infrastructure is outside the scope of the
  2310.    IPv6 effort.  We do note that there are on-going IETF activities in
  2311.    this area. The IPv6 transition working groups must coordinate with
  2312.    these activities.
  2313.  
  2314.    Just as clearly, the use of authentication and encryption may add to
  2315.    the cost and impact the performance of systems but the more secure
  2316.    infrastructure is worth the penalty.  Whatever penalty there is
  2317.    should also decrease in time with improved software and hardware
  2318.    assistance.
  2319.  
  2320.    The use of firewalls is increasing on the Internet.  We hope that the
  2321.    presence of the authentication and privacy features in IPv6 will
  2322.    reduce the need for firewalls, but we do understand that they will
  2323.    continue to be used for the foreseeable future.  In this light, we
  2324.    feel that clear guidance should be given to the developers of
  2325.    firewalls on the best ways to design and configure them when working
  2326.    in an IPv6 environment.
  2327.  
  2328.    We recommend that an "IPv6 framework for firewalls" be developed.
  2329.    This framework should explore the ways in which the Authentication
  2330.    Header can be used to strengthen firewall technology and detail how
  2331.    the IPv6 packet should be analyzed by a firewall.
  2332.  
  2333.    Some aspects of security require additional study.  For example, it
  2334.    has been pointed out [Vecchi94] that, even in non-military
  2335.    situations, there are places where procedures to thwart traffic
  2336.    analysis will be required.  This could be done by the use of
  2337.    encrypted encapsulation, but this and other similar requirements must
  2338.    be addressed on an on-going basis by the Security Area of the IETF.
  2339.    The design of IPv6 must be flexible enough to support the later
  2340.    addition of such security features.
  2341.  
  2342.    We believe that IPv6 with its inherent security features will provide
  2343.    the foundation upon which the Internet can continue to expand its
  2344.    functionality and user base.
  2345.  
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Bradner & Mankin                                               [Page 42]
  2355.  
  2356. RFC 1752                Recommendation for IPng             January 1995
  2357.  
  2358.  
  2359. 23. Authors' Addresses
  2360.  
  2361.    Scott Bradner
  2362.    Harvard University
  2363.    10 Ware St.
  2364.    Cambridge, MA 02138
  2365.  
  2366.    Phone: +1 617 495 3864
  2367.    EMail: sob@harvard.edu
  2368.  
  2369.  
  2370.    Allison Mankin
  2371.    USC/Information Sciences Institute
  2372.    4350 North Fairfax Drive, Suite 400
  2373.    Arlington, VA 22303
  2374.  
  2375.    Phone: +1 703-807-0132
  2376.    EMail: mankin@isi.edu
  2377.  
  2378.  
  2379.  
  2380.  
  2381.  
  2382.  
  2383.  
  2384.  
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Bradner & Mankin                                               [Page 43]
  2411.  
  2412. RFC 1752                Recommendation for IPng             January 1995
  2413.  
  2414.  
  2415. Appendix A - Summary of Recommendations
  2416.  
  2417.    5.3 Address Assignment Policy Recommendations
  2418.       changes in address assignment policies are not recommended
  2419.       reclamation of underutilized assigned addresses is not currently
  2420.          recommended
  2421.       efforts to renumber significant portions of the Internet are not
  2422.          currently recommended
  2423.       recommend consideration of assigning CIDR-type address blocks out
  2424.          of unassigned Class A addressees
  2425.    11. IPng Recommendation
  2426.       recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128
  2427.          bit ver)" [Deering94b] be adopted as the basis for IPng
  2428.       recommend that the documents listed in Appendix C be the basis of
  2429.          IPng
  2430.    13. IPng Working Group
  2431.       recommend that an IPng Working Group be formed, chaired by Steve
  2432.          Deering and Ross Callon
  2433.       recommend that Robert Hinden be the document editor for the IPng
  2434.          effort
  2435.    14. IPng Reviewer
  2436.       recommend that an IPng Reviewer be appointed and that Dave Clark
  2437.          be that reviewer
  2438.    15. Address Autoconfiguration
  2439.       recommend that an Address Autoconfiguration Working Group be
  2440.          formed, chaired by Dave Katz and Sue Thomson
  2441.    16.1 Transition - Short Term
  2442.       recommend that an IPng Transition Working Group be formed, chaired
  2443.          by Bob Gilligan and TBA
  2444.    16.2 Transition - Long Term
  2445.       recommend that the Transition and Coexistence Including Testing
  2446.          Working Group be chartered
  2447.    17. Other Address Families
  2448.       recommend that recommendations about the use of non-IPv6 addresses
  2449.          in IPv6 environments and IPv6 addresses in non-IPv6
  2450.          environments be developed
  2451.    18. Impact on Other IETF Standards
  2452.       recommend the IESG commission a review of all standards track RFCs
  2453.       recommend the IESG charge current IETF working groups with the
  2454.          task of understanding the impact of IPng on their proposals
  2455.          and, where appropriate, revise the documents to include support
  2456.          for IPng
  2457.       recommend the IESG charter new working groups where required to
  2458.          revise other standards RFCs
  2459.    20. APIs
  2460.       recommend that Informational RFCs be developed or solicited for a
  2461.          few of the common APIs
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Bradner & Mankin                                               [Page 44]
  2467.  
  2468. RFC 1752                Recommendation for IPng             January 1995
  2469.  
  2470.  
  2471.    21. Future of the IPng Area and Working Groups
  2472.       recommend that the IPng Area and Area Directorate continue until
  2473.          main documents are offered as Proposed Standards in late 1994
  2474.    22. Security Considerations
  2475.       recommend that support for the Authentication Header be required
  2476.       recommend that support for a specific authentication algorithm be
  2477.          required
  2478.       recommend that support for the Privacy Header be required
  2479.       recommend that support for a specific privacy algorithm be
  2480.          required
  2481.       recommend that an "IPng framework for firewalls" be developed
  2482.  
  2483. Appendix B - IPng Area Directorate
  2484.  
  2485.    J. Allard - Microsoft           <jallard@microsoft.com>
  2486.    Steve Bellovin  - AT&T          <smb@research.att.com>
  2487.    Jim Bound  - Digital            <bound@zk3.dec.com>
  2488.    Ross Callon  - Wellfleet        <rcallon@wellfleet.com>
  2489.    Brian Carpenter  - CERN         <brian.carpenter@cern.ch>
  2490.    Dave Clark  - MIT               <ddc@lcs.mit.edu >
  2491.    John Curran  - NEARNET          <curran@nic.near.net>
  2492.    Steve Deering  - Xerox          <deering@parc.xerox.com>
  2493.    Dino Farinacci  - Cisco         <dino@cisco.com>
  2494.    Paul Francis - NTT              <francis@slab.ntt.jp>
  2495.    Eric Fleischmann  - Boeing      <ericf@atc.boeing.com>
  2496.    Mark Knopper - Ameritech        <mak@aads.com>
  2497.    Greg Minshall  - Novell         <minshall@wc.novell.com>
  2498.    Rob Ullmann - Lotus             <ariel@world.std.com>
  2499.    Lixia Zhang  - Xerox            <lixia@parc.xerox.com>
  2500.  
  2501.    Daniel Karrenberg of RIPE joined the Directorate when it was formed
  2502.    but had to withdraw due to the demands of his day job.
  2503.  
  2504.    Since the Toronto IETF meeting Paul Francis has resigned from the
  2505.    Directorate to pursue other interests.  Robert Hinden of Sun
  2506.    Microsystems and Yakov Rekhter of IBM joined.
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Bradner & Mankin                                               [Page 45]
  2523.  
  2524. RFC 1752                Recommendation for IPng             January 1995
  2525.  
  2526.  
  2527. Appendix C - Documents Referred to the IPng Working Groups
  2528.  
  2529.    [Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec.
  2530.       (128 bit ver)", Work in Progress.
  2531.  
  2532.    [Francis94] Francis, P., "SIPP Addressing Architecture", Work in
  2533.       Progress.
  2534.  
  2535.    [Rekhter94] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
  2536.       Address Allocation", Work in Progress.
  2537.  
  2538.    [Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview",
  2539.       Work in Progress.
  2540.  
  2541.    [Gillig94b] Gilligan, R., Govindan, R., Thomson, S., and J. Bound,
  2542.       "SIPP Program Interfaces for BSD Systems", Work in Progress.
  2543.  
  2544.    [Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in
  2545.       Progress.
  2546.  
  2547.    [Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in
  2548.       Progress.
  2549.  
  2550.    [Ford94b] Ford, P., Li, T., and Y. Rekhter, "SDRP Routing Header for
  2551.       SIPP-16", Work in Progress.
  2552.  
  2553.    [Hinden94c] Hinden, R., "IP Next Generation Overview", Work in
  2554.       Progress.
  2555.  
  2556. Appendix D - IPng Proposal Overviews
  2557.  
  2558.    [Ford94a] Ford, P., and M. Knopper, "TUBA as IPng: A White Paper",
  2559.       Work in Progress.
  2560.  
  2561.    [Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper",
  2562.       RFC 1710, Sun Microsystems, October 1994.
  2563.  
  2564.    [McGovern94] McGovern, M., and R. Ullmann, "CATNIP: Common
  2565.       Architecture for the Internet", RFC 1707, Sunspot Graphics, Lotus
  2566.       Development Corp., October 1994.
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578. Bradner & Mankin                                               [Page 46]
  2579.  
  2580. RFC 1752                Recommendation for IPng             January 1995
  2581.  
  2582.  
  2583. Appendix E - RFC 1550 White Papers
  2584.  
  2585.    [Adam94] Adamson, B., "Tactical Radio Frequency Communication
  2586.       Requirements for IPng", RFC 1677, NRL, August 1994.
  2587.  
  2588.    [Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T
  2589.       Bell Laboratories, August 1994.
  2590.  
  2591.    [Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T
  2592.       Bell Laboratories, August 1994.
  2593.  
  2594.    [Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC
  2595.       1682, Digital Equipment Corporation, August 1994.
  2596.  
  2597.    [Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680,
  2598.       Bellcore, August 1994.
  2599.  
  2600.    [Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large
  2601.       Corporate Networks", RFC 1678, IBM, August 1994.
  2602.  
  2603.    [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC
  2604.       1672, University of Auckland, August 1994.
  2605.  
  2606.    [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other
  2607.       Considerations", RFC 1671, CERN, August 1994.
  2608.  
  2609.    [Chiappa94] Chiappa, N., "IPng Technical Requirements Of the Nimrod
  2610.       Routing and Addressing Architecture", RFC 1753, December 1994.
  2611.  
  2612.    [Clark94] Clark, R., Ammar, M., and K. Calvert, "Multiprotocol
  2613.       Interoperability In IPng", RFC 1683, Georgia Institute of
  2614.       Technology, August 1994.
  2615.  
  2616.    [Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC
  2617.       1669, BBN, August 1994.
  2618.  
  2619.    [Estrin94a] Estrin, D., Li, T., and Y. Rekhter, "Unified Routing
  2620.       Requirements for IPng", RFC 1668, USC, cisco Systems, IBM, August
  2621.       1994.
  2622.  
  2623.    [Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng",
  2624.       RFC 1687, Boeing Computer Services, August 1994.
  2625.  
  2626.    [Green94] Green, D., Irey, P., Marlow, D., and K. O'Donoghue, "HPN
  2627.       Working Group Input to the IPng Requirements Solicitation", RFC
  2628.       1679, NSWC-DD, August 1994.
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634. Bradner & Mankin                                               [Page 47]
  2635.  
  2636. RFC 1752                Recommendation for IPng             January 1995
  2637.  
  2638.  
  2639.    [Ghisel94] Ghiselli, A., Salomoni, D., and C. Vistoli, "INFN
  2640.       Requirements for an IPng", RFC 1676, INFN/CNAF, August 1994.
  2641.  
  2642.    [Heager94] Heagerty, D., "Input to IPng Engineering Considerations",
  2643.       RFC 1670, CERN, August 1994.
  2644.  
  2645.    [Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688,
  2646.       Daydreamer, August 1994.
  2647.  
  2648.    [Skelton94] Skelton, R., "Electric Power Research Institute Comments
  2649.       on IPng", RFC 1673, EPRI, August 1994.
  2650.  
  2651.    [Syming94] Symington, S., Wood, D., and J. Pullen, "Modeling and
  2652.       Simulation Requirements for IPng", RFC 1667, MITRE, George Mason
  2653.       University, August 1994.
  2654.  
  2655.    [Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674,
  2656.       CDPD Consortium, August 1994.
  2657.  
  2658.    [Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television
  2659.       Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994.
  2660.  
  2661. Appendix F - Additional References
  2662.  
  2663.    [Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF",
  2664.       Washington DC IETF, November 1992, (ietf/nov92/select-minutes-
  2665.       92nov.txt).
  2666.  
  2667.    [Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and
  2668.       Requirements", Work in Progress, September 1994.
  2669.  
  2670.    [Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF
  2671.       (ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes-
  2672.       94mar.txt).
  2673.  
  2674.    [Big] Archives of the big-internet mailing list, on munnari.oz.au in
  2675.       big-internet/list-archives.
  2676.  
  2677.    [Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng)
  2678.       White Paper Solicitation", RFC 1550, Harvard University, NRL,
  2679.       December 1993.
  2680.  
  2681.    [Callon87] Callon, R., "A Proposal for a Next Generation Internet
  2682.       Protocol", Proposal to X3S3, December 1987.
  2683.  
  2684.    [Callon92a] Callon, R., "CNAT", Work in Progress.
  2685.  
  2686.    [Callon92b] Callon, R., "Simple CLNP", Work in Progress.
  2687.  
  2688.  
  2689.  
  2690. Bradner & Mankin                                               [Page 48]
  2691.  
  2692. RFC 1752                Recommendation for IPng             January 1995
  2693.  
  2694.  
  2695.    [Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A
  2696.       Simple Proposal for Internet Addressing and Routing", RFC 1347,
  2697.       DEC, June 1992.
  2698.  
  2699.    [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
  2700.       Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
  2701.       August 1993.
  2702.  
  2703.    [Carpen94b] Carpenter, B, and J. Bound, "Recommendations for OSI NSAP
  2704.       usage in IPv6", Work in Progress.
  2705.  
  2706.    [Chiappa91]  Chiappa, J., "A New IP Routing and Addressing
  2707.       Architecture", Work in Progress.
  2708.  
  2709.    [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
  2710.       "Towards the Future Internet Architecture", RFC 1287, MIT, BBN,
  2711.       CNRI, ISI, UC Davis, December 1991.
  2712.  
  2713.    [Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet
  2714.       mailing list, 22 Sept. 1992.
  2715.  
  2716.    [Deering94a] Deering, S., and P. Francis, Message to sipp mailing
  2717.       list, 31 May 1994.
  2718.  
  2719.    [Estrin94b] Estrin, D., Zappala, D., Li, T., Rekhter, Y., and K.
  2720.       Varadhan, "Source Demand Routing: Packet Format and Forwarding
  2721.       Specification (Version 1)" Work in Progress.
  2722.  
  2723.    [Fuller93] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
  2724.       Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
  2725.       Strategy", RFC 1519, BARRNet, cisco Systems, MERIT, OARnet,
  2726.       September 1993.
  2727.  
  2728.    [Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in
  2729.       Progress.
  2730.  
  2731.    [Gross92} Gross, P., and P. Almquist, "IESG Deliberations on Routing
  2732.       and Addressing", RFC 1380, ANS, Stanford University, November
  2733.       1992.
  2734.  
  2735.    [Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December
  2736.       1994.
  2737.  
  2738.    [Hinden92a] Hinden, R., "New Scheme for Internet Routing and
  2739.       Addressing (ENCAPS)", Work in Progress.
  2740.  
  2741.    [Hinden94b] Hinden, R., Deering, S., and P. Francis, "Simple Internet
  2742.       Protocol Plus", Working Group Charter, April 1994.
  2743.  
  2744.  
  2745.  
  2746. Bradner & Mankin                                               [Page 49]
  2747.  
  2748. RFC 1752                Recommendation for IPng             January 1995
  2749.  
  2750.  
  2751.    [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address
  2752.       Encapsulation (IPAE): A Compatible version of IP with Large
  2753.       Addresses", Work in Progress.
  2754.  
  2755.    [Huston94] Huston, G., and A. Bansal, draft charter for the
  2756.       "Transition and Coexistence Including Testing (TACIT) Working
  2757.       Group, June 1994.
  2758.  
  2759.    [Huitema93] Huitema, C., "IAB Recommendations for an Intermediate
  2760.       Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July
  2761.       1993.
  2762.  
  2763.    [Huitema94] Huitema, C., "The H ratio for address assignment
  2764.       efficiency", RFC 1715, INRIA, October 1994.
  2765.  
  2766.    [IAB92] Internet Architecture Board, "IP Version 7", Work in
  2767.       Progress.
  2768.  
  2769.    [IAB94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
  2770.       of IAB Workshop on Security in the Internet Architecture -
  2771.       February 8-10, 1994", RFC 1636, USC/Informaiton Sciences
  2772.       Institute, MIT Laboratory for Computer Science, Trusted
  2773.       Information Systems, Inc., INRIA, IAB Chair, June 1994.
  2774.  
  2775.    [Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical
  2776.       Criteria", Work in Progress.
  2777.  
  2778.    [Kasten94] Partridge, C., and F. Kastenholz, "Technical Criteria for
  2779.       Choosing IP: The Next Generation (IPng)", RFC 1726, BBN Systems
  2780.       and Technologies, FTP Software, December 1994.
  2781.  
  2782.    [Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed
  2783.       Networks (TUBA)", Working Group Charter, January 1994.
  2784.  
  2785.    [Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen
  2786.       IPng Retreat, May 19 & 20 1994".
  2787.  
  2788.    [Leiner93] Leiner, B., and Y. Rekhter, "The MultiProtocol Internet",
  2789.       RFC 1560, USRA, IBM, December 1993.
  2790.  
  2791.    [Mankin94] Mankin, A., and S. Bradner, message to big-internet, tuba,
  2792.       sipp, catnip and ietf mailing lists, 7 July 1994.
  2793.  
  2794.    [Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification",
  2795.       RFC 904, UDEL, April 1984.
  2796.  
  2797.    [Mogul90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
  2798.       DECWRL, Stanford University, November 1990.
  2799.  
  2800.  
  2801.  
  2802. Bradner & Mankin                                               [Page 50]
  2803.  
  2804. RFC 1752                Recommendation for IPng             January 1995
  2805.  
  2806.  
  2807.    [Nat94] National Research Council, "Realizing the Information Future:
  2808.       The Internet and Beyond", National Academy Press, 1994.
  2809.  
  2810.    [Piscit94] Piscitello, D., "FTP Operation Over Big Address Records
  2811.       (FOOBAR)", RFC 1639, Core Competence, June 1994.
  2812.  
  2813.    [Provan91] Provan, D., "Transmitting IP Traffic over ARCNET
  2814.       Networks", RFC 1051, Novell, February 1991.
  2815.  
  2816.    [Postel94] Postel, J., Editor, "Internet Official Protocol
  2817.       Standards", RFC 1720, USC/Information Sciences Institute, November
  2818.       1994.
  2819.  
  2820.    [Solens93a] Solensky, F., and T. Li, "Charter for the Address
  2821.       Lifetime Expectations Working Group", FTP Software, Cisco Systems,
  2822.       November 1993.
  2823.  
  2824.    [Solens93b] Solensky, F., "Minutes of the Address Lifetime
  2825.       Expectations BOF (ALE)", Houston IETF, November 1993,
  2826.       (ietf/ale/ale-minutes-93nov.txt).
  2827.  
  2828.    [Solens94] Solensky, F., "Minutes of the Address Lifetime
  2829.       Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale-
  2830.       minutes-94jul.txt).
  2831.  
  2832.    [Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation
  2833.       IP (catnip), Working Group Charter, April 1994.
  2834.  
  2835.    [Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in
  2836.       Progress.
  2837.  
  2838.    [Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
  2839.       Process Software Corporation, June 1993.
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856.  
  2857.  
  2858. Bradner & Mankin                                               [Page 51]
  2859.  
  2860. RFC 1752                Recommendation for IPng             January 1995
  2861.  
  2862.  
  2863. Appendix G - Acknowledgments
  2864.  
  2865.    Reaching this stage of the recommendation would not have been even
  2866.    vaguely possible without the efforts of many people.  In particular,
  2867.    the work of IPng Directorate (listed in Appendix B), Frank Kastenholz
  2868.    and Craig Partridge (the authors of the Criteria document) along with
  2869.    Jon Crowcroft (who co-chaired the ngreq BOF) was critical.  The work
  2870.    and cooperation of the chairs, members and document authors of the
  2871.    three IPng proposal working groups, the ALE working group and the
  2872.    TACIT working group laid the groundwork upon which this
  2873.    recommendation sits.
  2874.  
  2875.    We would also like to thank the many people who took the time to
  2876.    respond to RFC1550 and who provided the broad understanding of the
  2877.    many requirements of data networking that any proposal for an IPng
  2878.    must address.
  2879.  
  2880.    The members of the IESG, the IAB, and the always active participants
  2881.    in the various mailing lists provided us with many insights into the
  2882.    issues we faced.
  2883.  
  2884.    Many other individuals gave us sometimes spirited but always useful
  2885.    counsel during this process.  They include (in no particular order)
  2886.    Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave
  2887.    Piscitello, Vint Cerf and Dan Lynch.
  2888.  
  2889.    Thanks to David Williams and Cheryl Chapman who took on the
  2890.    occasionally impossible task of ensuring that what is written here
  2891.    resembles English to some degree.
  2892.  
  2893.    To all of the many people mentioned above and those we have skipped
  2894.    in our forgetfulness, thank you for making this task doable.
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.  
  2909.  
  2910.  
  2911.  
  2912.  
  2913.  
  2914. Bradner & Mankin                                               [Page 52]
  2915.  
  2916.