[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

INTERNET-DRAFT                                   W. Biemolt,         SEC
NGTRANS WG                                       A. Durand,          SUN
Feb. 2002                                        D. Finkerson,       UNL
                                                 A. Hazeltine,      ASCI
                                                 M. Kaat,            SEC
                                                 T. Larder,        CISCO
                                                 R. van der Pol, SURFnet
                                                 Y. Sekiya,   Keio Univ.
                                                 H. Steenman,       AT&T
                                                 G. Tsirtsis,    FLARION

        An 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   Distribution of this memo is unlimited.


   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 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. The 6bone
   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 globally routable addresses >= a /16.
   5.1.1 Motivations
   5.1.2 Prerequisites and conditions of transition.
   5.1.3 Network infrastructure
   5.1.4 dual stack servers
   5.1.5 dual stack clients
   5.1.6 IPv6 aware applications
   5.1.7 Connection to the IPv6 Internet
   5.1.8 IPv6 only hosts
   5.1.9 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.4.1 Step 1: Upgrade the NAT box and connect to the IPv6 Internet
   5.4.2 Step 2: Dual stack clients and servers
   5.4.3 Step 3: IPv6 aware applications
   5.4.4 Step 4: IPv6 only hosts
   5.5 Introducing IPv6 in an ISP environment
   5.5.1 Introducing IPv6 in the core network
   5.5.2 Introducing IPv6 in the customer access network
   6. Security considerations
   7. References
   8. Authors' addresses
   Appendix A - IPv6 Address Issues
   A.1 IPv6 Address Allocation
   A.1.1 Site local vs global addresses
   A.1.2 Obtaining IPv6 Address Space
   A.2 IPv6 Registration Issues
   A.3 Example of IPv6 address allocation within a site /48 prefix
   Appendix B. IPv6 and DNS
   B.1 Forward mapping
   B.2 Reverse mapping
   B.3 Implementations
   Appendix C. IPv6 routing issues

1. Introduction

   The goal of this document is to provide an overview of several
   transition mechanisms developed within the IETF NGtrans
   working group. It is not intended to describe the complete
   migration from IPv4 to IPv6 for the whole Internet.
   It is an attempt to describe the possibilities
   of introducing IPv6 in a predominantly IPv4 environment
   and having both IPv6 and IPv4 connectivity.

   The scope of this document is limited to IPv6 unicast transition.
   Migration of IPv4 to IPv6 multicast environments is not

   Section 2 provide some information and pointers about the
   6bone[6bone], an IPv6 testbed.

   Sections 3 and 4 provide short descriptions of the different
   transition tools and mechanisms that translate between
   IPv6 and IPv4 and/or tunnel IPv6 over IPv4.

   Section 5 will discuss how IPv6 can be introduced in
   typical environments.

   Appendices A, B & C discuss issues about IPv6 address allocation,
   IPv6 addresses in the DNS and IPv6 routing protocols.

   Note: At the time this memo was originaly written, some recent
         tools like ISATAP or TEREDO did not exist and thus they
         are not described here.

2. The 6bone

   The 6bone[6bone] is an IPv6 Testbed that is an outgrowth of the
   IETF IPng project that created the IPv6 protocols intended
   to eventually replace the current Internet network layer
   protocols known as IPv4.
   The 6bone is currently a worldwide informal collaborative
   project, informally operated with oversight from the "NGtrans"
   (IPv6 Transition) Working Group of the IETF.
   The 6bone started as a virtual network (using IPv6 over IPv4
   tunneling/encapsulation) operating over the IPv4-based Internet
   to support IPv6 transport, and is slowly migrating to native
   links for IPv6 transport.
   The initial 6bone focus was on testing standards and
   implementations, while the current focus is more on testing
   transition and operational procedures.
   The 6bone operates under the IPv6 Testing Address Allocation
   (see  [RFC 2471]).

   A document describing the 6bone routing guidelines has been
   published as RFC 2772.

   More information can be found on http://www.6bone.net

   By now, the 6bone is not the only IPv6 backbone. Other
   backbones, academic and commercial are offering IPv6 services.

3. Basic transition mechanisms

    [RFC2893] defines some basic mechanisms:

    - 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 a resolver library capable of
   dealing with the IPv4 A records as well as the IPv6 AAAA records.
   When both A and AAAA records are listed in the DNS there are three
   different options [RFC2893], (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 appellation "Dual Stack" in itself is somehow misleading.
   Most implementations of IPv6 do not offer two completely distinct
   TCP/IP stacks, one for IPv4 and one for IPv6, but a 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 separated 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 manually 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 known tunneling techniques described later
   are based on IPv4 addresses at both ends of the tunnel,
   many of these techniques cannot work if an IPv4 address
   translation (NAT) happens between the two end-points of the tunnel.
   Also, When firewalls are used IP protocol 41 much be allowed
   to go through.

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 having 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 stack routers and IPv6 in IPv4 tunnels.

   Mechanisms 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 defines some generic criteria to compare tools.

   Applicability scope: where the transition tool applies to:
     host, domain or global.

   Understanding the scope of these mechanism is important when
   one is trying to compare or combine them together.
   A solution with scope of domain generally enables a whole domain
   to connect but should not have any effect on the rest of the
   Internet. A scope of a host enables the connection of
   a single host. Thus, two mechanism of the same scope have
   no impact on each other when applied on different places,
   but great care is needed when applied at the same location.
   For example, two domain one deploying 6over4 and another one
   deploying DSTM, should not experience any problem. However,
   it may not be easy nor recommeded to use both mechanism
   in the same domain. A domain can most of the times be assimilated
   to a site, but under some circonstances, can be larger and
   include several sites, for example in the case of an ISP
   offering NAT-PT service to its customers.

   IPv4 requirements: what is required in the IPv4 context
   to make the tool work.

   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 work.

   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.

   NAT impact: will this solution work if deployed behind a NAT box?

   Other requirements: other requirements not listed above.

4.1 Connecting IPv6 islands

   The mechanisms described here are designed to enable IPv6
   communication between IPv6 islands isolated in the IPv4 world.
   All of these rely 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:        global
   IPv4 requirements:          IPv4 inter connectivity between sites
   IPv4 address requirements:  >= 1 per site
   IPv6 requirements:          none
   IPv6 address requirements:  end-node needs one IPv6 address
   Host requirements:          IPv6 stack or IPv4/IPv6 stack
   Router requirements:        IPv4/IPv6 stack
   NAT impact:                 will not work if the tunnel has to cross
                               a NAT BOX.
                               may work if the tunnel end-point is
                               collocated with the NAT box
   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 to communicate. These
   addresses allow the hosts to derive the IPv4 addresses of the tunnel
   end-points from the IPv6 addresses.

   Applicability scope:        global
   IPv4 requirements:          IPv4 connectivity 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
   NAT impact:                 will not work if the tunnels have to cross
                               a NAT BOX
   Other requirements:         none

   As this solution requires one IPv4 address per host, its domain
   of application is extremely limited.

4.1.3 Tunnel Broker

   Configuring tunnels usually requires cooperation of the two parties
   to set up the correct tunnel end-points. Tunnel brokers [RFC3053]
   can help people 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 allow
   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:        global
   IPv4 requirements:          none specific
   IPv4 address requirements:  1
   IPv6 requirements:          none
   IPv6 address requirements:  none in the isolated client case
                               a prefix allocation if there is a network
                               to connect.
   Host requirements:          IPv4/IPv6 stack, IPv4 Web browser
   Router requirements:        none
   NAT impact:                 will not work if the tunnel has to cross
                               a NAT BOX
                               may work if the tunnel client is
                               collocated with the NAT box

   Other requirements:         Tunnel server, secure DNS update,
                               some form of keep alive mechanism.

4.1.4 6TO4

   The 6to4 [RFC3056] 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 IPv6 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 /16 prefix plus a 32
   bit field 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 for IPv6 address space
   from the registries. It is also very valuable in the absence
   of IPv6 ISPs as it reduces to zero the management of tunnels.

   Applicability scope:        global
   IPv4 requirements:          IPv4 connectivity between sites
   IPv4 address requirements:  >= 1 per site
   IPv6 requirements:          globally unique 6to4 prefix
   IPv6 address requirements:  none
   Host requirements:          IPv6 stack, miminal source address selection
   Router requirements:        implementation of special forwarding and
                               decapsulation rules
   NAT impact:                 will not work if the tunnel has to cross
                               a NAT BOX
                               may work if the 6to4 router is
                               collocated with the NAT box
   Other requirements:         creation of DNS record that reflects 6TO4
                               /48 prefix
                               relay router discovery mechanism

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:        domain
   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
   NAT impact:                 Will require substantial effort
                               to make work.
                               Will have to make IPv4 multicast
                               work across NAT first.
   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 mechanisms, communication between
   IPv6 hosts is enabled. Communication between an IPv4 host and
   an IPv6 host may also be important to establish. This can be done
   in 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 discussed
   below. It should be noted that in IPv4 applications, it is not uncommon
   that the application has knowledge of information from the network
   layer (like address length or the address itself). An example of this
   is FTP. This makes it necessary not only to translate the network
   layer packets but also to 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
   enable device.

   Applicability scope:        host
   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
   NAT impact:                 IPv6 communications will be end-to-end.
                               IPv4 ones will not.
   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 but wanting to use them.
   With this approach, fewer IPv4 addresses are used,
   but the communication between an IPv4-only client node and an IPv6-
   only server is broken. To re-establish this communication,
   proxies are installed for strategic services.

   Applicability scope:        host
   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
   NAT impact:                 IPv6 communications will be end-to-end.
                               IPv4 ones will not.
   Other requirements:         proxies for v4 clients to v6-only servers

4.2.3 SOCKS64

   The SOCKS Gateway [RFC3089] tool is a system that accepts
   enhanced 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 enable IPv4 hosts to connect to IPv6 hosts.
   No DNS modifications or address mapping are 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 latter
   cases resemble tunnel techniques without possible problems with
   fragmentation or hop limits.

   Applicability scope:        domain
   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
   NAT impact:                 The SOCKS relay and the NAT box
                               need to cooperate
   Other requirements:         dual stack SOCKS server. Here is an example:

          /---------- SITE ----------------------------------\
          |                    |                             |
          |                    | (IPv6 Segment)              |
          |     [IPv6 HOST] ---+                             |
          |                    |                             |
          |                    |                             |
          |     [IPv6 HOST] ---+                             |
          |                    |                             |
          |                    +------ [SOCK64 SERVER]       |
          |                    |              |              |
          |                                   |              |
          |              (IPv4/IPv6 Segment)  |              |
          |         ==================+=======+=======+      |
          |                           |               |      |
          |                    [IPv4 Router]   [IPv6 Router] |
          |                           |               |      |
                                      |               |
                                      |               |
                             {IPv4 Internet}   {IPv6 Internet}

4.2.4 SIIT

   The SIIT [RFC2765] 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:        domain
   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
   NAT impact:                 2 (or more) levels of translation.
   Other requirements:         some address allocation mechanism

4.2.5 NAT-PT

   NAT-PT, defined in [RFC2766] addresses 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:        domain
   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
   NAT impact:                 2 (or more) levels of translation.
   Other requirements:         DNS in IPv6 network, ALG for application
                               wich use literal addresses

4.2.6 BIS

   The Bump-In-The-Stack [RFC2767] model allows non-IPv6-capable applications
   runningon 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 layers, 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 to
   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 at 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
   NAT impact:                 The presence of NAT will have no effect on
                               IPv6 traffic, the IPv4 address is only
                               used internally.

   Other requirements:         ALG for application which uses literal

4.2.7 Transport Relay Translator

   Transport Relay Translator defined in [RFC3142] enables direct
   communication between IPv6 hosts and IPv4 hosts. This
   mechanism is somewhat similar to NAT-PT, but does the
   translation at the transport layer, not at the IP layer.
   There should be a dedicated router at a site to translate
   {UDP,TCP}/IPv6 to {UDP,TCP}/IPv4 and vice versa.
   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:        domain
   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
   NAT impact:                 May depend on the application.
   Other requirements:         DNS servers which can map IPv4 addresses
                               to IPv6 addresses

4.2.8 DSTM

   Dual Stack Transition Mechanism [DSTM] is a mechanism that
   allows a dual stack node whose IPv4 stack is enabled but not
   yet configured to temporarily acquire an IPv4 address to
   communicate with IPv4 only applications.

   The main idea is that when an IPv4/IPv6 host needs an IPv4
   address, it requests one for the duration of the
   communication to a DSTM server. The communication with
   the DSTM server is made on top of IPv6.

   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.

   Communication initiated from an IPv4 node to a DSTM node
   whose IPv4 stack is not yet configured is not supported
   at the moment but will be defined in future work.

   Applicability scope:        domain
   IPv4 requirements:          none specific
   IPv4 address requirements:  >= 1 per site
   IPv6 requirements:          IPv4 in IPv6 tunneling
   IPv6 address requirements:  none
   Host requirements:          IPv4/IPv6 stack with extensions
   Router requirements:        none
   NAT impact:                 Communications are done using IPv4,
                               so they may be impacted by any NAT boxes
                               encountered in the path.
   Other requirements:         IPv4 routing infrastructure or
                               tunnel end-points to decapsulate
                               IPv4 in IPv6 packets.

5. Case Studies

   The initial group of scenari being considered share many
   characteristics. They are looking at organizations with
   well-established networks and a history of internet connectivity.
   What distinguishes them is the number of globally routable IPv4
   addresses that they have available.

5.1 Large organization with globally routable addresses >= a /16.

   This is fairly typical for large US based Universities.

5.1.1 Motivations

   Such a site may be motivated to begin the integration
   of IPv6 into their network for a number of reasons:

   - They wish to remain at the forefront of technology.
   - They wish to maintain and where possible restore end-to-end
     connectivity. They see NAT's in their future and wish
     to prevent this from happening.
   - They believe there will be IPv6-only devices appearing
     at their installation and wish to be prepared for this
     technology shift.
   - Even though they have sufficient address space
     to meet their data needs for the immediate future,
     they do not have enough to migrate their
     telephone system to IP.
   - They have made a strategic decision to implement IPsec
     and believe IPv6 is the best platform.

5.1.2 Prerequisites and conditions of transition.

   - Integrating IPv6 cannot disrupt their current network.
   - All of the IPv4 connectivity and functionality must continue
     to operate.
   - Installing IPv6 must not impact the performance of anyone but those
     selected to test the IPv6 infrastructure.
   - It is all right that the IPv6 performance does not match their
     IPv4 performance, for the moment.

5.1.3 Network infrastructure

   The most likely situation is that there will be a small section of
   their network that will be made IPv6 capable. Various tools and
   configurations can be tested in this area and as they prove stable
   and useful they will be extended until they cover the entire
   infrastructure. It is likely that this will happen from the core
   of the network out, at least where installation is driven by
   the existing networking staff.

   Let us suppose that the network is made of a core set of routers
   that are redundantly interconnected. This may be an ATM core,
   it may utilize a gigabit or 100 megabit switched core,
   and it may have some POS or be some combination of all of these.
   In general each router will serve multiple wiring closets where
   the layer 2-switched infrastructure resides. Again for redundancy
   these switches are often connected to multiple routers.

   Most likely the site will be allocated a /48 range,
   e.g. 3FFE:ffff:0001::/48. This would give that manager the
   equivalent of the IPv4 /16 they are currently use.

   Having obtained the network number (and note that they
   may even get more than one prefix if they have multiple
   connectors), one approach would be to determine which
   of the core or edge router nodes will be upgraded to
   a dual stack IP implementation supporting both IPv4
   and IPv6.

   We would now have a situation that looks familiar:

                      /            \
                     /              \
                    /  IPv4 routed   \
                    \      core      /
                     \              /
                      \            /
                         --------  Int0        -------------
                        | Router |____________|layer2 switch|
                        |  R4/6  |             -------------
                         --------              | | | | | | |
                                               | | | | | | |

   The configuration in the router called R4/6 would allow
   both IPv4 and IPv6 traffic to pass to hosts attached
   to IPv4 and IPv6 enabled interfaces. For instance on
   the interface labeled Int0 (assumed to be Ethernet)
   the following statements
   would both be in the interface configuration:
        ip   address xxxx.xxxx.xxxx.xxxx
        ipv6 address 3ffe:ffff:0001::0/64 eui-64.
   While this leaves out some detail of the router configuration,
   fundamentally that Ethernet is now IPv6 capable.

   Assuming that there is a backbone network to connect to,
   the interface labeled Int1 might also be configured with
   both IPv4 and IPv6 addresses. If this is an ATM network,
   with an ATM-connected provider a point-to-point PVC could
   be configured allowing native IPv6 connectivity between the
   router and the provider. Any other layer 2 technologies
   can also bring native IPv6 service to R4/6.
   If a native IPv6 connection cannot be set up, a tunnel
   could be constructed out of that router using the Int1
   interface as the local tunnel end-point.

   Once the router is configured to forward IPv6 traffic,
   routing must also be configured. This can be as simple
   as a static default route pointing to the IPv6 provider.
   External routing can also be done using BGP4+.
   There is nothing particularly different about configuring
   an IPv4 BGP session and an IPv6 BGP session.

   Having done this much one final step remains before hosts
   are introduced to this network. The next step should be to
   obtain and operate a DNS server that is capable of
   handling both A records and AAAA records.

   At this point, there is an operational IPv6 network
   at this site. Anyone connecting to the switch labeled
   layer2 switch can send and receive IPv6 traffic as well as
   IPv4 traffic. Other links in the site network can be
   also upgraded to support IPv6.

   Next hosts and services must be introduced.

5.1.4 Dual stack servers

   The first step is to upgrade some enterprise servers to support
   a dual stack, IPv4 and IPv6.

   The dual stack servers will still serve the existing IPv4 clients.

   Note: It may be a good practice not to use stateless auto-
   configuration on the servers when the applications they run
   store IP addresses in configuration files. If the IPv6 addresses
   are derived from the MAC address of the NIC card and this one is
   changed, the IPv6 addresses of the server will change and the
   application may very well be confused if the configuration files are
   not updated as well.

5.1.5 Dual stack clients

   The second step is to get a dual stack IPv4/IPv6 on some clients
   which are on the IPv6-ready link.

   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

5.1.6 IPv6-aware applications

   Now that some clients and some servers can communicate with IPv6,
   it is time to obtain, setup and configure IPv6-aware applications.
   In the dual stack model, these same application serve IPv4 and IPv6,
   so there is no need to run two distinct applications,
   one for IPv4 and one for IPv6.

   Where IPv6-aware versions are not available, one of the techniques
   described in section 4.2 could be used.

5.1.7 Connection to the IPv6 Internet

   The organization may now think about a connection to the IPv6
   Internet. If its ISP cannot deliver an IPv6 native link, a
   configured tunnel to an IPv6 network 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 IPv6-only hosts

   When all IPv6 service and all 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 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 IPv6-only node and IPv4-only server

   Recalling our prerequistes IPv6-only nodes will 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 of the most suitable mechanism to deploy will depend on the organization.

5.2 Large organization with a few global IPv4 addresses (a /24 or less)

   There is really very little to distinguish this scenario from 5.1.
   Their motivation may be stronger, they are very likely losing
   Internet functionality. The combination of a /24 or less of address
   space more then 250 hosts in the organization will force the use
   of NAT's. This will certainly have some effect on the range of
   internet services available to these sites.

   Other than being more aggressive, their deployment strategy will not
   be much different from 5.1.

   Differences will emerge at the edge, where the NAT's are located.
   It is impossible to establish a tunnel end-point behind a NAT box.
   Should a tunnel connection be required to reach the global IPv6
   network, it will need to avoid the NAT, possibly by being located
   in a router outside the NAT'ed network or via some other technique.

   The existence of the NAT will also affect the use of some application
   and host level transition tools. An examination of the tool section
   of this document will provide information about those concerns.

5.3 The extranet case

   NAT techniques make it easy for a client using an internal address
   to initiate a connection to a server using an external address.
   However, the opposite case, that is a client using an external address
   trying to connect to a server using an internal address,
   is a very difficult one. This makes communication between hosts
   that are behind two different NAT domains even more difficult.

   An organization that has a fairly large number of
   branch offices which are, each of them, using the same IPv4 private
   address space and NAT techniques, will face a very difficult problem
   to connect them over the public Internet.

   It even gets worse when data have to be exchanged 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 an important goal.

   One way to achieve this is to deploy IPv6 in each site as
   described 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 and similar techniques apply.
   Typically this type of environment consists of one network
   segment with a small number of hosts using IPv4 private
   addresses.  The one global IPv4 address is assigned to a NAT box
   that connects the network to an ISP.  Most organizations of this
   size do not use routers internally although some may have a few
   internal network segments connected by a router.

5.4.1 Step 1: Upgrade the NAT box and connect to the IPv6 Internet

   The first step is to upgrade or replace the NAT box with a device
   supporting a dual stack, 6to4, and NAT-PT.  In the way the NAT
   device becomes an IPv6 router while still performing the NAT
   function for IPv4.  There are several possible methods of
   connecting to the IPv6 Internet without affecting the existing
   IPv4 service:

   - a native IPv6 connection if the ISP supports both IPv4 and
     native IPv6 connections
   - a 6to4 connection
   - a configured tunnel to an IPv6 provider
   - a connection to an IPv6 tunnel broker

   A 6to4 connection is recommended since it is likely to be some
   time before most ISPs offer native IPv6 services.  A
   configured tunnel requires more administrative effort both
   locally and at the IPv6 provider's end.  Tunnel broker
   connections are better suited to individual hosts or to small
   sites with infrequent connectivity requirements.

   At this point the organization will have a global 6to4 IPv6 prefix and
   the NAT box acting as an IPv6 router will advertise this prefix
   to the internal systems.  This 6to4 global prefix is derived from
   the single global IPv4 address.

   If the IPv4 address is a DHCP-assigned or other transient
   address, then the resulting 6to4 prefix will also be transient.
   In this case, the IPv6 router should also be configured to
   advertise a site-local prefix.  The site-local addresses for
   internal hosts can then be used in an internal DNS or similar
   naming service.  Using site-local addresses will promote easier
   communication among internal hosts since these internal addresses
   will not change when the global prefix changes.

5.4.2 Step 2: Dual stack clients and servers

   Clients and servers should be upgraded to support a dual stack
   once an IPv6 infrastructure exists.  Dual stack support will
   allow the use of IPv6 to begin while still supporting existing
   IPv4 services.

5.4.3 Step 3: IPv6-aware applications

   Once IPv6 is supported by the organization, IPv6 aware
   applications can be developed and installed.  Using the dual
   stack model, one application can support both IPv4 and IPv6

5.4.4 Step 4: IPv6-only hosts

   IPv6 only hosts can be deployed after the important applications
   have become IPv6-aware.  The private IPv4 addresses can be removed
   from the dual stack systems so that IPv6 is used for all
   communications.  The IPv4 NAT box upgraded in step 1 also includes
   NAT-PT to allow communication between IPv6 only internal hosts and
   the IPv4 Internet.

5.5 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 three steps must be taken first:

   - Request IPv6 address space
   - Register the IPv6 site, routing and delegations
   - Setup DNS

5.5.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 a new set of 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. It may be necessary to establishe tunnels
   if some of the intermediary routers cannot be upgraded to
   IPv6 or if dedicated lines are either not possible to install or
   simply not cost effective.

   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

   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 of the

5.5.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, as in the core network, to install a new
   set of 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[RFC3056]. 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 routea,r (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.

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

[DHCPv6]       J. Bound,  C. Perkins, "Dynamic Host Configuration
               Protocol for IPv6", draft-ietf-dhc-dhcpv6-23.txt
               (work in progress).

[DSTM]         J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition
               Mechanism (DSTM)", draft-ietf-ngtrans-dstm-07.txt
               (work in progress).

[IPASSIGN]     M. Blanchet,
               "A flexible method for managing the assignment of bits of an IPv6",
               draft-ietf-ipngwg-ipaddressassign-02.txt (work in progess)

[IRALLOC]      Regional IRs, "Provisional IPv6 assignment and allocation
               policy document (Draft 6; 27 May 1999)",
               ipv6policy-draft-090699.txt (work in progress).

[IS-IS]        C. Hopps,
               "Routing IPv6 with IS-IS",
               draft-ietf-isis-ipv6-02.txt, April 2001.

[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.

[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.

[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.

[RFC2672]      Matt Crawford, "Non-Terminal DNS Name Redirection",
               RFC2672, August 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.

[RFC2471]      R. Hinden, R. FInk, J. Postel,
               "IPv6 Testing Address Allocation", RFC2471, December 1998.
[RFC2765]      E. Nordmark, "Stateless IP/ICMP Translator",
               RFC 2765, February 2000.

[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.

[RFC2858]      T. Bates, R. Chandra, D.Katz, Y. Rekhter, "Multiprotocol
               Extensions for BGP-4", RFC 2858, June 2000.

[RFC2874]      M. Crawford, C. Huitema, S. Thomson, "DNS Extensions to
               Support IP Version 6",
               RFC2874, July 2000

[RFC2893]      R. Gilligan and E. Nordmark,
               "Transition Mechanisms for IPv6 Hosts and Routers",
               RFC 2893, August 2000.

[RFC3053]      A. Durand, P. Fasano, I. Guardini, D. Lento,
               "IPv6 Tunnel Broker", RFC3053, February 2001

[RFC3056]      B. Carpenter, K Moore,
               "Connection of IPv6 Domains via IPv4 Clouds",
               RFC3056, February 2001

[RFC3089]      H. Kitamura, A. Jinzaki, S. Kobayashi,
               "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
               RFC3089, April 2001.

[RFC3142]      J. Hagino, K. Yamamoto,
               "An IPv6-to-IPv4 transport relay translator",
               RFC3142, June 2001.

8. Authors' Addresses

   Wim Biemolt
   SURFnet ExpertiseCentrum bv
   P.O. Box 19115
   3501 DC  Utrecht
   The Netherlands
   Phone: +31 30 230 5305
   Fax: +31 30 230 5329
   Email: Wim.Biemolt@sec.nl

   Alain Durand
   SUN Microsystems, Inc.
   901 San Antonio road
   Palo Alto, CA 94303-4900
   Email: Alain.Durand@sun.com

   Dale Finkerson
   29 WSEC
   University of Nebraska
   Lincoln, Ne. 68588
   Phone: +1 402 472 0450
   Email: dmf@unl.edu

   Marijke Kaat
   SURFnet ExpertiseCentrum bv
   P.O. Box 19115
   3501 DC  Utrecht
   The Netherlands
   Phone: +31 30 230 5305
   Fax: +31 30 230 5329
   Email: Marijke.Kaat@sec.nl

   Andy Hazeltine
   Advanced Systems Consulting, Inc.
   4A Eves Drive, Suite 114
   Marlton, NJ 08053
   Phone: +1 856 983-3888
   Email: andy@advsys.com

   Tim Larder
   Cisco Systems Ltd.
   3, The Square,
   Stockley Park,
   UB11 1BN,
   United Kingdom.
   Phone +44 (0)20 8756 8846
   Email: tlarder@cisco.com

   Yuji Sekiya
   Keio University
   5322 Endo, Fujisawa
   Kanagawa 252-8520 Japan
   Fax  : +81 466 49 1101
   Email: sekiya@sfc.wide.ad.jp

   Henk Steenman
   AT&T, ICoE
   Laarderhoogtweg 25
   1101 EB Amsterdam
   The Netherlands
   Phone: +31 20 409 7656
   Fax: +31 20 453 1574
   Email: Henk.Steenman@icoe.att.com

   George Tsirtsis
   Flarion Technologies
   219 Lymington Avenue
   N22 6JL, London
   Tel/Fax: +44-20-88260073
   e-mail: G.Tsirtsis@Flarion.com

   Ronald van der Pol
   SURFnet bv
   P.O. Box 19035
   3501 DA  Utrecht
   The Netherlands
   Phone: +31 30 230 5305
   Fax: +31 30 230 5329
   Email: Ronald.vanderPol@surfnet.nl

9. Acknowledgment

   The authors would like to acknowledge earlier work on categorizing
   translators from Kazuhiko Yamamoto and Munechika Sumikawa.

Appendix A. IPv6 Address Issues

   The IPv6 Global Unicast Address format is described in [RFC2374].

   This address format splits the 128 bit IPv6 addresses into
   three level of hierarchy, the public topology, the site private
   topology, and the interface identifier.

   The public topology is described in the 48 first bits of an
   IPv6 address. Those 48 bits are made of:

     - 3 bits prefix to identify the IPv6 Global Unicast Address format
     - 45 bit network ID

   The site private topology is a 16 bit field.

   The interface identifier is a 64 bit field.

     | 3|        45        |   16   |          64 bits               |
     |FP|    network ID    |  SLA   |         Interface ID           |
     |  |                  |  ID    |                                |

     <--Public Topology--->   Site
                                     <------Interface Identifier----->

A.1 IPv6 Address Allocation

   IPv6 address space is very large. Much, much larger than the
   IPv4 address space. So the objective of IPv6 address allocation
   is more focused on route aggregation that address conservation.
   However, even though IPv6 address space is very large, it is an
   important resource that must be carefully managed for the good
   of the whole Internet. IPv6 address allocation follows
   strict rules that are discussed by the regional registries
   (RIPE-NCC, ARIN, APNIC) with guidance from the IETF.

A.1.1 Site local vs global addresses

   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, sites 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 each site will have 65536 subnets to define its
   internal topology and in each subnet almost 20 trillion hosts
   can be numbered.

   0                                48       64                  127
   |              prefix             | subnet |   Interface ID     |

A.1.2 Obtaining IPv6 Address Space

   IPv6 addresses can be obtained from the same organizations as the
   ones who register IPv4 addresses. Regional IRs delegate
   a part of the IPv6 address space to local IRs who further delegate
   parts of the address space to their ISP customers. Site will
   obtain IPv6 addresses directly from their ISP.

   The regional IRs use a slow start mechanism [IRALLOC] to
   allocate address space to ISPs. A special
   pre-qualification procedure can be used by ISP
   participating in the 6bone.

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.

A.3 Example of IPv6 address allocation within a site /48 prefix
 In this example the prefix of the site is 3ffe:ffff:0001::/48.
    This means there are 2^16 = 65536 subnets of size /64 available
    (in IPv6 each interface has a netmask of length 64).

    Suppose the site consists of 42 different departments. To leave
    room for future expansion we can split the /48 into 128 /55s
    as follows:

             prefix                usage
    3ffe:ffff:0001:0000::/55     backbone links
    3ffe:ffff:0001:0200::/55     reserved
    3ffe:ffff:0001:0400::/55     central services
    3ffe:ffff:0001:0600::/55     reserved
    3ffe:ffff:0001:0800::/55     department 1
    3ffe:ffff:0001:0A00::/55     reserved
    3ffe:ffff:0001:FC00::/55     department n
    3ffe:ffff:0001:FE00::/55     reserved

    Because it is difficult to predict what the best split will be
    (/53 or /54 or /55, etc) it is possible to assign the bits in a
    more flexible way. This is explained in [IPASSIGN]. Using
    this method makes it easier to change the prefix length to /54 or
    /56 in the future.

    The following table is an example how department 1 could use
    its 3ffe:ffff:0001:0800::/55 prefix:

             prefix               usage
    3ffe:ffff:0001:0800::/64    reserved
    3ffe:ffff:0001:0801::/64    reserved
    3ffe:ffff:0001:0802::/64    reserved
    3ffe:ffff:0001:080E::/64    reserved
    3ffe:ffff:0001:080F::/64    reserved

    3ffe:ffff:0001:0810::/64    computer room
    3ffe:ffff:0001:0811::/64    computer room
    3ffe:ffff:0001:0812::/64    computer room
    3ffe:ffff:0001:087E::/64    computer room
    3ffe:ffff:0001:087F::/64    computer room

    3ffe:ffff:0001:0880::/64    VLAN 1
    3ffe:ffff:0001:0881::/64    VLAN 2
    3ffe:ffff:0001:0882::/64    VLAN 3
    3ffe:ffff:0001:09FE::/64    VLAN n-1
    3ffe:ffff:0001:09FF::/64    VLAN n

    Again, it is better to assign the bits as explained in

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:ffff: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

   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:ffff:0180:0000::0001
                  IN   AAAA   3FFE:ffff:0d80:0000::0005
                  IN   AAAA   3FFE:ffff:4080:0000::0009
                  IN   AAAA   3FFE:ffff:5680:0000::000D

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 is represented as a name in the in-addr.arpa domain as:

   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:ffff:0400:0001:02C0:4FFF:FEC6:9CC7
   is represented as a name in the ip6.int domain as:


   This name is stored in the a DNS data file as follows (assuming
   a /64 prefix):

   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.

   Also note that ip6.int should be deprecated in the near future for ip6.arpa.

B.3 Implementations

   Most DNS implementations will be able to deal with the reverse
   mapping as used with IPv6 addresses. AAAA record is implemented
   in recent DNS implementations.

   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.Appendix C. IPv6 routing issues   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+)   [RFC2858, RFC2545], IS-IS [IS-IS] and OSPF [RFC2740] have   IPv6 extensions defined.   On the core of the 6bone, BGP4+ is mandated. More information   about 6bone routing guidelines can be found in [RFC2772].

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/