INTERNET-DRAFT W. Biemolt, SEC
NGTRANS WG M. Kaat, SEC
October 1999 T. Larder
R. van der Pol, SURFnet
H. Steenman, AT&T
A Guide to the Introduction of IPv6 in the IPv4 World
<draft-ietf-ngtrans-introduction-to-ipv6-transition-02.txt>
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 translation and migration 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.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 1]
Internet Draft Guide to IPv6 Transition Oct 1999
Table of Contents
Status of this Memo..............................................1
1. Introduction .................................................3
2. General IPv6 deployment issues................................3
2.1 IPv6 addressing ...........................................4
2.2 IPv6 and DNS...............................................4
2.3 Routing in IPv6............................................4
3. Basic Migration tools.........................................5
3.1 Dual Stack and Tunneling - Overlay IPv6....................5
3.2 Protocol Translation.......................................6
4. The Tools In System Solutions.................................7
4.1 Configured and Automatic Tunnels...........................7
4.2 6TO4.......................................................8
4.3 6OVER4.....................................................8
4.4 DSTM.......................................................9
4.5 SIIT.......................................................9
4.6 NAT-PT....................................................10
4.7 BITSv6....................................................10
4.8 SOCKS64...................................................10
5. Case Studies, categorization.................................11
5.1 Large organization with a lot of global IPv4 addresses....11
5.2 Large organization with few global IPv4 addresses.........12
5.3 Office or home network with one global ipv4 address.......12
5.4 New network with brand new services.......................13
5.5 ISP case..................................................13
5.6 Internet Exchange.........................................14
6. Case studies, examples.......................................15
6.1 Isolated IPv6 host in an IPv4 Domain......................15
6.2 Small/Medium Organization using a NAT.....................18
6.3 Introducing IPv6 in an ISP environment....................23
6.4 Internet Exchange.........................................25
7. Security considerations......................................27
References......................................................27
Authors' addresses..............................................29
Appendix A - Example of IPv6 address usage......................30
A.1 Ipv6 Address Assignments.................................30
A.2 Ipv6 Registration Issues.................................32
A.3 Example of IPv6 address usage............................32
Appendix B - Example of IPv6 address usage......................35
B.1 Forward mapping..........................................35
B.2 Reverse mapping..........................................35
B.3 Implementations..........................................36
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 2]
Internet Draft Guide to IPv6 Transition Oct 1999
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.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 3]
Internet Draft Guide to IPv6 Transition Oct 1999
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,
commonly implemented with the BIND software [BIND]. 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.
To use routing protocols in IPv6 networks they should be adjusted
to be able to handle IPv6 routing information. At this moment
only RIP (RIPng) [RFC2080, RFC2081] and BGP4 (BGP4+) [RFC2283,
BGP4-IPV6] implementations with IPv6 extensions are available. The
IETF OSPF Working Group [OSPFWG] has defined IPv6 extensions to the
OSPF routing protocol. Unfortunately, there are only a few
implementations available at this moment [ZEBRA] [TELEBIT]. On the
6bone static routing, BGP4+ and RIPng are used.
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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 4]
Internet Draft Guide to IPv6 Transition Oct 1999
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 practice see [RFC2546].
3. Basic Migration Tools
The main concern with the introduction of IPv6 in the current
Internet is the need for IPv6 devices to be able to the existing
IPv4 world. The (migration) tools that can help in accomplishing
this are divided in two broad categories:
- Dual Stack and Tunneling
- Translation
With the first approach the basic idea is that a host or device has
two stacks implemented, one for IPv4 and one for IPv6. Each
respective stack is used to communicate with other devices equipped
with the same IP stack. Tunneling is added to this approach to
facilitate the possibility to have two IPv6 (or IPv4) hosts
communicating with each other separated by an infrastructure of the
other version.
The Translation category of tools solves the communication problem
by translating the IPv6 packets into an IPv4 packet (and vise versa)
while preserving as much as possible the information contained in
the packet headers.
3.1 Dual Stack and Tunneling - Overlay IPv6
- Dual IP stack. Providing complete support for both IPv4 and
IPv6 in hosts and routers.
- IPv6 over IPv4 tunneling. Encapsulating IPv6 packets within
IPv4 headers to carry them over IPv4 routing infrastructures.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 5]
Internet Draft Guide to IPv6 Transition Oct 1999
+-------------------+ +--------+
| application | | IPv6 |
+-------------------+ | domain | +--------+
| TCP / UDP | +--------*---* |
+-------------------+ | IPv4 |
| IPv4 | IPv6 | |networks|
+-------------------+ | *---*--------+
| network layer | +--------+ | IPv6 |
| | | domain |
+-------------------+ +--------+
a. dual stack strategy b. route IPv6 over IPv4 only networks
3.1.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 records.
When both A and AAAA 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.
3.1.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. 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. For example by using
special IPv6 unicast addresses that carry an IPv4 address in the
low-order 32-bits, e.g. IPv4-compatible IPv6 addresses [RFC2373] or
IPv4-mapped IPv6 addresses [RFC2373].
3.2 Protocol Translation
Typically this a solution used to create the possibility to have IPv6
only hosts communicate with the IPv4 world. 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 [SIIT] 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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 6]
Internet Draft Guide to IPv6 Transition Oct 1999
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. The Tools In System Solutions
4.1 Configured And Automatic 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.
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 site
IPv6 requirements: none
IPv6 address requirements: IPv4 compatible addresses
Host requirements: IPv4/IPv6 stack
Router requirements: none
Other requirements: none
4.1.3 Tunnel Broker
The tunnel server [BROKER] is a web based tool that allows
interactive setup of an IPv6 over IPv4 tunnel. By requesting a
tunnel, the host gets assigned an IPv6 address out of the address
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 7]
Internet Draft Guide to IPv6 Transition Oct 1999
space of the tunnel provider. DNS will be updated automatically.
The created tunnel will provide IPv6 connectivity between the tunnel
provider's IPv6 environment and the isolated host. Currently several
implementations of tunnel servers exist [FREENET6], [CSELT].
Applicability scope: host
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.2 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.
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.3 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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 8]
Internet Draft Guide to IPv6 Transition Oct 1999
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.4 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. If an IPv4 host wants to communicate with an IPv4/IPv6
host, the DNS server sends back an A record for the host and DHCPv6
server sends a reconfigure command to the dual stack host to assign
a temporary IPv4 address. The DTI is a virtual interface on the host
which takes care encapsulating the IPv4 packets into IPv6 packets.
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
4.5 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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 9]
Internet Draft Guide to IPv6 Transition Oct 1999
Router requirements: none
Other requirements: none
4.6 NAT-PT
[NAT-PT] address the communication between IPv6 only and IPv4 only
hosts. The communication is realised 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.7 BITSv6
The Bump-In-The-Stack [BITSv6] model allows for the use of none
IPv6 capable applications on a dual stack host to communicate with
IPv6 only hosts. Added to the IPv4/IPv6 dual 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.
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.8 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"
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 10]
Internet Draft Guide to IPv6 Transition Oct 1999
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
5. Case Studies, categorization
5.1 Large organization with a lot of global IPv4 addresses
5.1.1 Description
- large organization
- multiple sites
- No shortage of IPv4 address space, i.e. every host in the
organization has Global Iv4 address.
- not possible to migrate at once
- introduction of IPv6 will be in islands in IPv4 ocean
5.1.2 Possible transition mechanism(s)
5.1.2.1 Internal communication
- Dual Stack/Tunneling
- 6over4 if a multicast environment is available
- Translation is only necessary if islands of IPv6 only devices are
created
5.1.2.2 External communication
In case the provider does not supply IPv6 connectivity, for
connectivity with other IPv6 domains use:
- Configured Tunnels
- Automatic tunnels (6TO4)
For connectivity with the IPv4 world use the existing set-up.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 11]
Internet Draft Guide to IPv6 Transition Oct 1999
5.2 Large organization with few global IPv4 addresses (a /24 or less)
5.2.1 Description
- large organization
- multiple sites
- IPv4 address space used on the Intranet is from the private ranges
- not possible to migrate at once
- introduction of IPv6 will be in islands in IPv4 ocean
- NAT between organization network and commodity Internet
5.2.2 Possible transition mechanism(s)
5.2.2.1 Internal communication
In essence this is the same situation is in the previous case, but
now all hosts use private address space for internal communication
over IPv4.
- Dual Stack/Tunneling
- 6over4 if a multicast environment is available
- Translation is only necessary if islands of IPv6 only devices are
created within the organization
5.2.2.2 External communication
In case the provider does not supply IPv6 connectivity.
For connectivity with other IPv6 domains:
- Configured or automatic (6TO4) tunnels originating on dual stack
routers that have at least one globally unique IPv4 address
For connectivity with the IPv4 world:
- Use the existing NAT box
- Use DSTM to temporarily assign a globally unique IP address to the
host. If IPv6 only devices are introduced in the organization a
translator mechanism should be added for these devices to talk to
the IPv4 world
- Implement NAT-PT (or similar)
5.3 Office or home network with ONE global ipv4 address
5.3.1 Description
Small amount of hosts One network segment One IPv4 address typically
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 12]
Internet Draft Guide to IPv6 Transition Oct 1999
assigned to NAT capable device.
5.3.2 Possible transition mechanism(s)
Upgrade to Dual Stack those devices that need communicate with the
outside world. No need to assign IPv4 addresses on these.
5.3.2.1 Internal communication
- IPv6
- IPv4 using private address space
5.3.2.2 External communication
For connectivity to IPv6 world:
- IPv6 if upstream provider is IPv6 capable
- Dynamic tunnels (6TO4) from egress router
- Configured tunnel to IPv6 capable provider
For connectivity to IPv4 world:
- NAT-PT
5.4 New network with brand new services
5.4.1 Description
[needs to be worked out ...]
5.4.2 Possible transition mechanism(s)
[needs to be worked out ...]
5.4.2.1 Internal communication
[needs to be worked out ...]
5.4.2.2 External communication
[needs to be worked out ...]
5.5 ISP case
5.5.1 Description
[needs to be worked out ...]
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 13]
Internet Draft Guide to IPv6 Transition Oct 1999
5.5.2 Possible transition mechanism(s)
[needs to be worked out ...]
5.5.2.1 Internal communication
[needs to be worked out ...]
5.5.2.2 External communication
[needs to be worked out ...]
5.6 Internet Exchange
[needs to be worked out ...]
5.6.1 Description
[needs to be worked out ...]
5.6.2 Steps to be taken
[needs to be worked out ...]
5.6.2 Possible transition mechanism(s)
[needs to be worked out ...]
5.6.2.1 Internal communication
[needs to be worked out ...]
5.6.2.2 External communication
[needs to be worked out ...]
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 14]
Internet Draft Guide to IPv6 Transition Oct 1999
6 Case studies, examples.
Below are some worked out examples for situations that might occur
in real live environments. Please note that the provided solutions
are only meant as global directions and should not be considered as
the final or even the best solution for the given situation.
6.1 Isolated IPv6 host in an IPv4 Domain
6.1.1 Introduction
A Corporate Customer requires connection to a new bank system. An
IPv6 host in the customer's site is needed to connect to the bank's
IPv6 only site. The bank decided to implement IPv6 only, to benefit
from its enhanced functionality e.g. standardised security. The bank
system is a specialised system and therefore only requires
communication with customer sites. The bank's border router (R2) is
a dual router but nodes within the Bank's network are IPv6 only.
[A diagram showing the current situation goes here]
6.1.2 Migration Requirements
- IPv6 host needs to communicate with all other nodes within the
customer network.
- Continually maintain IPv6 functionality, therefore no use of
translators should be permitted, need to maintain security and
authentication procedures.
- No changes should be made to the Bank's network.
6.1.3 Suitability of the Transition Categories for this Scenario
IPv4 AND IPv6 MECHANISMS One of these mechanisms will be required to
allow the node within the customer site to communicate with IPv6 and
IPv4 nodes.
TUNNELING AND ENCAPSULATION MECHANISMS Tunneling will be required to
allow IPv6 packets to traverse the IPv4 network.
TRANSLATORS Translators have been ruled out due to breaking end to
end connectivity.
6.1.4 Suitability of these Transition Mechanisms for this Scenario
DUAL STACK
Dual stack will need to be deployed in the node installed in the
customer's premises. To allow for some sort of routing through the
IPv4 network, the border router (R1) may also need to be installed
with both IPv4 and IPv6.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 15]
Internet Draft Guide to IPv6 Transition Oct 1999
DUAL STACK WITH CONFIGURED TUNNELS
The IPv4/IPv6 host could be configured to tunnel all IPv6 packets to
the default IPv4/IPv6 router. The packets would be encapsulated with
in IPv4 so that they could be routed to the router through IPv4
infrastructure. The problem is how does the host configure its IPv6
address can neighbour solicitations be transferred to the router
through configured tunneling. If you are configuring a tunnel to the
router R1 you might as well just tunnel all the way to the Bank's
Router R2 and leave R1 as a normal IPv4 router.
DUAL STACK WITH AIIH
No need to use AIIH mechanism as only one host is connecting.
DUAL STACK WITH DTI
Not relevant as packets will mostly be traversing IPv4 networks.
DUAL STACK WITH 6OVER4
6over4 could be used if the network supports multicast routing. As
6over4 only works within a domain the IPv4 router (R1) would need to
support IPv6 and also to have a 6over4 interface configured. The
host could then communicate to router R1 using IPv4 multicast
packets. The rest of the communication path would have to be carried
out by another mechanism such as configured tunneling or 6to4.
6TO4
This could be implemented at the routers R1 and R2 using their
unique IPv4 addresses as an NLA ID to create a unique IPv6 address.
6.1.5 Solution 1
For this solution the IPv4 Network does Support Multicasting.
Mechanisms Suggested in Solution
- Dual Stack
- 6over4
- 6to4 or configured tunneling.
ROUTER
The 6over4 mechanism will require the IPv4 network border router (R1)
to be installed with IPv6 and a 6over4 interface. Note this router
and the host does not need to be on the same segment, if in fact they
were then there would be no requirement for 6over4. The router and
the host are expected to have some IPv4 infrastructure between them.
A Configured tunnel will need to be set up between R1 and R2 so the
IPv6 packets can traverse the IPv4 Internet. The routers R1 and R2
could use the 6to4 method but this would mean that the router R2
would also have to implement 6to4 which in this case is not permitted
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 16]
Internet Draft Guide to IPv6 Transition Oct 1999
as one of the requirements is that `No changes should be made to the
Bank's network'.
HOST
The IPv4 host needs to firstly implement dual stack, keeping its
original IPv4 address and then implementing 6over4 to allow the host
to use encapsulation of IPv6 packets within IPv4 multicast packets.
As this can only be used within an organisation, uses IPv4
Organisation-Local Scope (239.192.0.0) the router (R1) needs to be
configured to support IPv6 routing. This host will find out its
prefix by sending a router solicitation encapsulated within an IPv4
multicast packet to router R1, the router will then return with a
router advertisement using the same method of encapsulation within
an IPv4 multicast packet.
[A diagram showing the solution goes here]
6.1.6 Solution 2
For this solution the IPv4 Network does not support Multicasting.
Mechanisms Suggested in Solution
- Dual Stack
- Configured Tunneling
HOST
The host firstly needs to be implemented with the dual Stack
mechanism. As the host is not going to be able to automatically be
allocated a globally unique IPv6 address this will need to be input
manually using the prefix of the router (R2). _Not sure if this can
be done or is acceptable it could also find out its address by
sending a router advertisement encapsulated within an IPv4 packet to
the router R2_. Secondly the host has to be manually configured with
a tunnel from host to the Bank's Router (R2). Once this is complete
the Host will be able to communicate with the end node retaining the
original functionality of the IPv6 packet.
SECURITY IMPLEMENTATION FOR BOTH SOLUTIONS
Both solutions will require some sort of Security implementation
whether the use of MD5 as an authentication algorithm or DES-CBC as
an encryption algorithm depends entirely on what the bank system
uses.
Implementers should be aware that, in addition to possible attacks
against IPv6, security attacks against IPv4 must also be
considered. Use of IP security at both IPv4 and IPv6 levels should
nevertheless be avoided, for efficiency reasons. For example, if
IPv6 is running encrypted, encryption of IPv4 would be redundant
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 17]
Internet Draft Guide to IPv6 Transition Oct 1999
except if traffic analysis is felt to be a threat. If IPv6 is
running authenticated, the authentication of IPv4 will add little.
Conversely, IPv4 security will not protect IPv6 traffic once it
leaves the IPv6-over- IPv4 domain. Therefore, implementing IPv6
security is required even if IPv4 security is available [6over4].
Although the above was written for 6over4, it is also particularly
relevant to all tunneling mechanisms used.
6.2 Small/Medium Organization using a NAT
6.2.1 Introduction
There are 9 offices, each office is linked using a point-to-point
connection as shown in the diagram. Each site contains a DHCP, DNS
and Mail server and routers are used between offices (as opposed to
half bridges) to minimise traffic. Each router uses the RIP routing
protocol.
The network currently uses a private address space of 192.168/16
prefix with each site using a /24 prefix as shown below:
[Diagram No of users and addressing in each office goes here]
HEAD OFFICE
The Head Offices in London has a DNS server and a NAT at the border
to convert the non-globally unique IP addresses to globally unique IP
addresses, this is used for security purposes as well as allowing its
own internal addressing structure. All external traffic and traffic
that is destined for external sources is sent through the NAT. This
external traffic is minimal with a large percentage of this being
SMTP traffic. Additionally the Head Office has a firewall which is
configured to route all incoming SMTP traffic from the ISP's servers
IP address to the internal mail router which is a Linux machine
running SENDMAIL. The internal mail router then looks at the domain
name in the message header and directly sends it to the relevant Mail
server in each of the offices. On this same machine runs the Proxy
Daemon Squid and NAT. An Intranet Server runs on a separate Linux
machine using Apache.
The NAT in the Billingsgate Office (Head Office) is used for external
communication and is assigned one IPv4 address (194.14.1.1). All
external communication will pass through this device.
[Diagram showing the layout and communication links between the]
[ offices goes here ]
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 18]
Internet Draft Guide to IPv6 Transition Oct 1999
6.2.2 Assumptions
Assume all testing and coding has been carried out on applications
to allow them to run on IPv6 only hosts. If any applications cannot
be run on IPv6 hosts this is detailed in Scenario 4 (IPv4 dependent
applications) and therefore is not covered in this scenario.
6.2.3 Migration Requirements
- To maintain a translator at the network border for ease of
maintenance.
- To allow for communication with IPv4 only hosts at all times during
the transition.
- Eventually eliminate all IPv4 traffic within the network.
Suitability of the Transition Categories for this Scenario.
IPV4 OR IPV6 MECHANISMS
One of these mechanisms will be required to allow nodes to
communicate with both IPv4 only nodes and IPv6 only nodes.
TUNNELING AND ENCAPSULATION MECHANISMS
The Internet is predominantly IPv4 so communication from one site to
another will require the use of tunneling and encapsulation.
TRANSLATORS
A translator could be used to replace the NAT at the border of the
network. This would work as communication outside the private
network is only to one particular end-point the ISP's server, so IPv4
to IPv6 translation could occur.
6.2.4 Suitability of these Transition Mechanisms for this Scenario
DUAL STACK AND NAT
The dual stack mechanism if implemented in the correct order could be
used on its own for communication within the private network but this
would not allow communication with external nodes due to non-globally
unique addressing. IPv6 addressing could be used for communication
with other nodes in the network and IPv4 addressing for communication
with the NAT. This mechanism will not suffer from scalability issues
in this scenario, there are enough IPv4 addresses to support dual
hosts as the address space is private. Manageability of two
different IP addresses for each node is an issue, which will
complicate administration.
DUAL STACK WITH CONFIGURED TUNNELS
To infer that you need configured tunnels means that you are likely
to have some IPv4 infrastructure between IPv6 router or between a
host and a router. In this scenario, upgrading all routers before
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 19]
Internet Draft Guide to IPv6 Transition Oct 1999
hosts will be easier than configuring tunnels between hosts and
routers and routers to routers. This mechanism could be used in a
situation where regional offices, e.g. Birmingham and Edinburgh have
upgraded to IPv6 and the Head Office still using IPv4. A tunnel
would need to be configured from Birmingham to Edinburgh,
encapsulating the IPv6 packet within IPv4 so that it can be routed at
the Head Office. Configured tunneling is more likely to be used in
large establishments or communication over a WAN where there is a
large IPv4 infrastructure.
DUAL STACK WITH AUTOMATIC TUNNELS
If used would allow hosts to be updated before routers. Each host
would need to be configured to use IPv4-Compatible IPv6 addresses,
tunneling would then occur between end-points. This network is only
small with only a few routers, all routers and routing are internal
to the organisation and as such would be easier to upgrade than have
the added problems of routing "flat" addresses and performance
degradation of encapsulating most IPv6 packets within IPv4 packet.
DUAL STACK WITH AIIH
One of the main reasons in using the AIIH mechanism is if there are
not enough IPv4 addresses for each Dual Stack node on the network.
In this scenario they are using a private address space and therefore
are not limited (within reason) to a number of IPv4 addresses.
DUAL STACK WITH DTI
Requires that all routers would need to support IPv6. If this is the
case then if you have the Dual stack and IPv6 routing through the
private network why use DTI? This mechanism would be used as part of
a complex solution for larger organisations with direct external
connections to the Internet and especially in the later stages of
transitioning. I don't think its benefits could be of use in this
scenario.
DUAL STACK AND TRANSLATOR
A NAT is already used at the border of the network which suits their
needs. All nodes in the organisation can be upgraded to dual stack
and the NAT be upgraded to convert IPv6 to IPv4 addresses. This
would allow all nodes in the network to be able to communicate using
only IPv6 and the translator used for converting IPv6 headers to
IPv4.
TRANSLATOR
Could be used on its own to replace the NAT already installed meaning
that the internal structure of the network could remain the same
without any alterations within the private network. Could be used in
the later stages once migration has been completed and most sites are
using IPv6.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 20]
Internet Draft Guide to IPv6 Transition Oct 1999
6OVER4
The internal network does not use multicasting so this mechanism is
not relevant for this scenario.
DUAL STACK, 6TO4 AND TRANSLATOR
Could be used to give the Translator a unique IPv6 address by using
the unique IPv4 address for the translator and using it as an NLA.
This would allow each node internal to the organisation to have a
unique IPv6 address.
6.2.5 Solution 1
Reasoning behind the solution
Currently uses private address space so there is no problem with
limited IPv4 addresses. The easiest approach in transitioning would
be to use dual stack on all hosts. This solution does not require
the complex methods of encapsulation.
Mechanisms Suggested in Solution
- Dual Stack
- Translator
- 6to4 (Option)
6.2.5.1 Stage 1: Head Office
Starting with the Head Office in London as most traffic will be
routed through here, it is essential that this is the first to be
upgraded to IPv6 to allow for communication to allow routing from
regional sites.
The order of Implementation within the Head Office can be followed
from that in Scenario 2, Solution 1 but has been detailed again
below:
DEFAULT ROUTER (R1)
Connects with all other offices. A software upgrade will be required
to allow this to operate as a dual router. The router will treat
IPv6 as an independent protocol so therefore RIPv2 will need to be
activated and configured for IPv6.
DHCP SERVER
Depending on whether this server is necessary is dependent on whether
stateful auto-configuration is required. If required will need to be
upgraded to dual stack to allow allocation of IPv4 addresses out of
the private address space and also stateful IPv6 addresses.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 21]
Internet Draft Guide to IPv6 Transition Oct 1999
DNS SERVER
Upgraded to a dual stack, a requirement for hosts to look up a
destination node using DNS to find out if v4 or v6 address is to be
used.
PROXY SERVER/TRANSLATOR
Will need to be bilingual. This is the conversion point for the
network and will be translating between IPv6 and IPv4 and vice versa.
The firewall will need no new configuration as the data sent to and
from will be IPv4 format, until ISP migrates to IPv6.
SERVERS
Once the above have been converted then the Mail Server and any File
Servers will need IPv6 installed. Again the Mail server may require
some extra configuration.
WORKSTATION
Now all the dependencies have been configured all workstations will
need to be upgraded to support IPv6. This can be in any order and
there is no time limit.
6.2.5.2 Stage 2: London Offices
Once the head office has been upgraded, the regional offices in
London can be upgraded. These can be carried out in whichever order
desired. The following implementation rule shown in stage 1 must
apply to each site:
- Default Router
- DHCP Server
- DNS Server
- Other Servers e.g. Mail Server etc.
- Workstations
6.2.5.3 Stage 3: Regional Offices
Once the London sites have been upgraded the regional sites can be
upgraded. The order is as follows:
Birmingham Manchester Glasgow Edinburgh
The order doesn't have to be followed but it should be noted that if
Glasgow is upgraded before Manchester and Birmingham then tunnels
will have to be configured from Glasgow's Router to the Head Office
Router. Implementation in each office should be followed in
accordance with Stage 1 and Stage 2.
6.2.5.4 Stage 4: Final Stage
Once all nodes within the organisation have been upgraded to IPv6,
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 22]
Internet Draft Guide to IPv6 Transition Oct 1999
the IPv4 component in each node can be deactivated to allow for just
IPv6 traffic on the network. Deactivation will obviously have to be
done in reverse order to the implementation i.e. disable IPv4 on the
workstations first and routers last. The translator at the border
will convert all IPv6 headers into IPv4 headers and vice versa.
Normally it is difficult for translators to convert from IPv4 to
IPv6 e.g. when external to internal communication is initiated. Only
one source in this case will be externally initiating communication
and this will be the ISP server when sending SMTP traffic. The
translator (will have to be an application translator) at the border
of the network can detect and forward SMTP traffic to the correct
node internally.
6TO4 OPTION
The 6to4 mechanism could be used in conjunction with the translator.
The one unique IP address associated with the translator could be
assigned to the NLA field creating a globally unique IPv6 prefix.
This would allow all nodes within the organisation to have a globally
unique IPv6 address and allow the NAT to receive either IPv6 or IPv4
packets.
6.2.6 Solution 2
Mechanisms Suggested in Solution
- Translator
If there was absolutely no need for the implementation of IPv6
within the organisation or if all IPv4 applications required
intensive configuration to convert for IPv6 support there is another
solution. In this case the NAT could just be upgraded to a
translator supporting external IPv6 traffic and leaving the current
internal infrastructure the same. This adds to the problem of how
IPv4 nodes can work out how to send to an IPv6 address external to
the organisation. As all external traffic would be sent to the ISP
address, the translator could be configured to send all external
traffic to this one IPv6 address. The nodes could be configured
manually to send any external data to a certain IPv4 address, which
could be configured by routers to send on to the translator. The
translator would need to know that this IPv4 address should be
converted to the IPv6 address of the ISP server. This would be
quite complex and it would be far easier, for long term
administration and maintenance, to migrate the network to IPv6.
6.3 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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 23]
Internet Draft Guide to IPv6 Transition Oct 1999
IPv6 in those areas.
For each area a couple of steps must be taken first:
- Request IPv6 address space as described in section 2.1.
- Register the IPv6 site, routing and delegations as described in
section 2.2.
- Setup DNS as described in section 2.3.
6.3.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. Automatic tunneling can be
done with for example [6TO4].
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.
6.3.3 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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 24]
Internet Draft Guide to IPv6 Transition Oct 1999
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. Automatic 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. To do this the ISP can install e.g. NAT-PT (see
section 5.3).
6.4 Internet Exchange
Based on address space distribution we can distinguish two models
for the setup of an IPv6 Internet Exchange (IE).
1. The more or less traditional model that is most common in the
IPv4 world. In this case each ISP connecting to the IE 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 IE acts as an address space
provider. In this case the IE 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 IE
needs to arrange for global transit through one or more global
transit providers (TLA ISPs) which are connected to the IE.
Implicitly, this means that the IE arranges transit for all
connected ISPs that use the address space assigned to the IE.
This requires quite a different business model for an IE than in
model 1.
Models 1 and 2 described above require the following steps to be
taken by the IE operator and/or the connected ISPs:
6.4.1 Model 1
- IE operator requests an NLA
Obtain globally unique address space. This can be an NLA from a
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 25]
Internet Draft Guide to IPv6 Transition Oct 1999
transit provider (TLA provider) that offers connectivity for the
IE infrastructure. A global prefix is preferred as next hop
attribute in BGP4 [BGP4-IPV6].
- Addressing infrastructure on IE
From the obtained address space addresses are assigned to the
interfaces of the routers connecting to the IE infrastructure.
- Update the IPv6 registry
The sites, allocations and route objects should be registered as
described in section 2.
- BGP announcements
ISPs connecting to the IE advertise to their peers their own
address space which is independent of the IE. This address space
can either be a TLA or an NLA.
6.4.3 Model 2
- IE operator requests a (sub-)TLA
The IE requests a (sub-)TLA from its regional IR. Customers on
the Internet Exchange get a next level NLA from this (sub-)TLA.
- Addressing infrastructure on IE
From the obtained address space addresses are assigned to the
interfaces of the routers connecting to the IE infrastructure.
- Update the IPv6 registry
The sites, allocations and route objects should be registered as
described in section 2.
- IE operator contracts global transit ISPs (TLA ISPs)
The IE 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 IE.
- BGP announcements
The transit providers for the IE address space announce the
(sub-)TLA from the IE to the global IPv6 network. To the IE
customers they announce all prefixes that can be reached by them
and for which they have a contract with the IE. Customers (NLA
ISPs) get a next level NLA from the IE. The NLA ISPs announce
their NLA to the TLA ISPs. They also announce their NLA to other
NLA ISPs of the IE if there is a peering agreement between them.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 26]
Internet Draft Guide to IPv6 Transition Oct 1999
7. 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 3 of this document
the reader is referred to the referenced documents.
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).
[AIIH] Jim Bound, "Assignment of IPv4 Global Addresses to IPv6
Hosts (AIIH)", draft-ietf-ngtrans-assgn-ipv4-addrs-01.txt
(work in progress).
[BITSv6] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
using the Bump-in-the-Stack technique",
draft-ietf-ngtrans-dual-stack-hosts-02.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).
[CSELT] https://carmen.cselt.it/ipv6tb
[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-00.txt
(work in progress).
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 27]
Internet Draft Guide to IPv6 Transition Oct 1999
[FREENET6] http://www.freenet6.net/
[IRALLOC] Regional IRs, "Provisional IPv6 assignment and allocation
policy document (Draft 6; 27 May 1999)",
ipv6policy-draft-090699.txt (work in progress).
[NAT-PT] George Tsirtsis, Pyda Srishuresh, "Network Address
Translation - Protocol Translation (NAT-PT)",
draft-ietf-ngtrans-natpt-06.txt (work in progress).
[OSPFWG] http://www.ietf.org/html.charters/ospf-charter.html
[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.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 28]
Internet Draft Guide to IPv6 Transition Oct 1999
[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.
[SIIT] Erik Nordmark, "Stateless IP/ICMP Translator",
draft-ietf-ngtrans-siit-06.txt (work in progress).
[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).
[TELEBIT] http://www.tbit.dk/
[ZEBRA] http://www.zebra.org/
Authors' Addresses
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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 29]
Internet Draft Guide to IPv6 Transition Oct 1999
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
Barbrook Cottage
Holmesdale Road
South Nutfield
Surrey RH1 4JE
Email: tim.larder@virgin.net
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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 30]
Internet Draft Guide to IPv6 Transition Oct 1999
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 organisations which have received
pTLA assignments from the 6bone.
A.1.1 Obtaining Ipv6 Address Space
IPv6 addresses can be obtained from the same organisations 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. 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.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 31]
Internet Draft Guide to IPv6 Transition Oct 1999
+--+----------+---------+---------+--------+--------------------+
| 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.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 32]
Internet Draft Guide to IPv6 Transition Oct 1999
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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 33]
Internet Draft Guide to IPv6 Transition Oct 1999
..... ...
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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 34]
Internet Draft Guide to IPv6 Transition Oct 1999
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
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 35]
Internet Draft Guide to IPv6 Transition Oct 1999
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 the AAAA record is only
implemented in recent DNS implementations, like BIND version 8.1 and
higher and the DNS server of Windows 2000. At this moment there is
no known implementation of the A6 record [DNSLOOKUP] or binary labels
[RFC2673].
Note that although these DNS servers implement extensions to support
the use of IPv6 addresses they are not necessarily IPv6 applications
themselves. For IPv6 only nodes an IPv6 DNS server is crucial.
Biemolt, Kaat, Larder, vd Pol, Steenman Expires April 2000 [page 36]
