idnits 2.17.1 draft-iab-case-for-ipv6-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1958 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2463 (ref. '10') (Obsoleted by RFC 4443) ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-dns-lookups (ref. '12') ** Obsolete normative reference: RFC 2460 (ref. '14') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2535 (ref. '17') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2117 (ref. '18') (Obsoleted by RFC 2362) ** Obsolete normative reference: RFC 1519 (ref. '19') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 ** Obsolete normative reference: RFC 2402 (ref. '24') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '25') (Obsoleted by RFC 4303, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '26') ** Obsolete normative reference: RFC 1981 (ref. '30') (Obsoleted by RFC 8201) ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '31') ** Obsolete normative reference: RFC 2461 (ref. '32') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. '33' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. '34') -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '35' ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '38') ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '39') ** Downref: Normative reference to an Informational RFC: RFC 2149 (ref. '40') ** Obsolete normative reference: RFC 1886 (ref. '41') (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 2462 (ref. '42') (Obsoleted by RFC 4862) ** Downref: Normative reference to an Historic RFC: RFC 1745 (ref. '43') ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '44') Summary: 25 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Architecture Board Steve King, Bay Networks 2 INTERNET DRAFT Ruth Fax, Bay Networks 3 Dimitry Haskin, Bay Networks 4 Wenken Ling, Bay Networks 5 Tom Meehan, Bay Networks 6 Robert Fink, LBNL 7 25 June 2000 Charles E. Perkins, Nokia Research Center 9 The Case for IPv6 10 draft-iab-case-for-ipv6-06.txt 12 Status of This Memo 14 This document is a submission by the Internet Architecture Board 15 (IAB) of the Internet Engineering Task Force (IETF). Comments should 16 be submitted to the iab@isi.edu mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document outlines the business and technical case for IPv6. It 39 is intended to acquaint both the existing IPv4 community with IPv6, 40 to encourage its support for change, and to attract potential future 41 users of Internet technology. 43 Contents 45 Status of This Memo i 47 Introduction 2 49 1. The Business Case for IPv6 3 50 1.1. IPv6: Standardization and Productization Status . . . . 3 51 1.2. IPv6 Design Goals . . . . . . . . . . . . . . . . . . . . 5 52 1.2.1. Addressing and Routing . . . . . . . . . . . . . 5 53 1.2.2. Eliminating Special Cases . . . . . . . . . . . . 6 54 1.2.3. Minimizing Administrative Workload . . . . . . . 8 55 1.2.4. Security . . . . . . . . . . . . . . . . . . . . 9 56 1.2.5. Mobility . . . . . . . . . . . . . . . . . . . . 10 57 1.3. The IPv6 solution . . . . . . . . . . . . . . . . . . . . 11 58 1.3.1. Address Autoconfiguration . . . . . . . . . . . . 11 59 1.3.2. IPv6 Header Format . . . . . . . . . . . . . . . 12 60 1.3.3. Multicast . . . . . . . . . . . . . . . . . . . . 13 61 1.3.4. Anycast . . . . . . . . . . . . . . . . . . . . . 14 62 1.3.5. Quality of Service . . . . . . . . . . . . . . . 16 63 1.3.6. The Transition to IPv6 . . . . . . . . . . . . . 16 64 1.3.7. IPv6 DNS . . . . . . . . . . . . . . . . . . . . 17 65 1.3.8. Application Modification for IPv6 . . . . . . . . 18 66 1.3.9. Routing in IPv6/IPv4 Networks . . . . . . . . . . 18 67 1.3.10. The Dual-Stack Transition Method . . . . . . . . 20 68 1.3.11. Automatic Tunneling . . . . . . . . . . . . . . . 20 70 2. The Technical Case for IPv6 21 71 2.1. IPv6 Headers vs. IPv4 Headers . . . . . . . . . . . . . . 21 72 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 23 73 2.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 24 74 2.4. Destination Options Headers . . . . . . . . . . . . . . . 24 75 2.5. Routing Headers . . . . . . . . . . . . . . . . . . . . . 25 76 2.6. Fragmentation Header . . . . . . . . . . . . . . . . . . 25 77 2.7. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 27 78 2.8. IPv6 Authentication Header . . . . . . . . . . . . . . . 27 79 2.9. IPv6 Encryption Header . . . . . . . . . . . . . . . . . 29 80 2.10. The IPv6 Address Architecture . . . . . . . . . . . . . . 31 81 2.11. The IPv6 Address Hierarchy . . . . . . . . . . . . . . . 32 82 2.12. Host Address Autoconfiguration . . . . . . . . . . . . . 35 83 2.13. Other Protocols and Services . . . . . . . . . . . . . . 39 85 3. Transition Scenarios 40 86 3.1. First Scenario: No Need to NAT . . . . . . . . . . . . . 40 87 3.2. Second Scenario: IPv6 from the Edges to the Core . . . . 42 88 3.3. Other mechanisms . . . . . . . . . . . . . . . . . . . . 43 90 4. Security Considerations 44 92 5. Acknowledgments 44 94 A. Myths 45 96 Introduction 98 This document provides an overview of the benefits of the IETF's 99 next-generation IP protocol known as IP Version 6 (IPv6). The core 100 protocols of IPv6 are stable and have been standardized by the 101 IETF; they are unlikely to change significantly at this point. The 102 intended audience for this document includes enterprise network 103 administrators and decision makers, router vendors, host vendors, 104 Internet Service Providers (ISPs) managers, and protocol engineers 105 who are as yet unfamiliar with the basic aspects of IPv6. This 106 document was revised based on an existing original, at the request of 107 the IAB. 109 The Internet Protocol (IP) has its roots in early research networks 110 of the 1970s, but within the past decade has become the leading 111 network-layer protocol. This means that IP is a primary vehicle for 112 a vast array of client/server and peer-to-peer communications, and 113 the current scale of deployment is straining many aspects of its 114 twenty-year old design [7]. 116 The Internet Engineering Task Force (IETF) has produced 117 specifications (see section 1.1) that define the next-generation 118 IP protocol known as "IPng," or "IPv6." IPv6 is both a near-term 119 and long-range concern for network owners and service providers. 120 IPv6 products have already come to market; on the other hand, IPv6 121 development work will likely continue for years to come. Though it 122 is based on much-needed enhancements to IPv4 standards, IPv6 should 123 be viewed as a new protocol that will provide a firmer base for the 124 continued growth of today's internetworks. 126 Because it is intended to replace IP (hereafter called IPv4) IPv6 127 is of considerable importance to businesses, consumers, and network 128 access providers of all sizes. IPv6 is designed to improve upon 129 IPv4's scalability, security, ease-of-configuration, and network 130 management; these issues are central to the competitiveness and 131 performance of all types of network-dependent businesses. IPv4 can 132 be modified to perform some of these functions, but the expectation 133 within the IAB is that the results are likely to be far less useful 134 than what could be obtained by widespread deployment of IPv6. On 135 the other hand IPv6 aims to preserve existing investment as much as 136 possible. End users, industry executives, network administrators, 137 protocol engineers, and many others will benefit from understanding 138 the ways that IPv6 will affect future internetworking and distributed 139 computing applications. 141 By early 1998 a worldwide IPv6 testing and pre-production deployment 142 network, called the 6BONE, had already reached approximately 143 400 sites and networks in 40 countries. There are over 50 IPv6 144 implementations completed or underway worldwide, and over 25 in test 145 or production use on the 6BONE. The 6BONE has been built by an active 146 population of protocol inventors, designers and programmers. They 147 have worked together to solve the questions and problems that might 148 be expected to arise during such a huge project. Their experience 149 has served to validate the expectations of the protocol designers. 151 This document presents IPv6 issues in several parts: 153 - The Business Case for IPv6, giving a high-level view of business 154 issues, protocol basics, and current status, and 155 - The Technical Case for IPv6, which describes more of the 156 functional and technical aspects of IPv6. 157 - Transition Scenarios, which discusses mechanisms that have been 158 designed to ease the transition from IPv4 to IPv6. 160 This document has been revised from an existing document originally 161 written by employees of Bay Networks (see Acknowledgements, 162 section 5). Since the original document was written, many things 163 have changed surrounding the standardization, implementation, and 164 deployment of IPv6. Recent developments involving IPv6 in telephony 165 standards illustrate the power and the essential need for IPv6's 166 features. Now that IPv6 is specified to be a required, mandatory 167 to implement network layer protocol by 3GPP, 3GPP2 and MWIF, we 168 can expect to see hundreds of millions, or more likely billions, 169 of IPv6-capable devices populating the Internet within 5 years. 170 This eventuality has been brought about because telephone equipment 171 manufacturers have recognized the advantages of the IPv6 architecture 172 as detailed in this document. 174 1. The Business Case for IPv6 176 Given the remarkable growth of the Internet, and business opportunity 177 represented by the Internet, IPv6 is of major interest to business 178 interests, enterprise internetworks, and the global Internet. IPv6 179 presents all networking interests with an opportunity for global 180 improvements, which is now receiving the collective action that is 181 needed to realize the benefits. 183 1.1. IPv6: Standardization and Productization Status 185 The base protocols of IPv6 have been approved as Draft Standards, 186 so that it is known to be highly stable and appropriate for 187 productization. A large number of end-user organizations, standards 188 groups, and network vendors have been working together on the 189 specification and testing of early IPv6 implementations. A number 190 of IETF working groups have produced IPv6 specifications that are 191 finished or well underway. Current Draft Standards at the time of 192 this writing include: 194 RFC 1981 Path MTU Discovery for IP version 6 195 RFC 2374 An IPv6 Aggregatable Global Unicast Address Format 196 RFC 2460 Internet Protocol, Version 6 (IPv6) Specification 197 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) 198 RFC 2462 IPv6 Stateless Address Autoconfiguration 199 RFC 2463 Internet Control Message Protocol (ICMPv6) for the 200 Internet Protocol Version 6 (IPv6) Specification 202 Current Proposed Standards include: 204 RFC 1886 DNS Extensions to support IP version 6 205 RFC 1887 An Architecture for IPv6 Unicast Address Allocation 206 RFC 2080 RIPng for IPv6 207 RFC 2373 IP Version 6 Addressing Architecture 208 RFC 2452 IP Version 6 Management Information Base for the 209 Transmission Control Protocol 210 RFC 2454 IP Version 6 Management Information Base for the User 211 Datagram Protocol 212 RFC 2464 Transmission of IPv6 Packets over Ethernet Networks 213 RFC 2465 Management Information Base for IP Version 6: Textual 214 Conventions and General Group 215 RFC 2466 Management Information Base for IP Version 6: ICMPv6 216 Group 217 RFC 2467 Transmission of IPv6 Packets over FDDI Networks 218 RFC 2470 Transmission of IPv6 Packets over Token Ring Networks 219 RFC 2472 IP Version 6 over PPP 220 RFC 2473 Generic Packet Tunneling in IPv6 Specification 221 RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks 222 RFC 2492 IPv6 over ATM Networks 223 RFC 2507 IP Header Compression 224 RFC 2526 Reserved IPv6 Subnet Anycast Addresses 225 RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit 226 Tunnels 227 RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 228 Inter-Domain Routing 229 RFC 2590 Transmission of IPv6 Packets over Frame Relay 230 RFC 2675 IPv6 Jumbograms 231 RFC 2710 Multicast Listener Discovery (MLD) for IPv6 232 RFC 2711 IPv6 Router Alert Option 234 There are too many related RFCs and Internet Drafts to list them all 235 here, but among them are included the following: 237 RFC 1888 OSI NSAPs and IPv6 238 RFC 2292 Advanced Sockets API for IPv6 239 RFC 2375 IPv6 Multicast Address Assignments 240 RFC 2450 Proposed TLA and NLA Assignment Rules 241 RFC 2471 IPv6 Testing Address Allocation 242 RFC 2553 Basic Socket Interface Extensions for IPv6 243 RFC 2740 OSPF for IPv6 [9] 244 RFC 29xx Router Renumbering for IPv6 [11] 245 work in progress Mobility Support in IPv6 [23] 246 work in progress DHCP for IP Version 6 [5, 35] 247 work in progress Site prefixes in Neighbor Discovery [33] 248 work in progress Routing of Scoped Addresses in the Internet 249 Protocol Version 6 (IPv6) 251 To RFC-editor: please replace "RFC 29xx" with the 252 appropriate value 254 Standards work on IPv6 and related components is far enough along 255 that numerous vendors have developed either prototype implementations 256 or products. For current information on implementations and vendor 257 activities, see the following URLS: 259 - http://playground.sun.com/pub/ipng/html/ipng-main.html 261 - http://www.ipv6forum.com 263 1.2. IPv6 Design Goals 265 IPv6 has been designed to enable high-performance, scalable 266 internetworks that should operate as needed for decades. Part of the 267 design process involved correcting the inadequacies of IPv4. IPv6 268 offers a number of enhanced features, such as a larger address space 269 and improved packet formats. Scalable networking requires careful 270 utilization of human resources as well as network resources; so, a 271 great deal of attention has been given to creating autoconfiguration 272 protocols for IPv6, minimizing the need for human intervention 273 when assigning IP addresses and relevant network parameters such 274 as link MTU. Other benefits relate to the fresh start that IPv6 275 gives to those who build and administer networks. For instance, 276 a well-structured, efficient and adaptable routing hierarchy 277 will be possible. The following sections give an overview of the 278 improvements that IPv6 brings to enterprise networking and the global 279 Internet. 281 1.2.1. Addressing and Routing 283 IPv6 helps to solve a number of problems that currently exist within 284 and between enterprises. On the global scale, IPv6 will allow 285 Internet backbone designers to create a flexible and expandable 286 global routing hierarchy. The Internet backbone, where major 287 enterprises and Internet Service Provider (ISP) networks come 288 together, depends upon the maintenance of a hierarchical address 289 system, similar to that of the national and international telephone 290 systems. Large central-office phone switches, for instance, only 291 need a three-digit national area code prefix to route a long-distance 292 telephone call toward the correct local exchange. The current 293 IPv4 system also uses an address hierarchy to sort traffic towards 294 networks attached to the Internet backbone. 296 Without an address hierarchy, backbone routers would be forced to 297 store route table information on the reachability of every network 298 in the world. Given the current number of IP subnets in the world 299 and the growth of the Internet, it is not feasible to manage route 300 tables and updates for so many routes. With a hierarchy, backbone 301 routers can use IP address prefixes to determine how traffic should 302 be routed through the backbone. In recent years, IPv4 has begun to 303 use a technique called Classless InterDomain Routing (CIDR) [38, 19], 304 which uses bit masks to allocate a variable portion of the 32-bit 305 IPv4 address to a network, subnet, or host. CIDR permits "route 306 aggregation" at various levels of the Internet hierarchy, whereby 307 backbone routers can store a single route table entry that provides 308 reachability to many lower- level networks. 310 But CIDR does not guarantee an efficient and scalable hierarchy. 311 In order to avoid maintaining a separate entry for each route 312 individually, it is important for routes at lower levels of the 313 routing hierarchy, that naturally have longer prefixes, to be 314 collected together (or "summarized", or "aggregated") into fewer and 315 less specific routes at higher levels of the routing hierarchy. 317 Legacy IPv4 address assignments that originated before CIDR and 318 the current access provider hierarchy often do not facilitate 319 summarization. The lack of uniformity of the current hierarchical 320 system, coupled with the difficulty in obtaining IPv4 addresses, 321 makes Internet addressing and routing quite complicated. These 322 issues affect high-level service providers and consequently 323 individual end users in all types of businesses. Finally, 324 renumbering IPv4 sites when changing from one ISP to another, 325 in order to maintain and improve address/route aggregation, is 326 significantly more expensive and difficult compared with IPv6's site 327 renumbering capabilities (see section 1.2.3). 329 1.2.2. Eliminating Special Cases 331 Many of the same problems that exist today in the Internet backbone 332 are also being felt at the level of the enterprise and the individual 333 business user. When an enterprise can't summarize its routes 334 effectively, it puts a larger load on the backbone route tables. 336 If an enterprise can't present globally unique addresses to the 337 Internet, it may be forced to deploy private, isolated address space 338 that isn't visible to the Internet. 340 Users in private address spaces with non-unique addresses typically 341 require gateways, and possibly Network Address Translators 342 (NATs) [39], to manage their connectivity to the outside world. In 343 such situations, some services are simply not available. A NAT 344 is meant to allow an enterprise to have whatever internal address 345 structure it desires, without concern for integrating internal 346 addresses with the global Internet. This is seen as particularly 347 convenient in the existing IPv4 world, with its more cumbersome 348 address space management. The NAT device sits on the border 349 between the enterprise and the Internet, converting private internal 350 addresses to a smaller pool of globally unique addresses that are 351 passed to the backbone and vice versa (see Figure 1). 353 | 354 | 355 Private address space | Unique global addresses 356 | 357 | 358 --------------- | 359 / \ +-----+ +----------+ 360 | Enterprise | | | | | 361 | |----| NAT |-----| Internet | 362 | Network | | | | | 363 \ / +-----+ +----------+ 364 --------------- | 365 | 366 | 367 | 369 Figure 1: Network Address Translator (NAT) 371 NAT may be appropriate in some organizations, particularly if 372 full connectivity with the outside world is not desired. But for 373 enterprises that require robust interaction with the Internet, NAT 374 devices often get in the way. The NAT technique of substituting 375 address fields in each and every packet that leaves and enters the 376 enterprise is very demanding, and presents a bottleneck between 377 the enterprise and the Internet. A NAT may keep up with address 378 conversion in a small network, but as the enterprise's Internet 379 access increases, the NAT's performance must increase in parallel. 380 The bottleneck effect is exacerbated by the difficulty of integrating 381 and synchronizing multiple NAT devices within a single enterprise. 383 Enterprises with NAT are less likely to achieve the reliable 384 high-performance Internet connectivity that is common today with 385 multiple routers attached to an ISP backbone in an arbitrary mesh 386 fashion. Furthermore, use of NAT devices takes away the additional 387 element of reliability afforded by the possibility for asymmetric 388 routing, since NAT devices require control of traffic directions both 389 to and from internally addressed network nodes. 391 NAT translators also run into trouble when applications embed IP 392 addresses in the packet payload, above the network layer. This 393 is the case for a number of applications, including certain File 394 Transfer Protocol (FTP) programs, Mobile IP, and the Windows Internet 395 Name Service (WINS) registration process of Windows 95 and Windows 396 NT. Unless a NAT parses every packet all the way to the application 397 level, it is likely to fail to translate some embedded addresses, 398 which will lead to application failures. NAT can also break Domain 399 Name Servers, because they work above the network layer. NATs 400 prevent the use of some types of IP-level security between the 401 endpoints of a transaction. Today, NAT devices are helpful in 402 certain limited scenarios for smaller enterprises, but are considered 403 by many to be generally disadvantageous for the long-term health of 404 the Internet. See [20] for a fuller discussion about the effects of 405 NAT use on the Internet. 407 1.2.3. Minimizing Administrative Workload 409 A major component of today's network administration involves the 410 assignment of networking parameters to computers and other network 411 nodes, that are needed before they can begin any sort of network 412 operation. Information such as an IP address, DNS server, default 413 router, and other configuration details have to be installed at 414 each network node. In many cases, this is still done by manual 415 configuration, either by the network administration, or worse yet by 416 the users themselves. Recent efforts to shift this administrative 417 load onto departmental servers have focussed on deployment of the 418 Dynamic Host Configuration Protocol (DHCP) [16, 1], but this comes 419 along with its own administrative difficulties. 421 IPv4's limitations also aggravate the occasional need in many 422 organizations to renumber network devices -- i.e., assign new IP 423 addresses to them. When an enterprise changes ISPs, it may have 424 to either renumber all addresses to match the new ISP-assigned 425 prefix, or implement Network Address Translation devices (NATs). 426 Renumbering may be indicated when a corporation undergoes a merger 427 or an acquisition with consequent network consolidation. Since 428 routing prefixes are assigned to reflect the routing topology of 429 the enterprise networks and the number of nodes attached to the 430 particular network links, there are two ways that the choice of 431 routing prefixes can become inconvenient or incorrect: 433 1. The routing prefix can become too long for the administration to 434 be able to increase the number of nodes that can be attached to 435 the particular link, and 437 2. The ways that the network links are connected together, or are 438 connected to the outside world, can change. 440 Either of these occurrence would indicate the need to renumber one or 441 more enterprise networks. It would be quite profitable to be able to 442 renumber enterprise networks without requiring expensive downtime for 443 the networks and or the nodes on the network. 445 Address shortages and routing hierarchy problems threaten the network 446 operations of larger enterprises, but they also affect small sites 447 -- even the home worker who dials in to the office via the Internet. 448 Smaller networks can be completely dropped from Internet backbone 449 route tables if they do not adapt to the address hierarchy, while 450 larger networks may refuse to renumber and cause a larger routing 451 problem for the backbone providers of the Internet. With today's 452 IPv4 address registries, ISPs with individual dial-in clients 453 cannot allocate IP numbers as freely as they wish. Consequently, 454 many dial-in users must use an address allocated from a pool on a 455 temporary basis. In other cases, small dial-in sites are forced to 456 share a single IP address among multiple end systems. 458 A unique IP address sets the stage for users to gain direct 459 connectivity to other users on the Internet, as determined by local 460 policy. It also simplifies a wide range of productive interactive 461 applications, of which telecommuting and remote diagnostics are only 462 two examples. Today's hierarchy of limited and poorly allocated IPv4 463 addresses has already caused problems, and will continue to do so 464 as more and more devices of varying capabilities are added to the 465 Internet. 467 1.2.4. Security 469 Encryption, authentication, and data integrity safeguards are needed 470 for enterprise internetworking and virtual private networks (VPNs). 471 For these purposes, IPv6 offers security header extensions. 473 The IPv6 authentication extension header allows a receiver to 474 determine with a high degree of certainty whether or not a packet 475 originated from the host indicated in its source address. This 476 prevents malicious users from configuring an IP host to impersonate 477 another, to gain access to secure resources. Such source-address 478 masquerading (spoofing) is among the techniques that could be used 479 to obtain valuable financial and corporate data, or could give 480 adversaries of the enterprise control of servers for malicious 481 purposes. Spoofing might fool a server into granting access to 482 valuable data, passwords, or network control utilities. IP spoofing 483 is known to be one of the most common forms of denial-of-service 484 attack; with IPv4 it is typically impossible for a server to 485 determine whether packets are being received from the legitimate 486 end node. Some enterprises have responded by installing firewalls, 487 but these devices introduce a number of new problems, including 488 performance bottlenecks, restrictive network policies, and limited 489 connectivity to the Internet or even between divisions of the same 490 company. 492 IPv6 uses a standard method to determine the authenticity of packets 493 received at the network layer, ensuring that network products from 494 different vendors can use interoperable authentication services. 495 IPv6 implementations are required to support the MD5 [26] and 496 SHA-1 [27] algorithms for authentication and integrity checking to 497 insure that any two IPv6 nodes can interoperate securely. Since the 498 specification is algorithm-independent, other techniques may be used 499 as well. 501 Along with packet spoofing, another major hole in Internet security 502 is the widespread deployment of traffic analyzers and network 503 "sniffers" which can surreptitiously eavesdrop on network traffic. 504 These generally helpful diagnostic devices can be misused by those 505 seeking access to credit card and bank account numbers, passwords, 506 trade secrets, and other valuable data. In IPv6 privacy (data 507 confidentiality) is provided by a standard header extension for 508 end-to-end encryption at the network layer. IPv6 encryption headers 509 indicate which encryption keys to use, and carry other handshaking 510 information. IPv4 network-layer extensions for this have been 511 defined and are compatible with those for IPv6, but are not yet in 512 wide use. 514 Both IPv6 security headers can be used directly between hosts 515 or in conjunction with a specialized security gateway that adds 516 an additional level of security with its own packet signing and 517 encryption methods. 519 1.2.5. Mobility 521 IPv4 has difficulties managing mobile computers, for several reasons: 523 - A mobile computer needs to make use of a forwarding address at 524 each new point of attachment to the Internet, and it's not always 525 so easy to get such an address with IPv4 527 - Informing any agent in the routing infrastructure about 528 the mobile node's new location requires good authentication 529 facilities which are not commonly deployed in IPv4 nodes. 531 - In IPv4, it may be difficult for mobile nodes to determine 532 whether or not they are attached to the same network. 534 - It is unlikely in IPv4 that mobile nodes would be able to inform 535 their communication partners about any change in location. 537 Each of these problems is solved in a natural way by using features 538 in IPv6. The benefits for mobile computing are apparent in quite a 539 number of aspects of the IPv6 protocol design, and go beyond merely 540 providing dial-up support for road warriors. The improvements 541 in option processing for destination options, autoconfiguration, 542 routing headers, encapsulation, security, and anycast addresses all 543 contribute to the natural design of mobility for IPv6 [23]. 545 1.3. The IPv6 solution 547 IPv6, with its immensely larger address space, defines a multi-level 548 hierarchical global routing architecture. Using CIDR-style 549 prefixes [38], the IPv6 address space can be allocated in a way that 550 facilitates route summarization, and controls expansion of route 551 tables in backbone routers. The vastly greater availability of IPv6 552 addresses eliminates the need for private address spaces. ISPs 553 will have enough addresses to allocate to smaller businesses and 554 dial-in users that need globally unique addresses to fully exploit 555 the Internet. Using an example from crowded telephone networks, one 556 might say that IPv6 eliminates the need for "extensions", so that all 557 offices have direct communication lines and do not need operators 558 (automatic or otherwise) to redirect calls. 560 1.3.1. Address Autoconfiguration 562 Each IPv6 node initially creates a local IPv6 address for itself 563 using "stateless" address autoconfiguration, not requiring a manually 564 configured server. Stateless autoconfiguration further makes it 565 possible for nodes to configure their own globally routable addresses 566 in cooperation with a local IPv6 router. Typically, the node 567 combines its 48 or 64 bit MAC (i.e., layer-2) address, assigned by 568 the equipment manufacturer, with a network prefix it learns from a 569 neighboring router. This keeps end user costs down by not requiring 570 knowledgeable staff to properly configure each workstation before 571 it can be deployed. These costs are currently part of the initial 572 equipment expense for almost all IPv4 computing platforms. With the 573 possibility of low or zero administrative costs, and the possibility 574 of extremely low cost network interfaces, new market possibilities 575 can be created for control of embedded computer systems. This 576 feature will also help when residential networks emerge as an 577 important market segment. 579 IPv4 networks often employ the Dynamic Host Configuration Protocol 580 (DHCP) to reduce the effort associated with manually assigning 581 addresses to end nodes. DHCP is termed a "stateful" address 582 configuration tool because it maintains static tables that determine 583 which addresses are assigned to newly connected network nodes. 584 A new version of DHCP has been developed for IPv6 to provide 585 similar stateful address assignment as may be desired by many 586 network administrators. DHCPv6 [5, 35] also assists with efficient 587 reconfiguration in addition to initial address configuration, by 588 using multicast from the DHCP server to any desired population of 589 clients. 591 The robust autoconfiguration capabilities of IPv6 will benefit 592 internetwork users at many levels. When an enterprise needs to 593 renumber, IPv6 autoconfiguration will allow hosts to be given 594 new prefixes, without even requiring manual reconfiguration 595 of workstations or DHCP clients. A key aspect of IPv6's eased 596 renumbering capability is its built-in support for multiple 597 simultaneous addresses. This capability allows a site to migrate 598 to a new numbering scheme slowly while continuing to support the 599 previous numbering scheme. Only when migration to the new addresses 600 is complete, are the old addresses retired. In contrast, with IPv4, 601 renumbering a network involves having a ``flag day'' -- that is, a 602 day when work stops and the network administrators are faced with 603 making a huge conversion. This function also assists enterprises 604 in keeping up with dynamic end-user populations. Autoconfiguration 605 allows mobile computers to receive valid forwarding addresses 606 automatically, no matter where they connect to the network. 608 1.3.2. IPv6 Header Format 610 IPv6 regularizes and enhances the basic header layout of the IP 611 packet (see Figures 5,6 in section 2.1). In IPv6, some of the IPv4 612 header information was dropped or made optional. The simplified 613 packet structure is expected to offset the bandwidth cost of the 614 longer IPv6 address fields. The 16-byte (128-bit) IPv6 addresses are 615 four times longer than the 4-byte IPv4 addresses, but as a result of 616 the retooling, the total IPv6 header size is only twice as large; 617 many processing aspects are substantially more efficient. Note 618 that a number of other designs were considered, including variable 619 length addresses; in the end, simplicity won out over infinite 620 extensibility, partially because 128 bits offers such a huge total 621 address space. Recent work [15] in IP header compression promises to 622 reduce or perhaps even effectively eliminate any additional network 623 load associated with the use of 128-bit addresses over low-bandwidth 624 links. 626 IPv6 encodes IP header options in a way that streamlines the 627 forwarding process. Optional IPv6 header information is conveyed 628 in independent "extension headers" located after the IPv6 header 629 and before the transport-layer header in each packet. Most IPv6 630 extension headers are not examined or processed by intermediate 631 nodes (in contrast with IPv4). This enables a big improvement 632 in the deployability of optional IPv6 features, compared to IPv4 633 where IP options typically cause a major performance loss for the 634 packet at every intermediate router. IPv6 header extensions are 635 variable in length and can contain more information than before. 636 Network protocol designers can introduce new header options in a 637 straightforward manner. More details about the comparisons between 638 the IPv4 and IPv6 headers are discussion in section 2.1. 640 So far, option fields have been specified for carrying explicit 641 routing information created by the source node, as well as for 642 mobility, authentication, encryption, and fragmentation control. 643 At the application level, header extensions are available for 644 specialized end-to-end network applications that require their own 645 header fields within the IP packet. 647 1.3.3. Multicast 649 Modern internetworks need to transmit streams of video, audio, 650 animated graphics, news, financial, or other timely data to groups 651 of functionally related but dispersed endstations. This is best 652 achieved by network layer multicast. Typically, a server sends out a 653 single stream of multimedia or time-sensitive data to be received by 654 subscribers. A multicast-capable network routes the server's packets 655 to each subscriber in the multicast group using an efficient path 656 (see Figure 2), replicating only as needed. In the figure, a single 657 packet from the source will be received by all the multicast group 658 members. When there are multiple networks containing multicast group 659 members, a packet distribution "tree" is created for the multicast 660 group. 662 Routers use multicast protocols such as DVMRP (Distance Vector 663 Multicast Routing Protocol) [44] and PIM (Protocol Independent 664 Multicast) [18] or MOSPF (Multicast Open Shortest Path First) [31] 665 to dynamically construct the packet distribution tree that connects 666 all members of a group with the multicast server. Only members that 667 have joined the multicast group perform the processing to receive 668 the data. A new member becomes part of a multicast group by sending 669 a "join" message to a nearby router. The distribution tree is then 670 Multicast Source 671 +---+ 672 | | 673 | | 674 +-+-+ 675 | 676 | 677 | 678 ---+------+----+----------+---+----+-----+--------+------+-----+- 679 | | | | | | | | | 680 | | | | | | | | | 681 | | | | | | | | | 682 | +-+-+ | | +-+-+ | | | | 683 | | | | | | | | +-+-+ | | 684 | | | | | | | | | | | +-+-+ 685 +-+-+ +---+ | +-+-+ +---+ | | | | | | 686 | | | | | | +---+ | | | 687 | | +-+-+ | | +-+-+ Multicast | +---+ 688 +---+ | | +---+ | | Group | 689 Multicast | | Multicast | | Member +-+-+ 690 Group +---+ Group +---+ | | 691 Member Member | | 692 +---+ 693 Multicast 694 Group 695 Member 697 Figure 2: Multicast in Action 699 adjusted to include the new route. Servers can then multicast a 700 single packet, and it will be replicated as needed and forwarded 701 through the internetwork to the multicast group. This conserves both 702 server and network resources and, hence, is superior to unicast and 703 broadcast solutions. Multicast applications have been developed 704 for IPv4, but IPv6 extends IP multicasting capabilities by defining 705 a much larger multicast address space. All IPv6 hosts and routers 706 are required to support multicast. In fact, IPv6 has no broadcast 707 address as such; it has various multicast addresses of various 708 scopes. The improved scoping offered in IPv6 promises to simplify 709 the use and administration of multicast in many applications. 711 1.3.4. Anycast 713 Anycast services, supported in the IPv6 specification, are not 714 defined architecturally in IPv4. Conceptually, anycast is a cross 715 ----- ----- ----- 716 | X | | Y | | Z | 717 ----- ----- ----- 718 \ | / ------- ISP transit domain --------- 719 \ | / | | 720 ------- | ------- | 721 | rtr |---------------------------------| rtr | | 722 ------- | ------- | 723 / \ | / \ | 724 / \ | / \ | 725 ------- ------- | ------- ------- | 726 | rtr | Enterprise| rtr |---------------| rtr | Anycast | rtr | | 727 ------- Network ------- | ------- Group ------- | 728 \ / | \ / | 729 \ / | \ / | 730 ------- | ------- | 731 | rtr |---------------------------------| rtr | | 732 ------- | ------- | 733 | | | 734 ----- | | 735 | Q | ------- ISP transit domain --------- 736 ----- 738 Figure 3: Anycast Addressing 740 between unicast and multicast: an arbitrary collection of nodes may 741 be designated as an anycast group [34]. A packet addressed to the 742 group's anycast address is delivered to only one of the nodes in the 743 group, typically the node with the "nearest" interface in the group, 744 according to current routing protocol metrics. This is in contrast 745 with multicast services, which deliver packets to all members of the 746 multicast group. Nodes in an anycast group are specially configured 747 to recognize anycast addresses, which are drawn from the unicast 748 address space [22]. 750 Anycasting is a new service, and its applications have not been fully 751 developed. Using anycast, an enterprise could forward packets to 752 exactly one of the routers on its ISP's backbone (see Figure 3). If 753 all of a provider's routers have the same anycast address, traffic 754 from the enterprise will have several redundant access points to the 755 Internet. And if one of the backbone routers goes down, the next 756 nearest device automatically will receive the traffic. 758 In figure 3, suppose some hosts Q, X, Y, and Z in an Enterprise 759 Network send data to the anycast address served by the backbone 760 routers in the Anycast Group of the ISP Transit Domain. The border 761 routers in the Enterprise Network forward the data just as they would 762 for data sent to a unicast address. Then, any one of the backbone 763 routers in the Anycast Group may receive the data, eliminating the 764 overhead which would have been incurred if the backbone routers were 765 instead configured to form a multicast group. If there are multiple 766 home agents for mobile nodes on a single home network, they also 767 join an anycast group. In that way, a mobile node can register with 768 exactly one home agent even in the case when it doesn't know the 769 address of any specific one. 771 1.3.5. Quality of Service 773 IPv4 carries a "differentiated services" byte and IPv6 carries an 774 equivalent "traffic class" byte, intended for support of simple 775 differentiated services. Both IPv4 and IPv6 can support the RSVP 776 protocol for more complex quality of service implementations. 777 Additionally, the IPv6 packet format contains a new 20-bit 778 traffic-flow identification field that will be of great value to 779 vendors who implement quality-of-service (QoS) network functions. 780 Such QoS products are still in the planning stage, but IPv6 lays the 781 foundation so that a wide range of QoS functions (including bandwidth 782 reservation and delay bounds) may be made available in a open and 783 interoperable manner. 785 An additional benefit for QoS in IPv6 is that a flow label has been 786 allocated within the IPv6 header that can be used to distinguish 787 traffic flows for optimized routing. Furthermore, the flow label can 788 be used to identify flows even when the payload is encrypted (i.e., 789 the port numbers are hidden). 791 1.3.6. The Transition to IPv6 793 The transition from IPv4 to IPv6 could take one of several paths. 794 Some are lobbying for rapid adoption of IPv6 as soon as possible. 795 Others prefer to defer IPv6 deployment until the IPv4 address space 796 is exhausted, or until other issues leave no other choice. Either 797 way, given the millions of existing IPv4 network nodes, IPv4 and IPv6 798 will coexist for an extended period of time. 800 Therefore, IETF protocol designers have gone to great lengths to 801 ensure that hosts and routers can be upgraded to IPv6 in a graceful, 802 incremental manner. The transition will prevent isolation of 803 IPv4 nodes, and also prevent "fork-lift" upgrades for entire user 804 populations. Transition mechanisms have been engineered to allow 805 network administrators flexibility in how and when they upgrade hosts 806 and intermediate nodes. IPv6 can be deployed in hosts first, in 807 routers first, or, alternatively, in a limited number of adjacent or 808 remote hosts and routers. The nodes that are upgraded initially do 809 not have to be colocated in the same local area network or campus. 811 Many upgraded hosts and routers will need to retain downward 812 compatibility with IPv4 devices for an extended time period (possibly 813 years or even indefinitely). It is also assumed that upgraded 814 devices should have the option of retaining their IPv4 addresses. To 815 accomplish these goals, IPv6 transition relies on several special 816 functions that have been specified by the ``ngtrans'' working group 817 of the IETF, including dual-stack hosts and routers, and tunneling 818 IPv6 via IPv4. A dual-stack host is a computer able to handle both 819 IPv4 and IPv6 packets. Such a computer can deliver packetized data 820 to a single application that has been equipped to ask for data from 821 both addressing domains. This facilitates easy transition from IPv4 822 to IPv6 since the application can then still receive data from its 823 current communications partners, without change in any way noticeable 824 to the users. 826 1.3.7. IPv6 DNS 828 Domain Name Service (DNS) is something that administrators must 829 consider before deploying IPv6 or dual-stack hosts. In response 830 to this issue, IETF designers have defined "DNS Extensions to 831 Support IP Version 6" [41] and "DNS Extensions to Support IPv6 832 Address Aggregation and Renumbering" [12]. These specifications 833 create new DNS record types (A6 and AAAA ("quad A") record types) 834 that map a domain name to an IPv6 address. Domain name lookups 835 (reverse lookups) based on 128-bit addresses also are defined. Once 836 an IPv6-capable DNS is in place, dual-stack hosts can interact 837 interchangeably with IPv6 nodes. If a dual-stack host queries DNS 838 and receives back a 32-bit address, IPv4 is used; if a 128-bit 839 address is received, then IPv6 is used. 841 In the current DNS, addresses are stored within DNS Resource Records 842 that contain complete addresses. Changing any of the bits of 843 an address (e.g., the bits defining the specific ISP the host is 844 connected to) requires updating every Resource Record for every one 845 of a site's hosts. This poses an administrative burden and requires 846 generating new cryptographic signatures for the records as well, when 847 DNSSEC is used [17]. For a site with tens of thousands of nodes, the 848 effort can be significant. 850 The new DNS extensions [12] defined by IPv6 will ease the process 851 of managing a site's addresses and in particular simplify the DNS 852 updates required should the site switch providers or otherwise need 853 renumbering. The new "A6" DNS records allow for the division of 854 an address into its logical components, each stored as a separate 855 component in the DNS. Should a site renumber, it only needs to update 856 the DNS records that define the new ISP, without modifying any of the 857 individual Resource Records associated with each specific host. A 858 change in a single DNS record is inherited transparently by all of 859 the site's hosts. 861 The new, renumbering-friendly DNS mechanisms allow a prefix change 862 for all of a site's hosts to be accomplished with as little as one 863 DNS record change in each of the forward and reverse data sets. It 864 also allows a typical site the option of storing the forward and 865 reverse data in the same DNS zone. It is expected that this scheme 866 will soon supplant the older, AAAA-based methods. 868 IPv6 autoconfiguration and IPv6 DNS can be linked by using dynamic 869 DNS updates, coupled with secure DNS. By these means DNS servers can 870 be securely and automatically updated whenever an IPv6 node acquires 871 a new address, enabling an additional measure of convenience compared 872 with renumbering in IPv4 today. 874 1.3.8. Application Modification for IPv6 876 Applications that do not directly access network functions (do not 877 call a socket or DNS API and do not handle numeric IP addresses in 878 any way) need no modifications to run in the dual-stack environment. 879 Applications that use certain interface APIs to communicate with the 880 network stack will require updating before using IPv6. For example, 881 applications that access DNS or use sockets must be enhanced with 882 the capability to handle A6 or AAAA records and 128-bit addresses. 883 Applications which are expected to run both IPv4 and IPv6, as well 884 as using IPv6 security, quality of service, and other features, will 885 need more extensive updating. 887 Adding such a dual-stack architecture to all the existing hosts 888 is, in fact, a significant effort. This effort has to be balanced 889 against the benefits of IPv6, and against the effort to renumber the 890 existing hosts if the network deployment grows past the restrictions 891 resulting from insufficient address space. 893 1.3.9. Routing in IPv6/IPv4 Networks 895 Routers running both IPv6 and IPv4 can be administered in much the 896 same fashion that IPv4-only networks are currently administered. 897 Multi-protocol extensions to BGP4 [43] have been defined by the IETF; 898 one of them carries IPv6 prefixes. The IPv6 extension has been 899 used widely in the 6bone since early 1997. IPv6 versions of other 900 popular routing protocols, such as Open Shortest Path First (OSPF) 901 and Routing Information Protocol (RIP), are also available. 903 Administrators may choose to keep the IPv6 topology and addressing 904 logically separate from the IPv4 network, even though both run on the 905 same physical infrastructure, allowing the two to be administered 906 separately. Alternatively, it may be advantageous to align the two 907 architectures by using the same domain boundaries, areas, and subnet 908 organization. Both approaches have their advantages. A separate 909 IPv6 architecture can be used to replace the inefficient IPv4 910 topologies burdening many of today's enterprises. An independent 911 IPv6 architecture presents the opportunity to build a fresh, 912 hierarchical network address plan that will facilitate connection to 913 one or more ISPs. This simplifies renumbering, route aggregation 914 (summarization), and other goals of a routing hierarchy. 916 Initially, many IPv6 hosts may have direct connectivity to each other 917 only via IPv4 routers. Such hosts will exist in islands of IPv6 918 topology surrounded by an ocean of IPv4. So, there are transition 919 mechanisms that allow IPv6 hosts to communicate over intervening 920 IPv4 networks. The essential technique of these mechanisms is IPv6 921 over IPv4 tunneling, which carries IPv6 packets within IPv4 packets 922 (see Figure 4). Tunneling allows early IPv6 implementations to take 924 +-------------------+ 925 +-----------+ | IPv4 Network | +-----------+ 926 | Dual-stack| | | | Dual-stack| 927 | IPv4/IPv6 ========tunnel through======== IPv4/IPv6 | 928 | router | | | | router | 929 +-----------+ | | +-----------+ 930 / | \ +-------------------+ / | \ 931 / | \ / | \ 932 / | \ / | \ 933 +--+ +--+ +--+ +--+ +--+ +--+ 934 | | | | | | | | | | | | 935 +--+ +--+ +--+ +--+ +--+ +--+ 936 IPv6 endstations IPv6 endstations 938 Figure 4: IPv6 over IPv4 Tunneling 940 advantage of existing IPv4 infrastructure without any change to IPv4 941 components. A dual-stack router or host on the "edge" of the IPv6 942 topology simply inserts an IPv4 header in front of ("encapsulates") 943 each IPv6 packet and sends it as native IPv4 traffic through existing 944 links. IPv4 routers forward this traffic without knowledge that IPv6 945 is involved. On the other side of the tunnel, another dual-stack 946 router or host "decapsulates" (removes the extra IP header from) the 947 IPv6 packet and routes it to the ultimate destination using standard 948 IPv6. 950 To accommodate different administrative needs, IPv6 transition 951 mechanisms include two types of tunneling: automatic and configured. 952 To build configured tunnels, administrators manually define IPv6-to- 953 IPv4 address mappings at tunnel endpoints. Outside of the tunnel, 954 traffic is forwarded with full 128-bit addresses. At the tunnel 955 entry point, a manually configured router table entry dictates 956 which IPv4 address is used to traverse the tunnel. This requires 957 a certain amount of manual administration at the tunnel endpoints, 958 but traffic is routed through the IPv4 topology dynamically, without 959 the knowledge of IPv4 routers. The 128-bit addresses do not have to 960 align with 32-bit addresses in any way. 962 Mbone deployment using IP-within-IP tunneling has been quite 963 successful, and validates this design approach as well as supporting 964 the likelihood of smooth transition. 966 1.3.10. The Dual-Stack Transition Method 968 Initial users of IPv6 machines will require continued interaction 969 with existing IPv4 nodes. This is accomplished with the dual-stack 970 IPv4/IPv6 approach. Many hosts and routers in today's multivendor, 971 multiplatform networking environment already support multiple network 972 stacks. For instance, the majority of routers in enterprise networks 973 are multiprotocol routers. Many workstations run some combination 974 of IPv4, IPX, AppleTalk, NetBIOS, SNA, DECnet, or other protocols. 975 The inclusion of one additional protocol (IPv6) on an endstation or 976 router is a well-understood problem. When running a dual IPv4/IPv6 977 stack, a host has access to both IPv4 and IPv6 resources. Routers 978 running both protocols can forward traffic for both IPv4 and IPv6 end 979 nodes. 981 Dual-stack machines can use totally independent IPv4 and IPv6 982 addresses, or they can be configured with an IPv6 address that 983 is IPv4-compatible. Dual-stack nodes can use conventional IPv4 984 autoconfiguration services (DHCP) to obtain their IPv4 addresses 985 while using IPv6 autoconfiguration mechanisms to obtain their IPv6 986 addresses. 988 1.3.11. Automatic Tunneling 990 Automatic tunnels use "IPv4-compatible" addresses, which are hybrid 991 IPv4/IPv6 addresses. A compatible address is created by adding 992 leading zeros to a 32-bit IPv4 address to pad it out to 128 bits. 993 When traffic is forwarded with a compatible address, the device at 994 the tunnel entry point can automatically address encapsulated traffic 995 by simply converting the IPv4-compatible 128-bit address to a 32-bit 996 IPv4 address. On the other side of the tunnel, the IPv4 header is 997 removed to reveal the original IPv6 address. Automatic tunneling 998 allows IPv6 hosts to dynamically exploit IPv4 networks, but it does 999 require the use of IPv4-compatible addresses, which do not bring the 1000 full benefits of the 128-bit address space. 1002 IPv6 nodes using IPv4-compatible addresses cannot take advantage 1003 of the extended address space, but they can exploit the other IPv6 1004 enhancements, including flow labels, authentication, encryption, 1005 multicast, and anycast. Once a node is migrated to IPv6 with IPv4 1006 compatibility, the door is open for a fairly painless move to the 1007 full IPv6 address space. IPv4-compatible addressing means that 1008 administrators can add IPv6 nodes while initially preserving their 1009 basic address and subnet architecture. Automatic tunnels are 1010 available when needed, but they may not be necessary when major 1011 backbone routers are upgraded to include the IPv6 stack. Upgrades 1012 can be achieved quickly and efficiently when backbone routers support 1013 full remote configuration and upgrade capabilities. 1015 2. The Technical Case for IPv6 1017 In this section, the technical aspects of IPv6 are discussed. In 1018 many cases, the technical details illustrate the concepts of the 1019 previous section. Other features are introduced as needed to help 1020 provide a fuller understanding of the protocol. 1022 2.1. IPv6 Headers vs. IPv4 Headers 1024 To start the technical look at IPv6, we compare the IPv6 header 1025 with the IPv4 header. Both headers carry version numbers and 1026 source/destination addresses, but as Figure 6 shows, the IPv6 header 1027 is considerably simplified, which makes for more efficient processing 1028 by routing nodes. Whereas IPv4 headers are potentially variable in 1029 length, IPv6 headers have a fixed length of 40 bytes. This allows 1030 router software designers to optimize the parsing of IPv6 headers 1031 along fixed boundaries. Additional processing efficiencies have been 1032 realized by reducing the number of required header fields in IPv6. 1033 An IPv4 header, illustrated in figure 5 contains at least 12 fields, 1034 depending on how they are counted, and can also contain additional 1035 (and hard to parse) option fields, not illustrated in the figure. 1036 IPv6, on the other hand, only uses 8 fields. 1038 One of the first IPv4 components to be discarded was the header 1039 length field, which is clearly no longer required due to the fixed 1040 header length of all IPv6 packets. The total length field of IPv4 1041 has been retained in the guise of the IPv6 payload length field. But 1042 this field does not include the length of the IPv6 header, which is 1043 always assumed to be 40 bytes. The new payload length field can 1044 +-------+-------+---------------+-------------------------------+ 1045 |Version| 4 bits| 8 bits | 16 bits | 1046 | == 4 | IHL |Type of Service| Total Length | 1047 +-------+-------+---------------+-------------------------------+ 1048 | 16 bits | 4 bits| 12 bits | 1049 | Identification | Flags | Fragment Offset | 1050 +-------------------------------+-------------------------------+ 1051 | 8 bits | 8 bits | 16 bits | 1052 | Time to Live | Protocol | Header Checksum | 1053 +-------------------------------+-------------------------------+ 1054 | 32 bits | 1055 | Source Address | 1056 +---------------------------------------------------------------+ 1057 | 32 bits | 1058 | Destination Address | 1059 +---------------------------------------------------------------+ 1060 : 0 or more bits : 1061 : IP options : 1062 +---------------------------------------------------------------+ 1064 Figure 5: IPv4 Header Format 1066 +-------+---------------+---------------------------------------+ 1067 |Version| 8 bits | 20 bits | 1068 | == 6 | Traffic Class | Flow Label | 1069 +-------+---------------+-------+---------------+---------------+ 1070 | 16 bits | 8 bits | 8 bits | 1071 | Payload Length | Next Header | Hop Limit | 1072 +-------------------------------+---------------+---------------+ 1073 | 128 bits | 1074 | | 1075 | Source Address | 1076 +---------------------------------------------------------------+ 1077 | 128 bits | 1078 | | 1079 | Destination Address | 1080 +---------------------------------------------------------------+ 1082 Figure 6: IPv6 Header Format 1084 accommodate packets up to 64 KB in length. Even larger packets, 1085 called "jumbograms", can be passed between IPv6 nodes if the payload 1086 length field is set to zero and a special extension header is added, 1087 as discussed below. 1089 The time-to-live (TTL) field of IPv4 has been renamed the IPv6 ``hop 1090 limit'' field, to describe more accurately its actual function. The 1091 field is used to break loops, by decrementing a maximum hop value by 1092 1 for each hop of the end-to-end route. The hop-limit field is set 1093 to the appropriate value by the source node. When the value in the 1094 hop limit field is decremented to zero, the packet is discarded. The 1095 IPv6 hop-count field allows up to 255 hops, which exceeds the needs 1096 for even the largest of networks, as best we can calculate today. 1098 In addition to the header length field, a number of basic IPv4 1099 fields were eliminated from the IPv6 header: fragment offset, 1100 identification, flags, checksum. The IPv4 type-of-service field is 1101 replaced by the IPv4 traffic class field, plus the all-new flow label 1102 field. The IPv4 fragmentation fields (offset, identification, and 1103 flags) have been moved to optional headers in IPv6, as discussed in 1104 section 2.6. Finally, the IPv4 checksum field has been abandoned in 1105 IPv6, since error checking typically is duplicated at other levels 1106 of the protocol stack. Bad packets will be detected below, at the 1107 link-layer, or above, at the transport layer. Requiring routers to 1108 perform error checking has caused reduced performance in today's 1109 Internet. 1111 2.2. Extension Headers 1113 IPv4 headers include an options field, which conveys information 1114 about security, source routing, and other optional parameters. 1115 Unfortunately, options are poorly utilized because routers typically 1116 offer degraded performance to packets that contained options. 1118 The IPv4 options field has been replaced in IPv6 by extension 1119 headers that are located after the primary IPv6 header and before the 1120 transport header and application payload. IPv6 extension headers 1121 provide security, fragmentation, source routing, and other functions. 1122 There is no set limit on the number of extension headers between the 1123 initial header and the higher layer payload. Since IPv6 separates 1124 options into modular headers, processing should be simpler and thus 1125 can remain on the fast path as needed. Figure 7 shows encryption and 1126 fragmentation headers occurring after the primary IPv6 header and 1127 before the Transmission Control Protocol (TCP) header. 1129 +----------+-------------------+----------------+----------------- 1130 | IPv6 Hdr | Fragmentation Hdr | Encryption Hdr | Transport, etc 1131 +----------+-------------------+----------------+----------------- 1133 Figure 7: IPv6 Extension Headers 1135 The protocol type field (e.g., TCP or User Datagram Protocol (UDP)), 1136 is has been replaced by the "Next Header" field; each header field 1137 indicates the type of the next header, which can be a TCP/UDP header, 1138 or another IPv6 extension header. IETF working groups have already 1139 defined a number of extension headers for IPv6 and have suggested 1140 guidelines for the order of header insertion. The suggested order 1141 for extension headers, if any are present, is as follows: 1143 - (Primary IPv6 header) 1144 - Hop-by-Hop options header 1145 - Destination options header-1 1146 - Source Routing header 1147 - Fragmentation header 1148 - Authentication header 1149 - IPv6 Encryption header 1150 - Destination options header-2 1152 followed by the upper layer headers and payload. 1154 Each extension header typically occurs only once within a given 1155 packet, except for the destination options header (as explained in 1156 Section 2.4). 1158 2.3. Hop-by-Hop Options Header 1160 When present, this header carries options that are examined by 1161 intermediate nodes along the forwarding path. It must be the first 1162 extension header after the initial IPv6 header. Since this header 1163 is read by all routers along the path, it is useful for transmitting 1164 management information or debugging commands to routers. One 1165 currently defined application of the hop-by-hop extension header 1166 is the Router Alert option, which informs routers that the packet 1167 should be processed completely by a router before it is forwarded to 1168 the next hop. An example of such a packet is an RSVP [6] resource 1169 reservation message for QoS. Another hop-by-hop extension header 1170 allows ``jumbograms'', or packets larger than 65,536 bytes [4]. 1172 2.4. Destination Options Headers 1174 There are two variations of this header, each with a different 1175 position in the packet. A Destination Options header appearing 1176 before a Routing Header will be processed by every node listed in 1177 the latter. A Destination Header appearing after a Routing Header, 1178 or without a Routing Header, will be processed only by the final 1179 destination. 1181 2.5. Routing Headers 1183 IPv6, in [14], defines a "Type 0" (zero) routing header, which gives 1184 a sending node a great deal of control over each packet's route. The 1185 IPv6 routing extension header replaces the loose source route (LSR) 1186 option supported currently by IPv4. This optional header allows a 1187 source node to specify a list of IP addresses that determine which 1188 routing path a packet will traverse. 1190 IPv6's loose source routing (LSR)) is illustrated in Figure 8. In 1191 "loose" forwarding, unlisted routers can be visited by a packet. So, 1192 for example in figure 8 the packet could be routed from router 3 1193 through router 4 and then to router 5, even though router 4 was not 1194 specified in the routing information field of the routing header. 1195 The source routing feature works in conjunction with another routing 1196 header field that contains a value equal to the total number of 1197 segments remaining in the source route. Each time a hop is made, 1198 this "segments left" field is decremented. 1200 IPv6 corrects another deficiency in the specification of IPv4 source 1201 routing options, by relaxing the requirement that destination nodes 1202 reverse the source route for transmitting packets back to the node 1203 originating the source route. This requirement is among the reasons 1204 that IPv4 source routing has almost entirely fallen out of use, 1205 because it opens up a big security hole. If a source route were to 1206 be reversed, without being sure that the source route was in fact 1207 originated by the indicated source node, then any other node within 1208 the Internet could easily masquerade as that indicated source node. 1209 IPv6 source routes, on the other hand, do not carry with them the 1210 same security exposure, since the recipient of such a routing header 1211 is not required to use the information for sending packets back to 1212 the source. 1214 When Type 0 routing headers are used, the initial IPv6 header 1215 contains the destination addresses of the first router in the 1216 source route, not the final destination address. At each hop, 1217 the intermediate node replaces this destination address with the 1218 address of the next routing node, and the "segments left" field is 1219 decremented. 1221 2.6. Fragmentation Header 1223 IPv4 has the ability to fragment packets at any point in the 1224 path, depending on the transmission capabilities of the links 1225 involved. This feature has been dropped in IPv6 in favor of 1226 end-to-end fragmentation/reassembly, which is executed only by 1227 IPv6 source and destination nodes. Packet fragmentation is not 1228 permitted in intermediate IPv6 nodes. The elimination of the 1229 IPv6 Packet 1230 +----------+-----+-------------------------------+- -- -- -- -- -- 1231 | IPv6 Hdr | ... | Route Information: 1, 2, 3, 5 | ... 1232 +----------+-----+-------------------------------+- -- -- -- -- -- 1234 +---+ 1235 | X | +-------+ +-------+ +---+ 1236 +---+ ---| rtr 4 |------------| rtr 5 |------| Y | 1237 \ / +-------+ +-------+ +---+ 1238 \ / \ 1239 +-------+ \ +-------+ 1240 | rtr 1 | \--| rtr 3 | 1241 +-------+ +-------+ 1242 \ / 1243 \ / 1244 +-------+ / 1245 | rtr 2 |-- 1246 +-------+ 1248 Figure 8: Source Routing Extension Header 1250 fragmentation field allows a simplified packet header design and 1251 better router performance for the great majority of cases where 1252 fragmentation is not required. Today's networks generally support 1253 frame sizes that are large enough to carry typical IP packets without 1254 fragmentation. In the event that fragmentation is required, IPv6 1255 provides an optional extension header that is used by source nodes 1256 to divide packets into smaller units. If higher level protocols 1257 are using larger payloads, the source node can make use of the IPv6 1258 fragmentation extension header to divide large packets into 1500-byte 1259 units for network transmission. The IPv6 destination node will 1260 reassemble these fragments in a manner that is transparent to upper 1261 layer protocols and applications. 1263 The IPv6 fragmentation header contains fields that identify a group 1264 of fragments as a packet and assigns them sequence numbers. The 1265 source node is responsible for sizing packets correctly, so it has to 1266 determine the Maximum Transmission Unit (MTU) of the end-to-end path, 1267 which is the smallest MTU of each link along the path. For instance, 1268 if two FDDI networks with 4500-byte MTUs are connected by an Ethernet 1269 with an MTU of 1500, then the source node must send packets that are 1270 no larger than 1500. 1272 End nodes can determine the smallest MTU of a path with the MTU 1273 path discovery process [30]. Typically, with this technique, the 1274 +--ICMP Datagram Too Big--<--+ 1275 v | 1276 +---+ FDDI +-----+ FDDI +-----+ Ethernet +-----+ FDDI +---+ 1277 | X |--------| rtr |--------| rtr |--------------| rtr |--------| Y | 1278 +---+ +-----+ +-----+ MTU = 1500 +-----+ +---+ 1279 | | 1280 +-->-MTU Discovery Message->-+ 1282 Figure 9: MTU Discovery Process 1284 source node probes the MTU by transmitting a packet with an MTU as 1285 large as the local interface can handle (see Figure 9). If this 1286 MTU is too large for some link along the path, an ICMP "Datagram 1287 too big" message will be sent back to the source. This message 1288 will contain a packet-too-big indicator and the MTU of the affected 1289 link. The source can then adjust the packet size downward (fragment) 1290 and retransmit another packet. This process is repeated until a 1291 packet gets all the way to the destination node. The discovered 1292 MTU is then used for fragmentation purposes. Although source-based 1293 fragmentation is fully supported in IPv6, it is recommended that 1294 network applications adjust packet size to accommodate the smallest 1295 MTU of the path. This will avoid the drawbacks associated with 1296 fragmentation/reassembly on source and destination nodes. 1298 2.7. IPv6 Security 1300 IPv6 has two security extension headers, one that enables the 1301 authentication of IP traffic for security purposes, and another that 1302 fully or partially encrypts IP packets. Implementation of security 1303 at the IP level can benefit "security aware" applications, as well as 1304 "security ignorant" applications that don't take explicit advantage 1305 of security features. 1307 2.8. IPv6 Authentication Header 1309 Using IPv6 authentication headers [24], hosts can verify the 1310 authenticity and integrity of the IPv6 payload data. The 1311 authentication header makes use of an established security 1312 association, that may, for instance, be based on the exchange of 1313 algorithm-independent secret keys. In a client/server session, for 1314 instance, both the client and the server need to have knowledge of 1315 the key. Before each packet is sent, IPv6 authentication creates a 1316 Message Integrity Code (MIC) (using, e.g., MD5 [26]) based on the key 1317 cryptographically digestified with the entire contents of the packet 1318 including data within the Authentication Extension to eliminate 1319 replay attacks. The MIC is then recomputed on the receiving side 1320 and compared. This approach provides authentication of the sender 1321 and guarantees that data within the packet has not been modified or 1322 replayed by an intervening party. Authentication can take place 1323 between clients, or clients and servers on the corporate backbone. 1324 It can also be deployed between remote nodes and corporate dial-in 1325 servers to ensure that the perimeter of the corporate security is not 1326 breached. 1328 2.9. IPv6 Encryption Header 1330 <-------------- Unencrypted ---------------> <----- Encrypted ----... 1331 +-------------+----------------+------------+------------------------ 1332 | IPv6 Header | Extension Hdrs | ESP Header | Transport Hdr & Payload 1333 +-------------+----------------+------------+------------------------ 1335 Figure 10: Transport Mode of IPv6 Encryption 1337 <-----Unencrypted--------> <--------- Encrypted ----------------... 1338 +--------+--------+-------+--------+--------+-------+--------------- 1339 |IPv6 Hdr|Ext.Hdrs|ESP Hdr|IPv6 Hdr|Ext.Hdrs|ESP Hdr|Transpt/Payload 1340 +--------+--------+-------+--------+--------+-------+--------------- 1341 <-Encapsulating Headers--> <--------- Original Packet -------....... 1343 Figure 11: Tunnel Mode of IPv6 Encryption 1345 Authentication headers eliminate a number of host spoofing and packet 1346 modification attacks, but they do not prevent passively reading of 1347 data traversing the Internet and corporate backbone networks. This 1348 protection is offered by the Encapsulating Security Payload (ESP) 1349 service of IPv6 -- another optional extension header [25]. Packets 1350 protected by the ESP encryption techniques can have very high levels 1351 of privacy and integrity -- something that is not widely available 1352 with the current Internet, except with certain secure applications 1353 (e.g., private electronic mail and secure HTTP Web servers). ESP 1354 provides encryption at the network layer, making it available to all 1355 applications in a standardized fashion. 1357 IPv6 ESP is used to encrypt the transport-layer header and payload 1358 (e.g., TCP, UDP), or else the appropriate IPv6 header fields along 1359 with the payload. Both these methods are accomplished with an ESP 1360 extension header that carries encryption parameters end-to-end. When 1361 just the transport payload is to be encrypted, the ESP header is 1362 inserted in the packet directly before the TCP or other transport 1363 header. In this case, the headers before the ESP header are not 1364 encrypted and the headers and payload after the ESP header are 1365 encrypted. This is referred to as "transport-mode" encryption, and 1366 is illustrated in figure 10. If it is desirable to encrypt the 1367 entire IP datagram, a new IPv6 and an ESP header are wrapped around 1368 all the fields (including the initial address fields) of the packet. 1369 Full datagram encryption is sometimes called "tunnel-mode" encryption 1370 because the payload of the datagram is unintelligible except at the 1371 endpoints of the security tunnel (see Figure 11). 1373 Fully encrypted datagrams are somewhat more secure than transport 1374 mode encryption because the headers of the fully encrypted packet are 1375 not available for traffic analysis. 1377 For instance, full tunnel-mode encryption allows the addresses 1378 contained in IPv6 source routing headers to be hidden from packet 1379 sniffing devices for the public portion of a path. This is in 1380 addition to the typical use of tunnel-mode encryption for the 1381 purposes of creating a private link. There is a considerable 1382 performance penalty for full encryption, due to the overhead and 1383 processing cost of adding an additional IPv6 header to each datagram. 1384 In spite of its cost, full ESP encryption is particularly valuable 1385 to create a security tunnel (steel pipe) between the firewalls of 1386 two remote sites (see Figure 12). The full datagram encryption 1387 in the tunnel ensures that the various headers and address fields 1388 of encrypted packets will not be visible as traffic traverses the 1389 public Internet. Within the tunnel, only the temporary encapsulating 1390 address header is visible. Once through the tunnel and safely within 1391 a firewall, the leading ESP headers are stripped off and the packet 1392 is again visible, including any source routing headers required to 1393 finish the path. 1395 ~~ ~~ 1396 F~ ~F 1397 +--------+ i~ +--------------------+ ~i +--------+ 1398 | | r~ | | ~r | | 1399 | Site 1 | e~ | Public Internet | ~e | Site 2 | 1400 | | ---------------------------------------- | | 1401 | <-------( - - - - - - ESP Steel Pipe - - - - - -()<-----<-- | 1402 | | ---------------------------------------- | | 1403 | | w~ | | ~w | | 1404 | | a~ | | ~a | | 1405 | | l~ +--------------------+ ~l | | 1406 +--------+ l~ ~l +--------+ 1407 ~~ ~~ 1409 Figure 12: Firewalls and Steel Pipe 1411 The encryption and authentication services of IPv6 together 1412 create the security solution often needed by business and military 1413 applications. An authentication header is typically carried 1414 inside an encrypted datagram, providing an additional layer of data 1415 integrity and verification of the sender's identification. The 1416 authentication header should be placed in front of the encrypted 1417 transport-mode portion of the packet. This approach enables the 1418 authentication to take place before decryption on the receiving 1419 end, which is important for security purposes. Taken together, the 1420 authentication and encryption services of IPv6 provide a robust, 1421 standards-based security mechanism that will play a decisive role in 1422 the continuing expansion of commerce and corporate operations onto 1423 IP-based network fabrics. 1425 2.10. The IPv6 Address Architecture 1427 Much of the discussion of IPv4 versus IPv6 focuses on the relative 1428 size of the address fields of the two protocols (32 bits versus 1429 128 bits). But an equally important difference is the relative 1430 abilities of IPv6 and IPv4 to provide a hierarchical address space 1431 that facilitates efficient routing architectures. IPv4 was initially 1432 designed with class A, class B, and class C addresses, which divided 1433 address bits between network and host but did not create a hierarchy 1434 that would allow a single high-level address to represent many 1435 lower-level addresses. Hierarchical address systems work in much 1436 the same way as telephony country codes or area codes, which allow 1437 long-haul phone switches to route calls efficiently to the correct 1438 country or region using only a portion of the full phone number. 1440 As the Internet grew, the non-hierarchical nature of the original 1441 IPv4 address space proved inadequate. This problem has been improved 1442 by use of CIDR (see section 1.2.1), but legacy address assignments 1443 still hamper routing within the Internet. These legacy assignments 1444 limit both local and global levels of internetworking. To combat 1445 IPv4 deficiencies at the local area network level, the subnetting 1446 technique has been developed to create a more manageable division of 1447 large networks. Using subnets, a single network address can stand 1448 for a number of physical networks, a technique that conserves address 1449 space considerably. For example, a single Class B address can be 1450 used to access hundreds of physical networks, each of which itself 1451 could have dozens or hundreds of individual hosts. 1453 At the level of large internet backbones and global routing, 1454 classful IPv4 addresses can be more efficiently aggregated with 1455 supernetting, a form of hierarchical addressing. With supernetting, 1456 backbone routers store a single address that represents the path 1457 to a number of lower level networks. This can considerably reduce 1458 the size of routing tables in backbone routers, which increases 1459 backbone performance and lowers the amount of memory and number of 1460 route processors required. Subnetting and supernetting have been 1461 particularly useful in extending the viability of the IPv4 Class C 1462 addresses. Both of these techniques are made possible by associating 1463 addresses stored in routers to bit masks that indicate which bits in 1464 an address are valid at the various levels of the hierarchy. 1466 The process of creating an IPv4 routing hierarchy was formalized 1467 in CIDR, as discussed in Section 1.2.1. For instance, CIDR allows 1468 a number of (plentiful) Class C addresses to be summarized by a 1469 single prefix address, allowing Class C addresses to function in 1470 a similar way to hard-to-get Class A and Class B addresses. CIDR 1471 has extended the life of IPv4 and helped the Internet scale to its 1472 current size, but it has not been implemented in a consistent way 1473 across the Internet and enterprise networks. Consequently, the route 1474 table efficiencies and address space conservation advantages of CIDR 1475 are not today fully realized, nor will they ever be fully realized, 1476 due to the legacy nature of IPv4 networks and the difficulty of 1477 restructuring them. IPv4 will continue to waste a larger proportion 1478 of its address space, and to burden routers with inefficient routes 1479 and excessively large routing tables. 1481 At the departmental and workgroup level of internetworking, IPv4 1482 engenders a high administrative workload associated with maintaining 1483 subnet bit masks and host addresses within the subnet structure, 1484 particularly where there are large, dynamic populations of end users. 1485 When an end user is moved in the subnetting environment, careful 1486 attention must be paid to ensure that the host renumbering process 1487 does not disrupt the ability of the user to make effective use of the 1488 network. The complexities and pitfalls of current subnetting methods 1489 can eventually make IPv4 less than viable in large organizations that 1490 experience growth of internetwork user populations (especially at 1491 current rates of growth). IPv6, with its greater subnetting space, 1492 makes the job of aggregating and administering networks much easier 1493 and more flexible. 1495 2.11. The IPv6 Address Hierarchy 1497 Motivated by the experience gained from IPv4, IPv6 designers made 1498 sure from the very beginning to provide a scalable address space that 1499 can be partitioned into a efficient global routing hierarchy. At 1500 the top of this hierarchy, several international registries assign 1501 blocks of addresses to top level aggregators (TLA). TLAs allocate 1502 blocks of addresses to Next Level Aggregators (NLA), which represent 1503 large providers and global corporate networks. When an NLA is a 1504 provider, it further allocates its addresses to its subscribers. 1505 Routing is efficient because NLAs that are under the same TLA will 1506 have addresses with a common TLA prefix. Subscribers with the same 1507 provider have IP addresses with an NLA common prefix. See Figure 13 1508 for an example of Aggregation-based Allocation Structures. Although 1509 a number of allocation schemes are possible within IPv6's huge 1510 address space, an aggregation-based hierarchy is favored by IETF 1511 +-----------+ +-----------+ 1512 | Long-Haul | - - - - - - - - - - - - -| Long-Haul | 1513 | Provider | | Provider | 1514 +-----------+ +-----------+ 1515 | \ / 1516 \--------\ /------------------/ 1517 | +---------------+ 1518 | Interexchange | - - - - - - ---> To other 1519 | | (TLA) | interexchanges 1520 +---------------+ 1521 | /--------/ | \ \---------------\ 1522 | / | \ \ 1523 +-----------+ +--------+ \ +-----------+ 1524 | Long-Haul | |Provider| \ | Long-Haul | 1525 | Provider | +--------+ | | Provider | 1526 +-----------+ | | +-----------+ 1527 | | | | | 1528 +----------+ | | +----------+ +----------+ 1529 |Subscriber| | | |Subscriber| | Provider | 1530 +----------+ | \ +----------+ +----------+ 1531 +----------+ \ | 1532 |Subscriber| \ | 1533 +----------+ +----------+ +----------+ 1534 |Subscriber| |Subscriber| 1535 +----------+ +----------+ 1537 Figure 13: Aggregation-based Allocation Structures 1539 designers because it allows a choice between various allocation 1540 approaches. Provider allocation divides the hierarchy along lines of 1541 large service providers, regardless of their location. Geographic 1542 allocation divides the hierarchy strictly on the basis of the 1543 location of providers/subscribers (as does the telephony system 1544 of country and area codes). Both of these approaches have their 1545 drawbacks because large backbone networks often don't conform 1546 strictly to geographic or provider boundaries. Some large networks, 1547 for instance, may connect to several ISPs; many large networks span 1548 numerous countries and geographical regions. 1550 Aggregation-based allocation is based on the existence today of a 1551 limited number of high-level exchange points, where large long-haul 1552 service providers and telephone networks interconnect. The use 1553 of these exchange points to divide the IPv6 address hierarchy has 1554 a geographical component because exchanges are distributed around 1555 the globe. It also has a provider orientation because all large 1556 providers are represented at one or more exchange points. 1558 | 3| 13 | 8 | 24 | 16 | 64 bits | 1559 +--+-----+---+--------+--------+--------------------------------+ 1560 |FP| TLA |RES| NLA | SLA | Interface ID | 1561 | | ID | | ID | ID | | 1562 +--+-----+---+--------+--------+--------------------------------+ 1563 <--Public Topology---> Site 1564 <--------> 1565 Topology 1566 <------Interface Identifier-----> 1568 Figure 14: Aggregation-based IPv6 Addresses 1570 As shown in Figure 14, the first 3 address bits indicate what type 1571 of address follows (unicast, multicast, etc.). The next 13 bits 1572 are allocated to the various TLAs around the world. Eight bits are 1573 reserved for future use, and the following 24 bits are allocated to 1574 the next lower level of providers and subscribers. 1576 Next level aggregators can divide the NLA address field to create 1577 their own hierarchy, one that maps well to the current ISP industry, 1578 in which smaller ISPs subscribe to higher level ISPs, and so on. 1579 This is accomplished by the further subdivision of the 32-bit 1580 NLA field (see Figure 15). Following the NLA ID are fields for 1582 <------------ 32 bits -----------> <--16 bits-> <---- 64 bits ----> 1583 +-------+-------------------------+------------+-------------------+ 1584 | NLA 1 | Site | SLA | Interface ID | 1585 +-------+-------------------------+------------+-------------------+ 1586 +-------+-----------------+------------+-------------------+ 1587 | NLA 2 | Site | SLA | Interface ID | 1588 +-------+-----------------+------------+-------------------+ 1589 +-----------------+------------+-------------------+ 1590 | NLA 3 | Site | SLA | Interface ID | 1591 +-----------------+------------+-------------------+ 1593 Figure 15: Subdividing the NLA Address Space 1595 subscriber site networking information: Site Level Aggregator (SLA) 1596 and Interface ID. Typically, service providers supply subscribers 1597 with blocks of contiguous addresses, which are then used by 1598 individual organizations to create their own local address hierarchy 1599 and identify subnets and hosts. The 16-bit SLA field supports up to 1600 65,535 individual subnets. The 64-bit Interface ID, which is used 1601 to identify an IPv6 interface on a network link, will typically be 1602 derived from the installed MAC address. Large sites are expected to 1603 get an entire SLA. 1605 Internet backbone routers must maintain 75,000 or more routes. As 1606 the Internet continues to grow in size, IPv6's uniform application 1607 of hierarchical routing will likely be the only viable method for 1608 keeping the size of backbone router tables under control. With an 1609 aggregator-based address hierarchy, all of a subscriber's internal 1610 network segments can be reached through one or more high-level 1611 aggregation points. This allows backbone routers around the globe 1612 to efficiently summarize the routes to a customer's networks with 1613 high-level TLA address prefixes. Routing tables in the highest-level 1614 backbones can be calculated quickly and efficiently because of 1615 the relatively small number of aggregated routes compared with 1616 IPv4. IPv6's large hierarchical address space also allows a more 1617 decentralized approach to IP address allocation. Service providers 1618 can allocate addresses independently from central authorities, 1619 encouraging global network growth and eliminating bureaucratic 1620 bottlenecks in the growth process. 1622 Aggregation-based addresses are just part of the total address 1623 space that has been defined for IPv6. Other address ranges have 1624 been assigned to multicasting and to nodes that only require 1625 unique addresses within a limited area (site-local and link-local 1626 addresses). 1628 Site-local and link-local addresses are available for private, 1629 internal use by all enterprises, and are not allocated by public 1630 registry authorities. Site-local addresses enable two separate 1631 domains to use the same non-unique addresses that never collide 1632 because site-local routing restrictions keep them apart. This has 1633 an advantage: if an ISP changes, site local addresses can remain 1634 the same because they do not directly connect to the outside world. 1635 Link local addresses operate only over a single link, and can be used 1636 for temporary "bootstrapping" of network nodes before they receive a 1637 globally unique address (more on this in section 2.12). 1639 2.12. Host Address Autoconfiguration 1641 IPv6 has an address architecture [17] that can accommodate Internet 1642 expansion for many decades to come. Furthermore, IPv6 hosts can 1643 have their addresses automatically configured and reconfigured in a 1644 cost-effective and manageable way. Automatic address configuration 1645 is necessary in hierarchical routing because it supports scalable 1646 (and thus cost-effective) numbering and renumbering of large 1647 populations of IP hosts. Even a small renumbering cost, if incurred 1648 tens of thousands of times for every ISP connection, adds up to a 1649 major administrative headache. Conversely, scalable renumbering 1650 techniques will enable business enterprises to shop for the best 1651 connectivity solutions with reduced renumbering costs of reconnection 1652 to a new provider. 1654 Autoconfiguration capabilities are important regardless of which 1655 style of address allocation is in effect. Occasionally, it may 1656 be necessary to renumber every host within an organization, as 1657 would be the case with a company that relocated its operations 1658 (with geographic addressing) or changed to another service provider 1659 (with provider-based addressing). Configuration of IP addresses 1660 is a fact of life at the workgroup and department levels of large 1661 networked organizations. IP addresses need to be configured for new 1662 hosts, for hosts that change location, and for hosts connected to 1663 physical networks that must be renumbered in response to external 1664 considerations (e.g., when a site changes ISPs). In addition to 1665 these traditional requirements for configuration, new requirements 1666 are emerging as large numbers of hosts become mobile. These 1667 requirements for reduced static configuration of router addresses, 1668 route parameters, and server addresses, are basically not met in any 1669 meaningful way for use with the existing IPv4 installed base. 1671 The process of autoconfiguration under IPv6 starts with the Neighbor 1672 Discovery (ND) protocol [32]. ND combines and refines the services 1673 provided in the IPv4 environment by Address Resolution Protocol 1674 (ARP) [36], Internet Control Message Protocol (ICMP) [37], and Router 1675 Advertisement [13]. Although it has a new name, ND is actually just 1676 a set of complementary ICMPv6 [10] messages that allow IPv6 nodes 1677 on the same link to discover link-layer addresses and to obtain and 1678 advertise various network parameters and reachability information. 1679 In a typical scenario, a host starts the process of autoconfiguration 1680 by creating a link-local address [42]. This address can be formed 1681 by prepending a generic local address prefix to a unique token 1682 (typically derived from the host's IEEE LAN interface address [21]). 1683 Once this address is formed, the host sends out an ND message to 1684 ensure that the address is unique. If no ICMP Neighbor Advertisement 1685 message comes back, the address is presumed unique. If a message 1686 comes back indicating that the link-local address is already in use, 1687 then a different token can be used (e.g., an administrative token, 1688 centrally generated, or a randomly generated token). 1690 Using the new link local address as a source address, the host then 1691 sends out an ND router solicitation, or waits for a periodic router 1692 advertisement. The solicitation is sent out using the IPv6 multicast 1693 service. Unlike the broadcast ARPs of IPv4, IPv6 ND multicast 1694 solicitations are not necessarily processed by all nodes on the link, 1695 which can conserve processing resources in hosts. IPv6 currently 1696 defines several permanent multicast groups for finding resources on 1697 the local node or link, including an all-routers group, an all-hosts 1698 group, and a DHCP server group. Routers respond to solicitation 1699 messages from hosts with a router advertisement that contains, 1700 among other things, prefix information that indicates a valid range 1701 of addresses for the subnet. The ND message exchange is shown in 1702 Figure 16. Routers also send unsolicited advertisements periodically 1703 to local multicast groups. 1705 +---+ +---+ 1706 | Y |---------------------| Z | 1707 +---+ +---+ 1708 / \ 1709 ----/ \----- 1710 / \ 1711 +---+ ----- Router Solicitation ------> +-----+ 1712 | X | | rtr |====To Internet 1713 +---+ <----- Router Advertisement ----- +-----+ 1714 \ / 1715 ---- ----- 1716 \ / 1717 \ / 1718 +---+ +---+ 1719 | W |---------------------| V | 1720 +---+ +---+ 1722 Figure 16: Neighbor Discovery (ND) Router Message Exchange 1724 The router advertisement message controls whether hosts use stateless 1725 or stateful autoconfiguration methods. In the case of stateful 1726 autoconfiguration, the host will contact a stateful address server, 1727 which will assign an address from a manually administered list. 1728 DHCP [16] is the protocol of choice for autoconfiguration in IPv4 1729 networks and has been reformulated for the IPv6 environment [5, 35]. 1731 With the stateless approach [42], a host can automatically configure 1732 its own IPv6 address without the help of a stateful address server 1733 or any human intervention. The host uses the globally valid address 1734 prefix information in the router advertisement message to create its 1735 own IPv6 address. This process involves the concatenation of a valid 1736 prefix with the host's link-layer address or a similar unique token. 1737 As long as the token is unique on the link and the prefix received 1738 from the router is correct, the newly configured IP address should 1739 provide reachability for the host extending to the entire enterprise 1740 and the Internet at large. 1742 The advantages of stateless autoconfiguration are many. For 1743 instance, if an enterprise changes service providers, the prefix 1744 information from the new provider can be propagated to routers 1745 throughout the enterprise, and hence to all stateless autoconfiguring 1746 hosts. Hypothetically, if all hosts in the enterprise use IPv6 1747 stateless autoconfiguration, the entire enterprise could be 1748 renumbered without the manual configuration of a single non-router 1749 host. At a more modest level, workgroups with substantial 1750 move/change activity also benefit from stateless autoconfiguration 1751 because hosts can receive a freshly configured and valid IP number 1752 each time they connect and reconnect to the network. 1754 +-------+ 1755 | Home | 1756 | Agent |\ 1757 +-------+ \ +---------------------+ 1758 \ | | 1759 ----------+ | +---+ 1760 | | /------------------| X | 1761 ----------+ <----/ | +---+ 1762 / | | 1763 / +---------------------+ 1764 / 1765 +--------+/ 1766 | Mobile | 1767 | Node | 1768 +--------+ 1770 Figure 17: Forwarding IP Traffic for Mobile IPv6 Nodes 1772 Address autoconfiguration plays an essential role in the support 1773 for mobile nodes within IPv6. Each mobile node can configure an 1774 appropriate address, no matter which network it is attached to; it 1775 uses this address as a kind of forwarding address (or, as it is 1776 called, a "care-of address"). Then, the mobile node can receive 1777 all of its data from its home network by asking a router (called a 1778 "home agent") to forward packets to it at its care-of address. This 1779 process is illustrated in figure 17. Better yet, the mobile node 1780 can also instruct any other node (e.g., node 'X' in the figure) to 1781 forward data to its care-of address, so that the data never traverses 1782 the home network. Although not shown by the figure, the mobile 1783 node is identified by its home address, even though it is receiving 1784 packets sent to its care-of address. This is important so that the 1785 mobile node can maintain its connections even when it is wireless 1786 and undergoing handoff operations during continued operation of its 1787 network applications. 1789 To facilitate dynamic host renumbering, IPv6 has a built-in 1790 mechanism to create a graceful transition from old to new addresses. 1791 Fundamental to this mechanism is the ability of IPv6 nodes to support 1792 multiple addresses per interface. IPv6 addresses assigned to an 1793 interface can be identified as valid, deprecated, or invalid. In 1794 the renumbering process, an interface's IPv6 address would become 1795 deprecated when a new address was automatically assigned (e.g., in 1796 the case of network renumbering). For a period of time after the new 1797 (valid) address is configured, the deprecated address continues to 1798 send and receive traffic. This allows sessions and communications 1799 based on the older address to be finished gracefully. Eventually 1800 the deprecated address becomes invalid and the valid address is used 1801 exclusively. Issuing multiple IP addresses allows renumbering to 1802 occur dynamically and transparently to end users and applications. 1803 Besides simplifying host renumbering, IPv6 has work underway to help 1804 with reconfiguring routers [11]. 1806 The above described stateless autoconfiguration process is 1807 particularly suited to conventional IP/LAN environments with 48-bit 1808 or 64-bit link-level addressing [21] and native multicast services. 1809 Other network environments with different link characteristics may 1810 require modified or alternative configuration techniques. For 1811 instance, current ATM networks do not inherently support multicast 1812 services or IEEE MAC addresses, due to the use of virtual circuits 1813 and telephony-style calling numbers. Multicasting solutions for 1814 ATM are seen in the emerging Multicast Address Resolution Server 1815 (MARS) [40] developed for IPv4 multicast over ATM. Plans have 1816 been devised to use MARS-style functionality to extend the IPv6 1817 Neighbor Discovery protocol across ATM networks. This allows network 1818 renumbering and stateless autoconfiguration to take place seamlessly 1819 in hybrid ATM/IPv6 fabrics [3, 2]. 1821 2.13. Other Protocols and Services 1823 The preceding discussion focuses on some of the more innovative 1824 and radical changes that IPv6 brings to internetworking. In many 1825 other areas, protocols and services will operate much the same as 1826 they do in the current IPv4 regime. As the industry moves to IPv6, 1827 PPP, DHCP and DNS servers are being modified to accommodate 128-bit 1828 addresses, but in terms of basic functionality, there will be little 1829 change. This is also generally true for interior and exterior 1830 routing protocols. 1832 For example, OSPF has been updated with full support for IPv6 [9], 1833 allowing routers to be addressed with 128-bit addresses. The 32-bit 1834 link-state records of current OSFP will be replaced by 128-bit 1835 records. In general, the OSPF IPv6 link-state database of backbone 1836 routers will run in parallel with the database for IPv4 topologies. 1838 In this sense, the two versions of OSPF will operate as "ships in the 1839 night," just as the routing engines for IPv4, OSI and proprietary 1840 protocols may coexist in the same router without major interaction. 1841 Given the limited nature of the OSPF IPv6 upgrade, those engineers 1842 and administrators who are proficient in OSPF for IPv4 should have 1843 little trouble adapting to the new version. An updated version of 1844 RIP is also available [28]. 1846 As with the interior gateway protocols, RFC 2545 provides a 1847 IPv6-compatible version of the exterior gateway protocols that 1848 are used by routers to establish reachability across the Internet 1849 backbone between large enterprises, providers, and other autonomous 1850 systems. Today's backbone routers use the Border Gateway Protocol 1851 (BGP) to distribute CIDR-based routing information throughout the 1852 Internet. BGP is known by providers and enterprises and has a large 1853 installed base. BGP extensions [29] have been defined to exchange 1854 reachability information based on the new IPv6 hierarchical address 1855 space. 1857 3. Transition Scenarios 1859 Section 1 of this paper provided an overview of the major transition 1860 mechanisms that are integral to the IPv6 design effort. These 1861 techniques include dual-stack IPv4 /IPv6 hosts and routers, tunneling 1862 of IPv6 via IPv4, and a number of IPv6 services, including IPv6 DNS, 1863 DHCP, MIBs, and so on. The flexibility and usefulness of the IPv6 1864 transition mechanisms are best gauged through scenarios that address 1865 real-world networking requirements. 1867 3.1. First Scenario: No Need to NAT 1869 Take, for instance, the case of two large, network-dependent 1870 organizations that must interface operations due to a merger and 1871 acquisition (M&A), or a new business partnership. Suppose both 1872 of the enterprises have large IPv4-based networks that have grown 1873 from small beginnings. Both of the original enterprises have a 1874 substantial number of private IPv4 addresses that are not necessarily 1875 unique within the current global IPv4 address space. Combining these 1876 two non-unique address spaces could require costly renumbering and 1877 restructuring of routers, host addresses, domains, areas, exterior 1878 routing protocols, and so on. This scenario is common in the current 1879 business climate, not only for Merger and Acquisition (M&A) projects, 1880 but also for large outsourcing and customer/supplier networking 1881 relationships, where many hosts from the parent, outsourcer, 1882 supplier, or partner must be integrated into one existing enterprise 1883 address structure. For these situations, IPv6 offers a convenient 1884 solution. 1886 -------------- -------------- 1887 / \ / \ 1888 | Enterprise | +----------+ | Enterprise | 1889 | A |-------| IPv6 rtr |-------| B | 1890 \ / +----------+ \ / 1891 -------------- -------------- 1892 ^ | 1893 | | 1894 | v 1895 +-------+ +-------+ 1896 |IPv4 + | IPv6 communication |IPv4 + | 1897 | IPv6| - - - - - - - - - - - - - > | IPv6| 1898 | Host | | Host | 1899 +-------+ +-------+ 1901 Figure 18: IPv6 Unites Private Address Spaces 1903 The task of logically merging two enterprise networks into a single 1904 autonomous domain can be expensive and disruptive. To avoid the 1905 cost and disruption of comprehensive renumbering, enterprises 1906 may be tempted to opt for the stopgap solution of a network 1907 address translator (NAT). In the M&A scenario, a NAT could allow 1908 the two enterprises to maintain their private addresses more or 1909 less unchanged. To accomplish this, a NAT must conduct address 1910 translation in real time for all packets that move between the two 1911 organizations. Unfortunately, this solution introduces all the 1912 problems associated with NATs that were discussed in section 1.2.2, 1913 including performance bottlenecks, lack of scalability, lack of 1914 standards, and lack of universal connectivity among all the nodes in 1915 the new enterprise and the Internet. 1917 In contrast with NAT, IPv6 seamlessly integrates the two physical 1918 networks (see Figure 18). Suppose the two originally independent 1919 enterprises are known as Enterprise A and Enterprise B. The first 1920 step is to determine which hosts need access to both sides of the 1921 new organization. These hosts are outfitted with dual IPv4/IPv6 1922 stacks, which allow them to maintain connectivity to their original 1923 IPv4 network while also participating in a new IPv6 logical 1924 network that will be created "on top" of the existing IPv4 physical 1925 infrastructure. 1927 The accounting department of the combined enterprise will often have 1928 financial applications on servers that will need to be accessed 1929 by accounting employees in both Enterprise A and Enterprise B. 1930 Both servers and clients will run IPv6, but they will also retain 1931 their IPv4 stacks. The IPv6 sessions of the accounting department 1932 will traverse the existing local and remote links as "just another 1933 protocol," requiring no changes to the physical network. The only 1934 requirement for IPv6 connectivity is that routers that are adjacent 1935 to accounting department users must be upgraded to run IPv6. Where 1936 end-to-end IPv6 connectivity can't be achieved, one of the IPv4/IPv6 1937 tunneling techniques can be employed. 1939 As integration continues, other departments in the newly merged 1940 enterprises will also be given IPv4/IPv6 hosts. As new departments 1941 and workgroups are added, they may be given dual-stack hosts, or in 1942 some cases, IPv6-only hosts. Hosts that require communications to 1943 the outside world via the Internet will likely receive dual stacks to 1944 maintain compatibility with IPv4 nodes exterior to the enterprise. 1945 But in some cases, hosts that only require access to internal servers 1946 and specific outside partners may be able to achieve connectivity 1947 with IPv6-only hosts. A migration to IPv6 presents the opportunity 1948 for a fresh start in terms of address allocation and routing protocol 1949 structure. IPv6 hosts and routers can immediately take advantage 1950 of IPv6 features such as stateless autoconfiguration, encryption, 1951 authentication, and so on. 1953 3.2. Second Scenario: IPv6 from the Edges to the Core 1955 For corporate users, connectivity requirements typically focus 1956 primarily on access to local e-mail, WWW, database, and applications 1957 servers. In this case, it may be best to initially upgrade only 1958 isolated workgroups and departments to IPv6, with backbone router 1959 upgrades implemented at a slower rate. As shown in Figure 19, 1960 independent workgroups can upgrade their clients and servers 1961 to dual-stack IPv4/IPv6 hosts or IPv6-only hosts. This creates 1962 "islands" of IPv6 functionality. 1964 After the first few IPv6 routers are in place, it may be desirable 1965 to connect IPv6 islands together with router-to-router tunnels. In 1966 this case, one or more routers in each island would be configured 1967 as tunnel endpoints. As illustrated in section 1, in figure 4, 1968 when hosts use full IPv6 128-bit addressing, tunnels are manually 1969 configured so that the routers participating in tunnels know the 1970 address of the endpoints of the tunnel. With IPv4-compatible IPv6 1971 addresses, automatic, nonconfigured tunneling is possible. 1973 Routing protocols treat tunnels as a single IPv6 hop, even if 1974 the tunnel is comprised of many IPv4 hops across a number of 1975 different media. IPv6 routers running OSPF can propagate link-state 1976 reachability advertisements through tunnels, just as they would 1977 across conventional point-to-point links. In the IPv6 environment, 1978 OSPF can ensure that each tunnel is weighted properly within the 1979 topology. Routers generally make packet-forwarding decisions in the 1980 IPv6 "Island" IPv6 "Island" 1981 -------------------- -------------------- 1982 | | | | 1983 | Dual Stack Hosts | | Dual Stack Hosts | 1984 | +---+ +---+ | | +---+ +---+ | 1985 | | | | | | | | | | | | 1986 | +---+ +---+ | | +---+ +---+ | 1987 | | | | | | | | 1988 | \ / | | \ / | 1989 | +-------+ | | +-------+ | 1990 | | Dual | | | | Dual | | 1991 | | Stack | | | | Stack | | 1992 | | Router| | | | Router| | 1993 | +-------+ | | +-------+ | 1994 | | | | 1995 -------------------- -------------------- 1996 \ / 1997 \ / 1998 +------+ +------+ 1999 IPv4 | IPv4 |-------------------| IPv4 | IPv4 2000 Hosts | rtr | | rtr | Hosts 2001 +---+ +------+ IPv4 +------+ +---+ 2002 | X |-\ / \ infrastructure / \ /-| W | 2003 +---+ \ / \-------\ /--------/ \ / +---+ 2004 \ / \ / \ / 2005 +---+ \ +-----+ +-----+ +-----+ / +---+ 2006 | Y |------| rtr |----------| rtr |---------| rtr |------| Z | 2007 +---+ +-----+ +-----+ +-----+ +---+ 2009 Figure 19: Islands of IPv6 2011 tunneling environment in the same way as in the IPv6-only network. 2012 The underlying IPv4 connections are essentially transparent to IPv6 2013 routing protocols. 2015 3.3. Other mechanisms 2017 Additional mechanisms for transition or for IPv4/IPv6 coexistence 2018 are also under discussion. For example, IPv4 multicast can be used 2019 to support neighbor discovery by isolated IPv6 nodes [8]. There are 2020 several proposals on how to support transactions between IPv4-only 2021 nodes and IPv6 nodes that do not have IPv4-compatible addresses. 2023 IETF members are putting intense effort into transition, as well 2024 as the basic IPv6 protocol specification. The combination of 2025 tunnels, compatible addresses, and dual-stack nodes gives network 2026 administrators the range of flexibility and interoperability they 2027 need to deploy IPv6. Transition services allow organizations 2028 depending upon current IPv4 networks to take advantage of the more 2029 technical IPv6 features. 2031 4. Security Considerations 2033 Sections 1.2.4, 2.8, and 2.9 of this paper emphasize the security 2034 benefits that IPv6 offers. By adopting IPv6, the Internet and the 2035 enterprise-specific applications will be much better able to satisfy 2036 their security needs by making use of standardized network features. 2037 Expediting the deployment for IPv6 will bring these security features 2038 into service sooner. Furthermore, the Internet will be able to 2039 avoid the security pitfalls made more likely by the deployment of 2040 NAT devices, as discussed in Section 1.2.2, and arising from any 2041 applications using IPv4 source routing (see section 2.5). 2043 5. Acknowledgments 2045 This work is derived from a Bay Networks white paper on IPv6 2046 (published in 1997) that was co-authored by Steve King, Ruth Fax, 2047 Dimitri Haskin, Wenken Ling, and Tom Meehan. They were all employed 2048 by Bay Networks at that time. Thanks to Steve Deering and Bob Hinden 2049 for their many efforts as chairs of the IPng working group. Thanks 2050 to Matt Crawford and Thomas Narten for their additional detailed 2051 comments. 2053 Full Copyright Statement 2055 Copyright (C) The Internet Society (1998). All Rights Reserved. 2057 This document and translations of it may be copied and furnished to 2058 others, and derivative works that comment on or otherwise explain it 2059 or assist in its implementation may be prepared, copied, published 2060 and distributed, in whole or in part, without restriction of any 2061 kind, provided that the above copyright notice and this paragraph 2062 are included on all such copies and derivative works. However, 2063 this document itself may not be modified in any way, such as by 2064 removing the copyright notice or references to the Internet Society 2065 or other Internet organizations, except as needed for the purpose 2066 of developing Internet standards in which case the procedures 2067 for copyrights defined in the Internet Standards process must be 2068 followed, or as required to translate it into languages other than 2069 English. 2071 The limited permissions granted above are perpetual and will not be 2072 revoked by the Internet Society or its successors or assigns. 2074 This document and the information contained herein is provided on an 2075 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2076 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2077 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2078 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2079 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2081 A. Myths 2083 Because of its potential for future dominance and the number of 2084 detailed technical choices that had to be made, the birth of IPv6 2085 has been attended by some controversy, and by a number of somewhat 2086 misleading stories that can distract network owners who are in 2087 the process of crafting their forward-looking network strategy. 2088 Confusion is to be expected, considering the implications of 2089 migrating our global internetwork infrastructure to an updated 2090 protocol. But if the IPv6 myths are perpetuated indefinitely, 2091 there's a risk that the Internet will not be able to progress 2092 beyond a patched-up version of IPv4. In these appendices, we try to 2093 counteract some of these myths. 2095 Myth #1: The only driving force behind IPv6 is address space 2096 depletion. 2098 Many of the discussions about a new Internet protocol focus on the 2099 fact that we will sooner or later run out of globally unique network 2100 layer addresses, due to IPv4's fixed 32-bit address space. The 2101 various address registries that assign blocks of IP addresses to 2102 large network service providers and network operators have become 2103 quite cautious about the way these addresses are handed out, though 2104 most predictions for IPv4 address exhaustion target a time frame that 2105 starts well into the this decade. 2107 With the long-haul in mind, IPv6 has been outfitted with a 128-bit 2108 address space that should guarantee globally unique addresses for 2109 every conceivable variety of network device for the foreseeable 2110 future (i.e., decades). IPv6 has 16 byte addresses, or 2112 340,282,366,920,938,463,463,374,607,431,768,211,456 2114 addresses (over a third of a duodecillion of them, in fact). The 2115 number of addresses gets a lot of attention but it is only one of 2116 many important issues that IPv6 designers have tackled. Other IPv6 2117 capabilities have been developed in direct response to current 2118 business requirements for more scalable network architectures, 2119 mandatory security and data integrity, extended quality-of-service 2120 (QoS), autoconfiguration, and more efficient network route 2121 aggregation at the global backbone level. These features are all 2122 specified with IPv6 in a way that would be difficult to realize as 2123 effectively in IPv4. 2125 Myth #2: Extensions to IPv4 can replicate IPv6 functionality. 2127 There have been multiple efforts to extend the life of IPv4 2128 incrementally with evolutionary changes to the protocol standards and 2129 various proprietary techniques. One such example is the development 2130 of network address translators (NAT) that preserve IPv4 address space 2131 by intercepting traffic and converting private intra-enterprise 2132 addresses into one or a few globally unique Internet addresses. 2133 Other examples include the various QoS and security enhancements to 2134 IPv4, which are in general scaled-back or identical to mechanisms 2135 specified in IPv6. 2137 We do not know how long IPv4's life can be extended by these 2138 techniques. What is certain is that the widespread introduction 2139 of NAT devices negatively affects the end-to-end viability of 2140 emerging Internet applications; in practice only a limited set of 2141 well-known applications can be correctly handled by NAT devices or 2142 by application level gateways associated with them. In particular 2143 NAT devices prevent the deployment of end-to-end IPv4 security. 2144 Furthermore, the development of new and innovative Internet 2145 applications is burdened with the design constraints posed by 2146 NATs [20]. Since NAT is strictly unnecessary for IPv6, standard 2147 end-to-end IPv6 security can be deployed, and a future enlivened 2148 by new lightweight and more fully functional applications can be 2149 envisioned. NAT translation is also known to create great difficulty 2150 in the construction of Virtual Private Networks (VPNs), since it 2151 makes address space administration difficult and interferes with 2152 standard security mechanisms. 2154 NAT also only works in a "flat universe" for a site accessing the 2155 global Internet - even moderately-sized enterprises are not flat 2156 internally, with nested multi-party relationships. Realistic NAT 2157 deployment solutions would have to include routing via multiple 2158 ingress/egress NATs for load balancing, multi-NAT-hop routes and 2159 so on - all this would create in miniature the v4 (or in fact v6) 2160 architecture, since it is solving the same problem, but piecewise and 2161 badly. 2163 It is hard to compare the costs of converting to IPv6 with those of 2164 remaining with IPv4 and its upgrades. Every network manager will 2165 have to make this comparison; but staying with IPv4 has been likened 2166 to the situation of a lobster in a pot of water, as the temperature 2167 slowly increases - at first, it feels comfortable. 2169 Myth #3: IPv6 support for a large diversity of network devices is 2170 not an end-user or business concern. 2172 Over the next few years, conventional computers on the Internet will 2173 be joined by a myriad of new devices, including palmtop personal 2174 data assistants (PDA), hybrid mobile phone technology with data 2175 processing capabilities, smart set-top boxes with integrated Web 2176 browsers, and embedded network components in equipment ranging from 2177 office copy machines to kitchen appliances. Some of the new devices 2178 requiring IP addresses and connectivity will be consumer-oriented, 2179 but many will become integral to the information management functions 2180 of corporations and institutions of all sizes. These new devices 2181 require features not fully understood by most protocol designers 2182 during the initial growth of the IPv4 Internet. 2184 IPv6's 128-bit address space will allow businesses to deploy a huge 2185 array of new desktop, mobile, and embedded network devices in a 2186 cost-effective, manageable way. Further, IPv6's autoconfiguration 2187 features will make it feasible for large numbers of devices to attach 2188 dynamically to the network, without incurring unsupportable costs for 2189 the administration for an ever-increasing number of adds, moves, and 2190 changes. 2192 The business requirement for IPv6 will be driven by end-user 2193 applications. Applications for mobile nodes, electronic commerce, 2194 and those needing specialized routing features will be easier 2195 to design and implement using IPv6, especially as compared to 2196 IPv4 patched by NAT. To remain competitive in the coming era of 2197 high-density networking, businesses should exploit IPv6 to create a 2198 highly scalable address space and robust autoconfiguration services 2199 that will remain viable in the face of an explosion of end-user 2200 networking needs. 2202 Myth #4: IPv6 is primarily relevant to backbone routers, not 2203 end-user applications. 2205 It is true that IPv6 address aggregation allows efficient multitiered 2206 routing hierarchies that prevent the uncontrolled growth of backbone 2207 router tables. But many of the advanced features of IPv6 also 2208 bring direct benefits to end-user applications at the workgroup 2209 and departmental levels. For instance, applications will have 2210 available the mandatory IPv6 encryption and authentication services 2211 as an integral part of the IP stack. For mobile business users 2212 and changing organizations, IPv6 autoconfiguration will allow the 2213 efficient assignment of IP addresses without the delays and cost 2214 associated with manual address administration or even traditional 2215 DHCP, which takes place in many current IP networks. IPv6 is very 2216 much both an end-user concern and a business concern. This concern 2217 will become increasingly important as QoS flows and QoS routing 2218 become important architectural components of the Internet. 2220 Myth #5: Asynchronous Transfer Mode (ATM) cell switching will negate 2221 the need for IPv6. 2223 ATM and other switching methods offer interesting technology for 2224 present and future internetworks, but ATM is, by itself, not a 2225 replacement for packet routing Internet architecture. ATM is better 2226 understood as a link-layer technology over a non-broadcast multiple 2227 access (NBMA) medium. It gives some isolation properties, and 2228 offers the promise for offering improved Quality of Service (QoS) 2229 connections for applications that need it. Even these hypothetical 2230 advantages are not yet fully developed for ATM, and it is possible 2231 that these advantages will be equally well available in future IPv6 2232 networks not running over ATM. 2234 Fortunately, network owners do not have to make a choice between ATM 2235 or IPv6 because the two protocols will continue to serve different 2236 and complementary roles in corporate networking. Large networks 2237 will make use of both protocols. For many network designers, 2238 ATM is a useful transmission medium for high-speed IPv6 backbone 2239 networks. Standards and development work has integrated ATM and IPv6 2240 environments. IPv6, like its predecessor IPv4, provides network 2241 layer services over all major link types, including ATM, Ethernet, 2242 Token Ring, ISDN, Frame Relay, and T1. 2244 Myth #6: IPv6 is something that only large telephone companies or 2245 the government should worry about. 2247 Some Internet pundits have characterized IPv6 as a concern that's 2248 outside the corporate network and outside the current time frame. 2249 In reality, IPv6 is a standards track and mainstream solution 2250 for the operation and continued efficiency of day-to-day business 2251 activities. But the only way that IPv6 will take hold and succeed is 2252 if businesses and institutions of all types come to terms with the 2253 inadequacies of IPv4 and begin to lay plans for migration. In the 2254 past few years, Internet protocols have enabled a whole new style of 2255 distributed commerce that brings people together inside enterprises 2256 and gives enterprises access to the entire world. In fact, the 2257 sustained and impressive growth of the Internet, which has inspired 2258 the current engineering efforts for IPv6, is in large measure due to 2259 the penetration of the World Wide Web to business and consumer end 2260 users. Offering services to such end users is of interest to many 2261 more institutions than merely governments and telephone companies. 2263 Myth #7: IPv6 requires extensive modifications to existing operating 2264 systems, applications, and programming techniques. 2266 IPv6 obviously requires certain modifications to the network protocol 2267 handling modules installed on the relevant computers. However, 2268 this typically requires little or no change to the base operating 2269 system outside the network protocol stack. Simple and natural 2270 modifications, typically confined to fewer than a dozen lines of the 2271 programs, can be made to enable applications to use IPv6 addresses 2272 directly. Since IPv6 reserves a part of its address space for 2273 compatibility with IPv4 addresses, applications modified to handle 2274 IPv6 addresses can still communicate with existing IPv4 clients and 2275 servers. 2277 Moreover, the transition strategies defined for IPv6 deployment 2278 within the IPv4 Internet should make the gradual adoption of IPv6 a 2279 smooth process that allows existing applications to be converted for 2280 native IPv6 operation in a gradual, controlled manner. 2282 Myth #8: Too Little, Too Soon 2284 IPv6 appears as an incremental enhancement to IPv4, and some 2285 people say that if we are going to go to all the trouble to switch 2286 network-layer protocols, we really ought to go all out for some 2287 really futuristic feature-full new protocol. This argument ignores 2288 the following simple facts: 2290 - The purpose of a network-layer protocol is to hook together 2291 networks, and 2293 - IPv6 builds on the amazing success of IP, by not forgetting the 2294 successful parts, and by repairing the known faults. This is far 2295 different than starting over again with something unknown and 2296 untested. 2298 Those who claim that it is too early for IPv6 ignore the facts that 2299 existing solutions extending the life of IPv4 are clearly stopgap 2300 measures, and that one can put IPv6 into service now. 2302 Myth #9: Site Renumbering is fixed in IPv6 2304 Although IPv6 has gone a long way to enable more convenient 2305 renumbering operations, it is a mistake to say that renumbering is 2306 a completely solved problem. IPv6 engineers are still considering 2307 designs for renumbering routers, and for renumbering collections of 2308 computers larger than a single network. Furthermore, applications 2309 that have been ported from IPv4 to IPv6 do not automatically become 2310 more able to support renumbering. Some applications will require 2311 small design improvements in order to support renumbering. Lastly, 2312 the biggest impediment to renumbering seems typically to be the 2313 institution of administrative practices that key information directly 2314 on IP addresses instead of some more appropriate indexing method. 2315 These administrative practices require attention and adherence to 2316 more modern guidelines for Internet administration before the problem 2317 of renumbering can be considered to be solved. 2319 Myth #10: Routing is fixed in IPv6 2321 Because IPv6 Routing is fundamentally the same as IPv4's CIDR, some 2322 have asserted that IPv6 routing has all the same problems as IPv4 2323 routing, and thus there is no benefit in moving to IPv6. However, 2324 IPv6 does offer improvements for routing in a number of ways. It 2325 allows for allocation of IPv6 addresses in a way that is more 2326 favorable for aggregation than existing IPv4 allocations. It allows 2327 for more streamlined packet forwarding than IPv4 routers can do, 2328 especially when IP options are used. IPv6's larger address space 2329 offers opportunities for more optimal network planning, since the 2330 constraints for planning out network connectivity have been relaxed 2331 to such a great extent. Furthermore, since every IPv6 router can be 2332 presumed to have security processing enabled, it is much easier to 2333 institute the appropriate security measures for authentication and 2334 keeping private data private. 2336 However, there are still many operational issues that need attention. 2337 IPv6 routing protocols are largely adapted from almost identical 2338 IPv4 routing protocols, and thus inherit some of the same problems. 2339 Improvements continue to be made to routing protocols to improve 2340 their stability, convergence time, and configurability. One of the 2341 hardest problems is to make routing protocols more human-friendly, 2342 so that it does not take a genius to make the routing fabric work 2343 reliably. There are remaining issues surrounding multi-homing that 2344 have not been solved. All of these issues will continue to receive 2345 the attention of engineers involved with the creation of IPv6. The 2346 scoped addresses and native security are expected to make their 2347 solution much easier. 2349 References 2351 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 2352 Extensions. Request for Comments (Draft Standard) 2132, 2353 Internet Engineering Task Force, March 1997. 2355 [2] G. Armitage, P. Schulter, and M. Jork. IPv6 over ATM Networks. 2356 Request for Comments (Proposed Standard) 2492, Internet 2357 Engineering Task Force, January 1999. 2359 [3] G. Armitage, P. Schulter, M. Jork, and G. Harter. IPv6 over 2360 Non-Broadcast Multiple Access (NBMA) networks. Request for 2361 Comments (Proposed Standard) 2491, Internet Engineering Task 2362 Force, January 1999. 2364 [4] D. Borman, S. Deering, and R. Hinden. IPv6 Jumbograms. Request 2365 for Comments (Proposed Standard) 2675, Internet Engineering Task 2366 Force, August 1999. 2368 [5] J. Bound and C. Perkins. Dynamic Host Configuration Protocol 2369 for IPv6 (DHCPv6). Internet Draft, Internet Engineering Task 2370 Force, May 2000. Work in progress. 2372 [6] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin. 2373 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 2374 Specification. Request for Comments (Proposed Standard) 2205, 2375 Internet Engineering Task Force, September 1997. 2377 [7] B. Carpenter. Architectural Principles of the Internet. 2378 Request for Comments (Informational) 1958, Internet Engineering 2379 Task Force, June 1996. 2381 [8] B. Carpenter and C. Jung. Transmission of IPv6 over IPv4 2382 Domains without Explicit Tunnels. Request for Comments 2383 (Proposed Standard) 2529, Internet Engineering Task Force, March 2384 1999. 2386 [9] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. Request for 2387 comments (proposed standard), Internet Engineering Task Force, 2388 December 1999. 2390 [10] A. Conta and S. Deering. Internet Control Message Protocol 2391 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2392 Specification. Request for Comments (Draft Standard) 2463, 2393 Internet Engineering Task Force, December 1998. 2395 [11] M. Crawford. Router Renumbering for IPv6. Internet Draft, 2396 Internet Engineering Task Force. Work in progress. 2397 draft-ietf-ipngwg-router-renum-10.txt, March 2000. 2399 [12] M. Crawford, C. Huitema, and S. Thomson. DNS Extensions to 2400 Support IPv6 Address Aggregation and Renumbering. Internet 2401 Draft, Internet Engineering Task Force. Work in progress. 2402 draft-ietf-ipngwg-dns-lookups-08.txt, May 2000. 2404 [13] S. Deering. ICMP Router Discovery Messages. Request for 2405 Comments (Proposed Standard) 1256, Internet Engineering Task 2406 Force, September 1991. 2408 [14] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 2409 Specification. Request for Comments (Draft Standard) 2460, 2410 Internet Engineering Task Force, December 1998. 2412 [15] M. Degermark, B. Nordgren, and S. Pink. IP Header Compression. 2413 Request for Comments (Proposed Standard) 2507, Internet 2414 Engineering Task Force, February 1999. 2416 [16] R. Droms. Dynamic Host Configuration Protocol. Request for 2417 Comments (Draft Standard) 2131, Internet Engineering Task Force, 2418 March 1997. 2420 [17] D. Eastlake. Domain Name System Security Extensions. Request 2421 for Comments (Proposed Standard) 2535, Internet Engineering Task 2422 Force, March 1999. 2424 [18] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, 2425 M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. 2426 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 2427 Specification. Request for Comments (Experimental) 2117, 2428 Internet Engineering Task Force, June 1997. 2430 [19] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless 2431 Inter-Domain Routing (CIDR): an Address Assignment and 2432 Aggregation Strategy. Request for Comments (Proposed Standard) 2433 1519, Internet Engineering Task Force, September 1993. 2435 [20] T. Hain. Architectural Implications of NAT. Internet Draft, 2436 Internet Engineering Task Force, May 1999. Work in progress. 2438 [21] IEEE. Guidelines for 64-bit Global Identifier (EUI-64) 2439 Registration Authority, March 1997. 2440 http://standards.ieee.org/db/oui/tutorials/EUI64.html. 2442 [22] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast 2443 Addresses. Request for Comments (Proposed Standard) 2526, 2444 Internet Engineering Task Force, March 1999. 2446 [23] D. Johnson and C. Perkins. Mobility Support in IPv6. 2447 draft-ietf-mobileip-ipv6-12.txt, April 2000. (work in 2448 progress). 2450 [24] S. Kent and R. Atkinson. IP Authentication Header. Request for 2451 Comments (Proposed Standard) 2402, Internet Engineering Task 2452 Force, November 1998. 2454 [25] S. Kent and R. Atkinson. IP Encapsulating Security Payload 2455 (ESP). Request for Comments (Proposed Standard) 2406, Internet 2456 Engineering Task Force, November 1998. 2458 [26] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 2459 for Message Authentication. Request for Comments 2460 (Informational) 2104, Internet Engineering Task Force, 2461 February 1997. 2463 [27] C. Madson and R. Glenn. The Use of HMAC-SHA-1-96 within ESP and 2464 AH. Request for Comments (Proposed Standard) 2404, Internet 2465 Engineering Task Force, November 1998. 2467 [28] G. Malkin and R. Minnear. RIPng for IPv6. Request for Comments 2468 (Proposed Standard) 2080, Internet Engineering Task Force, 2469 January 1997. 2471 [29] P. Marques and F. Dupont. Use of BGP-4 Multiprotocol Extensions 2472 for IPv6 Inter-Domain Routing. Request for Comments (Proposed 2473 Standard) 2545, Internet Engineering Task Force, March 1999. 2475 [30] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for 2476 IP version 6. Request for Comments (Proposed Standard) 1981, 2477 Internet Engineering Task Force, August 1996. 2479 [31] J. Moy. Multicast Extensions to OSPF. Request for Comments 2480 (Proposed Standard) 1584, Internet Engineering Task Force, March 2481 1994. 2483 [32] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 2484 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2485 2461, Internet Engineering Task Force, December 1998. 2487 [33] E. Nordmark. Site prefixes in Neighbor Discovery. Internet 2488 Draft, Internet Engineering Task Force, March 2000. Work in 2489 progress. 2491 [34] C. Partridge, T. Mendez, and W. Milliken. Host Anycasting 2492 Service. Request for Comments (Informational) 1546, Internet 2493 Engineering Task Force, November 1993. 2495 [35] C. Perkins and J. Bound. Extensions for the Dynamic Host 2496 Configuration Protocol for IPv6. 2497 draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress). 2499 [36] D. C. Plummer. Ethernet Address Resolution Protocol: Or 2500 converting network protocol addresses to 48.bit Ethernet address 2501 for transmission on Ethernet hardware. Request for Comments 2502 (Standard) 826, Internet Engineering Task Force, November 1982. 2504 [37] J. Postel. Internet Control Message Protocol. Request for 2505 Comments (Standard) 792, Internet Engineering Task Force, 2506 September 1981. 2508 [38] Y. Rekhter and T. Li. An Architecture for IP Address Allocation 2509 with CIDR. Request for Comments (Proposed Standard) 1518, 2510 Internet Engineering Task Force, September 1993. 2512 [39] P. Srisuresh and M. Holdrege. IP Network Address Translator 2513 (NAT) Terminology and Considerations. Request for Comments 2514 (Informational) 2663, Internet Engineering Task Force, August 2515 1999. 2517 [40] R. Talpade and M. Ammar. Multicast Server Architectures 2518 for MARS-based ATM multicasting. Request for Comments 2519 (Informational) 2149, Internet Engineering Task Force, May 1997. 2521 [41] S. Thomson and C. Huitema. DNS Extensions to support IP version 2522 6. Request for Comments (Proposed Standard) 1886, Internet 2523 Engineering Task Force, December 1995. 2525 [42] S. Thomson and T. Narten. IPv6 Stateless Address 2526 Autoconfiguration. Request for Comments (Draft Standard) 2462, 2527 Internet Engineering Task Force, December 1998. 2529 [43] K. Varadhan, S. Hares, and Y. Rekhter. BGP4/IDRP for IP---OSPF 2530 Interaction. Request for Comments (Proposed Standard) 1745, 2531 Internet Engineering Task Force, December 1994. 2533 [44] D. Waitzman, C. Partridge, and S. E. Deering. Distance Vector 2534 Multicast Routing Protocol. Request for Comments (Experimental) 2535 1075, Internet Engineering Task Force, November 1988. 2537 Editors' Addresses 2539 Questions about this memo can also be directed to the authors: 2541 Robert Fink Charles E. Perkins 2542 Esnet R&D Communications Systems Lab 2543 Lawrence Berkeley Nat'l Laboratory Nokia Research Center 2544 1 Cyclotron Road 313 Fairchild Drive 2545 Bldg. 50A, Room 3139 2546 Mail-Stop 50A-3111 2547 Berkeley, CA 94720 Mountain View, California 94043 2548 USA USA 2549 Phone: +1 510 486-5692 Phone: +1-650 625-2986 2550 Fax: +1 510 486-4790 Fax: +1 650 625-2502 2551 E-mail: rlfink@lbl.gov EMail: charliep@iprg.nokia.com 2552 www.iprg.nokia.com/~charliep