idnits 2.17.1 draft-ipng-recommendation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 208 has weird spacing: '...all for propo...' == Line 477 has weird spacing: '...ith the servi...' == Line 481 has weird spacing: '...testing and d...' == Line 1386 has weird spacing: '...ormance and m...' == Line 1407 has weird spacing: '...ecurity assoc...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1994) is 10816 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Deering94b' on line 2058 looks like a reference -- Missing reference section? 'Callon87' on line 2152 looks like a reference -- Missing reference section? 'Vecchi94' on line 2135 looks like a reference -- Missing reference section? 'Taylor94' on line 2133 looks like a reference -- Missing reference section? 'Huitema94' on line 2199 looks like a reference -- Missing reference section? 'Gross92' on line 499 looks like a reference -- Missing reference section? 'Fuller93' on line 2176 looks like a reference -- Missing reference section? 'IAB92' on line 2201 looks like a reference -- Missing reference section? 'Carpen93' on line 2159 looks like a reference -- Missing reference section? 'Gross94' on line 2184 looks like a reference -- Missing reference section? 'Solens93a' on line 2232 looks like a reference -- Missing reference section? 'Solens93b' on line 2235 looks like a reference -- Missing reference section? 'Bos93' on line 308 looks like a reference -- Missing reference section? 'Solens94' on line 2238 looks like a reference -- Missing reference section? 'Rekhter94' on line 2062 looks like a reference -- Missing reference section? 'Almqu92' on line 2140 looks like a reference -- Missing reference section? 'Bradner93' on line 2149 looks like a reference -- Missing reference section? 'Skelton94' on line 2128 looks like a reference -- Missing reference section? 'Adam94' on line 2091 looks like a reference -- Missing reference section? 'Syming94' on line 2130 looks like a reference -- Missing reference section? 'Green94' on line 2119 looks like a reference -- Missing reference section? 'Brazd94' on line 2099 looks like a reference -- Missing reference section? 'Simpson94' on line 2126 looks like a reference -- Missing reference section? 'Brown94' on line 407 looks like a reference -- Missing reference section? 'Britt94' on line 2101 looks like a reference -- Missing reference section? 'Fleisch94' on line 2117 looks like a reference -- Missing reference section? 'Carpen94a' on line 2105 looks like a reference -- Missing reference section? 'Heager94' on line 2124 looks like a reference -- Missing reference section? 'Curran94' on line 2112 looks like a reference -- Missing reference section? 'Bound94' on line 2097 looks like a reference -- Missing reference section? 'Bello94a' on line 2093 looks like a reference -- Missing reference section? 'Clark94' on line 2109 looks like a reference -- Missing reference section? 'Ghisel94' on line 2122 looks like a reference -- Missing reference section? 'Kasten92' on line 2206 looks like a reference -- Missing reference section? 'Kasten94' on line 2209 looks like a reference -- Missing reference section? 'Callon92a' on line 2154 looks like a reference -- Missing reference section? 'Hinden92a' on line 2185 looks like a reference -- Missing reference section? 'Chiappa91' on line 2164 looks like a reference -- Missing reference section? 'Callon92b' on line 2155 looks like a reference -- Missing reference section? 'Tsuchiya92' on line 2243 looks like a reference -- Missing reference section? 'Deering92' on line 2169 looks like a reference -- Missing reference section? 'Ullmann93' on line 2245 looks like a reference -- Missing reference section? 'Callon92c' on line 2156 looks like a reference -- Missing reference section? 'Hinden92b' on line 2190 looks like a reference -- Missing reference section? 'McGovern94' on line 2085 looks like a reference -- Missing reference section? 'Hinden94a' on line 2083 looks like a reference -- Missing reference section? 'Ford94a' on line 2081 looks like a reference -- Missing reference section? 'Chiappa94' on line 2107 looks like a reference -- Missing reference section? 'Sukonnik94' on line 2241 looks like a reference -- Missing reference section? 'Hinden94b' on line 2188 looks like a reference -- Missing reference section? 'Knopper94' on line 607 looks like a reference -- Missing reference section? 'Big' on line 2147 looks like a reference -- Missing reference section? 'Knopper94b' on line 2214 looks like a reference -- Missing reference section? 'Deering94a' on line 2171 looks like a reference -- Missing reference section? 'Francis94' on line 2060 looks like a reference -- Missing reference section? 'Gillig94a' on line 2064 looks like a reference -- Missing reference section? 'Mankin94' on line 2218 looks like a reference -- Missing reference section? 'Hinden94c' on line 2076 looks like a reference -- Missing reference section? 'Estrin94b' on line 2173 looks like a reference -- Missing reference section? 'Berk94' on line 1547 looks like a reference -- Missing reference section? 'Katz94a' on line 1576 looks like a reference -- Missing reference section? 'Katz94b' on line 1580 looks like a reference -- Missing reference section? 'Gillig94c' on line 2180 looks like a reference -- Missing reference section? 'Gilig94a' on line 1639 looks like a reference -- Missing reference section? 'Huston94' on line 2193 looks like a reference -- Missing reference section? 'Carpen94b' on line 2162 looks like a reference -- Missing reference section? 'Postel94' on line 2230 looks like a reference -- Missing reference section? 'Mills84' on line 2220 looks like a reference -- Missing reference section? 'Provan91' on line 2228 looks like a reference -- Missing reference section? 'Piscit94' on line 2226 looks like a reference -- Missing reference section? 'Mogul90' on line 2222 looks like a reference -- Missing reference section? 'Gillig94b' on line 2067 looks like a reference -- Missing reference section? 'Nat94' on line 2224 looks like a reference -- Missing reference section? 'IAB94' on line 2203 looks like a reference -- Missing reference section? 'Atkins94a' on line 2070 looks like a reference -- Missing reference section? 'Atkins94b' on line 2072 looks like a reference -- Missing reference section? 'Ford94b' on line 2074 looks like a reference -- Missing reference section? 'Bello94b' on line 2095 looks like a reference -- Missing reference section? 'Brownl94' on line 2103 looks like a reference -- Missing reference section? 'Estrin94a' on line 2114 looks like a reference -- Missing reference section? 'Berkow94' on line 2143 looks like a reference -- Missing reference section? 'Bos94' on line 2145 looks like a reference -- Missing reference section? 'Clark91' on line 2166 looks like a reference -- Missing reference section? 'Huitema93' on line 2196 looks like a reference -- Missing reference section? 'Knopper94a' on line 2212 looks like a reference -- Missing reference section? 'Leiner93' on line 2216 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 88 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bradner 2 Internet draft Harvard University 3 A. Mankin 4 NRL 5 September 1994 7 The Recommendation for the IP Next Generation Protocol 9 11 Status of this Memo 13 This document presents the recommendation of the IPng Area Directors 14 on what should be used to replace the current version of the Internet 15 Protocol. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net 32 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 33 Rim). 35 Table of Contents 37 1. Summary. . . . . . . . . . . . . . . . . . . . . . . . . .4 38 2. Background . . . . . . . . . . . . . . . . . . . . . . . .5 39 3. A Direction for IPng . . . . . . . . . . . . . . . . . . .6 40 4. IPng Area. . . . . . . . . . . . . . . . . . . . . . . . .7 41 5. ALE Working Group. . . . . . . . . . . . . . . . . . . . .8 42 5.1 ALE Projections. . . . . . . . . . . . . . . . . . . . . .8 43 5.2 Routing Table Size . . . . . . . . . . . . . . . . . . . .9 44 5.3 Address Assignment Policy Recommendations. . . . . . . . .9 45 6. IPng Technical Requirements. . . . . . . . . . . . . . . 10 46 6.1 The IPng Technical Criteria document . . . . . . . . . . 11 47 7. IPng Proposals . . . . . . . . . . . . . . . . . . . . . 12 48 7.1 CATNIP. . . . . . . . . . . . . . . . . . . . . . . . . 13 49 7.2 SIPP. . . . . . . . . . . . . . . . . . . . . . . . . . 13 50 7.3 TUBA. . . . . . . . . . . . . . . . . . . . . . . . . . 14 51 8. IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 15 52 8.1 CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 16 53 8.2 SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 16 54 8.3 TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 17 55 8.4 Summary of Proposal Reviews. . . . . . . . . . . . . . . 18 56 9. A Revised Proposal . . . . . . . . . . . . . . . . . . . 19 57 10 Assumptions . . . . . . . . . . . . . . . . . . . . . . 20 58 10.1 Criteria Document and Timing of Recommendation . . . . . 20 59 10.2 Address Length . . . . . . . . . . . . . . . . . . . . . 20 60 11. IPng Recommendation. . . . . . . . . . . . . . . . . . . 21 61 11.1 IPng Criteria Document and IPng. . . . . . . . . . . . . 22 62 11.2 IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . 23 63 12. IPv6 Overview . . . . . . . . . . . . . . . . . . . . . 23 64 12.1 IPv6 Header Format . . . . . . . . . . . . . . . . . . . 25 65 12.2 Extension Headers. . . . . . . . . . . . . . . . . . . . 26 66 12.2.1 Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 26 67 12.2.2 IPv6 Header Options. . . . . . . . . . . . . . . . . . . 27 68 12.2.3 Routing Header . . . . . . . . . . . . . . . . . . . . . 28 69 12.2.4 Fragment Header. . . . . . . . . . . . . . . . . . . . . 29 70 12.2.5 Authentication Header. . . . . . . . . . . . . . . . . . 30 71 12.2.6 Privacy Header . . . . . . . . . . . . . . . . . . . . . 31 72 12.2.7 End-to-End Option Header . . . . . . . . . . . . . . . . 33 73 13. IPng Working Group . . . . . . . . . . . . . . . . . . . 33 74 14. IPng Reviewer . . . . . . . . . . . . . . . . . . . . . 34 75 15. Address Autoconfiguration. . . . . . . . . . . . . . . . 35 76 16. Transition . . . . . . . . . . . . . . . . . . . . . . . 36 77 16.1 Transition - Short Term. . . . . . . . . . . . . . . . . 36 78 16.2 Transition - Long Term . . . . . . . . . . . . . . . . . 37 79 17. Other Address Families . . . . . . . . . . . . . . . . . 38 80 18. Impact on Other IETF Standards . . . . . . . . . . . . . 39 81 19. Impact on non-IETF standards and on products . . . . . . 40 82 20. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 83 21. Future of the IPng Area and Working Groups . . . . . . . 41 84 22. Security Considerations. . . . . . . . . . . . . . . . . 42 85 23. Authors' Addresses . . . . . . . . . . . . . . . . . . . 44 87 Appendix A Summary of Recommendations . . . . . . . . . . . . . 45 88 Appendix B IPng Area Directorate. . . . . . . . . . . . . . . . 46 89 Appendix C Documents Referred to the IPng Working Groups. . . . 46 90 Appendix D IPng Proposal Overviews. . . . . . . . . . . . . . . 47 91 Appendix E RFC 1550 White Papers. . . . . . . . . . . . . . . . 47 92 Appendix F Additional References. . . . . . . . . . . . . . . . 48 93 Appendix G Acknowledgments. . . . . . . . . . . . . . . . . . . 50 95 1. Summary 97 The IETF started its effort to select a successor to IPv4 in late 98 1990 when projections indicated that the Internet address space would 99 become an increasingly limiting resource. Several parallel efforts 100 then started exploring ways to resolve these address limitations 101 while at the same time providing additional functionality. The IETF 102 formed the IPng Area in late 1993 to investigate the various 103 proposals and recommend how to proceed. We developed an IPng 104 technical criteria document and evaluated the various proposals 105 against it. All were found wanting to some degree. After this 106 evaluation, a revised proposal was offered by one of the working 107 groups that resolved many of the problems in the previous proposals. 108 The IPng Area Directors recommend that the IETF designate this 109 revised proposal as the IPng and focus its energy on bringing a set 110 of documents defining the IPng to Proposed Standard status with all 111 deliberate speed. 113 This protocol recommendation includes a simplified header with a 114 hierarchical address structure that permits rigorous route 115 aggregation and is also large enough to meet the needs of the 116 Internet for the foreseeable future. The protocol also includes 117 packet-level authentication and encryption along with plug and play 118 autoconfiguration. The design changes the way IP header options are 119 encoded to increase the flexibility of introducing new options in the 120 future while improving performance. It also includes the ability to 121 label traffic flows. 123 Specific recommendations include: 125 * current address assignment policies are adequate 126 * there is no current need to reclaim underutilized assigned network 127 numbers 128 * there is no current need to renumber major portions of the Internet 129 * CIDR-style assignments of parts of unassigned Class A address space 130 should be considered 131 * "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" 132 [Deering94b] be adopted as the basis for IPng 133 * the documents listed in Appendix C be the foundation of the IPng 134 effort 135 * an IPng Working Group be formed, chaired by Steve Deering and Ross 136 Callon 137 * Robert Hinden be the document editor for the IPng effort 138 * an IPng Reviewer be appointed and that Dave Clark be the reviewer 139 * an Address Autoconfiguration Working Group be formed, chaired by 140 Dave Katz and Sue Thomson 141 * an IPng Transition Working Group be formed, chaired by Bob Gilligan 142 and TBA 144 * the Transition and Coexistence Including Testing Working Group be 145 chartered 146 * recommendations about the use of non-IPv6 addresses in IPv6 147 environments and IPv6 addresses in non-IPv6 environments be 148 developed 149 * the IESG commission a review of all IETF standards documents for 150 IPng implications 151 * the IESG task current IETF working groups to take IPng into account 152 * the IESG charter new working groups where needed to revise old 153 standards documents 154 * Informational RFCs be solicited or developed describing a few 155 specific IPng APIs 156 * the IPng Area and Area Directorate continue until main documents 157 are offered as Proposed Standards in late 1994 158 * support for the Authentication Header be required 159 * support for a specific authentication algorithm be required 160 * support for the Privacy Header be required 161 * support for a specific privacy algorithm be required 162 * an "IPng framework for firewalls" be developed 164 2. Background 166 Even the most farseeing of the developers of TCP/IP in the early 167 1980s did not imagine the dilemma of scale that the Internet faces 168 today. 1987 estimates projected a need to address as many as 100,000 169 networks at some vague point in the future. [Callon87] We will reach 170 that mark by 1996. There are many realistic projections of many 171 millions of interconnected networks in the not too distant future. 172 [Vecchi94, Taylor94] 174 Further, even though the current 32 bit IPv4 address structure can 175 enumerate over 4 billion hosts on as many as 16.7 million networks, 176 the actual address assignment efficiency is far less than that, even 177 on a theoretical basis. [Huitema94] This inefficiency is exacerbated 178 by the granularity of assignments using Class A, B and C addresses. 180 In August 1990 during the Vancouver IETF meeting, Frank Solensky, 181 Phill Gross and Sue Hares projected that the current rate of 182 assignment would exhaust the Class B space by March of 1994. 184 The then obvious remedy of assigning multiple Class C addresses in 185 place of Class B addresses introduced its own problem by further 186 expanding the size of the routing tables in the backbone routers 187 already growing at an alarming rate. 189 We faced the dilemma of choosing between accepting either limiting 190 the rate of growth and ultimate size of the Internet, or disrupting 191 the network by changing to new techniques or technologies. 193 The IETF formed the Routing and Addressing (ROAD) group in November 194 1991 at the Santa Fe IETF meeting to explore this dilemma and guide 195 the IETF on the issues. The ROAD group reported their work in March 196 1992 at the San Diego IETF meeting. [Gross92] The impact of the 197 recommendations ranged from "immediate" to "long term" and included 198 adopting the CIDR route aggregation proposal [Fuller93] for reducing 199 the rate of routing table growth and recommending a call for 200 proposals "to form working groups to explore separate approaches for 201 bigger Internet addresses." 203 In the late spring of 1992 the IAB issued "IP version 7" [IAB92], 204 concurring in the ROAD group's endorsement of CIDR and also 205 recommending "an immediate IETF effort to prepare a detailed and 206 organizational plan for using CLNP as the basis for IPv7." After 207 spirited discussion, the IETF decided to reject the IAB's 208 recommendation and issue the call for proposals recommended by the 209 ROAD group. This call was issued in July 1992 at the Boston IETF 210 meeting and a number of working groups were formed in response 212 During the July 1993 Amsterdam IETF meeting an IPng (IP Next 213 Generation) Decision Process (ipdecide) BOF was held. This BOF "was 214 intended to help re-focus attention on the very important topic of 215 making a decision between the candidates for IPng. The BOF focused on 216 the issues of who should take the lead in making the recommendation 217 to the community and what criteria should be used to reach the 218 recommendation." [Carpen93] 220 3. A Direction for IPng 222 In September 1993 Phill Gross, chair of the IESG issued "A Direction 223 for IPng". [Gross94] In this memo he summarized the results of the 224 ipdecide BOF and open IESG plenary in Amsterdam. 226 * The IETF needs to move toward closure on IPng. 227 * The IESG has the responsibility for developing an IPng 228 recommendation for the Internet community. 229 * The procedures of the recommendation-making process should be open 230 and published well in advance by the IESG. 231 * As part of this process, the IPng WGs may be given new milestones 232 and other guidance to aid the IESG. 233 * There should be ample opportunity for community comment prior to 234 final IESG recommendation. 236 The memo also announced "a temporary, ad hoc, 'area' to deal 237 specifically with IPng issues." Phill asked two of the current IESG 238 members, Allison Mankin (Transport Services Area) and Scott Bradner 239 (Operational Requirements Area), to act as Directors for the new 240 area. The Area Directors were given a specific charge on how to 241 investigate the various IPng proposals and how to base their 242 recommendation to the IETF. It was also requested that a specific 243 recommendation be made. 245 * Establish an IPng directorate. 246 * Ensure that a completely open process is followed. 247 * Develop an understanding of the level of urgency and the time 248 constraints imposed by the rate of address assignment and rate of 249 growth in the routing tables. 250 * Recommend the adoption of assignment policy changes if warranted. 251 * Define the scope of the IPng effort based on the understanding of 252 the time constraints. 253 * Develop a clear and concise set of technical requirements and 254 decision criteria for IPng. 255 * Develop a recommendation about which of the current IPng candidates 256 to accept, if any. 258 4. IPng Area 260 After the IPng Area was formed, we recruited a directorate. (Appendix 261 B) The members of the directorate were chosen both for their general 262 and specific technical expertise. The individuals were then asked to 263 have their management authorize this participation in the process and 264 confirm that they understood the IETF process. 266 We took great care to ensure the inclusion of a wide spectrum of 267 knowledge. The directors are experts in security, routing, the 268 needs of large users, end system manufacturers, Unix and non-Unix 269 platforms, router manufacturers, theoretical researchers, protocol 270 architecture, and the operating regional, national, and international 271 networks. Additionally, several members of the directorate were 272 deeply involved in each of the IPng proposal working groups. 274 The directorate functions as a direction-setting and preliminary 275 review body as requested by the charge to the area. The directorate 276 engages in biweekly conference calls, participates in an internal 277 mailing list and corresponds actively on the Big-Internet mailing 278 list. The directorate held open meetings during the March 1994 279 Seattle and July 1994 Toronto IETF meetings as well as two additional 280 multi-day retreats. To ensure that the IPng process was as open as 281 possible, we took minutes during these meetings and then published 282 them. Additionally, we placed the archives of the internal IPng 283 mailing list on an anonymous ftp site. (Hsdndev.harvard.edu: 284 pub/ipng.) 286 5. ALE Working Group 288 We needed a reasonable estimate of the time remaining before we 289 exhausted the IPv4 address space in order to determine the scope of 290 the IPng effort. If the time remaining was about the same needed to 291 deploy a replacement, then we would have select the IPng which would 292 only fix the address limitations since we would not have enough time 293 to develop any other features. If more time seemed available, we 294 could consider additional improvements. 296 The IETF formed an Address Lifetime Expectations (ALE) Working Group 297 in 1993 "to develop an estimate for the remaining lifetime of the 298 IPv4 address space based on currently known and available 299 technologies." [Solens93a] Tony Li of Cisco Systems and Frank 300 Solensky of FTP Software are the co-chairs. The IETF also charged 301 the working group to consider if developing more stringent address 302 allocation and utilization policies might provide more time for the 303 transition. 305 5.1 ALE Projections 307 The ALE Working Group met during the November 1993 Houston, 308 [Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto 309 [Solens94] IETF meetings. They projected at the Seattle meeting, 310 later confirmed at the Toronto meeting that, using the current 311 allocation statistics, the Internet would exhaust the IPv4 address 312 space between 2005 and 2011. 314 Some members of the ipv4-ale and big-internet mailing lists called 315 into question the reliability of this projection. It has been 316 criticized as both too optimistic and as too pessimistic. 318 Some people pointed out that this type of projection makes an 319 assumption of no paradigm shifts in IP usage. If someone were to 320 develop a new 'killer application', (for example cable-TV set top 321 boxes.) The resultant rise in the demand for IP addresses could make 322 this an over-estimate of the time available. 324 There may also be a problem with the data used to make the 325 projection. The InterNIC allocates IP addresses in large chunks to 326 regional Network Information Centers (NICs) and network providers. 327 The NICs and the providers then re-allocate addresses to their 328 customers. The ALE projections used the Internic assignments without 329 regard to the actual rate of assignment of addresses to the end 330 users. They did the projection this way since the accuracy of the 331 data seems quite a bit higher. While using this once-removed data 332 may add a level of over-estimation since it assumes the rate of large 333 block allocation will continue, this may not be the case. 335 These factors reduce the reliability of the ALE estimates but, in 336 general, they seem to indicate enough time remaining in the IPv4 337 address space to consider adding features in an IPng besides just 338 expanding the address size even when considering time required for 339 development, testing, and deployment. 341 5.2 Routing Table Size 343 Another issue in Internet scaling is the increasing size of the 344 routing tables required in the backbone routers. Adopting the CIDR 345 block address assignment and aggregating routes reduced the size of 346 the tables for awhile but they are now expanding again. Providers now 347 need to more aggressively advertise their routes only in aggregates. 348 Providers must also advise their new customers to renumber their 349 networks in the best interest of the entire Internet community. 351 The problem of exhausting the IPv4 address space may be moot if this 352 issue is ignored and if routers cannot be found that can keep up with 353 the table size growth. Before implementing CIDR the backbone routing 354 table was growing at a rate about 1.5 times as fast as memory 355 technology. 357 We should also note that even though IPng addresses are designed with 358 aggregation in mind switching to IPng will not solve the routing 359 table size problem unless the addresses are assigned rigorously to 360 maximize the affect of such aggregation. This efficient advertising 361 of routes can be maintained since IPng includes address 362 autoconfiguration mechanisms to allow easy renumbering if a customer 363 decides to switch providers. Customers who receive service from more 364 than one provider may limit the ultimate efficiency of any route 365 aggregation. [Rekhter94] 367 5.3 Address Assignment Policy Recommendations 369 The IESG Chair charged the IPng Area to consider recommending more 370 stringent assignment policies, reclaiming some addresses already 371 assigned, or making a serious effort to renumber significant portions 372 of the Internet. [Gross94] 374 The IPng Area Directors endorse the current address assignment 375 policies in view of the ALE projections. We do not feel that anyone 376 should take specific efforts to reclaim underutilized addresses 377 already assigned or to renumber forcefully major portions of the 378 Internet. We do however feel that we should all encourage network 379 service providers to assist new customers in renumbering their 380 networks to conform to the provider's CIDR assignments. 382 The ALE Working Group recommends that we consider assigning CIDR-type 383 address blocks out of the unassigned Class A address space. The IPng 384 Area Directors concur with this recommendation. 386 6. IPng Technical Requirements 388 The IESG provided an outline in RFC 1380 [Gross92] of the type of 389 criteria we should use to determine the suitability of an IPng 390 proposal. The IETF further refined this understanding of the 391 appropriate criteria with the recommendations of a Selection Criteria 392 BOF held during the November 1992 IETF meeting in Washington D.C. 393 [Almqu92] We felt we needed to get additional input for determining 394 the requirements and issued a call for white papers. [Bradner93] 395 This call, issued as RFC 1550, intended to reach both inside and 396 outside the traditional IETF constituency to get the broadest 397 possible understanding of the requirements for a data networking 398 protocol with the broadest possible application. 400 We received twenty one white papers in response to the RFC 1550 401 solicitation. ( Appendix E) We received responses from the 402 industries that many feel will be the major providers of data 403 networking services in the future; the cable TV industry [Vecchi94], 404 the cellular industry [Taylor94], and the electric power industry 405 [Skelton94]. In addition, we received papers that dealt with 406 military applications [Adam94, Syming94, Green94], ATM [Brazd94], 407 mobility [Simpson94], accounting [Brown94], routing [Estrin94a, 408 Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94, 409 Flei94], large corporate networking [Britt94, Fleisch94], transition 410 [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host 411 implementations [Bound94], as well as a number of other issues. 412 [Bello94a, Clark94, Ghisel94] 414 These white papers, a Next Generation Requirements (ngreq) BOF 415 (chaired by Jon Crowcroft and Frank Kastenholz) held during the March 416 1994 Seattle IETF meeting, discussions within the IPng Area 417 Directorate and considerable discussion on the big-internet mailing 418 list were all used by Frank Kastenholz and Craig Partridge in 419 revising their earlier criteria draft [Kasten92] to produce 420 "Technical Criteria for Choosing IP The Next Generation (IPng)." 421 [Kasten94] This document is the "clear and concise set of technical 422 requirements and decision criteria for IPng" called for in the charge 423 from the IESG Chair. We used this document as the basic guideline 424 while evaluating the IPng proposals. 426 6.1 The IPng Technical Criteria document 428 The criteria described in this document include: (from Kasten94 ) 430 * complete specification - The proposal must completely describe the 431 proposed protocol. We must select an IPng by referencing specific 432 documents, not to future work. 433 * architectural simplicity - The IP-layer protocol should be as 434 simple as possible with functions located elsewhere that are more 435 appropriately performed at protocol layers other than the IP layer. 436 * scale - The IPng Protocol must allow identifying and addressing at 437 least 10**9 leaf-networks (and preferably much more) 438 * topological flexibility - The routing architecture and protocols 439 ofIPng must allow for many different network topologies. They must 440 not assume that the network's physical structure is a tree. 441 * performance - A state of the art, commercial grade router must be 442 able to process and forward IPng traffic at speeds capable of fully 443 utilizing common, commercially available, high-speed media at the 444 time. 445 * robust service - The network service and its associated routing and 446 control protocols must be robust. 447 * transition - The protocol must have a straightforward transition 448 plan from IPv4. 449 * media independence - The protocol must work across an internetwork 450 of many different LAN, MAN, and WAN media, with individual link 451 speeds ranging from a ones-of-bits per second to hundreds of 452 gigabits per second. 453 * datagram service - The protocol must support an unreliable datagram 454 delivery service. 455 * configuration ease - The protocol must permit easy and largely 456 distributed configuration and operation. Automatic configuration of 457 hosts and routers is required. 458 * security - IPng must provide a secure network layer. 459 * unique names - IPng must assign unique names to all IP-Layer 460 objects in the global, ubiquitous, Internet. These names may or 461 may not have any location, topology, or routing significance. 462 * access to standards - The protocols that define IPng and its 463 associated protocols should be as freely available and 464 redistributable as the IPv4 and related RFCs. There must be no 465 specification-related licensing fees for implementing or selling 466 IPng software. 467 * multicast support - The protocol must support both unicast and 468 multicast packet transmission. Dynamic and automatic routing of 469 multicasts is also required. 470 * extensibility - The protocol must be extensible; it must be able 471 to evolve to meet the future service needs of the Internet. This 472 evolution must be achievable without requiring network-wide 473 software upgrades. 475 * service classes - The protocol must allow network devices to 476 associate packets with particular service classes and provide them 477 with the services specified by those classes. 478 * mobility - The protocol must support mobile hosts, networks and 479 internetworks. 480 * control protocol - The protocol must include elementary support for 481 testing and debugging networks. (e.g. ping and traceroute) 482 * tunneling support - IPng must allow users to build private 483 internetworks on top of the basic Internet Infrastructure. Both 484 private IP-based internetworks and private non-IP-based (e.g., CLNP 485 or AppleTalk) internetworks must be supported. 487 7. IPng Proposals 489 By the time that the IPng Area was formed, the IETF had already aimed 490 a considerable amount of IETF effort at solving the addressing and 491 routing problems of the Internet. Several proposals had been made 492 and some of these reached the level of having a working group 493 chartered. A number of these groups subsequently merged forming 494 groups with a larger consensus. These efforts represented different 495 views on the issues which confront us and sought to optimize 496 different aspects of the possible solutions. 498 By February 1992 the Internet community developed four separate 499 proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps" 500 [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b]. By 501 December 1992 three more proposals followed; "The P Internet 502 Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP) 503 [Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego 504 IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger 505 Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP 506 Address Encapsulation" (IPAE) [Hinden92b]. 508 By November 1993, IPAE merged with SIP while still maintaining the 509 name SIP. This group then merged with PIP and the resulting working 510 group called themselves "Simple Internet Protocol Plus" (SIPP). At 511 the same time the TP/IX Working Group changed its name to "Common 512 Architecture for the Internet" (CATNIP). 514 None of these proposals were wrong nor were others right. All of the 515 proposals would work in some ways providing a path to overcome the 516 obstacles we face as the Internet expands. The task of the IPng Area 517 was to ensure that the IETF understand the offered proposals, learn 518 from the proposals and provide a recommendation on what path best 519 resolves the basic issues while providing the best foundation upon 520 which to build for the future. 522 The IPng Area evaluated three IPng proposals as they were described 523 in their RFC 1550 white papers: CATNIP [McGovern94] , SIPP 524 [Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much 525 of a research project for consideration as an IPng candidate. Since 526 Nimrod represents one possible future Internet routing strategy we 527 solicited a paper describing any requirements Nimrod would put on an 528 IPng to add to the requirements process. [Chiappa94] 530 7.1 CATNIP 532 "Common Architecture for the Internet (CATNIP) was conceived as a 533 convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP 534 design provides for any of the transport layer protocols in use, for 535 example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the 536 network layer protocol formats: CLNP, IP (version 4), IPX, and 537 CATNIP. With some attention paid to details, it is possible for a 538 transport layer protocol (such as TCP) to operate properly with one 539 end system using one network layer (e.g. IP version 4) and the other 540 using some other network protocol, such as CLNP." [McGovern94] 542 "The objective is to provide common ground between the Internet, OSI, 543 and the Novell protocols, as well as to advance the Internet 544 technology to the scale and performance of the next generation of 545 internetwork technology." 547 "CATNIP supports OSI Network Service Access Point (NSAP) format 548 addresses. It also uses cache handles to provide both rapid 549 identification of the next hop in high performance routing as well as 550 abbreviation of the network header by permitting the addresses to be 551 omitted when a valid cache handle is available. The fixed part of the 552 network layer header carries the cache handles." [Sukonnik94] 554 7.2 SIPP 556 "Simple Internet Protocol Plus (SIPP) is a new version of IP which is 557 designed to be an evolutionary step from IPv4. It is a natural 558 increment to IPv4. It was not a design goal to take a radical step 559 away from IPv4. Functions which work in IPv4 were kept in SIPP. 560 Functions which didn't work were removed. It can be installed as a 561 normal software upgrade in internet devices and is interoperable with 562 the current IPv4. Its deployment strategy was designed to not have 563 any 'flag' days. SIPP is designed to run well on high performance 564 networks (e.g. ATM) and at the same time is still efficient for low 565 bandwidth networks (e.g. wireless). In addition, it provides a 566 platform for new internet functionality that will be required in the 567 near future." [Hinden94b] 568 "SIPP increases the IP address size from 32 bits to 64 bits, to 569 support more levels of addressing hierarchy and a much greater number 570 of addressable nodes. SIPP addressing can be further extended, in 571 units of 64 bits, by a facility equivalent to IPv4's Loose Source and 572 Record Route option, in combination with a new address type called 573 'cluster addresses' which identify topological regions rather than 574 individual nodes." 576 "SIPP changes in the way IP header options are encoded allows for 577 more efficient forwarding, less stringent limits on the length of 578 options, and greater flexibility for introducing new options in the 579 future. A new capability is added to enable the labeling of packets 580 belonging to particular traffic 'flows' for which the sender requests 581 special handling, such as non-default quality of service or 'real- 582 time' service." [Hinden94a] 584 7.3 TUBA 586 "The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to 587 minimize the risk associated with migration to a new IP address 588 space. In addition, this proposal is motivated by the requirement to 589 allow the Internet to scale, which implies use of Internet 590 applications in a very large ubiquitous worldwide Internet. It is 591 therefore proposed that existing Internet transport and application 592 protocols continue to operate unchanged, except for the replacement 593 of 32-bit IP addresses with larger addresses. TUBA does not mean 594 having to move over to OSI completely. It would mean only replacing 595 IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would 596 run on top of CLNP." [Callon92c] 598 "The TUBA effort will expand the ability to route Internet packets by 599 using addresses which support more hierarchy than the current 600 Internet Protocol (IP) address space. TUBA specifies the continued 601 use of Internet transport protocols, in particular TCP and UDP, but 602 specifies their encapsulation in ISO 8473 (CLNP) packets. This will 603 allow the continued use of Internet application protocols such as 604 FTP, SMTP, TELNET, etc. TUBA seeks to upgrade the current system by 605 a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the 606 corresponding large Network Service Access Point (NSAP) address 607 space." [Knopper94] 609 "The TUBA proposal makes use of a simple long-term migration proposal 610 based on a gradual update of Internet Hosts (to run Internet 611 applications over CLNP) and DNS servers (to return larger addresses). 612 This proposal requires routers to be updated to support forwarding of 613 CLNP (in addition to IP). However, this proposal does not require 614 encapsulation nor translation of packets nor address mapping. IP 615 addresses and NSAP addresses may be assigned and used independently 616 during the migration period. Routing and forwarding of IP and CLNP 617 packets may be done independently." ([Callon92c] 619 8. IPng Proposal Reviews 621 The IPng Directorate discussed and reviewed the candidate proposals 622 during its biweekly teleconferences and through its mailing list. In 623 addition, members of the Big-Internet mailing list discussed many of 624 the aspects of the proposals, particularly when the Area Directors 625 posted several specific questions to stimulate discussion. [Big] 627 The directorate members were requested to each evaluate the 628 proposals.in preparation for a two day retreat held near Chicago on 629 May 19th and 20th 1994. The retreat opened with a roundtable airing 630 of the views of each of the participants, including the Area 631 Directors, the Directorate and a number of guests invited by the 632 working group chairs for each for the proposals. [Knopper94b] We 633 will publish these reviews as well as a more detailed compendium 634 review of each of the proposals as companion memos. 636 The following table summarizes each of the three proposals reviewed 637 against the requirements in the IPng Criteria document. They do not 638 necessarily reflect the views of the Area Directors. "Yes" means the 639 reviewers mainly felt the proposal met the specific criterion. "No" 640 means the reviewers mainly felt the proposal did not meet the 641 criterion. "Mixed" means that the reviewers had mixed reviews with 642 none dominating. "Unknown" means that the reviewers mainly felt the 643 documentation did not address the criterion. 645 CATNIP SIPP TUBA 646 ------ ---- ---- 647 complete spec no yes mostly 648 simplicity no no no 649 scale yes yes yes 650 topological flex yes yes yes 651 performance mixed mixed mixed 652 robust service mixed mixed yes 653 transition mixed no mixed 654 media indepdnt yes yes yes 655 datagram yes yes yes 656 config. ease unknown mixed mixed 657 security unknown mixed mixed 658 unique names mixed mixed mixed 659 access to stds yes yes mixed 660 multicast unknown yes mixed 661 extensibility unknown mixed mixed 662 service classes unknown yes mixed 663 mobility unknown mixed mixed 664 control proto unknown yes mixed 665 tunneling unknown yes mixed 667 8.1 CATNIP Reviews 669 All the reviewers felt that CATNIP is not completely specified. 670 However, many of the ideas in CATNIP are innovative and a number of 671 reviewers felt CATNIP shows the best vision of all of the proposals. 672 The use of Network Service Attachment Point Addresses (NSAPs) is well 673 thought out and the routing handles are innovative. 675 While the goal of uniting three major protocol families, IP, ISO-CLNP 676 and Novell IPX is laudable our consensus was that the developers had 677 not developed detailed enough plans to support realizing that goal. 678 The plans they do describe suffer from the complexity of trying to be 679 the union of a number of existing network protocols. Some reviewers 680 felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into 681 NSAPs and, as such, does not deal with the routing problems of the 682 current and future Internet. 684 Additionally the reviewers felt that CATNIP has poor support for 685 multicasting and mobility and does not specifically deal with such 686 important topics as security and autoconfiguration. 688 8.2 SIPP Reviews 690 Most of the reviewers, including those predisposed to other 691 proposals, felt as one reviewer put it, that SIPP is an 692 "aesthetically beautiful protocol well tailored to compactly satisfy 693 today's known network requirements." The SIPP Working Group has been 694 the most dynamic over the last year, producing a myriad of 695 documentation detailing almost all of the aspects necessary to 696 produce a complete protocol description. 698 The biggest problem the reviewers had with SIPP was with IPAE, SIPP's 699 transition plan. The overwhelming feeling was that IPAE is fatally 700 flawed and could not be made to work reliably in an operational 701 Internet. 703 There was significant disagreement about the adequacy of the SIPP 64 704 bit address size. Although you can enumerate 10**15 end nodes in 64 705 bits people have different views about how much inefficiency real- 706 world routing plans introduce. [Huitema94] The majority felt that 64 707 bit addresses do not provide adequate space for the hierarchy 708 required to meet the needs of the future Internet. In addition since 709 no one has any experience with extended addressing and routing 710 concepts of the type proposed in SIPP, the reviewers generally felt 711 quite uncomfortable with this methodology. The reviewers also felt 712 that the design introduces some significant security issues. 714 A number of reviewers felt that SIPP did not address the routing 715 issue in any useful way. In particular, there has been no serious 716 attempt made at developing ways to abstract topology information or 717 to aggregate information about areas of the network. 719 Finally, most of the reviewers questioned the level of complexity in 720 the SIPP autoconfiguration plans as well as in SIPP in general, other 721 than the header itself. 723 8.3 TUBA Reviews 725 The reviewers generally felt that the most important thing that TUBA 726 has offers is that it is based on CLNP and there is significant 727 deployment of CLNP-capable routers throughout the Internet. There 728 was considerably less agreement that there was significant deployment 729 of CLNP-capable hosts or actual networks running CLNP. Another 730 strong positive for TUBA is the potential for convergence of ISO and 731 IETF networking standards. A number of reviewers pointed out that, 732 if TUBA were to be based on a changed CLNP then the advantage of an 733 existing deployed infrastructure would be lost and that the 734 convergence potential would be reduced. 736 A number of aspects of CLNP were felt to be a problem by the 737 reviewers including the inefficiencies introduced by the lack of any 738 particular word alignment of the header fields, CLNP source route, 739 the lack of a flow ID field, the lack of a protocol ID field, and the 740 use of CLNP error messages in TUBA. The CLNP packet format or 741 procedures would have to be modified to resolve at least some of 742 these issues. 744 There seems to be a profound disagreement within the TUBA community 745 over the question of the ability of the IETF to modify the CLNP 746 standards. In our presentation in Houston we said that we felt that 747 "clone and run" was a legitimate process. This is also what the IAB 748 proposed in "IP version 7". [IAB92] The TUBA community has not 749 reached consensus that this view is reasonable. While many, 750 including a number of the CLNP document authors, are adamant that 751 this is not an issue and the IETF can make modifications to the base 752 standards, many others are just as adamant that the standards can 753 only be changed through the ISO standards process. Since the 754 overwhelming feeling within the IETF is that the IETF must 'own' the 755 standards on which it is basing its future, this disagreement within 756 the TUBA community was disquieting. 758 For a number of reasons, unfortunately including prejudice in a few 759 cases, the reviews of the TUBA proposals were much more mixed than 760 for SIPP or CATNIP. Clearly TUBA meets the requirements for the 761 ability to scale to large numbers of hosts, supports flexible 762 topologies, is media independent and is a datagram protocol. To the 763 reviewers, it was less clear that TUBA met the other IPng 764 requirements and these views varied widely. 766 There was also disagreement over the advisability of using NSAPs for 767 routing given the wide variety of NSAP allocation plans. The 768 Internet would have to restrict the use of NSAPs to those which are 769 allocated with the actual underlying network topology in mind if the 770 required degree of aggregation of routing information is to be 771 achieved. 773 8.4 Summary of Proposal Reviews 775 To summarize, significant problems were seen in all three of the 776 proposals. The feeling was that, to one degree or another, both SIPP 777 and TUBA would work in the Internet context but each exhibited its 778 own problems. Some of these problems would have to be rectified 779 before either one would be ready to replace IPv4, much less be the 780 vehicle to carry the Internet into the future. Other problems could 781 be addressed over time. CATNIP was felt to be too incomplete to be 782 considered. 784 9. A Revised Proposal 786 As mentioned above, there was considerable discussion of the 787 strengths and weaknesses of the various IPng proposals during the 788 IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b] After 789 this retreat Steve Deering and Paul Francis, two of the co-chairs of 790 the SIPP Working Group, sent a message to the sipp mailing list 791 detailing the discussions at the retreat and proposing some changes 792 in SIPP. [Deering94a] 794 The message noted "The recurring (and unsurprising) concerns about 795 SIPP were: 797 (1) complexity/manageability/feasibility of IPAE, and 799 (2) adequacy/correctness/limitations of SIPP's addressing and routing 800 model, especially the use of loose source routing to accomplish 801 'extended addressing'". 803 They "proposed to address these concerns by changing SIPP as follows: 805 * Change address size from 8 bytes to 16 bytes (fixed-length). 807 * Specify optional use of serverless autoconfiguration of the 16-byte 808 address by using IEEE 802 address as the low-order ("node ID") 809 part. 811 * For higher-layer protocols that use internet-layer addresses as 812 part of connection identifiers (e.g., TCP), require that they use 813 the entire 16-byte addresses. 815 * Do *not* use Route Header for extended addressing." 817 After considerable discussion on the sipp and big-internet mailing 818 lists about these proposed changes, the SIPP working group published 819 a revised version of SIPP [Deering94b], a new addressing architecture 820 [Francis94], and a simplified transition mechanism [Gillig94a]. 821 These were submitted to the IPng Directorate for their consideration. 823 This proposal represents a synthesis of multiple IETF efforts with 824 much of the basic protocol coming from the SIPP effort, the 825 autoconfiguration and transition portions influenced by TUBA, the 826 addressing structure is based on the CIDR work and the routing header 827 evolving out of the SDRP deliberations. 829 10. Assumptions 831 10.1 Criteria Document and Timing of Recommendation 833 In making the following recommendations we are making two assumptions 834 of community consensus; that the IPng criteria document represents 835 the reasonable set of requirements for an IPng, and that a specific 836 recommendation should be made now and that from this point on the 837 IETF should proceed with a single IPng effort. 839 As described above, the IPng Technical Criteria document [Kasten94] 840 was developed in a open manner and was the topic of extensive 841 discussions on a number of mailing lists. We believe that there is a 842 strong consensus that this document accurately reflects the 843 community's set of technical requirements which an IPng should be 844 able to meet. 846 A prime topic of discussion on the big-internet mailing list this 847 spring as well as during the open IPng directorate meeting in 848 Seattle, was the need to make a specific IPng recommendation at this 849 time. Some people felt that additional research would help resolve 850 some of the issues that are currently unresolved. While others 851 argued that selecting a single protocol to work on would clarify the 852 picture for the community, focus the resources of the IETF on 853 finalizing its details, and, since the argument that there were open 854 research items could be made at any point in history, there might 855 never be a 'right' time. 857 Our reading of the community is that there is a consensus that a 858 specific recommendation should be made now. This is consistent with 859 the views expressed during the ipdecide BOF in Amsterdam [Gross94] 860 and in some of the RFC 1550 white papers [Carpen94a]. 862 There is no particular reason to think that the basic recommendation 863 would be significantly different if we waited for another six months 864 or a year. Clearly some details which are currently unresolved could 865 be filled in if the recommendation were to be delayed, but the 866 current fragmentation of the IETF's energies limits the efficiency of 867 this type of detail resolution. Concentrating the resources of the 868 IETF behind a single effort seems to us to be a more efficient way to 869 proceed. 871 10.2 Address Length 873 One of the most hotly discussed aspects of the IPng design 874 possibilities was address size and format. During the IPng process 875 four distinct views were expressed about these issues: 877 1. The view that 8 bytes of address are enough to meet the current 878 and future needs of the Internet (squaring the size of the IP 879 address space). More would waste bandwidth, promote inefficient 880 assignment, and cause problems in some networks (such as mobiles 881 and other low speed links). 883 2. The view that 16 bytes is about right. That length supports easy 884 auto-configuration as well as organizations with complex internal 885 routing topologies in conjunction with the global routing topology 886 now and well into the future. 888 3. The view that 20 byte OSI NSAPs should be used in the interests of 889 global harmonization. 891 4. The view that variable length addresses which might be smaller or 892 larger than 16 bytes should be used to embrace all the above 893 options and more, so that the size of the address could be 894 adjusted to the demands of the particular environment, and to 895 ensure the ability to meet any future networking requirements. 897 Good technical and engineering arguments were made for and against 898 all of these views. Unanimity was not achieved, but we feel that a 899 clear majority view emerged that the use of 16 byte fixed length 900 addresses was the best compromise between efficiency, functionality, 901 flexibility, and global applicability. [Mankin94] 903 11. IPng Recommendation 905 After a great deal of discussion in many forums and with the 906 consensus of the IPng Directorate, we recommend that the protocol 907 described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit 908 ver)" [Deering94b] be adopted as the basis for IPng, the next 909 generation of the Internet Protocol. We also recommend that the 910 other documents listed in Appendix C be adopted as the basis of 911 specific features of this protocol. 913 This proposal resolves most of the perceived problems, particularly 914 in the areas of addressing, routing, transition and address 915 autoconfiguration. It includes the broad base of the SIPP proposal 916 effort, flexible address autoconfiguration features, and a merged 917 transition strategy. We believe that it meets the requirements 918 outlined in the IPng Criteria document and provides the framework to 919 fully meet the needs of the greater Internet community for the 920 foreseeable future. 922 11.1 IPng Criteria Document and IPng 924 A detailed review of how IPng meets the requirements set down in the 925 IPng Criteria document [Kasten94] will soon be published. Following 926 is our feelings about the extent to which IPng is responsive to the 927 criteria. 929 * complete specification - the base specifications for IPng are 930 complete but transition and address autoconfiguration do remain to 931 be finalized 932 * architectural simplicity - the protocol is simple, easy to explain 933 and uses well established paradigms 934 * scale - an address size of 128 bits easily meets the need to 935 address 10**9 networks even in the face of the inherent 936 inefficiency of address allocation for efficient routing 937 * topological flexibility - the IPng design places no constraints on 938 network topology except for the limit of 255 hops 939 * performance - the simplicity of processing, the alignment of the 940 fields in the headers, and the elimination of the header checksum 941 will allow for high performance handling of IPng data streams 942 * robust service - IPng includes no inhibitors to robust service and 943 the addition of packet-level authentication allows the securing of 944 control and routing protocols without having to have separate 945 procedures 946 * transition - the IPng transition plan is simple and realistically 947 covers the transition methods that will be present in the 948 marketplace 949 * media independence - IPng retains IPv4's media independence, it may 950 be possible to make use of IPng's Flow Label in some connection- 951 oriented media such as ATM 952 * datagram service - IPng preserves datagram service as its basic 953 operational mode, it is possible that the use of path MTU discovery 954 will complicate the use of datagrams in some cases 955 * configuration ease - IPng will have easy and flexible address 956 autoconfiguration which will support a wide variety of environments 957 from nodes on an isolated network to nodes deep in a complex 958 internet 959 * security - IPng includes specific mechanisms for authentication and 960 encryption at the internetwork layer; the security features do rely 961 on the presence of a yet to be defined key management system 962 * unique names - IPng addresses may be used as globally unique names 963 although they do have topological significance 964 * access to standards - all of the IPng standards will be published 965 as RFCs with unlimited distribution 966 * multicast support - IPng specifically includes multicast support 967 * extensibility - the use of extension headers and an expandable 968 header option feature will allow the introduction of new features 969 into IPng when needed in a way that minimizes the disruption of the 970 existing network 971 * service classes - the IPng header includes a Flow Label which may 972 be used to differentiate requested service classes 973 * mobility - the proposed IPv4 mobility functions will work with IPng 974 * control protocol - IPng includes the familiar IPv4 control protocol 975 features 976 * tunneling support - encapsulation of IPng or other protocols within 977 IPng is a basic capability described in the IPng specifications 979 11.2 IPv6 981 The IANA has assigned version number 6 to IPng. The protocol itself 982 will be called IPv6. 984 The remainder of this memo is used to describe IPv6 and its features. 985 This description is an overview snapshot. The standards documents 986 themselves should be referenced for definitive specifications. We 987 also make a number of specific recommendations concerning the details 988 of the proposed protocol, the procedures required to complete the 989 definition of the protocol, and the IETF working groups we feel are 990 necessary to accomplish the task. 992 12. IPv6 Overview 994 IPv6 is a new version of the Internet Protocol, it has been designed 995 as an evolutionary, rather than revolutionary, step from IPv4. 996 Functions which are generally seen as working in IPv4 were kept in 997 IPv6. Functions which don't work or are infrequently used were 998 removed or made optional. A few new features were added where the 999 functionality was felt to be necessary. 1001 The important features of IPv6 include: [Hinden94c] 1003 * expanded addressing and routing capabilities - The IP address size 1004 is increased from 32 bits to 128 bits providing support for a much 1005 greater number of addressable nodes, more levels of addressing 1006 hierarchy, and simpler auto-configuration of addresses. 1008 The scaleability of multicast routing is improved by adding a 1009 "scope" field to multicast addresses. 1011 A new type of address, called a "cluster address" is defined to 1012 identify topological regions rather than individual nodes. The use 1013 of cluster addresses in conjunction with the IPv6 source route 1014 capability allows nodes additional control over the path their 1015 traffic takes. 1017 * simplified header format - Some IPv4 header fields have been 1018 dropped or made optional to reduce the common-case processing cost 1019 of packet handling and to keep the bandwidth overhead of the IPv6 1020 header as low as possible in spite of the increased size of the 1021 addresses. Even though the IPv6 addressses are four time longer 1022 than the IPv4 addresses, the IPv6 header is only twice the size of 1023 the IPv4 header. 1025 * support for extension headers and options - IPv6 options are placed 1026 in separate headers that are located in the packet between the IPv6 1027 header and the transport-layer header. Since most IPv6 option 1028 headers are not examined or processed by any router along a 1029 packet's delivery path until it arrives at its final destination, 1030 this organization facilitates a major improvement in router 1031 performance for packets containing options. Another improvement is 1032 that unlike IPv4, IPv6 options can be of arbitrary length and not 1033 limited to 40 bytes. This feature plus the manner in which they 1034 are processed, permits IPv6 options to be used for functions which 1035 were not practical in IPv4. 1037 A key extensibility feature of IPv6 is the ability to encode, 1038 within an option, the action which a router or host should perform 1039 if the option is unknown. This permits the incremental deployment 1040 of additional functionality into an operational network with a 1041 minimal danger of disruption. 1043 * support for authentication and privacy - IPv6 includes the 1044 definition of an extension which provides support for 1045 authentication and data integrity. This extension is included as a 1046 basic element of IPv6 and support for it will be required in all 1047 implementations. 1049 IPv6 also includes the definition of an extension to support 1050 confidentiality by means of encryption. Support for this extension 1051 will be strongly encouraged in all implementations. 1053 * support for autoconfiguration - IPv6 supports multiple forms of 1054 autoconfiguration, from "plug and play" configuration of node 1055 addresses on an isolated network to the full-featured facilities 1056 offered by DHCP. 1058 * support for source routes - IPv6 includes an extended function 1059 source routing header designed to support the Source Demand Routing 1060 Protocol (SDRP). The purpose of SDRP is to support source-initiated 1061 selection of routes to complement the route selection provided by 1062 existing routing protocols for both inter-domain and intra-domain 1063 routes. [Estrin94b] 1065 * simple and flexible transition from IPv4 - The IPv6 transition plan 1066 is aimed at meeting four basic requirements: [Gillig94a] 1068 - Incremental upgrade. Existing installed IPv4 hosts and routers 1069 may be upgraded to IPv6 at any time without being dependent on 1070 any other hosts or routers being upgraded. 1071 - Incremental deployment. New IPv6 hosts and routers can be 1072 installed at any time without any prerequisites. 1073 - Easy Addressing. When existing installed IPv4 hosts or routers 1074 are upgraded to IPv6, they may continue to use their existing 1075 address. They do not need to be assigned new addresses. 1076 - Low start-up costs. Little or no preparation work is needed in 1077 order to upgrade existing IPv4 systems to IPv6, or to deploy new 1078 IPv6 systems. 1080 * quality of service capabilities - A new capability is added to 1081 enable the labeling of packets belonging to particular traffic 1082 "flows" for which the sender has requested special handling, such 1083 as non-default quality of service or "real-time" service. 1085 12.1 IPv6 Header Format 1087 The IPv6 header, although longer than the IPv4 header, is 1088 considerably simplified. A number of functions that were in the IPv4 1089 header have been relocated in extension headers or dropped. 1090 [Deering94b] 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 |Version| Flow Label | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Payload Length | Next Header | Hop Limit | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | | 1098 + + 1099 | | 1100 + Source Address + 1101 | | 1102 + + 1103 | | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | | 1106 + + 1107 | | 1108 + Destination Address + 1109 | | 1110 + + 1111 | | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 * Version - Internet Protocol version number. IPng has been assigned 1114 version number 6. (4-bit field) 1116 * Flow Label - This field may be used by a host to label those 1117 packets for which it is requesting special handling by routers 1118 within a network, such as non-default quality of service or "real- 1119 time" service. (28-bit field) 1121 * Payload Length - Length of the remainder of the packet following 1122 the IPv6 header, in octets. To permit payloads of greater than 64K 1123 bytes, if the value in this field is 0 the actual packet length 1124 will be found in an Hop-by-Hop option. (16-bit unsigned integer) 1126 * Next Header - Identifies the type of header immediately following 1127 the IPv6 header. The Next Header field uses the same values as the 1128 IPv4 Protocol field (8-bit selector field) 1130 * Hop Limit - Used to limit the impact of routing loops. The Hop 1131 Limit field is decremented by 1 by each node that forwards the 1132 packet. The packet is discarded if Hop Limit is decremented to 1133 zero. (8-bit unsigned integer) 1135 * Source Address - An address of the initial sender of the packet. 1136 (128 bit field) 1138 * Destination Address - An address of the intended recipient of the 1139 packet (possibly not the ultimate recipient, if an optional Routing 1140 Header is present). (128 bit field) 1142 12.2 Extension Headers 1144 In IPv6, optional internet-layer information is encoded in separate 1145 headers that may be placed between the IPv6 header and the 1146 transport-layer header in a packet. There are a small number of such 1147 extension headers, each identified by a distinct Next Header value. 1148 [From a number of the documents listed in Appendix C.] 1150 12.2.1 Hop-by-Hop Option Header 1152 The Hop-by-Hop Options header is used to carry optional 1153 information that must be examined by every node along a packet's 1154 delivery path. The Hop-by-Hop Options header is identified by a 1155 Next Header value of 0 in the IPv6 header, and has the following 1156 format: 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Next Header | Hdr Ext Len | | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1161 | | 1162 . . 1163 . Options . 1164 . . 1165 | | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 * Next Header - Identifies the type of header immediately 1169 following the Hop-by-Hop Options header. Uses the same values 1170 as the IPv4 Protocol field. (8-bit selector) 1172 * Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet 1173 units, not including the first 8 octets. (8-bit unsigned 1174 integer) 1176 * Options - Contains one or more TLV-encoded options. (Variable- 1177 length field, of length such that the complete Hop-by-Hop 1178 Options header is an integer multiple of 8 octets long.) 1180 12.2.2 IPv6 Header Options 1182 Two of the currently-defined extension headers -- the Hop-by-Hop 1183 Options header and the End-to-End Options header -- may carry a 1184 variable number of Type-Length-Value (TLV) encoded "options", of 1185 the following format: 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1188 | Option Type | Opt Data Len | Option Data 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1191 * Option Type - identifier of the type of option (8-bit field) 1193 * Opt Data Len - Length of the Option Data field of this option, 1194 in octets. (8-bit unsigned integer) 1196 * Option Data - Option-Type-specific data. (Variable-length field) 1198 The Option Type identifiers are internally encoded such that their 1199 highest-order two bits specify the action that must be taken if 1200 the processing IPv6 node does not recognize the Option Type: 1202 00 - skip over this option and continue processing the header 1203 01 - discard the packet 1204 10 - discard the packet and send an ICMP Unrecognized Type message 1205 to the packet's Source Address, pointing to the unrecognized 1206 Option Type 1207 11 - undefined. 1209 In the case of Hop-by-Hop options only, the third-highest-order 1210 bit of the Option Type specifies whether or not the Option Data of 1211 this option shall be included in the integrity assurance 1212 computation performed when an Authentication header is present. 1213 Option data that changes en route must be excluded from that 1214 computation. 1216 12.2.3 Routing Header 1218 The Routing header is used by an IPv6 source to list one or more 1219 intermediate nodes (or topological clusters) to be "visited" on 1220 the way to a packet's destination. This particular form of the 1221 Routing Header is designed to support SDRP. [Estrin94b] 1223 0 1 2 3 1224 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 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Next Header |Routing Type=1 |M|F| Reserved | SrcRouteLen | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | NextHopPtr | Strict/Loose Bit Mask | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | | 1231 . . 1232 . Source Route . 1233 . . 1234 | | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 * Next Header - Identifies the type of header immediately 1238 following the Fragement header. Uses the same values as the 1239 IPv4 Protocol field. (8-bit selector) 1241 * Routing Type - Indicates the type of routing supported by this 1242 header. Value must be 1. 1244 * MRE flag - Must Report Errors. If this bit is set to 1, and a 1245 router can not further forward a packet (with an incompletely 1246 traversed source route), as specified in the Source Route, the 1247 router must generate an ICMP error message. If this bit is set 1248 to 0, and a router can not further forward a packet (with an 1249 incompletely traversed source route), as specified in the Source 1250 Route, the router should not generate an ICMP error message. 1252 * F flag - Failure of Source Route Behavior. If this bit it set 1253 to 1, it indicates that if a router can not further forward a 1254 packet (with an incompletely traversed source route), as 1255 specified in the Source Route, the router must set the value of 1256 the Next Hop Pointer field to the value of the Source Route 1257 Length field, so that the subsequent forwarding will be based 1258 solely on the destination address. If this bit is set to 0, it 1259 indicates that if a router can not further forward a packet 1260 (with an incompletely traversed source route), as specified in 1261 the Source Route, the router must discard the packet. 1263 * Reserved - Initialized to zero for transmission; ignored on 1264 reception. 1266 * SrcRouteLen - Source Route Length - Number of source route 1267 elements/hops in the SDRP Routing header. Length of SDRP 1268 routing header can be calculated from this value (length = 1269 SrcRouteLen * 16 + 8) This field may not exceed a value of 24. 1270 (8 bit unsigned integer) 1272 * NextHopPtr - Next Hop Pointer- Index of next element/hop to be 1273 processed; initialized to 0 to point to first element/hop in the 1274 source route. When Next Hop Pointer is equal to Source Route 1275 Length then the Source Route is completed. (8 bit unsigned 1276 integer) 1278 * Strict/Loose Bit Mask - The Strict/Loose Bit Mask is used when 1279 making a forwarding decision. If the value of the Next Hop 1280 Pointer field is N, and the N-th bit in the Strict/Loose Bit 1281 Mask field is set to 1, it indicates that the next hop is a 1282 Strict Source Route Hop. If this bit is set to 0, it indicates 1283 that the next hop is a Loose Source Route Hop. (24 bit 1284 bitpattern) 1286 * Source Route - A list of IPv6 addresses indicating the path that 1287 this packet should follow. A Source Route can contain an 1288 arbitrary intermix of unicast and cluster addresses. (integral 1289 multiple of 128 bits) 1291 12.2.4 Fragment Header 1293 The Fragment header is used by an IPv6 source to send payloads 1294 larger than would fit in the path MTU to their destinations. 1295 (Note: unlike IPv4, fragmentation in IPv6 is performed only by 1296 source nodes, not by routers along a packet's delivery path) The 1297 Fragment header is identified by a Next Header value of 44 in the 1298 immediately preceding header, and has the following format: 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Next Header | Reserved | Fragment Offset |Res|M| 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Identification | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 * Next Header - Identifies the type of header immediately 1307 following the Fragment header. Uses the same values as the IPv4 1308 Protocol field. (8 bit selector) 1310 * Reserved, Res - Initialized to zero for transmission; ignored on 1311 reception. 1313 * Fragment Offset - The offset, in 8-octet units, of the following 1314 payload, relative to the start of the original, unfragmented 1315 payload. (13-bit unsigned integer) 1317 * M flag - 1 = more fragments; 0 = last fragment. 1319 * Identification - A value assigned to the original payload that 1320 is different than that of any other fragmented payload sent 1321 recently with the same IPv6 Source Address, IPv6 Destination 1322 Address, and Fragment Next Header value. (If a Routing header 1323 is present, the IPv6 Destination Address is that of the final 1324 destination.) The Identification value is carried in the 1325 Fragment header of all of the original payload's fragments, and 1326 is used by the destination to identify all fragments belonging 1327 to the same original payload. (32 bit field) 1329 12.2.5 Authentication Header 1331 The Authentication header is used to provide authentication and 1332 integrity assurance for IPv6 packets. Non-repudiation may be 1333 provided by an authentication algorithm used with the 1334 Authentication header, but it is not provided with all 1335 authentication algorithms that might be used with this header. 1336 The Authentication header is identified by a Next Header value of 1337 51 in the immediately preceding header, and has the following 1338 format: 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Next Header | Auth Data Len | Reserved | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Security Association ID | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | | 1346 . . 1347 . Authentication Data . 1348 . . 1349 | | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 * Next Header - Identifies the type of header immediately 1353 following the Authentication header. Uses the same values as 1354 the IPv4 Protocol field. (8-bit selector) 1356 * Auth Data Len - Length of the Authentication Data field in 8- 1357 octet units. (8-bit unsigned integer) 1359 * Reserved - Initialized to zero for transmission; ignored on 1360 reception. 1362 * Security Assoc. ID - When combined with the IPv6 Source Address, 1363 identifies to the receiver(s) the pre-established security 1364 association to which this packet belongs. (32 bit field) 1366 * Authentication Data - Algorithm-specific information required 1367 to authenticate the source of the packet and assure its 1368 integrity, as specified for the pre-established security 1369 association. (Variable-length field, an integer multiple of 8 1370 octets long.) 1372 12.2.6 Privacy Header 1374 The Privacy Header seeks to provide confidentiality and integrity 1375 by encrypting data to be protected and placing the encrypted data 1376 in the data portion of the Privacy Header. Either a transport- 1377 layer (e.g. UDP or TCP) frame may be encrypted or an entire IPv6 1378 datagram may be encrypted, depending on the user's security 1379 requirements. This encapsulating approach is necessary to provide 1380 confidentiality for the entire original datagram. If present, the 1381 Privacy Header is always the last non-encrypted field in a packet. 1383 The Privacy Header works between hosts, between a host and a 1384 security gateway, or between security gateways. This support for 1385 security gateways permits trustworthy networks to exist without 1386 the performance and monetary costs of security, while providing 1387 security for traffic transiting untrustworthy network segments. 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Security Association Identifier (SAID) | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | | 1393 . Initialization Vector . 1394 | | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Next Header* | Length* | Reserved* | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | | 1399 | Protected Data* +-+-+-+-+-+-+-+-+-+-+ 1400 | | trailer* | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 *encrypted 1404 * Security Association Identifier (SAID) - Identifies the security 1405 association for this datagram. If no security association has 1406 been established, the value of this field shall be 0x0000. A 1407 security association is normally one-way. An authenticated 1408 communications session between two hosts will normally have two 1409 SAIDs in use (one in each direction). The receiving host uses 1410 the combination of SAID value and originating address to 1411 distinguish the correct association. (32 bit value) 1413 * Initialization Vector - This field is optional and its value 1414 depends on the SAID in use. For example, the field may contain 1415 cryptographic synchronization data for a block oriented 1416 encryption algorithm. It may also be used to contain a 1417 cryptographic initialization vector. A Privacy Header 1418 implementation will normally use the SAID value to determine 1419 whether this field is present and, if it is, the field's size 1420 and use. (presence and length dependent on SAID) 1422 * Next Header - encrypted - Identifies the type of header 1423 immediately following the Privacy header. Uses the same values 1424 as the IPv4 Protocol field. (8 bit selector) 1426 * Reserved - encrypted - Ignored on reception. 1428 * Length - encrypted - Length of the Privacy Header in 8-octet 1429 units, not including the first 8 octets. (8-bit unsigned 1430 integer) 1432 * Protected Data - encrypted - This field may contain an entire 1433 encapsulated IPv6 datagram, including the IPv6 header, a 1434 sequence of zero or more IPv6 options, and a transport-layer 1435 payload, or it may just be a sequence of zero or more IPv6 1436 options followed by a transport-layer payload. (variable 1437 length) 1439 * trailer (Algorithm-dependent Trailer) - encrypted - A field 1440 present to support some algorithms which need to have padding 1441 (e.g. to a full cryptographic block size for block-oriented 1442 encryption algorithms) or for storage of authentication data for 1443 use with a encryption algorithm that provides confidentiality 1444 without authentication. It is present only when the algorithm 1445 in use requires such a field. (presence and length dependent on 1446 SAID) 1448 12.2.7 End-to-End Option Header 1450 The End-to-End Options header is used to carry optional 1451 information that needs to be examined only by a packet's 1452 destination node(s). The End-to-End Options header is identified 1453 by a Next Header value of TBD in the immediately preceding header, 1454 and has the same format as the Hop-by-Hop Option Header except for 1455 the ability to exclude an option from the authentication integrity 1456 assurance computation. 1458 13. IPng Working Group 1460 We recommend that a new IPng Working Group be formed to produce 1461 specifications for the core functionality of the IPv6 protocol suite. 1462 The working group will carry out the recommendations of the IPng Area 1463 Directors as outlined at the July 1994 IETF and in this memo. We 1464 recommend that this working group be chaired by Steve Deering of 1465 Xerox PARC and Ross Callon of Wellfleet. 1467 The primary task of the working group is to produce a set of 1468 documents that define the basic functions, interactions, assumptions, 1469 and packet formats for IPv6. We recommend that Robert Hinden of Sun 1470 Microsystems be the editor for these documents. The documents listed 1471 in Appendix C will be used by the working group to form the basis of 1472 the final document set. 1474 The work of the IPng Working Group includes: 1476 * complete the IPv6 overview document 1477 * complete the IPv6 detailed operational specification 1478 * complete the IPv6 Addressing Architecture specification 1479 * produce specifications for IPv6 encapsulations over various media 1480 * complete specifications for the support of packets larger than 64KB 1481 * complete specifications of the DNS enhancements required to support 1482 IPv6 1483 * complete specification of ICMP, IGMP and router discovery for 1484 support of IPv6. 1485 * complete specification of path MTU discovery for IPv6 1486 * complete specifications of IPv6 in IPv6 tunneling 1487 * complete the suggested address format and assignment plan 1488 * coordinate with the Address Autoconfiguration Working Group 1489 * coordinate with the NGTRANS and TACIT Working Groups 1490 * complete specifications of authentication and privacy support 1491 headers 1493 The working group should also consider a few selected enhancements 1494 including: 1496 * consider ways to compress the IPv6 header in the contexts of native 1497 IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6 1498 * consider specifying support for a larger minimum MTU 1500 14. IPng Reviewer 1502 Currently it is the task of the IPng Area Directors, the IPng 1503 Directorate and the chairs of the proposed ipng working group to 1504 coordinate the activities of the many parallel efforts currently 1505 directed towards different aspects of IPng. While this is possible 1506 and currently seems to be working well it can not be maintained over 1507 the long run because, among other reasons, the IPng Area will be 1508 dissolved eventually and its Directorate disbanded. It will also 1509 become much more difficult as IPng related activities start up in 1510 other IETF areas. 1512 We recommend that an IPng Reviewer be appointed to be specifically 1513 responsible for ensuring that a consistent view of IPv6 is maintained 1514 across the related working groups. We feel that this function is 1515 required due to the complex nature of the interactions between the 1516 parts of the IPng effort and due to the distribution of the IPng 1517 related work amongst a number of IETF areas. We recommend that Dave 1518 Clark of MIT be offered this appointment. 1520 This would be a long-term task involving the review of on-going 1521 activities. The aim is not for the IPng Reviewer to make 1522 architectural decisions since that is the work of the various working 1523 groups, the IAB, and the IETF as a whole.. The aim is to spot gaps 1524 or misunderstandings before they reach the point where functionality 1525 or interworkability is threatened. 1527 15. Address Autoconfiguration 1529 As data networks become more complex the need to be able to bypass at 1530 least some of the complexity and move towards "plug and play" becomes 1531 ever more acute. The user can not be expected to be able to 1532 understand the details of the network architecture or know how to 1533 configure the network software in their host. In the ideal case, a 1534 user should be able to unpack a new computer, plug it into the local 1535 network and "just" have it work without requiring the entering of any 1536 special information. Security concerns may restrict the ability to 1537 offer this level of transparent address autoconfiguration in some 1538 environments but the mechanisms must be in place to support whatever 1539 level of automation which the local environment feels comfortable 1540 with. 1542 The basic requirement of "plug and play" operation is that a host 1543 must be able to acquire an address dynamically, either when attaching 1544 to a network for the first time or when the host needs to be 1545 readdressed because the host moved or because the identity of the 1546 network has changed. There are many other functions required to 1547 support a full "plug and play" environment. [Berk94] Most of these 1548 must be addressed outside of the IPv6 Area but a focused effort to 1549 define a host address autoconfiguration protocol is part of the IPv6 1550 process. 1552 We recommend that a new Address Autoconfiguration Working Group 1553 (addrconf) be formed with Dave Katz of Cisco Systems and Sue Thomson 1554 of Bellcore as co-chairs. The purpose of this working group is to 1555 design and specify a protocol for allocating addresses dynamically to 1556 IPv6 hosts. The address configuration protocol must be suitable for 1557 a wide range of network topologies, from a simple isolated network to 1558 a sophisticated globally connected network. It should also allow for 1559 varying levels of administrative control, from completely automated 1560 operation to very tight oversight. 1562 The scope of this working group is to propose a host address 1563 autoconfiguration protocol which supports the full range of 1564 topological and administrative environments in which IPv6 will be 1565 used. It is the intention that, together with IPv6 system discovery, 1566 the address autoconfiguration protocol will provide the minimal 1567 bootstrapping information necessary to enable hosts to acquire 1568 further configuration information (such as that provided by DHCP in 1569 IPv4). The scope does not include router configuration or any other 1570 host configuration functions. However, it is within the scope of the 1571 working group to investigate and document the interactions between 1572 this work and related functions including system discovery, DNS 1573 autoregistration, service discovery, and broader host configuration 1574 issues, to facilitate the smooth integration of these functions. 1576 [Katz94a] 1578 The working group is expected to complete its work around the end of 1579 1994 and disband at that time. The group will use "IPv6 Address 1580 Autoconfiguration Architecture" [Katz94b] draft document as the basis 1581 of their work. 1583 16. Transition 1585 The transition of the Internet from IPv4 to IPv6 has to meet two 1586 separate needs. There is a short term need to define specific 1587 technologies and methods to transition IPv4 networks, including the 1588 Internet, into IPv6 networks and an IPv6 Internet. There is also a 1589 long term need to do broad-based operational planning for transition, 1590 including developing methods to allow decentralized migration 1591 strategies, understanding the ramifications of a long period of 1592 coexistence when both protocols are part of the basic infrastructure, 1593 developing an understanding of the type and scope of architectural 1594 and interoperability testing that will be required to ensure a 1595 reliable and manageable Internet in the future. 1597 16.1 Transition - Short Term 1599 Any IPng transition plan must take into account the realities of what 1600 types of devices vendors will build and network managers will deploy. 1601 The IPng transition plan must define the procedures required to 1602 successfully implement the functions which vendors will be likely to 1603 include in their devices. This is the case even if there are good 1604 arguments to recommend against a particular function, header 1605 translation for example. If products will exist it is better to have 1606 them interoperate than not. 1608 We recommend that a new IPng Transition (NGTRANS) Working Group be 1609 formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co- 1610 chairs to design the mechanisms and procedures to support the 1611 transition of the Internet from IPv4 to IPv6 and to give advice on 1612 what procedures and techniques are preferred. 1614 The work of the group will fall into three areas: 1616 * Define the processes by which the Internet will make the transition 1617 from IPv4 to IPv6. As part of this effort, the group will produce 1618 a document explaining to the general Internet community what 1619 mechanisms will be employed in the transition, how the transition 1620 will work, the assumptions about infrastructure deployment inherent 1621 in the operation of these mechanisms, and the types of 1622 functionality that applications developers will be able to assume 1623 as the protocol mix changes over time. 1624 * Define and specify the mandatory and optional mechanisms that 1625 vendors should implement in hosts, routers, and other components of 1626 the Internet in order for the transition to be carried out. Dual- 1627 stack, encapsulation and header translation mechanisms must all be 1628 defined, as well as the interaction between hosts using different 1629 combinations of these mechanisms. The specifications produced will 1630 be used by people implementing these IPv6 systems. 1631 * Articulate a concrete operational plan for the Internet to make the 1632 transition from IPv4 to IPv6. The result of this work will be a 1633 transition plan for the Internet that network operators and 1634 Internet subscribers can execute. 1635 [Gillig94c] 1637 The working group is expected to complete its work around the end of 1638 1994 and disband at that time. The group will use the "Simple SIPP 1639 Transition (SST)" [Gilig94a] overview document as the starting point 1640 for its work. 1642 16.2 Transition - Long Term 1644 There are a number of transition related topics in addition to 1645 defining the specific IPv4 to IPv6 mechanisms and their deployment, 1646 operation and interaction. The ramifications and procedures of 1647 migrating to a new technology or to a new version of an existing 1648 technology must be fully understood. 1650 We recommend that the Transition and Coexistence Including Testing 1651 (TACIT) Working Group, which was started a few months ago, explore 1652 some of the basic issues associated with the deployment of new 1653 technology into an established Internet. The TACIT Working Group 1654 will focus on the generic issues of transition and will not limit 1655 itself to the upcoming transition to IPv6 because, over time, 1656 enhancements to IPv6 (IPv6ng) will be developed and accepted. At 1657 that point they will need to be deployed into the then existing 1658 Internet. The TACIT Working Group will be more operationally 1659 oriented than the NGTRANS Working Group and will continue well into 1660 the actual IPv6 transition. 1662 The main areas of exploration are: 1664 * Make the transition from a currently deployed protocol to a new 1665 protocol while accomodating heterogeneity and decentralized 1666 management. 1667 * Since it is often difficult or impossible to replace all legacy 1668 systems or software, it is important to understand the 1669 characteristics and operation of a long period of coexistence 1670 between a new protocol and the existing protocol. 1671 * The Internet must now be considered a utility. We are far removed 1672 from a time when a new technology could be deployed to see if it 1673 would work in large scale situations. Rigorous architectural and 1674 interoperability testing must be part of the predeployment phase of 1675 any proposed software for the Internet. Testing the scaling up 1676 behaviors and robustness of a new protocol will offer particular 1677 challenges. The WG should determine if there are lessons to be 1678 learned from: OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2 1679 transition, DECnet Phase 4 to Phase 5 planning and transition, 1680 among others. 1682 The TACIT Working Group will explore each of these facets of the 1683 deployment of new technology and develop a number of documents to 1684 help guide users and managers of affected data networks and provide 1685 to the IETF: 1687 * Detailed descriptions of problem areas in transition and 1688 coexistence, both predicted, based on lessons learned, and observed 1689 as the IPv6 process progresses. 1690 * Recommendations for specific testing procedures. 1691 * Recommendations for coexistence operations procedures 1692 * Recommendations for the smoothing of decentralized transition 1693 planning. 1694 [Huston94] 1696 17. Other Address Families 1698 There are many environments in which there are one or more network 1699 protocols already deployed or where a significant planning effort has 1700 been undertaken to create a comprehensive network addressing plan. In 1701 such cases there may be a temptation to integrate IPv6 into the 1702 environment by making use of an existing addressing plan to define 1703 all or part of the IPv6 addresses. The advantage of doing this is 1704 that it permits unified management of address space among multiple 1705 protocol families. The use of common addresses can help faciliate 1706 transition from other protocols to IPv6. 1708 If the existing addresses are globally unique and assigned with 1709 regard to network topology this may be a reasonable idea. The IETF 1710 should work with other organizations to develop algorithms that could 1711 be used to map addresses between IPv6 and other environments. The 1712 goal for any such mapping must be to provide an unambiguous 1 to 1 1713 map between individual addresses. 1715 Suggestions have been made to develop mapping algorithms for Novell 1716 IPX addresses, some types of OSI NSAPs, E164 addresses and SNA 1717 addresses. Each of these possibilities should be carefully examined 1718 to ensure that use of such an algorithm solves more problems than it 1719 creates. In some cases it may be better to recommend either that a 1720 native IPng addressing plan be developed instead, or that an IPv6 1721 address be used within the non-IP environment. [Carpen94b] 1723 We recommend that, in conjunction with other organizations, 1724 recommendations about the use of non-IPv6 addresses in IPv6 1725 environments and IPv6 addresses in non-IPv6 environments be 1726 developed. 1728 18. Impact on Other IETF Standards 1730 Many current IETF standards are affected by IPv6. At least 27 of the 1731 current 51 full Internet Standards must be revised for IPv6, along 1732 with at least 6 of the 20 Draft Standards and at least 25 of the 130 1733 Proposed Standards. [Postel94] 1735 In some cases the revisions consist of simple changes to the text, 1736 for example, in a number of RFCs an IP address is referred to in 1737 passing as a "32 bit IP address" even though IP addresses are not 1738 directly used in the protocol being defined. All of the standards 1739 track documents will have to be checked to see if they contain such 1740 references. 1742 In most of the rest of the cases revisions to the protocols, 1743 including packet formats, will be required. In many of these cases 1744 the address is just being carried as a data element and a revised 1745 format with a larger field for the address will have no effect on the 1746 functional paradigm. 1748 In the remaining cases some facet of the operation of the protocol 1749 will be changed as a result of IPv6. For example, the security and 1750 source route mechanisms are fundamentally changed from IPv4 with 1751 IPv6. Protocols and applications that relied on the IPv4 1752 functionality will have to be redesigned or rethought to use the 1753 equivalent function in IPv6. 1755 In a few cases this opportunity should be used to determine if some 1756 of the RFCs should be moved to historic, for example EGP [Mills84] 1757 and IP over ARCNET. [Provan91] 1759 The base IPng Working Group will address some of these, existing IETF 1760 working groups can work on others, while new working groups must be 1761 formed to deal with a few of them. The IPng Working Group will be 1762 responsible for defining new versions of ICMP, ARP/RARP, and UDP. It 1763 will also review RFC 1639, "FTP Operation Over Big Address Records 1764 (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90] 1766 Existing working groups will examine revisions for some of the 1767 routing protocols: RIPv2, IS-IS, IDRP and SDRP. A new working group 1768 may be required for OSPF. 1770 The existing DHCP Working Group may be able to revise DHCP and 1771 examine BOOTP. 1773 A TCPng Working Group will be formed soon, and new working groups 1774 will have to be formed to deal with standards such as SNMP, DNS, NTP, 1775 NETbios, OSI over TCP, Host Requirements, and Kerberos as well as 1776 reviewing most of the RFCs that define IP usage over various media. 1778 In addition to the standards track RFCs mentioned above there are 1779 many Informational and Experimental RFCs which would be affected as 1780 well as numerous Internet Drafts (and those standards track RFCs that 1781 we missed). 1783 We recommend that the IESG commission a review of all standards track 1784 RFCs to ensure that a full list of affected documents is compiled. We 1785 recommend that the IESG charge current IETF working groups with the 1786 task of understanding the impact of IPv6 on their proposals and, 1787 where approprate, revise the documents to include support for IPv6. 1789 We recommend that the IESG charter new working groups where required 1790 to revise other standards RFCs. 1792 19. Impact on non-IETF standards and on products 1794 Many products and user applications which rely on the size or 1795 structure of IPv4 addresses will need to be modified to work with 1796 IPv6. While the IETF can facilitate an investigation of the impacts 1797 of IPv6 on non-IETF standards and products, the primary 1798 responsibility for doing so resides in the other standards bodies and 1799 the vendors. 1801 Examples of non-IETF standards that are effected by IPv6 include the 1802 POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun 1803 ONC, the Andrew File System and MIT's Kerberos. Most products that 1804 provide specialized network security including firewall-type devices 1805 are among those that must be extended to support IPv6. 1807 20. APIs 1809 It is traditional to state that the IETF does not "do" APIs. While 1810 there are many reasons for this, the one most commonly referenced is 1811 that there are too many environments where TCP/IP is used, too many 1812 different operating systems, programming languages, and platforms. 1813 The feeling is that the IETF should not get involved in attempting to 1814 define a language and operating system independent interface in the 1815 face of such complexity. 1817 We feel that this historical tendency for the IETF to avoid dealing 1818 with APIs should be reexamined in the case of IPv6. We feel that in 1819 a few specific cases the prevalence of a particular type of API is 1820 such that a single common solution for the modifications made 1821 necessary by IPv6 should be documented. 1823 We recommend that Informational RFCs be solicited or developed for 1824 these few cases. In particular, the Berkeley-style sockets 1825 interface, the UNIX TLI and XTI interfaces, and the WINSOCK 1826 interfaces should be targeted. A draft document exists which could 1827 be developed into the sockets API description. [Gillig94b] 1829 21. Future of the IPng Area and Working Groups 1831 In our presentation at the Houston IETF meeting we stated that the 1832 existing IPng proposal working groups would not be forced to close 1833 down after the recommendation was made. Each of them has been 1834 working on technologies that may have applications in addition to 1835 their IPng proposal and these technologies should not be lost. 1837 Since the Toronto IETF meeting the existing IPng working groups have 1838 been returned to the Internet Area. The group members may decide to 1839 close down the working groups or to continue some of their efforts. 1840 The charters of the working groups must be revised if they choose to 1841 continue since they would no longer be proposing an IPng candidate. 1843 In Toronto the chairs of the SIPP Working Group requested that the 1844 SIPP Working Group be concluded. The chairs of the TUBA Working 1845 Group requested that the TUBA working group be understood to be in 1846 hiatus until a number of the documents in process were completed, at 1847 which time they would request that the working group be concluded. 1849 We recommend that the IPng Area and its Directorate continue until 1850 the basic documents have entered the standards track in late 1994 or 1851 early 1995 and that after such time the area be dissolved and those 1852 IPng Area working groups still active be moved to their normal IETF 1853 areas. 1855 22. Security Considerations 1857 The security of the Internet has long been questioned. It has been 1858 the topic of much press coverage, many conferences and workshops. 1859 Almost all of this attention has been negative, pointing out the many 1860 places where the level of possible security is far less than that 1861 deemed necessary for the current and future uses of the Internet. A 1862 number of the RFC 1550 White Papers specifically pointed out the 1863 requirement to improve the level of security available [Adam94, 1864 Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the 1865 Information Future". [Nat94] 1867 In February of 1994 the IAB convened a workshop on security in the 1868 Internet architecture. The report of this workshop [IAB94] includes 1869 an exploration of many of the security problem areas and makes a 1870 number of recommendations to improve the level of security that the 1871 Internet offers its users. 1873 We feel that an improvement in the basic level of security in the 1874 Internet is vital to its continued success. Users must be able to 1875 assume that their exchanges are safe from tampering, diversion and 1876 exposure. Organizations that wish to use the Internet to conduct 1877 business must be able to have a high level of confidence in the 1878 identity of their correspondents and in the security of their 1879 communications. The goal is to provide strong protection as a matter 1880 of course throughout the Internet. 1882 As the IAB report points out, many of the necessary tools are not a 1883 function of the internetworking layer of the protocol. These higher 1884 level tools could make use of strong security features in the 1885 internetworking layer if they were present. While we expect that 1886 there will be a number of special high-level security packages 1887 available for specific Internet constituencies, support for basic 1888 packet-level authentication will provide for the adoption of a much 1889 needed, widespread, security infrastructure throughout the Internet. 1891 It is best to separate the support for authentication from the 1892 support for encryption. One should be able to use the two functions 1893 independantly. There are some applications which 1895 It is our recommendation that IPv6 support packet authentication as a 1896 basic and required function. Applications should be able to rely on 1897 support for this feature in every IPv6 implementation. Support for a 1898 specific authentication algorithm should also be mandated while 1899 support for additional algorithms should be optional. 1901 Thus we recommend that support for the Authentication Header be 1902 required in all compliant IPv6 implementations. 1904 We recommend that support for a specific authentication algorithm be 1905 required. The specific algorithm should be determined by the time 1906 the IPv6 documents are offered as Proposed Standards. 1908 We recommend that support for the Privacy Header be required in IPv6 1909 implementations. 1911 We recommend that support for a privacy authentication algorithm be 1912 required. The specific algorithm should be determined by the time 1913 the IPv6 documents are offered as Proposed Standards. 1915 Clearly, a key management infrastructure will be required in order to 1916 enable the use of the authentication and encryption headers. 1917 However, defining such an infrastructure is outside the scope of the 1918 IPv6 effort. We do note that there are on-going IETF activities in 1919 this area. The IPv6 transition working groups must coordinate with 1920 these activities. 1922 Just as clearly, the use of authentication and encryption may add to 1923 the cost and impact the performance of systems but the more secure 1924 infrastructure is worth the penalty. Whatever penalty there is 1925 should also decrease in time with improved software and hardware 1926 assistance. 1928 The use of firewalls is increasing on the Internet. We hope that the 1929 presence of the authentication and privacy features in IPv6 will 1930 reduce the need for firewalls, but we do understand that they will 1931 continue to be used for the foreseeable future. In this light, we 1932 feel that clear guidance should be given to the developers of 1933 firewalls on the best ways to design and configure them when working 1934 in an IPv6 environment. 1936 We recommend that an "IPv6 framework for firewalls" be developed. 1937 This framework should explore the ways in which the Authentication 1938 Header can be used to strengthen firewall technology and detail how 1939 the IPv6 packet should be analyzed by a firewall. 1941 Some aspects of security require additional study. For example, it 1942 has been pointed out [Vecchi94] that, even in non-military 1943 situations, there are places where procedures to thwart traffic 1944 analysis will be required. This could be done by the use of 1945 encrypted encapsulation, but this and other similar requirements must 1946 be addressed on an on-going basis by the Security Area of the IETF. 1947 The design of IPv6 must be flexible enough to support the later 1948 addition of such security features. 1950 We believe that IPv6 with its inherent security features will provide 1951 the foundation upon which the Internet can continue to expand its 1952 functionality and user base. 1954 23. Authors' Addresses 1956 Scott Bradner 1957 Harvard University 1958 10 Ware St. 1959 Cambridge, MA 02138 1961 Phone: +1 617 495 3864 1962 EMail: sob@harvard.edu 1964 Allison Mankin 1965 Naval Research Laboratory 1966 c/o Code 5591 1967 Washington D.C. 20375-5000 1969 Phone: +1 202 404 7030 1970 EMail: mankin@cmf.nrl.navy.mil 1972 Appendix A - Summary of Recommendations 1974 5.3 Address Assignment Policy Recommendations 1975 changes in address assignment policies are not recommended 1976 reclamation of underutilized assigned addresses is not currently 1977 recommended 1978 efforts to renumber significant portions of the Internet are not 1979 currently recommended 1980 recommend consideration of assigning CIDR-type address blocks out 1981 of unassigned Class A addressees 1982 11. IPng Recommendation 1983 recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128 1984 bit ver)" [Deering94b] be adopted as the basis for IPng 1985 recommend that the documents listed in Appendix C be the basis of 1986 IPng 1987 13. IPng Working Group 1988 recommend that an IPng Working Group be formed, chaired by Steve 1989 Deering and Ross Callon 1990 recommend that Robert Hinden be the document editor for the IPng 1991 effort 1992 14. IPng Reviewer 1993 recommend that an IPng Reviewer be appointed and that Dave Clark 1994 be that reviewer 1995 15. Address Autoconfiguration 1996 recommend that an Address Autoconfiguration Working Group be 1997 formed, chaired by Dave Katz and Sue Thomson 1998 16.1 Transition - Short Term 1999 recommend that an IPng Transition Working Group be formed, chaired 2000 by Bob Gilligan and TBA 2001 16.2 Transition - Long Term 2002 recommend that the Transition and Coexistence Including Testing 2003 Working Group be chartered 2004 17. Other Address Families 2005 recommend that recommendations about the use of non-IPv6 addresses 2006 in IPv6 environments and IPv6 addresses in non-IPv6 2007 environments be developed 2008 18. Impact on Other IETF Standards 2009 recommend the IESG commission a review of all standards track RFCs 2010 recommend the IESG charge current IETF working groups with the 2011 task of understanding the impact of IPng on their proposals 2012 and, where approprate, revise the documents to include support 2013 for IPng 2014 recommend the IESG charter new working groups where required to 2015 revise other standards RFCs 2016 20. APIs 2017 recommend that Informational RFCs be developed or solicited for a 2018 few of the common APIs 2019 21. Future of the IPng Area and Working Groups 2020 recommend that the IPng Area and Area Directorate continue until 2021 main documents are offered as Proposed Standards in late 1994 2022 22. Security Considerations 2023 recommend that support for the Authentication Header be required 2024 recommend that support for a specific authentication algorithm be 2025 required 2026 recommend that support for the Privacy Header be required 2027 recommend that support for a specific privacy algorithm be 2028 required 2029 recommend that an "IPng framework for firewalls" be developed 2031 Appendix B - IPng Area Directorate 2033 J. Allard - Microsoft 2034 Steve Bellovin - AT&T 2035 Jim Bound - Digital 2036 Ross Callon - Wellfleet 2037 Brian Carpenter - CERN 2038 Dave Clark - MIT 2039 John Curran - NEARNET 2040 Steve Deering - Xerox 2041 Dino Farinacci - Cisco 2042 Paul Francis - NTT 2043 Eric Fleischmann - Boeing 2044 Mark Knopper - Ameritech 2045 Greg Minshall - Novell 2046 Rob Ullmann - Lotus 2047 Lixia Zhang - Xerox 2049 Daniel Karrenberg of RIPE joined the Directorate when it was formed 2050 but had to withdraw due to the demands of his day job. 2052 Since the Toronto IETF meeting Paul Francis has resigned from the 2053 Directorate to pursue other interests. Robert Hinden of Sun 2054 Microsystems and Yakov Rekhter of IBM have joined. 2056 Appendix C - Documents Referred to the IPng Working Groups 2058 [Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec. 2059 (128 bit ver)", Work in progress, July 1994 2060 [Francis94] Francis, P., "SIPP Addressing Architecture", Work in 2061 progress, xx 1994 2062 [Rekhter94] Rekhter, Y. and T. Li, "An Architecture for IPv6 Unicast 2063 Address Allocation", Work in progress, August 1994 2064 [Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview", 2065 Work in progress, xx 1994 2067 [Gillig94b] Gilligan, R., R. Govindan, S. Thomson, and J. Bound, 2068 "SIPP Program Interfaces for BSD Systems", work in progress, April 2069 1994 2070 [Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in 2071 progress, xx 1994 2072 [Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in 2073 progress, xx 1994 2074 [Ford94b] Ford, P., T. Li, Y. Rekhter, "SDRP Routing Header for 2075 SIPP-16", Work in progress, xx 1994 2076 [Hinden94c] Hinden, R., "IP Next Generation Overview", Work in 2077 progress, September 1994 2079 Appendix D - IPng Proposal Overviews 2081 [Ford94a] Ford, P., M. Knopper, "TUBA as IPng: A White Paper", Work 2082 in progress, LANL, AADS, August 1994 2083 [Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper", 2084 RFC xxx, Sun Microsystems, August 1994 2085 [McGovern94] McGovern, M., R. Ullmann, "CATNIP: Common Architecture 2086 for the Internet", RFC xxx, Sunspot Graphics, Lotus Development 2087 Corp., August 1994 2089 Appendix E - RFC 1550 White Papers 2091 [Adam94] Adamson, B., "Tactical Radio Frequency Communication 2092 Requirements for IPng", RFC 1677, NRL, August 1994 2093 [Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T 2094 Bell Laboratories. August 1994 2095 [Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T 2096 Bell Laboratories. August 1994 2097 [Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC 2098 1682, Digital, August 1994 2099 [Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680, 2100 Bellcore, August 1994 2101 [Britt94] Britton, E., J. Tavs, "IPng Requirements of Large Corporate 2102 Networks", RFC 1678, IBM, August 1994 2103 [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC 2104 1672, University of Auckland, August 1994 2105 [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other 2106 Considerations", RFC 1671, CERN, August 1994 2107 [Chiappa94] Chiappa, J. N., "IPng Technical Requirements Of the 2108 Nimrod Routing and Addressing Architecture", RFC xxx, August 1994 2109 [Clark94] Clark, R., M. Ammar, K. Calvert, "Multiprotocol 2110 Interoperability In IPng", RFC 1683, Georgia Institute of 2111 Technology, August 1994 2112 [Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC 2113 1669, BBN, August 1994 2114 [Estrin94a] Estrin, D., T. Li, Y. Rekhter, "Unified Routing 2115 Requirements for IPng", RFC 1668, USC, Cisco Systems, IBM, August 2116 1994 2117 [Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng", 2118 RFC 1687, Boeing Computer Services, August 1994 2119 [Green94] Green, D., P. Irey, D. Marlow, K. O'Donoghue, "HPN Working 2120 Group Input to the IPng Requirements Solicitation", RFC 1679, 2121 NSWC-DD, August 1994 2122 [Ghisel94] Ghiselli, A., D. Salomoni, C. Vistoli, "INFN Requirements 2123 for an IPng", RFC 1676, INFN/CNAF, August 1994 2124 [Heager94] Heagerty, D., "Input to IPng Engineering Considerations", 2125 RFC 1670, CERN, August 1994 2126 [Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688, 2127 Daydreamer, August 1994 2128 [Skelton94] Skelton, R., "Electric Power Research Institute Comments 2129 on IPng", RFC 1673, EPRI, August 1994 2130 [Syming94] Symington, S., D. Wood, J. Pullen, "Modeling and 2131 Simulation Requirements for IPng", RFC 1667, MITRE, George Mason 2132 University, August 1994 2133 [Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674, 2134 CDPD Consortium, August 1994 2135 [Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television 2136 Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994 2138 Appendix F - Additional References 2140 [Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF", 2141 Washington DC IETF, November 1992, (ietf/nov92/select-minutes- 2142 92nov.txt) 2143 [Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and 2144 Requirements", work in progress, September 1994 2145 [Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF 2146 (ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes-94mar.txt) 2147 [Big] Archives of the big-internet mailing list, on munnari.oz.au in 2148 pub/big-internet/list-archives 2149 [Bradner93] Bradner, S., A. Mankin, "IP: Next Generation (IPng) White 2150 Paper Solicitation", RFC 1550, Harvard University, NRL, December 2151 1993. 2152 [Callon87] Callon, R., "A Proposal for a Next Generation Internet 2153 Protocol", proposal to X3S3, December 1987 2154 [Callon92a] Callon, R., "CNAT", Work in progress, 1992 2155 [Callon92b] Callon, R., "Simple CLNP", Work in progress, 1992 2156 [Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A 2157 Simple Proposal for Internet Addressing and Routing", RFC 1347, 2158 DEC, June 1992 2159 [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision 2160 Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt, 2161 August 1993 2162 [Carpen94b] Carpenter, B, and J.Bound "Recommendations for OSI NSAP 2163 usage in IPv6", Work in progress, August 1994 2164 [Chiappa91] Chiappa, J., "A New IP Routing and Addressing 2165 Architecture", Work in Progress, July 1991. 2166 [Clark91] Clark, D., L. Chapin, V. Cerf, R. Braden, and R. Hobby 2167 "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, 2168 CNRI, ISI, UC Davis, December 1991 2169 [Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet 2170 mailing list, 1992 2171 [Deering94a] Deering, S. and P. Francis, Message to sipp mailing 2172 list, 31 May 1994 2173 [Estrin94b] Estrin, D., D. Zappala, T. Li, Y. Rekhter, and K. 2174 Varadhan, "Source Demand Routing: Packet Format and Forwarding 2175 Specification (Version 1)" Work in progress, March 1994 2176 [Fuller93] Fuller, V., T. Li, J. Yu, K. Varadhan, "Classless Inter- 2177 Domain Routing (CIDR): an Address Assignment and Aggregation 2178 Strategy", RFC 1519, BARRNet, Cisco Systems, MERIT, OARnet, 2179 September 1993 2180 [Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", draft charter, 2181 August 1994 2182 [Gross92} Gross, P., and P. Almquist, "IESG Deliberations on Routing 2183 and Addressing", RFC 1380, ANS, Stanford University, November 1992 2184 [Gross94] Gross, P. "A Direction for IPng", RFC xxx, MCI, August 1994 2185 [Hinden92a] Hinden, R., "New Scheme for Internet Routing and 2186 Addressing (ENCAPS)", Email message to Big-Internet mailing 2187 list,March 16, 1992. 2188 [Hinden94b] Hinden, R., S. Deering, and P. Francis, "Simple Internet 2189 Protocol Plus", working group charter, April 1994 2190 [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address 2191 Encapsulation (IPAE): A Compatible version of IP with Large 2192 Addresses", Work in Progress, June 1992. 2193 [Huston94] Huston, G., and A. Bansal, draft charter for the 2194 "Transition and Coexistence Including Testing (TACIT) working 2195 group, June 1994 2196 [Huitema93] Huitema, C., "IAB Recommendations for an Intermediate 2197 Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July 2198 1993 2199 [Huitema94] Huitema, C., "The H ratio for address assignment 2200 efficiency", RFC xxx, INRIA, September 1994 2201 [IAB92] Internet Architecture Board, "IP Version 7", work in 2202 progress, July 1992 2203 [IAB94] Internet Architecture Board, R. Braden, D. Clark, S. Crocker, 2204 C. Huitema, "Report of IAB Workshop on Security in the Internet 2205 Architecture - February 8-10, 1994", RFC 1636, June 1994 2206 [Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical 2207 Criteria", work in progress 1992 2209 [Kasten94] Kastenholz, F, and C. Partridge, "Technical Criteria for 2210 Choosing IP: The Next Generation (IPng)", RFC xxx, FTP Software, 2211 BBN, August 1994 2212 [Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed 2213 Networks (TUBA)", working group charter, January 1994 2214 [Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen 2215 IPng Retreat, May 19 & 20 1994" 2216 [Leiner93] Leiner, B., Y. Rekhter, "The MultiProtocol Internet", RFC 2217 1560, USRA, IBM, December 1993 2218 [Mankin94] Mankin, A. and S. Bradner, message to big-internet, tuba, 2219 sipp, catnip and ietf mailing lists, 7 July 1994 2220 [Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification", 2221 RFC 904, April 1984 2222 [Mogul90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 2223 DECWRL, November 199 2224 [Nat94] National Research Council, "Realizing the Information Future: 2225 The Internet and Beyond", National Academy Press, 1994 2226 [Piscit94] Piscitello, D., "FTP Operation Over Big Address Records 2227 (FOOBAR)", RFC 1639, Core Competence, June 1994 2228 [Provan91] Provan, D., "Transmitting IP Traffic over ARCNET 2229 Networks", RFC 1051, Novell, Feburary 1991 2230 [Postel94] Postel, J., "Internet Official Protocol Standards", RFC 2231 1610, ISI, July 1994 2232 [Solens93a] Solensky, F.and T. Li, "Charter for the Address Lifetime 2233 Expectations Working Group", FTP Software, Cisco Systems, November 2234 1993 2235 [Solens93b] Solensky, F., "Minutes of the Address Lifetime 2236 Expectations BOF (ALE)", Houston IETF, November 1993, 2237 (ietf/ale/ale-minutes-93nov.txt) 2238 [Solens94] Solensky, F., "Minutes of the Address Lifetime 2239 Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale- 2240 minutes-94jul.txt) 2241 [Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation 2242 IP (catnip), working group charter, April 1994 2243 [Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in 2244 Progress, May 1992. 2245 [Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 2246 1993 2248 Appendix G - Acknowledgments 2250 Reaching this stage of the recommendation would not have been even 2251 vaguely possible without the efforts of many people. In particular, 2252 the work of IPng Directorate (listed in Appendix B), Frank Kastenholz 2253 and Craig Partridge (the authors of the Criteria document) along with 2254 Jon Crowcroft (who co-chaired the ngreq BOF) was critical. The work 2255 and cooperation of the chairs, members and document authors of the 2256 three IPng proposal working groups, the ALE working group and the 2257 TACIT working group laid the groundwork upon which this 2258 recommendation sits. 2260 We would also like to thank the many people who took the time to 2261 respond to RFC1550 and who provided the broad understanding of the 2262 many requireemnts of data networking that any proposal for an IPng 2263 must address. 2265 The members of the IESG, the IAB, and the always active participants 2266 in the various mailing lists provided us with many insights into the 2267 issues we faced. 2269 Many other individuals gave us sometimes spirited but always useful 2270 counsel during this process. They include (in no particular order) 2271 Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave 2272 Piscitello, Vint Cerf and Dan Lynch. 2274 Thanks to David Williams and Cheryl Chapman who took on the 2275 occasionally impossible task of ensuring that what is written here 2276 resembles English to some degree. 2278 To all of the many people mentioned above and those we have skipped 2279 in our forgetfulness, thank you for making this task doable. 2281 Expire in six months