INTERNET-DRAFT W. Biemolt, SEC NGTRANS WG M. Kaat, SEC July 2000 T. Larder, CISCO H. Steenman, AT&T R. van der Pol, SURFnet G. Tsirtsis, BT Y. Sekiya, ISI A. Durand, SUN K. Yamamoto, IIJ On overview of the introduction of IPv6 in the Internet Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document is a guide to the introduction of IPv6 in the IPv4 based Internet or Intranets. Several general issues to start IPv6 networking in a predominantly IPv4 world are discussed, such as IPv6 addresses, IPv6 DNS and routing issues. Short descriptions are given of the different transition tools and mechanisms that translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The remainder of this document describes how IPv6 can be introduced in various environments, such as ISPs, Internet Exchanges and end user environments. Suggestions are given on the use of the different translation and migration tools in each environment. Table of Contents 1. Introduction 2. General IPv6 deployment issues 2.1 IPv6 addressing 2.2 IPv6 and DNS 2.3 Routing in IPv6 3. Basic transition mechanism 3.1 Dual IP stack 3.2 Tunneling 4. The Tools In System Solutions 4.1 Connecting IPv6 islands 4.1.1 Configured tunnels 4.1.2 Automatic tunnels 4.1.3 Tunnel Broker 4.1.4 6TO4 4.1.5 6OVER4 4.2 Communication between IPv4 and IPv6 nodes. 4.2.1 Dual stack model 4.2.2 Limited Dual stack model 4.2.3 SOCKS64 4.2.4 SIIT 4.2.5 NAT-PT 4.2.6 BIS 4.2.7 Transport Relay Translator 4.2.8 DSTM 5. Case Studies 5.1 Large organization with a lot of global IPv4 addresses 5.1.1 Motivations 5.1.2 Prerequisites 5.1.3 Getting experience 5.1.4 Step 1: dual stack servers and routers 5.1.5 Step 2: dual stack clients 5.1.6 Step 3: IPv6 aware applications 5.1.7 Step 4: Connection to the IPv6 Internet 5.1.8 Step 5: IPv6 only hosts 5.1.9 Step 6: IPv6 only node and IPv4 only server 5.2 Large organization with few global IPv4 addresses (a /24 or less) 5.3 The extranet case 5.4 Office or home network with ONE global ipv4 address 5.5 New network with brand new services 5.6 Introducing IPv6 in an ISP environment 5.6.1 Introducing IPv6 in the core network 5.6.2 Introducing IPv6 in the customer access network 5.7 Internet Exchange 5.7.1 The traditional IX model 5.7.1.1 Address space: 5.7.1.2 Addressing infrastructure on IX: 5.7.1.3 Updating the IPv6 registries: 5.7.1.4 BGP announcements: 5.7.2 The addressing IX model 5.7.2.1 Address space: 5.7.2.2 Addressing infrastructure on IX: 5.7.2.3 Updating the IPv6 registries: 5.7.2.4 Contracts with global transit ISPs (TLA ISPs) 5.7.2.5 BGP announcements: 6. Security considerations 7. References 8. Authors' addresses Appendix A - Example of IPv6 address usage A.1 IPv6 Address Assignments A.2 IPv6 Registration Issues A.3 Example of IPv6 address usage Appendix B - Example of IPv6 address usage B.1 Forward mapping B.2 Reverse mapping B.3 Implementations 1. Introduction This document is a guide to the introduction of IPv6 in the current IPv4 based Internet or Intranets. Section 2 shortly introduces some aspects concerning the introduction of IPv6 like addressing, DNS and routing. Addressing and DNS issues are more extensively discussed in the Appendices A and B respectively. In sections 3 and 4 short descriptions will be given of the different translation and migration tools and mechanisms that translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. In sections 5 and 6 we will discuss how IPv6 can be introduced in various typical environments. An overview is presented in chapter 5 where environments are categorized and the applicability of the different tools are discussed. In chapter 6 some examples of "real live" environments are presented. This document addresses the use of IPv6 in a unicast environment. Migration of IPv4 to IPv6 multicast environments has not been considered. This document is not intended to describe the complete migration from IPv4 to IPv6 for the whole Internet. It is however an attempt to describe the possibilities to introduce IPv6 in a predominantly IPv4 environment and have both IPv6 and IPv4 connectivity within the desired scope. 2. General IPv6 deployment issues The implementation of an IPv6 network is comparable to the implementation of an IPv4 network. In both cases address space needs to be obtained and the Domain Name System (DNS) and routing should be set up correctly. In Appendix A it is discussed how to obtain aggregatable globally routable IPv6 address space [RFC2374] and how to register this address space. Furthermore, it is discussed how IPv6 hosts can be registered in the DNS. Section 2.3 discusses some IPv6 routing issues. The transition from current IPv4 hosts will most probably follow a dual stack strategy. It is also foreseen however that new devices might be introduced on the network as IPv6 only hosts. Besides upgrading hosts and routers to IPv6 a few other issues need to be addressed like addressing, DNS and routing. These are shortly discussed in the following paragraph. 2.1 IPv6 addressing Some general information concerning IPv6 addressing is discussed in Appendix A. 2.2 IPv6 and DNS Applications are not supposed to directly handle IP addresses but should use names. The mapping between host names and IP addresses in the Domain Name System (DNS) is a crucial service on the Internet [RFC1034, RFC1035]. This service is provided by DNS servers. Using an A record a name can point to an IPv4 address (forward mapping) and using a PTR record an IPv4 address can be mapped back to a name (reverse mapping). This mechanism cannot easily be extended to support IPv6 addresses. Some enhancements are needed to use DNS with IPv6 addresses [RFC1886]. To support the storage of IPv6 addresses within DNS and to facilitate renumbering currently other extensions are being defined [DNSLOOKUP]. A more extensive discussion on IPv6 and DNS is presented in Appendix B. 2.3 Routing in IPv6 To exchange reachability information routing protocols are used. There are two types of routing protocols, the intra-domain (IGP) and inter-domain (EGP) routing protocols. In the IPv4 world commonly used IGPs are RIP, OSPF and IS-IS and the EGP that is used is mostly BGP4. Besides the use of routing protocols static routing can also be used. Routing protocols have been adapted to handle IPv6 routing information. RIP (RIPng) [RFC2080, RFC2081], BGP4 (BGP4+) [RFC2283, BGP4-IPV6], and OSPF [RFC2740] have IPv6 extensions defined. On the core of the IPv6 backbone, BGP4+ is recommended. IPv6 routing is very strict in aggregation. Care must be taken what to announce to other ISPs, especially in peerings with other TLA ISPs. ISPs should only announce sub-TLAs and smaller (i.e. at most a /29) to other TLA ISPs. The TLA ISP can decide which (sub-)TLAs it will announce to another TLA ISPs according to its routing policy. The TLA ISP is allowed to announce prefixes larger than a /29 to ISPs and customers that fall inside its own (sub-)TLA. Usually, a /48 is the largest prefix that will be announced. An NLA ISP can be multi-homed to several TLA ISPs. The NLA ISP will get a next level NLA from all of them, but the NLA ISP should not announce these NLAs to all TLA ISPs. The NLA ISP should only announce the NLA that was given by that TLA ISP to that TLA ISP. On the other side, the NLA ISP will announce all NLAs to its customers. For specific information about routing aspects of IPv6 transition see [RFC2185] and for 6bone routing guidelines see by [RFC2772] that obsoletes [RFC2546]. 3. Basic transition mechanism [RFC1933] defines some basic mechanism: - Dual IP stack. Providing complete support for both IPv4 and IPv6 in hosts or routers. - IPv6 over IPv4 tunneling. Encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures. +-------------------+ +--------+ | application | | IPv6 | +-------------------+ | domain | +--------+ | TCP / UDP | +--------*---* | +-------------------+ | IPv4 | | IPv4 | IPv6 | |networks| +-------------------+ | *---*--------+ | network layer | +--------+ | IPv6 | | | | domain | +-------------------+ +--------+ a. dual stack node b. route IPv6 over IPv4 only networks 3.1 Dual IP stack Dual stack nodes will be able to interoperate directly with both IPv4 and IPv6 nodes. They must provide resolver libraries capable of dealing with the IPv4 A records as well as the IPv6 AAAA or A6 records. When both A and AAAA or A6 records are listed in the DNS there are three different options [RFC1933], (i) return only IPv6 address(es), (ii) return only IPv4 address(es) or (iii) return both IPv4 and IPv6 addresses. The selection of which address type to return, or, in which order can affect what type of IP traffic is generated. The appelation "Dual Stack" in itself is somehow misleading. Most implementation of IPv6 do not offer two completely distinct TCP/IP stacks, one for IPv4 and one for IPv6, but an hybrid stack in which most of the code is shared between the two protocol suites. However, as the term "Dual Stack" is widely used in other documents, this text will keep on using it. 3.2 Tunneling IPv6 nodes (or networks) that are separate by IPv4 infrastructures can build a virtual link by configuring a tunnel. IPv6 packets going towards another IPv6 domain will then be encapsulated within IPv4 packets. The tunnel end-points are two IPv4 addresses and two IPv6 addresses. Two types of tunneling can be employed: configured and automatic. Configured tunnels are created by manual configuration. The 6bone itself is an example of a network containing mainly configured tunnels. Automatic tunnels on the other hand do not need manual configuration. The tunnel end-points are automatically determined by using IPv4 compatible IPv6 addresses [RFC2373]. Since most of the tunneling techniques described after are based on a tunnel using IPv4 addresses at both end of the tunnel, this means that many of the techniques cannot work if an IPv4 address translation happens between the two ends of the tunnel. 4. The Tools In System Solutions When introducing IPv6 in the Internet, one faces two different sets of problems. The first one is related to have IPv6 communications among two or more IPv6 islands isolated in the IPv4 world. The second set is related to the establishment of (or some sort of) communications between the existing IPv4 world and the new IPv6 world. In the first set of problems, solutions are generally based on dual stacks routers and IPv6 in IPv4 tunnels. Mechanism to solve the second set of problems rely on dual stack techniques, application level gateways, NAT technology or on temporary allocation of IPv4 address and IPv4 in IPv6 tunneling. This document define some generic criteria to compare tools. Applicability scope: where the transition tool applies to: site, host. A solution with scope of site generally enables a whole site to connect, where a scope of a host enables the connection of a host. IPv4 requirements: what is required in the IPv4 context to make the tool works. IPv4 address requirements: This tries to identify how many IPv4 addresses are required. In some contexts, the need for many IPv4 addresses can be a no-go criteria. IPv6 requirements: what is required in the IPv6 context to make the tool works. IPv6 address requirements: This identifies how many IPv6 addresses are required for this specific solution. Host requirements: What is needed for the hosts to participate in this solution. Router requirements: What is needed for the routers to enable this solution. Other requirements: other requirements not listed above. 4.1 Connecting IPv6 islands The mechanism describe here are designed to enable IPv6 communication between IPv6 islands isolated in the IPv4 world. All of them relay on tunnels. 4.1.1 Configured tunnels Manually configured tunnels can be used to connect IPv6 hosts or networks over an IPv4 infrastructure. Typically configured tunnels are used between sites where traffic will be exchanged regularly. Note that a site can be limited to a single host. Applicability scope: site IPv4 requirements: IPv4 inter connectivity between sites IPv4 address requirements: >= 1 per site IPv6 requirements: none IPv6 address requirements: none specific Host requirements: IPv6 stack or IPv4/IPv6 stack Router requirements: IPv4/IPv6 stack Other requirements: none 4.1.2 Automatic tunnels Automatic tunnels are used as configured tunnels to connect separated IPv6 hosts or networks. Automatic tunnels are created when needed and broken up when no longer necessary. Typically Automatic tunnels are used between individual hosts or between networks where only incidentally there is a need for traffic exchange. A pre-requisite for the use of Automatic tunnels is the existence of IPv4 compatible addresses for the IPv6 hosts that need intercommunication. These addresses allow the hosts to derive the IPv4 addresses of the tunnel endpoints from the IPv6 addresses. Applicability scope: host IPv4 requirements: IPv4 interconnectivity between sites IPv4 address requirements: 1 per host IPv6 requirements: none IPv6 address requirements: IPv4 compatible addresses Host requirements: IPv4/IPv6 stack Router requirements: none Other requirements: none As this solution requires one IPv4 address per hosts, its domain of application is extremely limited. 4.1.3 Tunnel Broker Configuring tunnels usually require cooperation of the two parties to set up the correct tunnel end-points. The tunnel broker model is a concept to help people to collect the necessary information to set up the tunnels. A tunnel broker can be viewed as an IPv6 ISP offering connectivity through IPv6 over IPv4 tunnels. Current implementations are web based tools that allows interactive setup of an IPv6 over IPv4 tunnel. By requesting a tunnel, the tunnel client gets assigned IPv6 addresses out of the address space of the tunnel provider. It can request either a single address or a network prefix if a site is to be connected. DNS will be updated automatically. The created tunnel will provide IPv6 connectivity between the tunnel provider's IPv6 environment and the isolated host/site. Applicability scope: host/site IPv4 requirements: none specific IPv4 address requirements: 1 IPv6 requirements: none IPv6 address requirements: none Host requirements: IPv4/IPv6 stack, IPv4 Web browser Router requirements: none Other requirements: Tunnel server 4.1.4 6TO4 The 6to4 [6TO4] tool is applicable for the interconnection of isolated IPv6 domains in an IPv4 world. The egress router of the IPv6 domain creates a tunnel to the other domain. The IPv4 endpoints of the tunnel are identified in the prefix of the IPv6 domain. This prefix is made up of a unique 6TO4 TLA plus an NLA that identifies the site by the IPv4 address of the translating egress router. Another interesting effect of 6to4 is that it automatically derives a /48 IPv6 from an IPv4 address. With this mechanism, sites can start to deploy IPv6 without having to ask IPv6 address space from the registries. It is also very valuable in the absence of IPv6 ISP as it reduce to zero the management of tunnels. Applicability scope: site IPv4 requirements: IPv4 interconnectivity between sites IPv4 address requirements: >= 1 per site IPv6 requirements: globally unique 6to4 prefix (TLA624) IPv6 address requirements: none Host requirements: IPv6 stack Router requirements: implementation of special forwarding and decapsulation rules Other requirements: creation of DNS record that reflects 6TO4 prefix and "IPv4" address NLA 4.1.5 6OVER4 6over4 [RFC2529] interconnects isolated IPv6 hosts in a site through IPv6 in IPv4 encapsulation without explicit tunnels. A virtual link is created using an IPv4 multicast group with organizational local scope. IPv6 multicast addresses are mapped to IPv4 multicast addresses to be able to do Neighbor Discovery. To route between the IPv6 Internet and the 6over4 domain in an organization, a router needs to be configured as 6over4 on at least one interface. Applicability scope: host IPv4 requirements: IPv4 multicast connectivity between hosts IPv4 address requirements: 1 per host IPv6 requirements: none IPv6 address requirements: none Host requirements: IPv4/IPv6 stack Router requirements: 6over4 configuration to route between different virtual links and/or virtual links and the IPv6 Internet Other requirements: To connect IPv6 hosts on different physical links, IPv4 Multicast routing must be enabled on the routers connecting the links 4.2 Communication between IPv4 and IPv6 nodes. when IPv6 islands are installed and connected together using one or several of the above mechanism, communication between IPv6 hosts is enabled. Communication between an IPv4 host and an IPv6 host may be important to establish. This can be done by several ways, either by relaying at the application level, or translating at the network layer or by temporarily allocating an IPv4 address to the IPv6 node. Note on Protocol Translation: Typically a protocol translator maps the fields in the packets header of one of the protocols to semantically similar fields in the packet header of the other protocol. A set of rules for the translation between IPv4 and IPv6 is defined in the SIIT [RFC2765] proposal further discussed below. It should be noted in IPv4 applications it is not uncommon that the application has knowledge of information from the network layer (like address length or addresses itself). An example of this is FTP. This makes it necessary not only to translate the network layer packets but also translate at the application layer. 4.2.1 Dual stack model In the dual stack model, all IPv6 nodes, hosts or routers, are dual stacked. That way, communication to IPv4 nodes takes place with the IPv4 stack and communication with the IPv6 world takes place with the IPv6 stack. The limitation of this approach is the need to allocate an IPv4 address to each new IPv6 equipment. Applicability scope: site IPv4 requirements: IPv4 addressing plan and IPv4 routing plan IPv4 address requirements: 1 per host, many per router IPv6 requirements: IPv6 addressing plan and IPv6 routing plan IPv6 address requirements: 1 per host, many per router Host requirements: IPv4/IPv6 stack Router requirements: IPv4/IPv6 stack, IPv6 routing protocols Other requirements: 4.2.2 Limited Dual stack model In the limited dual stack model, only the "server" nodes are dual-stacked. The new "client nodes" are IPv6 only. A server node is defined as a node hosting enterprise Internet services, such as file sharing, DNS, web... A client node is defined as a node not offering those services. With this approach, much less IPv4 addresses are used, but the communication between an IPv4 client node and an IPv6 one is broken. To re-establish this communication, proxies are installed for strategic services. Applicability scope: site IPv4 requirements: use existing IPv4 infrastructure IPv4 address requirements: 1 per server node IPv6 requirements: IPv6 addressing plan and IPv6 routing plan IPv6 address requirements: 1 per new host, many per new router Host requirements: IPv4/IPv6 stack on servers, IPv6 stack on new clients Router requirements: IPv4/IPv6 stack, IPv6 routing protocols Other requirements: 4.2.3 SOCKS64 The SOCKS Gateway [SOCKS-GATE] tool is a gateway system that accepts enhanced [SOCKS-EXT] SOCKS [RFC1928] connections from IPv4 hosts and relays it to IPv4 or IPv6 hosts. Especially for "socksified" sites, who already use SOCKS aware clients and a SOCKS server, SOCKS Gateway provides an easy way to let IPv4 hosts connect to IPv6 hosts. No DNS modifications or address mapping is needed. The principle can also be used to allow IPv6 hosts to connect to IPv4 hosts, IPv4 hosts over IPv6 networks and IPv6 hosts over IPv4 networks. The later cases resemble tunnel techniques without possible problems with fragmentation or hop limits. Applicability scope: site IPv4 requirements: none specific IPv4 address requirements: 1 per host IPv6 requirements: >= 1 per site IPv6 address requirements: none Host requirements: clients should be "socksified" Router requirements: none Other requirements: dual stack SOCKS server 4.2.4 SIIT The [SIIT] protocol describes a method to translate between IPv6 and IPv4. Translation is limited to the IP packet header. The work does not describe a method to assign a temporary IPv4 address to the IPv6 node. The translator is operating in a stateless mode, which means that translation needs to be done for every packet. Applicability scope: site IPv4 requirements: none IPv4 address requirements: 1 temporary per IPv6 host IPv6 requirements: none IPv6 address requirements: IPv4-mapped and IPv4-translated addresses to identify IPv4 nodes and IPv6 capable nodes respectively Host requirements: IPv6 stack Router requirements: none Other requirements: none 4.2.5 NAT-PT NAT-PT, defined in [RFC2766] address the communication between IPv6 only and IPv4 only hosts. The communication is realized by use of a dedicated device that does the translation between IPv4 and IPv6 addresses and keeps state during the time of the session. The NAT-PT device also includes an application layer gateway to make translation possible between IPv4 and IPv6 DNS requests and answers. Applicability scope: site IPv4 requirements: none IPv4 address requirements: >=1 per site IPv6 requirements: none IPv6 address requirements: none Host requirements: IPv6 stack Router requirements: none, but the router might be the NAT-PT device Other requirements: none 4.2.6 BIS The Bump-In-The-Stack [RFC2767] model allows for the use of non IPv6 capable applications on an IPv4 host to communicate with IPv6 only hosts. Added to the IPv4 stack are three modules that intervene between the application and the network, an extension to the name resolver, an address mapper and a translator. The main idea is that when an IPv4 application needs to communicate with an IPv6 only host, the IPv6 address of that host is mapped into an IPv4 address out of a pool local to the dual stack hosts. The IPv4 packet generated for the communication is translated into an IPv6 packet according to SIIT. One can view Bump-in-the-stack as a particular implementation of NAT-PT within the IP stack of a host. Note that a similar technique can be implemented it the library level on a dual stack host. Applicability scope: host IPv4 requirements: none specific IPv4 address requirements: pool of private address space per host IPv6 requirements: none IPv6 address requirements: none Host requirements: IPv6/IPv4 stack plus extensions Router requirements: none Other requirements: none 4.2.7 Transport Relay Translator Transport Relay Translator defined in [TRT] enables direct communication between IPv6 hosts and IPv4 hosts. There should be a dedicated box for a site to relay a TCP/IPv6 connection and a TCP/IPv4 connection. Also, there should be a DNS server which can map IPv4 addresses to IPv6 addresses. No modification is necessary for IPv6 hosts and IPv4 hosts. For scalability, multiple dedicated boxes can be installed for a site with multiple dummy IPv6 prefixes. UDP traffic can be relayed by the same technique as that of TCP. Applicability scope: site IPv4 requirements: none IPv4 address requirements: 1 per site IPv6 requirements: none IPv6 address requirements: One dummy prefix out of the site address Host requirements: none Router requirements: none, but an intermediate device must be a transport relay translator Other requirements: DNS servers which can map IPv4 addresses to IPv6 addresses 4.2.8 DSTM Dual Stack Transition Mechanism [DSTM] is a combination of two mechanisms, Assignment of IPv4 Global Addresses to IPv6 hosts, (AIIH) and Dynamic Tunneling Interface (DTI). AIIH is based on cooperation between DNS and DHCPv6 [DHCPv6]. The main idea is that when an IPv4/IPv6 host wants to communicate with an IPv4 only host, it requests for the duration of the communication a temporary IPv4 address to the AIIH server. If an IPv4 host wants to initiate a communication with an IPv4/IPv6 host, it first ask the DNS for an A record. The DNS server in charge of the final resolution will ask the DHCPv6 server to allocate a temporary IPv4 address for the dual stack host and it will sends back this address in an A record to the IPv4 host. The DHCPv6 server will send a reconfigure command to the dual stack host to assign that temporary IPv4 address. The implementation of this part of the mechanism is optional. In the absence of IPv4 internal routing infrastructure, the dual stack host will encapsulate IPv4 packets in IPv6 packets to a tunnel endpoint that will decapsulate them and inject them in the IPv4 infrastructure. This encapsulation is done by the DTI virtual interface. Applicability scope: site IPv4 requirements: none specific IPv4 address requirements: >= 1 per site IPv6 requirements: DHCPv6 extensions [DHCPv6-EXT] IPv6 address requirements: none Host requirements: IPv4/IPv6 stack Router requirements: none Other requirements: none 5. Case Studies This section will describe some possible transitions scenarios for some typical cases. Neither the list of cases nor the lists of solutions are exhaustive. 5.1 Large organization with a lot of global IPv4 addresses 5.1.1 Motivations Why would a large organization with plenty of IPv4 addresses want to do IPv6? IPv4 address depletion being the main driver behind IPv6, one could ask the question. The main motivations could be: - This organization wants to take advantage of the other benefits of IPv6, such as auto-configuration, mobile-IP with shortcuts or mandated IPsec. - The Internet has significantly adopted IPv6 and the organization thinks it is strategic to do it. - This organization exchange important traffic with other organizations that do not have that many IPv4 addresses and have are using NAT. Using IPv6 would be a way to re-establish end to end IP connectivity with them. 5.1.2 Prerequisites IP service is probably in place since many years in such an organization, users rely on it and network administrator know how to run it efficiently. Thus a number or important points must be satisfied to help the adoption of IPv6: - IPv4 service must not be affected. Existing IPv4 applications must be running the same way regardless of of the presence of IPv6 in the network. - Existing IPv4 nodes must be able to talk to the same number of nodes as before the introduction of IPv6, that is, IPv6 must not partition the IPv4 network. - The introduction of IPv6 must be made gradually, in a step by step approach. - Training to IPv6 must be done at the rate of the integration of IPv6. 5.1.3 Getting experience Setting up an experimental platform with few hosts and routers and connecting it to the 6bone is a good way to gain IPv6 experience that will be very valuable in the next steps of the transition. 5.1.4 Step 1: dual stack servers and routers The first step is to upgrade some enterprise servers to support a dual stack, IPv4 and IPv6. At the same time, some routers on the same links are also upgraded to support a dual stack. Note that in the case where multiple routers are present on a link, only one of them need to be upgraded. Those dual stack servers will still serve existing IPv4 clients. They will learn IPv6 prefixes and default routes from the the IPv6 routers. They will be able to communicate with using IPv6. Note: It may be a good practice not to use stateless autoconfiguration on the servers when the applications they run use IP addresses internally. In case of hardware change, those applications may be confused by the new addresses. Most of the times, those upgrades are software only, no hardware need to be change. However, some routers performing hardware acceleration may require some hardware upgrades as well to maintain the same level of performance as with IPv4. 5.1.5 Step 2: dual stack clients The second step is to get dual stacks IPv4/IPv6 on some clients which are on IPv6 ready links, that is, on links where a dual stack router sends IPv6 router advertisements. Again, this is usually achieved by a software upgrade. Stateless auto-configuration is very convenient for those clients to lower the administration burden. At this stage, the enterprise DNS should be populated with IPv6 addresses. 5.1.6 Step 3: IPv6 aware applications Now that some clients and some servers can communicate with IPv6, it is time to get IPv6 aware applications. In the dual stack model, the same application serves IPv4 and IPv6, so there is no need to run two sets of applications, one for IPv4 and one for IPv6. If IPv6 aware versions are not available, a last resource solution will be to run the IPv4 versions with a wrapper implementing the Bump in the API technique. This solution is far from perfect, but allows early deployment to happen. 5.1.7 Step 4: Connection to the IPv6 Internet The organization may now think about a connection to the IPv6 Internet. If its ISP can not deliver a IPv6 native link, a configured tunnel to the 6bone or a 6to4 tunnel are possible alternatives. That tunnel will originate from a dual stack router at the border of the organization site. Punching holes in the organization firewall may be necessary to dig the tunnel. However, in such a case, setting up an IPv6 firewall may be mandated by the organization security policy. 5.1.8 Step 5: IPv6 only hosts When IPv6 service and critical IPv6 applications are available, one can think about deploying IPv6 only nodes and IPv6 only links. At this stage, those nodes will communicate only with other IPv6 hosts, IPv6 only or dual stacks. Getting a 'pure' IPv6 only node may in practice not be possible. Removing the IPv4 part of a dual stack may not be possible. However, one can use a dual stack node and only configure the loopback address 127.0.0.1 on the IPv4 stack. That way, this node will not consume any global IPv4 addresses, and will behave very much like an IPv6 only node. 5.1.9 Step 6: IPv6 only node and IPv4 only server Those IPv6 only node will eventually need to talk to IPv4 only servers, within the organization or on the Internet. To achieve this, several techniques can be used: - deploying proxies per critical applications - deploying SIIT, NAT-PT or TCP-Relays - deploying DSTM The choice the right mechanism to deploy will depend from organization to organization. 5.2 Large organization with few global IPv4 addresses (a /24 or less) This case is very similar to the precedent one. However, IPv4 address conservation will be stressed. Private IPv4 addresses will be used instead of global IPv4 ones. Getting a global IPv6 address will allow nodes to re-establish end to end IP connectivity with other IPv6 hosts on the Internet. An easy upgrade path is, in step 4, to upgrade the NAT box to a NAT-PT + 6to4 box. 5.3 The extranet case An organization that wants to (re-)connect a fairly large number of branch offices which are, each of them, using the same IPv4 private address space, will face a very difficult problem. It even get worse when data have to be exchange with all the organization suppliers and customers if those ones are also using IPv4 private addresses and NAT techniques. Re-establishing end to end IP connectivity for some applications could become and important goal. One way to achieve this is to deploy IPv6 in each sites as describe in 5.2. The 6to4 mechanism will manage automatically all the necessary tunnels between the various sites, provided that each of them has, at least, one global IPv4 address. 5.4 Office or home network with ONE global ipv4 address This is an extreme case of 5.2. The same techniques applies. 5.5 New network with brand new services [to be completely rewritten] 5.6 Introducing IPv6 in an ISP environment The network of an ISP consists of at least three main areas: the core network, the connections to other IPSs and the customer access network. The next two sections will discuss how an ISP can introduce IPv6 in those areas. For each area a couple of steps must be taken first: - Request IPv6 address space - Register the IPv6 site, routing and delegations - Setup DNS 5.6.1 Introducing IPv6 in the core network It is not really necessary to introduce IPv6 into the core of the network. An ISP may decide to tunnel IPv6 over its existing IPv4 infrastructure. But if the ISP decides to introduce IPv6 into the core, this can be done in several ways. An ISP might decide to install separate dual stack or IPv6-only routers in the core. These will be interconnected by dedicated lines (ATM PVCs, leased lines, etc.) or (if the routers are dual stack) by IPv6 in IPv4 tunnels over the existing IPv4 core infrastructure. Routing can be setup such that IPv4 packets are routed through the old IPv4 infrastructure and IPv6 packets are routed through the new IPv6 infrastructure. When dual stack routers are stable enough to be used in the core, things become simpler. The ISP can configure the core routers as dual stack routers which will route both IPv4 and IPv6 packets. Next a connection to the global IPv6 network should be made. This can be done by a direct IPv6 connection or by some tunneling mechanism. If the core of the network supports IPv6 and the other ISP also supports IPv6 a direct link can be used to transport IPv6 packets. When there is no direct IPv6 connection tunneling mechanisms must be used to reach the global IPv6 network. An ISP might decide to setup one or more routers at the edge of its network to act as 6to4 gateways. This enables other IPv6 islands to reach the ISP by 6to4 tunneling. An alternative to the use of dynamic tunnels is the use of static ones as is the case on the 6Bone. 5.6.2 Introducing IPv6 in the customer access network The customer access network consists of dial up and leased lines connected to an access router. There are at least two possibilities to introduce IPv6. The first possibility is to upgrade access routers to dual stack routers. Both IPv4 and IPv6 customers connect to these dual stack routers. Another possibility is to install separate IPv6 or dual stack routers. IPv4-only customers connect to the old IPv4-only access routers. IPv6 customers connect to the new access routers. These IPv6 access routers must be connected to the global IPv6 network. If the core does not support IPv6, one of the transition mechanisms from section 3 must be used. Dynamic tunneling can be done with for example [6TO4]. An alternative to the use of dynamic tunnels is the use of statically configured ones. When the core network does support IPv6 the access routers can be connected to the nearest IPv6 core router (either by IPv4/IPv6 link, dedicated link or tunneling over IPv4). When the customer is an IPv6-only site, the ISP might decide to provide some transition mechanisms to help the customer reach IPv4-only nodes. 5.7 Internet Exchange Based on address space distribution we can distinguish two models for the setup of an IPv6 Internet eXchange (IX). 1. The more or less traditional model that is most common in the IPv4 world. In this case each ISP connecting to the IX arranges its own IPv6 address space. In peering arrangements between ISPs the prefix for this address space is exchanged. 2. An addressing model where the IX acts as an address space provider. In this case the IX obtains a TLA and can assign NLAs from this TLA address space to connected ISPs. In order to obtain global connectivity for the Internet Exchange TLA, the IX needs to arrange for global transit through one or more global transit providers (TLA ISPs) which are connected to the IX. Implicitly, this means that the IX arranges transit for all connected ISPs that use the address space assigned to the IX. This requires quite a different business model for an IX than in model 1. 5.7.1 The traditional IX model 5.7.1.1 Address space: The IX obtains some globally unique address space. This can be an NLA from a transit provider (TLA provider) that offers connectivity for the IX infrastructure. A global prefix is preferred as next hop attribute in BGP4 [BGP4-IPV6]. 5.7.1.2 Addressing infrastructure on IX: Addresses are assigned from the obtained address space to the interfaces of the routers connecting to the IX infrastructure. 5.7.1.3 Updating the IPv6 registries: The sites, allocations and route objects should be registered as described in section 2. 5.7.1.4 BGP announcements: ISPs connecting to the IX advertise to their peers their own address space which is independent of the IX. This address space can either be a TLA or an NLA. 5.7.2 The addressing IX model 5.7.2.1 Address space: The IX requests a (sub-)TLA from its regional IR. Customers on the Internet Exchange get a next level NLA from this (sub-)TLA. 5.7.2.2 Addressing infrastructure on IX: Addresses are assigned from the obtained address space to the interfaces of the routers connecting to the IX infrastructure. 5.7.2.3 Updating the IPv6 registries: The sites, allocations and route objects should be registered as described in section 2. 5.7.2.4 Contracts with global transit ISPs (TLA ISPs) The IX should contract several TLA ISPs that will provide connectivity to the global IPv6 network. Such a TLA ISP must agree to transit traffic from all customers connected to the IX. 5.7.2.5 BGP announcements: The transit providers for the IX address space announce the (sub-)TLA from the IX to the global IPv6 network. To the IX customers they announce all prefixes that can be reached by them and for which they have a contract with the IX. Customers (NLA ISPs) get a next level NLA from the IX. The NLA ISPs announce their NLA to the TLA ISPs. They also announce their NLA to other NLA ISPs of the IX if there is a peering agreement between them. 6. Security considerations There are no specific security issues introduced by this document. For the specific security issues with the different translations and migration tools that are discussed in section 4 of this document the reader is referred to the referenced documents. 7. References [6BONE] http://www.6bone.net/ [6TO4] B. Carpenter, K Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-03.txt (work in progress). [6PAPA] R. Fink, "6BONE Pre-Qualification for Address Prefix Allocation (6PAPA)", draft-ietf-ngtrans-6bone-6papa-01.txt (work in progress) [AIIH] Jim Bound, "Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH)", draft-ietf-ngtrans-assgn-ipv4-addrs-01.txt (work in progress). [BROKER] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel Broker", draft-ietf-ngtrans-broker-00.txt (work in progress). [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration Protocol for IPv6", draft-ietf-dhc-dhcpv6-14.txt (work in progress). [DHCPv6-EXT] C. Perkins, J. Bound, "Extensions for the Dynamic Host Configuration Protocol for IPv6", draft-ietf-dhc-v6exts-11.txt (work in progress). [DNAME] Matt Crawford, "Non-Terminal DNS Name Redirection", draft-ietf-dnsind-dname-03.txt (work in progress). [DNSLOOKUP] M. Crawford, C. Huitema, S. Thomson, "DNS Extensions to Support IP Version 6", draft-ietf-ipngwg-dns-lookups-05.txt (work in progress). [DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition Mechanism (DSTM)", draft-ietf-ngtrans-dstm-01.txt (work in progress). [IRALLOC] Regional IRs, "Provisional IPv6 assignment and allocation policy document (Draft 6; 27 May 1999)", ipv6policy-draft-090699.txt (work in progress). [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", RFC 1034, November 1987. [RFC1035] P. Mockapetris, "Domain names - implementation and specification", RFC 1035, November 1987. [RFC1886] S. Thomson and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC1928] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [RFC1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [RFC2080] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2081] G. Malkin, "RIPng Protocol Applicability Statement", RFC 2081, January 1997. [RFC2185] R. Callon, D. Haskin, "Routing Aspects of IPv6 Transition", RFC 2185, September 1997. [RFC2283] T. Bates, R. Chandra, D.Katz, Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. [RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2374] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC2529, March 1999. [RFC2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC2545, March 1999. [RFC2546] A. Durand, B. Buclin, "6Bone Routing Practice", RFC 2546, March 1999. [RFC2673] Matt Crawford, "Binary Labels in the Domain Name System", RFC 2673, August 1999. [RFC2740] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC2765] E. Nordmark, "Stateless IP/ICMP Translator", RFC 2765, xxxx [RFC2766] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts using the Bump-in-the-Stack technique", RFC 2767, February 2000. [RFC2772] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines" RFC 2772, February 2000. [SOCKS-EXT] H. Kitamura, "SOCKSv5 Protocol Extensions for IPv6/IPv4 Communication Environment", draft-kitamura-socks-ipv6-01.txt (work in progress). [SOCKS-GATE] H. Kitamura, A. Jinzaki, S. Kobayashi, "A SOCKS-based IPv6/IPv4 Gateway Mechanism", draft-ietf-ngtrans-socks-gateway-02.txt (work in progress). [TRT] J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport relay translator", draft-ietf-ngtrans-tcpudp-relay-00.txt, (work in progress). 8. Authors' Addresses -> This section needs update. Wim Biemolt Marijke Kaat SURFnet ExpertiseCentrum bv SURFnet ExpertiseCentrum bv P.O. Box 19115 P.O. Box 19115 3501 DC Utrecht 3501 DC Utrecht The Netherlands The Netherlands Phone: +31 30 230 5305 Phone: +31 30 230 5305 Fax: +31 30 230 5329 Fax: +31 30 230 5329 Email: Wim.Biemolt@sec.nl Email: Marijke.Kaat@sec.nl Ronald van der Pol Henk Steenman SURFnet bv AT&T, ICoE P.O. Box 19035 Laarderhoogtweg 25 3501 DA Utrecht 1101 EB Amsterdam The Netherlands The Netherlands Phone: +31 30 230 5305 Phone: +31 20 409 7656 Fax: +31 30 230 5329 Fax: +31 20 453 1574 Email: Ronald.vanderPol@surfnet.nl Email: Henk.Steenman@icoe.att.com Tim Larder Cisco Systems Ltd. 3, The Square, Stockley Park, Uxbridge, UB11 1BN, United Kingdom. Phone +44 (0)20 8756 8846 email tlarder@cisco.com Alain Durand SUN Microsystems, Inc. 901 San Antonio road UMPK17-202 Palo Alto, CA 94303-4900 USA Phone: +1 650 786 7503 Email: Alain.Durand@sun.com Kazu Yamamoto IIJ Appendix A. IPv6 Address Issues A.1 IPv6 Address Assignments Most of the transition mechanisms require dual stack systems and thus globally routable IPv6 addresses as well as globally routable IPv4 addresses. Although sometimes private IPv4 addresses [RFC1918] will suffice. But to allow communication between IPv4 and IPv6 hosts over the Internet at least one globally unique IPv4 address is always needed. Globally unique IPv4 addresses can be obtained from one of the Regional Internet Registries (IR), Local Internet Registries (LIR) or an Internet Service Provider (ISP). Without special registration a site can deploy IPv6 site local addresses which are similar to IPv4 private addresses [RFC1918]. However, site local addresses do not allow for communication over the Internet. For this you need to apply for globally routable IPv6 addresses. Most sites will get a /48 prefix with 16 bits for subnetting and 64 bits for interface ID addressing. This means that 65536 subnets can be defined and in each subnet almost 20 trillion hosts can be numbered. 0 48 64 127 +---------------------------------+--------+--------------------+ | prefix | subnet | Interface ID | +---------------------------------+--------+--------------------+ At present, there is an experimental network called the "6bone" which is operated based on IPv6. For this network, a part of the aggregatable address space is assigned, the so-called Pseudo TLA (pTLA) 3ffe::/16. Provider pTLAs are assigned by the 6bone [6BONE]. NLAs are assigned in turn by those organizations which have received pTLA assignments from the 6bone. A.1.1 Obtaining IPv6 Address Space IPv6 addresses can be obtained from the same organizations as the ones who register IPv4 addresses. Basically regional IRs delegate a part of the IPv6 address space to local IRs who further delegate parts of the address space to their customers. The smallest assignment that can be made to a customer is a /48 prefix. A difference between IPv4 and IPv6 allocations is that one of the main objectives of IPv6 allocation is route aggregation, i.e. to minimize the number of prefixes that need to be advertised in the default-free core of the Internet. The regional IRs use a slow start mechanism [IRALLOC] to allocate TLAs to ISPs. A special prequalification procedure [6PAPA] can be used by ISP participating in the 6bone. ISPs can be divided into two categories: those ISPs that can get a (sub-)TLA from their regional Internet Registry (IR) and those ISPs that will not get a (sub-)TLA. In this document the first category is referred to as "TLA ISPs" and the second category is referred to as "NLA ISPs", because they will get an NLA from their upstream provider(s). TLA ISPs will get a sub-TLA first and can apply for a full TLA later. This sub-TLA is a /29 prefix. The TLA ISP will allocate /48 prefixes to end customer sites and /(29+n) prefixes to NLA ISPs, in which "n" (0<=n<=19) is the number of bits used to identify NLA ISPs [RFC2374]. +--+----------+---------+---------+--------+--------------------+ | 3| 13 | 13 | 19 | 16 | 64 bits | +--+----------+---------+---------+--------+--------------------+ |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+----------+---------+---------+--------+--------------------+ |<--- TLA ISP prefix -->|<--->|<------ bits for NLA ISP --------> | | NLA ISP identifier (n bits) An NLA ISP will be allocated a prefix between /29 and /48. It will use the remaining bits in the NLA ID to identify its customers. These customers will get a /48. +--+----------+---------+---------+--------+--------------------+ | 3| 13 | 13 | 19 | 16 | 64 bits | +--+----------+---------+---------+--------+--------------------+ |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+----------+---------+---------+--------+--------------------+ |<------ NLA ISP prefix ----->|<->|<------ bits for sites ------> | | end customer site identifier (19-n bits) An example of IPv6 address usage can be found in appendix A. A.2 IPv6 Registration Issues In the current IPv4 world address space allocations are registered in the various databases managed by the regional IRs. Autonomous System (AS) information and routing policies are registered in the distributed Internet Routing Registry database (IRR). The IRs, LIRs and ISPs are supposed to register address space allocations and assignments, contact persons, AS numbers, routing policies and other useful data for network management in the various databases. A special IPv6 registration database has been setup for the 6bone community, on the whois server named "whois.6bone.net". This is a special version of the RIPE database software and it is referred to as the "6bone database". This database has special objects, the "inet6num:" object for assigned IPv6 prefixes, and the "ipv6-site:" object which is used to register specific information about a site connected to the 6bone, such as the configured tunnels and the origin AS. In the ipv6-site objects the IPV6 applications that are supported on that specific site can be found. The database can be queried by using a modified whois client or the web-based "whois" service at http://www.6bone.net/whois.html. At this time only the 6bone database supports the special IPv6 objects. Currently, there are no database objects to register IPv6 routing policies. When the regional IRs will start allocating (sub-)TLAs the allocated and assigned IPv6 prefixes, routing policies etc. will have to be registered. At this moment it is unclear how exactly IPv6 registrations will be done. A.3 Example of IPv6 address usage Sites will get a /48. An example of how to use such a /48 is given below. In this example the site is allocated 3FFE:1234:5678::/48. 3FFE:1234:5678::/48 | | I1 +-----+-----+ I2 +-------+ R1 +-------------------+ | +---------+-+ | | | I3 | +-------+-------+ +----+ +-----+----+ | | | | R2 | | | | +----------+ +----+----+ +----+----+ +----+----+ |||||||||| | R3 | | R4 | | R5 | links +---------+ +---------+ +---------+ | | | | | | | | | | links links links R[1-5] are routers and I[1-3] are the interfaces of R1. Suppose the expected number of hosts on the links is: router immediate year 1 year 2 R2 34 50 70 R3 19 20 25 R4 9 10 15 R5 3 5 10 A number plan could be like the one shown in the table below. On R1 the following prefixes will be used on the interfaces: I1 3FFE:1234:5678:2000::/50 I2 3FFE:1234:5678:0000::/49 I3 3FFE:1234:5678:2300::/50 Initially, R2 will get 256 /64s, R3 will get 48 /64s, R4 will get 32 /64s and R5 will get 16 /64s. 3FFE:1234:5678:0000::/50 ------------------------ 3FFE:1234:5678:0000::/49 I2 3FFE:1234:5678:1000::/49 free 3FFE:1234:5678:2000::/49 I1 + I3 3FFE:1234:5678:3000::/49 free ..... ... 3FFE:1234:5678:F000::/49 free 3FFE:1234:5678:0000::/49 ------------------------ 3FFE:1234:5678:0000::/64 interfaces of R2 ..... ... 3FFE:1234:5678:00FF::/64 interfaces of R2 3FFE:1234:5678:0100::/64 reserved for R2 ..... ... 3FFE:1234:5678:02FF::/64 reserved for R2 3FFE:1234:5678:0300::/64 free ..... ... 3FFE:1234:5678:2000::/49 ------------------------ 3FFE:1234:5678:2000::/50 I1 3FFE:1234:5678:2100::/50 reserved for I1 3FFE:1234:5678:2200::/50 reserved for I1 3FFE:1234:5678:2300::/50 I3 3FFE:1234:5678:2400::/50 reserved for I3 3FFE:1234:5678:2500::/50 reserved for I3 3FFE:1234:5678:2600::/50 free ..... ... 3FFE:1234:5678:2F00::/50 free 3FFE:1234:5678:2000::/50 ------------------------ 3FFE:1234:5678:2000::/64 interfaces of R3 ..... ... 3FFE:1234:5678:202F::/64 interfaces of R3 3FFE:1234:5678:2030::/64 reserved for R3 ..... ... 3FFE:1234:5678:204F::/64 reserved for R3 3FFE:1234:5678:2050::/64 interfaces of R4 ..... ... 3FFE:1234:5678:206F::/64 interfaces of R4 3FFE:1234:5678:2070::/64 reserved for R4 ..... ... 3FFE:1234:5678:209F::/64 reserved for R4 3FFE:1234:5678:20A0::/64 free ..... ... 3FFE:1234:5678:20FF::/64 free 3FFE:1234:5678:2300::/50 ------------------------ 3FFE:1234:5678:2300::/64 interfaces of R5 ..... ... 3FFE:1234:5678:230F::/64 interfaces of R5 3FFE:1234:5678:2310::/64 reserved for R5 ..... ... 3FFE:1234:5678:231F::/64 reserved for R5 3FFE:1234:5678:2320::/64 free ..... ... 3FFE:1234:5678:23FF::/64 free Appendix B. IPv6 and DNS B.1 Forward mapping A host's 128 bit IPv6 address can be stored with an AAAA record. For example: $ORIGIN ipv6.surfnet.nl. ... zesbot IN AAAA 3FFE:0604:0000:0001:02C0:4FFF:FEC6:9CC7 This is similar to the use of the A record in IPv4, for example: $ORIGIN ipv6.surfnet.nl. ... zesbot IN A 192.87.110.60 Note that both A and AAAA records for a given zone are stored in the same DNS data file. If a node has more than one IPv6 address it must have more than one AAAA record. For example: $ORIGIN ipv6.surfnet.nl. ... amsterdam9 IN AAAA 3FFE:0600:8000:0000::0001 IN AAAA 3FFE:0600:8000:0000::0005 IN AAAA 3FFE:0600:8000:0000::0009 IN AAAA 3FFE:0600:8000:0000::000D Currently a new record type, A6, is being defined to map a domain name to an IPv6 address, containing a reference to a "prefix" [DNSLOOKUP]. The aim of the A6 record is to facilitate network renumbering and multihoming. Domains employing the A6 record for IPv6 addresses can have automatically generated AAAA records to ease transition. After the A6 records are widely deployed it is expected that the AAAA records are no longer needed. B.2 Reverse mapping IPv4 uses the "in-addr.arpa" domain for the reverse mapping. An IPv4 address is represented as a name in the in-addr.arpa domain by a sequence of bytes, written as decimal digits, separated by dots with the suffix ".in-addr.arpa". The sequence of bytes is encoded in reverse order, i.e. the low-order bytes is encoded first, followed by the next low-order bytes and so on. For example the IPv4 address 192.87.110.60 is represented as a name in the in-addr.arpa domain as: 60.110.87.192.in-addr.arpa. This name is stored in a DNS data file as follows: $ORIGIN 110.87.192.in-addr.arpa. ... 60 IN PTR zesbot.ipv6.surfnet.nl. For IPv6 addresses the special domain "ip6.int" is defined to look up a record given an IPv6 address. The process works exactly the same as with IPv4. Except that an IPv6 address is represented by nibbles, written as hexadecimal digits, separated by dots. For example the IPv6 address 3FFE:0604:0000:0001:02C0:4FFF:FEC6:9CC7 is represented as a name in the ip6.int domain as: 7.c.c.9.6.c.e.f.f.f.f.4.0.c.2.0.1.0.0.0.0.0.0.0.4.0.6.0.e.f.f.3.ip6.int. This name is stored in the a DNS data file as follows (assuming a /64 prefix): $ORIGIN 1.0.0.0.0.0.0.0.4.0.6.0.e.f.f.3.ip6.int. ... 7.c.c.9.6.c.e.f.f.f.f.4.0.c.2.0 IN PTR zesbot.ipv6.surfnet.nl. Note that the IPv4 and IPv6 reverse mappings are stored in different DNS data files. B.3 Implementations Most DNS implementations will be able to deal with the reverse mapping as used with IPv6 addresses. However AAAA record is only implemented in recent DNS implementations and support for A6 record [DNSLOOKUP] or binary labels [RFC2673] is just coming. Note that although these DNS servers implement extensions to support the use of IPv6 addresses they are not necessarily IPv6 applications themselves, some use IPv4 transport. For IPv6 only nodes, an IPv6 resolver and an IPv6 DNS server are crucial.