idnits 2.17.1 draft-hinden-ipng-overview-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-19) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RECM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 1994) is 10779 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: 'RFC-1340' is mentioned on line 430, but not defined ** Obsolete undefined reference: RFC 1340 (Obsoleted by RFC 1700) == Unused Reference: 'AUTH' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'AUTO' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'COMP' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'DISC' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'DIS2' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'DHCP' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'DNS' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'ICMP' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'SARC' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'SECR' is defined on line 1093, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASSN' -- No information found for draft-rekhter-ipng-arch-IPv6-addr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ALLO' -- No information found for draft-ietf-sipp-ap - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'AUTO' ** Obsolete normative reference: RFC 1338 (ref. 'CIDR') (Obsoleted by RFC 1519) -- Possible downref: Normative reference to a draft: ref. 'COMP' == Outdated reference: A later version (-02) exists of draft-simpson-ipv6-discov-process-00 -- Possible downref: Normative reference to a draft: ref. 'DISC' == Outdated reference: A later version (-02) exists of draft-simpson-ipv6-discov-formats-00 -- Possible downref: Normative reference to a draft: ref. 'DIS2' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'EFFC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMP' -- No information found for draft-ietf-ipng-ipv6-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPNG' -- Possible downref: Non-RFC (?) normative reference: ref. 'RECM' -- No information found for draft-ietf-sipp-sa - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SARC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SECR' -- Unexpected draft version: The latest known version of draft-ietf-sipp-spec is -00, but you're referring to -01. (However, the state information for draft-ietf-sipp-sa is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. 'SIPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIT' Summary: 15 errors (**), 0 flaws (~~), 15 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert M. Hinden 3 Sun Microsystems, Inc. 4 October 1994 6 IP Next Generation Overview 7 9 Abstract 11 This document presents an overview of the protocol which was 12 recommended as the Next Generation of IP by the IPng Area Directors 13 of the Internet Engineering Task Force at the Toronto IETF Meeting 14 on July 25, 1994 [RECM]. 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as ``work in 27 progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 31 Shadow Directories on ds.internic.net (US East Coast), 32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 33 munnari.oz.au (Pacific Rim). 35 This Internet Draft expires on April 1, 1995. 37 Distribution of this memo is unlimited. 39 1. Introduction 41 This document presents an overview of the Next Generation Internet 42 Protocol which was recommended by the IPng Area Directors of the 43 Internet Engineering Task Force at the Toronto IETF meeting on July 25, 44 1994 [RECM]. The formal name of this protocol is IPv6 (where the "6" 45 refers to it being assigned version number 6). The current version of 46 the Internet Protocol is version 4 (referred to as IPv4). 48 This overview is is intended to give the reader an overview of the IPng 49 protocol. For more detailed information the reader should consult the 50 documents listed in the reference section. 52 IPng is a new version of IP which is designed to be an evolutionary step 53 from IPv4. It is a natural increment to IPv4. It can be installed as a 54 normal software upgrade in internet devices and is interoperable with 55 the current IPv4. Its deployment strategy was designed to not have any 56 "flag" days. IPng is designed to run well on high performance networks 57 (e.g. ATM) and at the same time is still efficient for low bandwidth 58 networks (e.g. wireless). In addition, it provides a platform for new 59 internet functionality that will be required in the near future. 61 This white paper describes the work of IETF IPng working group. Several 62 individuals deserve specific recognition. These include Steve Deering, 63 Paul Francis, Bob Gilligan, Dave Crocker, Ran Atkinson, Jim Bound, Ross 64 Callon, Bill Fink, Ramesh Govindan, Christian Huitema, Erik Nordmark, 65 Tony Li, Dave Katz, Yakov Rekhter, Bill Simpson, and Sue Thompson. 67 2. Key Issues for the Next Generation of IP 69 There are several key issues that should be considered when reviewing 70 the design of the next generation internet protocol. Some are very 71 straightforward. For example the new protocol must be able to support 72 large global internetworks. Others are less obvious. There must be a 73 clear way to transition the current large installed base of IPv4 74 systems. It doesn't matter how good a new protocol is if there isn't a 75 practical way to transition the current operational systems running IPv4 76 to the new protocol. 78 2.1 Growth 80 Growth is the basic issue which caused there to be a need for a next 81 generation IP. If anything is to be learned from our experience with 82 IPv4 it is that the addressing and routing must be capable of handling 83 reasonable scenarios of future growth. It is important that we have an 84 understanding of the past growth and where the future growth will come 85 from. 87 Currently IPv4 serves what could be called the computer market. The 88 computer market has been the driver of the growth of the Internet. It 89 comprises the current Internet and countless other smaller internets 90 which are not connected to the Internet. Its focus is to connect 91 computers together in the large business, government, and university 92 education markets. This market has been growing at an exponential rate. 93 One measure of this is that the number of networks in current Internet 94 (40,073 as of 10/4/94) is doubling approximately every 12 months. The 95 computers which are used at the endpoints of internet communications 96 range from PC's to Supercomputers. Most are attached to Local Area 97 Networks (LANs) and the vast majority are not mobile. 99 The next phase of growth will probably not be driven by the computer 100 market. While the computer market will continue to grow at significant 101 rates due to expansion into other areas such as schools (elementary 102 through high school) and small businesses, it is doubtful it will 103 continue to grow at an exponential rate. What is likely to happen is 104 that other kinds of markets will develop. These markets will fall into 105 several areas. They all have the characteristic that they are extremely 106 large. They also bring with them a new set of requirements which were 107 not as evident in the early stages of IPv4 deployment. The new markets 108 are also likely to happen in parallel with one another. It may turn out 109 that we will look back on the last ten years of Internet growth as the 110 time when the Internet was small and only doubling every year. The 111 challenge for an IPng is to provide a solution which solves todays 112 problems and is attractive in these emerging markets. 114 Nomadic personal computing devices seem certain to become ubiquitous as 115 their prices drop and their capabilities increase. A key capability is 116 that they will be networked. Unlike the majority of todays networked 117 computers they will support a variety of types of network attachments. 118 When disconnected they will use RF wireless networks, when used in 119 networked facilities they will use infrared attachment, and when docked 120 they will use physical wires. This makes them an ideal candidate for 121 internetworking technology as they will need a common protocol which can 122 work over a variety of physical networks. These types of devices will 123 become consumer devices and will replace the current generation of 124 cellular phones, pagers, and personal digital assistants. In addition 125 to the obvious requirement of an internet protocol which can support 126 large scale routing and addressing, they will require an internet 127 protocol which imposes a low overhead and supports auto configuration 128 and mobility as a basic element. The nature of nomadic computing 129 requires an internet protocol to have built in authentication and 130 confidentiality. It also goes without saying that these devices will 131 need to communicate with the current generation of computers. The 132 requirement for low overhead comes from the wireless media. Unlike 133 LAN's which will be very high speed, the wireless media will be several 134 orders of magnitude slower due to constraints on available frequencies, 135 spectrum allocation, error rates, and power consumption. 137 Another market is networked entertainment. The first signs of this 138 emerging market are the proposals being discussed for 500 channels of 139 television, video on demand, etc. This is clearly a consumer market. 140 The possibility is that every television set will become an Internet 141 host. As the world of digital high definition television approaches, 142 the differences between a computer and a television will diminish. As 143 in the previous market, this market will require an Internet protocol 144 which supports large scale routing and addressing, and auto 145 configuration. This market also requires a protocol suite which imposes 146 the minimum overhead to get the job done. Cost will be the major factor 147 in the selection of an appropriate technology. 149 Another market which could use the next generation IP is device control. 150 This consists of the control of everyday devices such as lighting 151 equipment, heating and cooling equipment, motors, and other types of 152 equipment which are currently controlled via analog switches and in 153 aggregate consume considerable amounts of electrical power. The size of 154 this market is enormous and requires solutions which are simple, robust, 155 easy to use, and very low cost. The potential pay-back is that 156 networked control of devices will result in cost savings which are 157 extremely large. 159 The challenge the IETF faced in the selection of an IPng is to pick a 160 protocol which meets today's requirements and also matches the 161 requirements of these emerging markets. These markets will happen with 162 or without an IETF IPng. If the IETF IPng is a good match for these new 163 markets it is likely to be used. If not, these markets will develop 164 something else. They will not wait for an IETF solution. If this 165 should happen it is probable that because of the size and scale of the 166 new markets the IETF protocol would be supplanted. If the IETF IPng is 167 not appropriate for use in these markets, it is also probable that they 168 will each develop their own protocols, perhaps proprietary. These new 169 protocols would not interoperate with each other. The opportunity for 170 the IETF is to select an IPng which has a reasonable chance to be used 171 in these emerging markets. This would have the very desirable outcome 172 of creating an immense, interoperable, world-wide information 173 infrastructure created with open protocols. The alternative is a world 174 of disjoint networks with protocols controlled by individual vendors. 176 2.2. Transition 178 At some point in the next three to seven years the Internet will require 179 a deployed new version of the Internet protocol. Two factors are 180 driving this: routing and addressing. Global internet routing based on 181 the on 32-bit addresses of IPv4 is becoming increasingly strained. IPv4 182 address do not provide enough flexibility to construct efficient 183 hierarchies which can be aggregated. The deployment of Classless 184 Inter-Domain Routing [CIDR] is extending the life time of IPv4 routing 185 routing by a number of years, the effort to manage the routing will 186 continue to increase. Even if the IPv4 routing can be scaled to support 187 a full IPv4 Internet, the Internet will eventually run out of network 188 numbers. There is no question that an IPng is needed, but only a 189 question of when. 191 The challenge for an IPng is for its transition to be complete before 192 IPv4 routing and addressing break. The transition will be much easier 193 if IPv4 address are still globally unique. The two transition 194 requirements which are the most important are flexibility of deployment 195 and the ability for IPv4 hosts to communicate with IPng hosts. There 196 will be IPng-only hosts, just as there will be IPv4-only hosts. The 197 capability must exist for IPng-only hosts to communicate with IPv4-only 198 hosts globally while IPv4 addresses are globally unique. 200 The deployment strategy for an IPng must be as flexible as possible. 201 The Internet is too large for any kind of controlled rollout to be 202 successful. The importance of flexibility in an IPng and the need for 203 interoperability between IPv4 and IPng was well stated in a message to 204 the sipp mailing list by Bill Fink, who is responsible for a portion of 205 NASA's operational internet. In his message he said: 207 "Being a network manager and thereby representing the interests of a 208 significant number of users, from my perspective it's safe to say 209 that the transition and interoperation aspects of any IPng is *the* 210 key first element, without which any other significant advantages 211 won't be able to be integrated into the user's network environment. 212 I also don't think it wise to think of the transition as just a 213 painful phase we'll have to endure en route to a pure IPng 214 environment, since the transition/coexistence period undoubtedly 215 will last at least a decade and may very well continue for the 216 entire lifetime of IPng, until it's replaced with IPngng and a new 217 transition. I might wish it was otherwise but I fear they are facts 218 of life given the immense installed base. 220 "Given this situation, and the reality that it won't be feasible to 221 coordinate all the infrastructure changes even at the national and 222 regional levels, it is imperative that the transition capabilities 223 support the ability to deploy the IPng in the piecemeal fashion... 224 with no requirement to need to coordinate local changes with other 225 changes elsewhere in the Internet... 227 "I realize that support for the transition and coexistence 228 capabilities may be a major part of the IPng effort and may cause 229 some headaches for the designers and developers, but I think it is a 230 duty that can't be shirked and the necessary price that must be paid 231 to provide as seamless an environment as possible to the end user 232 and his basic network services such as e-mail, ftp, gopher, X-Window 233 clients, etc... 235 "The bottom line for me is that we must have interoperability during 236 the extended transition period for the base IPv4 functionality..." 238 Another way to think about the requirement for compatibility with IPv4 239 is to look at other product areas. In the product world, backwards 240 compatability is very important. Vendors who do not provide backward 241 compatibility for their customers usually find they do not have many 242 customers left. For example, chip makers put considerable effort into 243 making sure that new versions of their processor always run all of the 244 software that ran on the previous model. It is unlikely that Intel 245 would develop a new processor in the X86 family that did not run DOS and 246 the tens of thousands of applications which run on the current versions 247 of X86's. 249 Operating system vendors go to great lengths to make sure new versions 250 of their operating systems are binary compatible with their old version. 251 For example the labels on most PC or MAC software usually indicate that 252 they require OS version XX or greater. It would be foolish for 253 Microsoft come out with a new version of Windows which did not run the 254 applications which ran on the previous version. Microsoft even provides 255 the ability for windows applications to run on their new OS NT. This is 256 an important feature. They understand that it was very important to 257 make sure that the applications which run on Windows also run on NT. 259 The same requirement is also true for IPng. The Internet has a large 260 installed base. Features need to be designed into an IPng to make the 261 transition as easy as possible. As with processors and operating 262 systems, it must be backwards compatible with IPv4. Other protocols 263 have tried to replace TCP/IP, for example XTP and OSI. One element in 264 their failure to reach widespread acceptance was that neither had any 265 transition strategy other than running in parallel (sometimes called 266 dual stack). New features alone are not adequate to motivate users to 267 deploy new protocols. IPng must have a great transition strategy and 268 new features. 270 3. History of the IPng Effort 272 The IPng protocol represents the evolution of many different IETF 273 proposals and working groups focused on developing an IPng. It 274 represents over three years of effort focused on this topic. A brief 275 history follows: 277 By the Winter of 1992 the Internet community had developed four separate 278 proposals for IPng. These were "CNAT", "IP Encaps", "Nimrod", and 279 "Simple CLNP". By December 1992 three more proposals followed; "The P 280 Internet Protocol" (PIP), "The Simple Internet Protocol" (SIP) and 281 "TP/IX". In the Spring of 1992 the "Simple CLNP" evolved into "TCP and 282 UDP with Bigger Addresses" (TUBA) and "IP Encaps" evolved into "IP 283 Address Encapsulation" (IPAE). 285 By the fall of 1993, IPAE merged with SIP while still maintaining the 286 name SIP. This group later merged with PIP and the resulting working 287 group called themselves "Simple Internet Protocol Plus" (SIPP). At 288 about the same time the TP/IX Working Group changed its name to "Common 289 Architecture for the Internet" (CATNIP). 291 The IPng area directors made a recommendation for an IPng in July of 292 1994. This recommendation, from [RECM], includes the following 293 elements: 295 o Current address assignment policies are adequate. 296 o There is no current need to reclaim underutilized assigned network 297 numbers. 298 o There is no current need to renumber major portions of the 299 Internet. 300 o CIDR-style assignments of parts of unassigned Class A address space 301 should be considered. 302 o "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [SIPP] 303 be adopted as the basis for IPng. 304 o The documents listed in Appendix C be the foundation of the IPng 305 effort. 306 o An IPng Working Group be formed, chaired by Steve Deering and Ross 307 Callon. 308 o Robert Hinden be the document editor for the IPng effort. 309 o An IPng Reviewer be appointed and that Dave Clark be the reviewer. 310 o An Address Autoconfiguration Working Group be formed, chaired by 311 Dave Katz and Sue Thomson. 312 o An IPng Transition Working Group be formed, chaired by Bob Gilligan 313 and TBA. 314 o The Transition and Coexistence Including Testing Working Group be 315 chartered. 316 o Recommendations about the use of non-IPv6 addresses in IPv6 317 environments and IPv6 addresses in non-IPv6 environments be 318 developed. 319 o The IESG commission a review of all IETF standards documents for 320 IPng implications. 321 o The IESG task current IETF working groups to take IPng into 322 account. 323 o The IESG charter new working groups where needed to revise old 324 standards documents. 325 o Informational RFCs be solicited or developed describing a few 326 specific IPng APIs. 327 o The IPng Area and Area Directorate continue until main documents 328 are offered as Proposed Standards in late 1994. 329 o Support for the Authentication Header be required. 330 o Support for a specific authentication algorithm be required. 331 o Support for the Privacy Header be required. 332 o Support for a specific privacy algorithm be required. 333 o An "IPng framework for firewalls" be developed. 335 4. IPng Overview 337 IPng is a new version of the Internet Protocol, designed as a successor 338 to IP version 4 [IPV4]. IPng is assigned IP version number 6 and is 339 formally called IPv6 [IPNG]. 341 IPng was designed to take an evolutionary step from IPv4. It was not a 342 design goal to take a radical step away from IPv4. Functions which work 343 in IPv4 were kept in IPng. Functions which didn't work were removed. 344 The changes from IPv4 to IPng fall primarily into the following 345 categories: 347 o Expanded Routing and Addressing Capabilities 349 IPng increases the IP address size from 32 bits to 128 bits, to 350 support more levels of addressing hierarchy and a much greater 351 number of addressable nodes, and simpler auto-configuration of 352 addresses. 354 The scaleability of multicast routing is improved by adding a 355 "scope" field to multicast addresses. 357 A new type of address called a "cluster address" is defined, to 358 identify topological regions rather than individual nodes. The use 359 of cluster addresses in the IPng source route allows nodes to 360 control the path which their traffic flows. 362 o Header Format Simplification 364 Some IPv4 header fields have been dropped or made optional, to 365 reduce the common-case processing cost of packet handling and to 366 keep the bandwidth cost of the IPng header as low as possible 367 despite the increased size of the addresses. Even though the IPng 368 addresses are four time longer than the IPv4 addresses, the IPng 369 header is only twice the size of the IPv4 header. 371 o Improved Support for Options 373 Changes in the way IP header options are encoded allows for more 374 efficient forwarding, less stringent limits on the length of 375 options, and greater flexibility for introducing new options in the 376 future. 378 o Quality-of-Service Capabilities 380 A new capability is added to enable the labeling of packets 381 belonging to particular traffic "flows" for which the sender 382 requests special handling, such as non-default quality of service 383 or "real-time" service. 385 o Authentication and Privacy Capabilities 387 IPng includes the definition of extensions which provide support 388 for authentication, data integrity, and (optionally) 389 confidentiality. This is included as a basic element of IPng and 390 will be included in all implementations. 392 The IPng protocol consists of two parts, the basic IPng header and IPng 393 Options. 395 4.1 IPng Header Format 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 |Version| Flow Label | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Payload Length | Next Header | Hop Limit | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 + + 404 | | 405 + Source Address + 406 | | 407 + + 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 + + 412 | | 413 + Destination Address + 414 | | 415 + + 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Version 4-bit Internet Protocol version number = 6. 420 Flow Label 28-bit field. See IPng Quality of Service 421 section. 423 Payload Length 16-bit unsigned integer. Length of payload, 424 i.e., the rest of the packet following the 425 IPng header, in octets. 427 Next Header 8-bit selector. Identifies the type of header 428 immediately following the IPng header. Uses 429 the same values as the IPv4 Protocol field 430 [RFC-1340]. 432 Hop Limit 8-bit unsigned integer. Decremented by 1 433 by each node that forwards the packet. 434 The packet is discarded if Hop Limit is 435 decremented to zero. 437 Source Address 128 bits. An address of the initial sender of 438 the packet. See [ADDR] for details. 440 Destination Address 128 bits. An address of the intended recipient 441 of the packet (possibly not the ultimate 442 recipient, if an optional Routing Header is 443 present). 444 4.2 IPng Options 446 IPng includes an improved option mechanism over IPv4. IPng options are 447 placed in separate headers that are located between the IPng header and 448 the transport-layer header in a packet. Most IPng option headers are 449 not examined or processed by any router along a packet's delivery path 450 until it arrives at its final destination. This facilitates a major 451 improvement in router performance for packets containing options. In 452 IPv4 the presence of any options requires the router to examine all 453 options. The other improvement is that unlike IPv4, IPng options can be 454 of arbitrary length and the total amount of options carried in a packet 455 is not limited to 40 bytes. This feature plus the manner in which they 456 are processed, permits IPng options to be used for functions which were 457 not practical in IPv4. A good example of this is the IPng 458 Authentication and Security Encapsulation options. 460 In order to improve the performance when handling subsequent option 461 headers and the transport protocol which follows, IPng options are 462 always an integer multiple of 8 octets long, in order to retain this 463 alignment for subsequent headers. 465 The IPng option headers which are currently defined are: 467 Option Function 468 --------------- --------------------------------------- 469 Routing Extended Routing (like IPv4 loose source 470 route). 471 Fragmentation Fragmentation and Reassembly. 472 Authentication Integrity and Authentication. 473 Security Encapsulation Confidentiality. 474 Hop-by-Hop Option Special options which require hop by hop 475 processing. 476 End-to-End Options Optional information to be examined by 477 the destination node. 479 4.3 IPng Addressing 481 IPng addresses are 128-bits long and are identifiers for individual 482 nodes and sets of nodes. There are three types of IPng addresses. 483 These are unicast, cluster, and multicast. Unicast addresses identify a 484 single node. Cluster addresses identify a group of nodes, that share a 485 common address prefix, such that a packet sent to a cluster address will 486 be delivered to one member of the group. Multicast addresses identify a 487 group of nodes, such that a packet sent to a multicast address is 488 delivered to all of the nodes in the group. 490 IPng supports addresses which are four times the number of bits as IPv4 491 addresses (128 vs. 32). This is 4 Billion times 4 Billion (2^^96) times 492 the size of the IPv4 address space (2^^32). This works out to be: 494 340,282,366,920,938,463,463,374,607,431,768,211,456 496 This is an extremely large address space. In a theoretical sense this 497 is approximately 665,570,793,348,866,943,898,599 addresses per square 498 meter of the surface of the planet Earth (assuming the earth surface is 499 511,263,971,197,990 square meters). 501 In more practical terms the assignment and routing of addresses requires 502 the creation of hierarchies which reduces the efficiency of the usage of 503 the address space. Christian Huitema performed an analysis in [EFFC] 504 which evaluated the efficiency of other addressing architectures 505 (including the French telephone system, USA telephone systems, current 506 internet using IPv4, and IEEE 802 nodes). He concluded that 128bit IPng 507 addresses could accommodate between 8x10^^17 to 2x10^^33 nodes assuming 508 efficiency in the same ranges as the other addressing architectures. 509 Even his most pessimistic estimate this would provide 1,564 for 510 addresses per square meter of the surface of the planet Earth. The 511 optimistic estimate would allow for 3,911,873,538,269,506,102 addresses 512 per square meter of the surface of the planet Earth. 514 The specific type of IPng address is indicated by the leading bits in 515 the address. The variable-length field comprising these leading bits is 516 called the Format Prefix (FP). The initial allocation of these prefixes 517 is as follows: 519 Allocation Prefix Fraction of 520 (binary) Address Space 521 ------------------------------- -------- ------------- 522 Reserved 0000 0000 1/256 523 Reserved 0000 0001 1/256 524 NSAP Allocation 0000 001 1/128 525 IPX Allocation 0000 010 1/128 526 Reserved 0000 011 1/128 527 Reserved 0000 100 1/128 528 Reserved 0000 101 1/128 529 Reserved 0000 110 1/128 530 Reserved 0000 111 1/128 531 Reserved 0001 1/16 532 Reserved 001 1/8 533 Provider-Based Unicast Address 010 1/8 534 Reserved 011 1/8 535 Reserved for Geographic Addresses 100 1/8 536 Reserved 101 1/8 537 Reserved 110 1/8 538 Reserved 1110 1/16 539 Reserved 1111 0 1/32 540 Reserved 1111 10 1/64 541 Reserved 1111 110 1/128 542 Local Use Addresses 1111 1110 1/256 543 Multicast Addresses 1111 1111 1/256 545 This allocation supports the direct allocation of provider addresses, 546 NSAP addresses, IPX addresses, local use addresses, and multicast 547 addresses. Space is reserved for geographic addresses. The remainder 548 of the address space is reserved for future use. This can be used for 549 expansion of existing use (e.g. additional provider addresses, IPX 550 addresses, etc.) or new uses (e.g. separate locators and EID). 552 Fifteen percent of the address space is initially allocated. The 553 remaining 85% is reserved for future use. 555 4.3.1 Unicast Addresses 557 There are several forms of unicast address assignment in IPv6. These 558 are global provider hierarchical unicast addresses, geographical 559 hierarchical addresses, NSAP hierarchical addresses, IPX hierarchical 560 addresses, local-use addresses, and IP-only host addresses. Additional 561 addresses types can be defined in the future. The assignment plan for 562 unicast addresses is described in [ALLO] and [ASSN]. 564 4.3.1.1 Provider Based Unicast Addresses 566 Provider based unicast addresses are used for global communication. 567 They are similar in function to IPv4 addresses under CIDR. Their format 568 is: 570 | 3 | n bits | m bits | p bits | 125-n-m-p | 571 +-----+--------------+-----------------+-----------+-----------+ 572 | 010 | PROVIDER ID | SUBSCRIBER ID | SUBNET ID | NODE ID | 573 +-----+--------------+-----------------+-----------+-----------+ 575 The first 3 bits identify the address as a provider-oriented address. A 576 provider ID is assigned to internet service providers, which then assign 577 portions of the address space to subscribers. This usage is similar to 578 assignment of IP addresses under CIDR. The SUBSCRIBER ID distinguishes 579 among multiple subscribers attached to the provider identified by the 580 PROVIDER ID. The SUBNET ID identifies a topologically connected group 581 of nodes within the subscriber network identified by the subscriber 582 prefix. The NODE ID identifies a single node among the group of nodes 583 identified by the subnet prefix. 585 4.3.1.2 Local-Use Address 587 A local-use address is a unicast address that has only local routability 588 scope (within the subnet or within a subscriber network), and may have 589 local or global uniqueness scope. They are intended for use inside of a 590 site for "plug and play" local communication and for bootstrapping up to 591 a single global addresses. Their format is: 593 | 8 | 594 | bits | n bits | m bits | p bits | 595 +--------+---------+---------------+------------------------------+ 596 |11111110| 0 | SUBNET ID | NODE ID | 597 +--------+---------+---------------+------------------------------+ 599 The NODE ID is an identifier which much be unique in the domain in which 600 it is being used. In most cases these will use a node's IEEE-802 48bit 601 address. The SUBNET ID identifies a specific subnet in a site. The 602 combination of the SUBNET ID and the NODE ID to form a local use address 603 allows a large private internet to be constructed without any other 604 address allocation. 606 Local-use addresses allow organizations that are not (yet) connected to 607 the global Internet to operate with out the need to request an address 608 prefix from the global Internet address space. Local-use addresses can 609 be used instead. If the organization later connects to the global 610 Internet, it can use it's SUBNET ID and NODE ID in combination with a 611 global prefix (e.g. PROVIDER ID + SUBSCRIBER ID) to create a global 612 address. 614 4.3.1.3 IPv4-Only Addresses 616 IPng unicast addresses are assigned to IPv4-only hosts as part of the 617 SIT scheme for transition from IPv4 to IPng [SIT]. Such addresses have 618 the following form: 620 | 80 bits | 16 | 32 bits | 621 +--------------------------------------+----+---------------------+ 622 |0000..............................0000|XXXX| IP ADDRESS | 623 +--------------------------------------+----+---------------------+ 625 The high-order 80bits of the address identify the address as an IPv4 626 address. Bits 80-95 distinguish between an IPv4 only node and an IPng 627 node. 629 4.3.2 Cluster Addresses 631 Cluster addresses are unicast addresses that are used to reach the 632 "nearest" one (according to unicast routings notion of nearest) of the 633 set of boundary routers of a cluster of nodes identified by a common 634 prefix in the IPng unicast routing hierarchy. These are used to 635 identify a set of nodes. The cluster address, when used as part of an 636 route sequence, permits a node to select which of several providers it 637 wants to carry its traffic. A cluster address can only be used as a 638 destination address. In this example there would be a cluster address 639 for each provider. This capability is sometimes called "source selected 640 policies". Cluster addresses have the general form: 642 | n bits | 128-n bits | 643 +---------------------------------+-------------------------------+ 644 | CLUSTER PREFIX |0000000000000000000000000000000| 645 +---------------------------------+-------------------------------+ 647 4.3.3 Multicast Addresses 649 A IPng multicast address is an identifier for a group of nodes. A node 650 may belong to any number of multicast groups. Multicast addresses have 651 the following format: 653 | 8 | 4 | 4 | 112 bits | 654 +------ -+----+----+---------------------------------------------+ 655 |11111111|FLGS|SCOP| GROUP ID | 656 +--------+----+----+---------------------------------------------+ 658 Where: 660 11111111 at the start of the address identifies the address as 661 being a multicast address. 663 +-+-+-+-+ 664 FLGS is a set of 4 flags: |0|0|0|T| 665 +-+-+-+-+ 667 The high-order 3 flags are reserved, and must be initialized to 0. 669 T = 0 indicates a permanently-assigned ("well-known") multicast 670 address, assigned by the global internet numbering authority. 672 T = 1 indicates a non-permanently-assigned ("transient") multicast 673 address. 675 SCOP is a 4-bit multicast scope value used to limit the scope of 676 the multicast group. The values are: 678 0 reserved 8 intra-organization scope 679 1 intra-node scope 9 (unassigned) 680 2 intra-link scope A (unassigned) 681 3 (unassigned) B intra-community scope 682 4 (unassigned) C (unassigned) 683 5 intra-site scope D (unassigned) 684 6 (unassigned) E global scope 685 7 (unassigned) F reserved 687 GROUP ID identifies the multicast group, either permanent or 688 transient, within the given scope. 690 4.4 IPng Routing 692 Routing in IPng is almost identical to IPv4 routing under CIDR except 693 that the addresses are 128-bit IPng addresses instead of 32-bit IPv4 694 addresses. With very straightforward extensions, all of IPv4's routing 695 algorithms (OSPF, RIP, IDRP, ISIS, etc.) can used to route IPng. 697 IPng also includes simple routing extensions which support powerful new 698 routing functionality. These capabilities include: 700 Provider Selection (based on policy, performance, cost, etc.) 701 Host Mobility (route to current location) 702 Auto-Readdressing (route to new address) 704 The new routing functionality is obtained by creating sequences of IPng 705 addresses using the IPng Routing option. The routing option is used by 706 a IPng source to list one or more intermediate nodes (or topological 707 clusters) to be "visited" on the way to a packet's destination. This 708 function is very similar in function to IPv4's Loose Source and Record 709 Route option. 711 In order to make address sequences a general function, IPng hosts are 712 required to reverse routes in a packet it receives containing address 713 sequences in order to return the packet to its originator. This 714 approach is taken to make IPng host implementations from the start 715 support the handling and reversal of source routes. This is the key for 716 allowing them to work with hosts which implement the new features such 717 as provider selection or extended addresses. 719 Three examples show how the address sequences can be used. In these 720 examples, address sequences are shown by a list of individual addresses 721 separated by commas. For example: 723 SRC, I1, I2, I3, DST 725 Where the first address is the source address, the last address is the 726 destination address, and the middle addresses are intermediate 727 addresses. 729 For these examples assume that two hosts, H1 and H2 wish to communicate. 730 Assume that H1 and H2's sites are both connected to providers P1 and P2. 731 A third wireless provider, PR, is connected to both providers P1 and P2. 733 ----- P1 ------ 734 / | \ 735 / | \ 736 H1 PR H2 737 \ | / 738 \ | / 739 ----- P2 ------ 741 The simplest case (no use of address sequences) is when H1 wants to send 742 a packet to H2 containing the addresses: 744 H1, H2 746 When H2 replied it would reverse the addresses and construct a packet 747 containing the addresses: 749 H2, H1 751 In this example either provider could be used, and H1 and H2 would not 752 be able to select which provider traffic would be sent to and received 753 from. 755 If H1 decides that it wants to enforce a policy that all communication 756 to/from H2 can only use provider P1, it would construct a packet 757 containing the address sequence: 759 H1, P1, H2 761 This ensures that when H2 replies to H1, it will reverse the route and 762 the reply it would also travel over P1. The addresses in H2's reply 763 would look like: 765 H2, P1, H1 767 If H1 became mobile and moved to provider PR, it could maintain (not 768 breaking any transport connections) communication with H2, by sending 769 packets that contain the address sequence: 771 H1, PR, P1, H2 773 This would ensure that when H2 replied it would enforce H1's policy of 774 exclusive use of provider P1 and send the packet to H1 new location on 775 provider PR. The reversed address sequence would be: 777 H2, P1, PR, H1 779 The address sequence facility of IPng can be used for provider 780 selection, mobility, and readdressing. It is a simple but powerful 781 capability. 783 4.5 IPng Quality-of-Service Capabilities 785 The Flow Label field in the IPng header may be used by a host to label 786 those packets for which it requests special handling by IPng routers, 787 such as non-default quality of service or "real-time" service. This 788 labeling is important in order to support applications which require 789 some degree of consistent throughput, delay, and/or jitter. The Flow 790 Label is a 28-bit field, internally structured into two subfields as 791 follows: 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 |TCLASS | FLOW ID | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 TCLASS 4-bit traffic class 799 FLOW ID 24-bit flow identifier 801 A flow is a sequence of packets sent from a particular source to a 802 particular (unicast or multicast) destination for which the source 803 desires special handling by the intervening routers. The nature of that 804 special handling might be conveyed to the routers by a control protocol, 805 such as a resource reservation protocol, or by information within the 806 flow's packets themselves, e.g., in a hop-by-hop option. 808 There may be multiple active flows from a source to a destination, as 809 well as traffic that is not associated with any flow. A flow is 810 identified by the combination of a Source Address and a non-zero FLOW 811 ID. Packets that do not belong to a flow carry a FLOW ID of zero. 813 A FLOW ID is assigned to a flow by the flow's source node. New FLOW IDs 814 must be chosen (pseudo-)randomly and uniformly from the range 1 to 815 FFFFFF hex. The purpose of the random allocation is to make any set of 816 bits within the FLOW ID suitable for use as a hash key by the routers, 817 for looking up the special-handling state associated with the flow. A 818 FLOW ID must not be re-used by a source for a new flow while any state 819 associated with the previous usage still exists in any router. 821 The TCLASS subfield provides a means separate from the FLOW ID for a 822 source to identify the desired delivery priority of its packets, 823 relative to other packets from the same source. The TCLASS values are 824 divided into two ranges: values 0 through 7 are used to label flow- 825 controlled packets, e.g., packets that belong to a TCP connection, and 826 values 8 through 15 are used to label non-flow-controlled packets, e.g., 827 "real-time" packets being sent without any flow-control feedback from 828 the receivers. 830 For flow-controlled traffic, the following TCLASS values are recommended 831 for particular application categories: 833 0 - uncharacterized traffic 834 1 - "filler" traffic (e.g., netnews) 835 2 - unattended data transfer (e.g., email) 836 3 - (reserved) 837 4 - attended bulk transfer (e.g., FTP, NFS) 838 5 - (reserved) 839 6 - interactive traffic (e.g., telnet, X) 840 7 - internet control traffic (e.g., routing protocols, SNMP) 842 For non-flow-controlled traffic, the lowest TCLASS value (8) should be 843 used for those packets that the sender is most willing to have discarded 844 under conditions of congestion (e.g., high-fidelity video traffic), and 845 the highest value (15) should be used for those packets that the sender 846 is least willing to have discarded (e.g., low-fidelity audio traffic). 847 There is no relative ordering implied between the flow-controlled 848 classes and the non-flow-controlled classes. 850 4.6 IPng Security 852 The current Internet has a number of security problems and lacks 853 effective privacy and authentication mechanisms below the application 854 layer. IPng remedies these shortcomings by having two integrated 855 options that provide security services. These two options may be used 856 singly or together to provide differing levels of security to different 857 users. This is very important because different user communities have 858 different security needs. 860 The first mechanism, called the "IPng Authentication Header", is an 861 option which provides authentication and integrity (without 862 confidentiality) to IPng datagrams. While the option is algorithm- 863 independent and will support many different authentication techniques, 864 the use of keyed MD5 is proposed to help ensure interoperability within 865 the worldwide Internet. This can be used to eliminate a significant 866 class of network attacks, including host masquerading attacks. The use 867 of the IPng Authentication Header is particularly important when source 868 routing is used with IPng because of the known risks in IP source 869 routing. Its placement at the internet layer can help provide host 870 origin authentication to those upper layer protocols and services that 871 currently lack meaningful protections. This mechanism should be 872 exportable by vendors in the United States and other countries with 873 similar export restrictions because it only provides authentication and 874 integrity, and specifically does not provide confidentiality. The 875 exportability of the IPng Authentication Header encourages its 876 widespread implementation and use. 878 The second security option provided with IPng is the "IPng Encapsulating 879 Security Header". This mechanism provides integrity and confidentiality 880 to IPng datagrams. It is simpler than some similar security protocols 881 (e.g. SP3D, ISO NLSP) but remains flexible and algorithm-independent. 882 To achieve interoperability within the global Internet, the use of DES 883 CBC is being used as the standard algorithm for use with the IPng 884 Encapsulating Security Header. 886 5. IPng Transition Mechanisms 888 The key transition objective is to allow IPv6 and IPv4 hosts to 889 interoperate. A second objective is to allow IPv6 hosts and routers to 890 be deployed in the Internet in a highly diffuse and incremental fashion, 891 with few interdependencies. A third objective is that the transition 892 should be as easy as possible for end-users, system administrators, and 893 network operators to understand and carry out. 895 The Simple IP version Six Transition (SIT) is a set of protocol 896 mechanisms implemented in hosts and routers, along with some operational 897 guidelines for addressing and deployment, designed to make transitioning 898 the Internet to IPv6 work with as little disruption as possible [SIT]. 900 SIT provides a number of features, including: 902 - Incremental upgrade and deployment. Individual IPv4 hosts and 903 routers may be upgraded to IPv6 one at a time without requiring any 904 other hosts or routers to be upgraded at the same time. New IPv6 905 hosts and routers can be installed one by one. 907 - Minimal upgrade dependencies. The only prerequisite to upgrading 908 hosts to IPv6 is that the DNS server must first be upgraded to 909 handle IPv6 address records. There are no pre-requisites to 910 upgrading routers. 912 - Easy Addressing. When existing installed IPv4 hosts or routers are 913 upgraded to IPv6, they may continue to use their existing address. 914 They do not need to be assigned new addresses. Administrators do 915 not need to draft new addressing plans. 917 - Low start-up costs. Little or no preparation work is needed in 918 order to upgrade existing IPv4 systems to IPv6, or to deploy new 919 IPv6 systems. 921 The mechanisms employed by SIT include: 923 - An IPv6 addressing structure that embeds IPv4 addresses within IPv6 924 addresses, and encodes other information used by the transition 925 mechanisms. 927 - A model of deployment where all hosts and routers upgraded to IPv6 928 in the early transition phase are "dual" capable (i.e. implement 929 complete IPv4 and IPv6 protocol stacks). 931 - The technique of encapsulating IPv6 packets within IPv4 headers to 932 carry them over segments of the end-to-end path where the routers 933 have not yet been upgraded to IPv6. 935 - The header translation technique to allow the eventual introduction 936 of routing topologies that route only IPv6 traffic, and the 937 deployment of hosts that support only IPv6. Use of this technique 938 is optional, and would be used in the later phase of transition if 939 it is used at all. 941 SIT ensures that IPv6 hosts can interoperate with IPv4 hosts anywhere in 942 the Internet up until the time when IPv4 addresses run out, and allows 943 IPv6 and IPv4 hosts within a limited scope to interoperate indefinitely 944 after that. This feature protects the huge investment users have made 945 in IPv4. SIT ensures that IPv6 does not render IPv4 obsolete. Hosts 946 that need only a limited connectivity range (e.g. printers) need never 947 be upgraded to IPv6. 949 The incremental upgrade features of SIT allow the host and router 950 vendors to integrate IPv6 into their product lines at their own pace, 951 and allows the end users and network operators to deploy IPng on their 952 own schedules. 954 6. Why IPng? 956 There are a number of reasons why IPng is appropriate for the next 957 generation of the Internet Protocol. It solves the Internet scaling 958 problem, provides a flexible transition mechanism for the current 959 Internet, and was designed to meet the needs of new markets such as 960 nomadic personal computing devices, networked entertainment, and device 961 control. It does this in a evolutionary way which reduces the risk of 962 architectural problems. 964 Ease of transition is a key point in the design of IPng. It is not 965 something was was added in at the end. IPng is designed to interoperate 966 with IPv4. Specific mechanisms (embedded IPv4 addresses, pseudo- 967 checksum rules etc.) were built into IPng to support transition and 968 compatability with IPv4. It was designed to permit a gradual and 969 piecemeal deployment with a minimum of dependencies. 971 IPng supports large hierarchical addresses which will allow the Internet 972 to continue to grow and provide new routing capabilities not built into 973 IPv4. It has cluster addresses which can be used for policy route 974 selection and has scoped multicast addresses which provide improved 975 scaleability over IPv4 multicast. It also has local use addresses which 976 provide the ability for "plug and play" installation. 978 The address structure of IPng was also designed to support carrying the 979 addresses of other internet protocol suites. Space was allocated in the 980 addressing plan for IPX and NSAP addresses. This was done to facilitate 981 migration of these internet protocols to IPng. 983 IPng is designed to have performance better than IPv4 and still work 984 well in low bandwidth applications like wireless. Its headers are less 985 expensive to process than IPv4 and its 128-bit addresses are chosen to 986 be well matched to the new generation of 64bit processors. Its compact 987 header minimizes bandwidth overhead which makes it appropriate for 988 wireless use. 990 IPng provides a platform for new Internet functionality. This includes 991 support for real-time flows, provider selection, host mobility, end-to- 992 end security, auto-configuration, and auto-reconfiguration. 994 In summary, IPng is a new version of IP. It can be installed as a 995 normal software upgrade in internet devices. It is interoperable with 996 the current IPv4. Its deployment strategy was designed to not have any 997 "flag" days. IPng is designed to run well on high performance networks 998 (e.g. ATM) and at the same time is still efficient for low bandwidth 999 networks (e.g. wireless). In addition, it provides a platform for new 1000 internet functionality that will be required in the near future. 1002 7. Where to Get Additional Information 1004 The documentation listed in the reference sections can be found in one 1005 of the IETF internet draft directories or in the archive site for the 1006 IPng working group. This is located at: 1008 ftp.parc.xerox.com in the /pub/ipng directory. 1010 In addition other material relating to IPng (such as postscript versions 1011 of presentations on IPng) can also be found in the IPng working group 1012 archive. 1014 To join the IPng working group, send an electronic mail message to: 1016 majordomo@sunroof.eng.sun.com 1018 with 1020 subscribe ipng 1022 in the body portion of the message. 1024 An archive of mail sent to this mailing list can be found in the IETF 1025 directories at cnri.reston.va.us. 1027 8. Information about the Author 1029 Robert M. Hinden TEL: (415) 336-2082 1030 Manager, Internet Engineering FAX: (415) 336-6016 1031 Sun Microsystems, Inc. EMAIL: hinden@eng.sun.com 1032 MS MTV5-44 1033 2550 Garcia Ave. 1034 Mt. View, CA 94303 1035 USA 1036 8. References 1038 [ADDR] R. Hinden, Editor, "IP Next Generation Addressing Architecture", 1039 Internet Draft, draft-hinden-ipng-addr-00.txt, October 1994. 1041 [ASSN] T.Li, P. Lothberg, Y. Rekhter, "IPv6 Provider Unicast Address 1042 Assignment", Internet Draft, In Preparation. 1044 [ALLO] Y. Rekhter, T. Li, "An Architecture for IPv6 Unicast Address 1045 Allocation", Internet Draft, draft-rekhter-ipng-arch-IPv6-addr- 1046 01.txt, October 1994. 1048 [AUTH] R. Atkinson, "IPv6 Authentication Header", Internet Draft, 1049 draft-ietf-sipp-ap-04.txt, August 1994. 1051 [AUTO] D. Katz, S. Thomson, "Automatic Host Address Assignment in 1052 IPv6", Internet Draft, In Perpetration. 1054 [CIDR] V. Fuller, et al, "Supernetting: an Address Assignment and 1055 Aggregation Strategy", RFC 1338. 1057 [COMP] W. Simpson, "IPv6 Header Compression", Internet Draft, draft- 1058 simpson-ipv6-hc-00.txt, September 1994. 1060 [DISC] W. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet 1061 Draft, draft-simpson-ipv6-discov-process-00.txt, October 1994. 1063 [DIS2] W. Simpson, "IPv6 Neighbor Discovery -- ICMP Message Formats", 1064 Internet Draft, draft-simpson-ipv6-discov-formats-00.txt, 1065 September 1994. 1067 [DHCP] S. Thomson, "IPng Extensions to BOOTP/DHCP", Internet Draft, In 1068 Preparation. 1070 [DNS] S. Thomson, C. Huitema, "DNS Extensions to support IP version 1071 6", Internet Draft, , October 1072 1994. 1074 [EFFC] C. Huitema, "The H Ratio for Address Assignment Efficiency" 1075 Internet Draft, In Preparation. 1077 [ICMP] S. Deering, A. Conta, "ICMP and IGMP for the Internet Protocol 1078 Version 6 (IPv6)", Internet Draft, In Preparation, October 1994. 1080 [IPNG] R. Hinden, Editor, "Internet Protocol, Version 6 (IPv6) 1081 Specification", Internet Draft, draft-ietf-ipng-ipv6-spec- 1082 01.txt, October 1994. 1084 [IPV4] J. Postel, "Internet Protocol", RFC-791, September, 1981. 1086 [RECM] S. Bradner, A. Mankin, "The Recommendation for the IP Next 1087 Generation Protocol", Internet Draft, September 1994. 1090 [SARC] R. Atkinson, "IPv6 Security Architecture" Internet Draft, 1091 draft-ietf-sipp-sa-03.txt, September 1994. 1093 [SECR] R. Atkinson, "IPng Encapsulating Security Payload (ESP)", 1094 Internet Draft, In Perpetration. 1096 [SIPP] S. Deering, "Simple Internet Protocol Plus (SIPP) Specification 1097 (128-bit address version)", Internet Draft, draft-ietf-sipp- 1098 spec-01.txt, July 1994. 1100 [SIT] R. Gilligan, "Simple IPv6 Transition (SIT) Overview, Internet 1101 Draft, In Perpetration.