One document matched: draft-ietf-ngtrans-introduction-to-ipv6-transition-00.txt
INTERNET-DRAFT W. Biemolt, SEC
NGTRANS WG M. Kaat, SEC
April 1999 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-00.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 current
IPv4 based Internet or Intranets. Several general issues to start
IPv6 networking in a predominantly IPv4 world are discussed, such
as how to obtain IPv6 address space, IPv6 DNS and routing issues.
Short descriptions are given of the different translation and
migration tools that translate between IPv6 and IPv4 and/or tunnel
IPv6 over IPv4. The remainder of the document describes how IPv6
can be introduced in various environments, such as ISPs, Internet
Exchanges and end user environments and suggestions are given on the
use of the different translation and migration tools.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 1]
Internet Draft Guide to IPv6 Transition Apr 1999
Table of Contents
Status of this Memo..............................................1
1. Introduction .................................................3
2. General IPv6 implementation issues............................3
2.1 IPv6 address assignments.. ................................4
2.1.1 Obtaining IPv6 address space...........................4
2.1.2 Example of IPv6 address usage..........................6
2.2 IPv6 registration issues...................................8
2.3 IPv6 and DNS...............................................8
2.3.1 Forward mapping........................................8
2.3.2 Reverse mapping.......................................10
2.3.3 Implementations.......................................10
2.4 Routing issues in IPv6....................................11
3. Migration tools..............................................11
3.1 Transition strategies.....................................12
3.2 A short characterisation of the different migration tools.13
4. ISP environments.............................................17
4.1 Introducing IPv6 in an ISP environment....................17
4.1.1 Introducing IPv6 in the core network..................17
4.1.2 Introducing IPv6 in the customer access network.......18
4.2 Internet Exchange.........................................18
5. End user environments........................................20
5.1 Introducing IPv6 in an Intranet environment...............20
5.2 Introducing IPv6 with IPv6 capable upstream provider......21
5.3 Introducing IPv6 without IPv6 capable upstream provider...21
5.4 Single host with upstream provider offering IPv6
connectivity..............................................22
5.5 Single host without upstream provider offering IPv6
connectivity..............................................22
6. IPv6 information on the Internet.............................22
7. Security considerations......................................23
References......................................................24
Authors' addresses..............................................26
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 2]
Internet Draft Guide to IPv6 Transition Apr 1999
1. Introduction
This document is a guide to the introduction of IPv6 in the current
IPv4 based Internet or Intranets. Section 2 outlines the general
issues to start IPv6 networking in a predominantly IPv4 world.
Things that will be handled here are ways to obtain IPv6 address
space, IPv6 registration issues, IPv6 DNS issues and routing issues.
In section 3 short descriptions will be given of the different
translation and migration tools that translate between IPv6 and
IPv4 and/or tunnel IPv6 over IPv4.
In sections 4 and 5 we will discuss how IPv6 can be introduced in
various typical environments. Environments we distinguish are:
ISPs, Internet Exchanges and End User Environments. Emphasis in
these sections will be on the use of the various translation and
integration tools that are discussed in section 3.
In section 6 pointers to IPv6 information on the Internet will
be given.
This document addresses the use of IPv6 in a unicast environment.
Migration of IPv4 to IPv6 multicast environments has not been
considered.
<DISCLAIMER> 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 that exist today to
introduce IPv6 in a predominantly IPv4 environment and have both
IPv6 and IPv4 connectivity within the desired scope. <END DISCLAIMER>
2. General IPv6 implementation issues
The transition from IPv4 to IPv6 will probably follow a dual-stack
strategy. The transformation of IPv4 hosts to dual-stack host should
not require too much effort considering the similarities between the
IPv4 and IPv6 protocol. Upgrading routers is slightly more complex.
Besides implementing IPv6 for hosts and routers a few other things
need to be done before IPv6 actually can be deployed.
First of all IPv6 addresses need to be obtained and these IPv6
addresses need to be registered with Internet Registries and in the
Domain Name System (DNS). Most sites will get a /48 prefix with
16 bits for subnetting and 64 bits for interface ID addressing.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 3]
Internet Draft Guide to IPv6 Transition Apr 1999
0 48 64 127
+---------------------------------+--------+--------------------+
| prefix | subnet | Interface ID |
+---------------------------------+--------+--------------------+
In the following sections it is discussed how to obtain aggregatable
globally routable IPv6 address space and how to register this address
space. Furthermore, in section 2.3 it is discussed how IPv6 hosts
can be registered in the DNS. Section 2.4 discusses some IPv6 routing
issues.
2.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.
At present, there is an experimental network called the "6bone"
which is operated based on IPv6. For this network, a part of the
aggregatable address space is assigned, the so-called Pseudo TLA
(pTLA) 3ffe::/16. Provider pTLAs are assigned by the 6bone [6BONE].
NLAs are assigned in turn by those organisations which have received
pTLA assignments from the 6bone.
2.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
minimise 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
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 4]
Internet Draft Guide to IPv6 Transition Apr 1999
that can get a (sub-)TLA from their regional Internet Registry (IR)
and those ISPs that will not get a (sub-)TLA. In this document the
first category is referred to as "TLA ISPs" and the second category
is referred to as "NLA ISPs", because they will get an NLA from their
upstream provider(s).
TLA ISPs will get a sub-TLA first and can apply for a full TLA later.
This sub-TLA is a /29 prefix. The TLA ISP will allocate /48 prefixes
to end customer sites and /(29+n) prefixes to NLA ISPs, in which "n"
(0<=n<=19) is the number of bits used to identify NLA ISPs [RFC2374].
+--+----------+---------+---------+--------+--------------------+
| 3| 13 | 13 | 19 | 16 | 64 bits |
+--+----------+---------+---------+--------+--------------------+
|FP| TLA | sub-TLA | NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+----------+---------+---------+--------+--------------------+
|<--- TLA ISP prefix -->|<--->|<------ bits for NLA ISP -------->
|
|
NLA ISP identifier (n bits)
An NLA ISP will be allocated a prefix between /29 and /48. It will
use the remaining bits in the NLA ID to identify its customers.
These customers will get a /48.
+--+----------+---------+---------+--------+--------------------+
| 3| 13 | 13 | 19 | 16 | 64 bits |
+--+----------+---------+---------+--------+--------------------+
|FP| TLA | sub-TLA | NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+----------+---------+---------+--------+--------------------+
|<------ NLA ISP prefix ----->|<->|<------ bits for sites ------>
|
|
end customer site identifier (19-n bits)
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 5]
Internet Draft Guide to IPv6 Transition Apr 1999
2.1.2 Example of IPv6 address usage
Sites will get a /48. An example of how to use such a /48 is given below.
In this example the site is allocated 3FFE:1234:5678::/48.
3FFE:1234:5678::/48
|
|
Int1 +-----+-----+ Int2
+-------+ R1 +-------------------+
| +---------+-+ |
| | Int3 |
+-------+-------+ +----+ +-----+----+
| | | | 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:
Int1 3FFE:1234:5678:2000::/50
Int2 3FFE:1234:5678:0000::/49
Int3 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 Int2
3FFE:1234:5678:1000::/49 free
3FFE:1234:5678:2000::/49 Int1 + Int3
3FFE:1234:5678:3000::/49 free
.....
3FFE:1234:5678:F000::/49 free
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 6]
Internet Draft Guide to IPv6 Transition Apr 1999
3FFE:1234:5678:0000::/49
------------------------
3FFE:1234:5678:0000::/64 interfaces of R2
.....
3FFE:1234:5678:00FF::/64 interfaces of R2
3FFE:1234:5678:0100::/64 reserved for R2
.....
3FFE:1234:5678:02FF::/64 reserved for R2
3FFE:1234:5678:0300::/64 free
.....
3FFE:1234:5678:2000::/49
------------------------
3FFE:1234:5678:2000::/50 Int1
3FFE:1234:5678:2100::/50 reserved for Int1
3FFE:1234:5678:2200::/50 reserved for Int1
3FFE:1234:5678:2300::/50 Int3
3FFE:1234:5678:2400::/50 reserved for Int3
3FFE:1234:5678:2500::/50 reserved for Int3
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
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 7]
Internet Draft Guide to IPv6 Transition Apr 1999
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
2.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. The database can be queried by using 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.
2.3 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
resource" record a name can point to an IPv4 address (forward
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 8]
Internet Draft Guide to IPv6 Transition Apr 1999
mapping) and using a "PTR resource" 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].
2.3.1 Forward mapping
A host's 128 bit IPv6 address can be stored with an "AAAA resource"
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 resource" record in IPv4, for
example:
$ORIGIN ipv6.surfnet.nl.
...
zesbot IN A 192.87.110.60
Note that both "A" and "AAAA resource" records 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 resource 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 resource 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 resource records are
widely deployed it is expected that the AAAA records are no longer
needed.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 9]
Internet Draft Guide to IPv6 Transition Apr 1999
2.3.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 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.
This can be compared to the reverse mapping of IPv4 addresses.
For example the IPv4 address 192.87.110.60 is represented as a name
in the in-addr.arpa domain as:
60.110.87.192.in-addr.arpa.
This name is stored in a DNS data file as follows:
$ORIGIN 110.87.192.in-addr.arpa.
...
60 IN PTR zesbot.ipv6.surfnet.nl.
Note that the IPv4 and IPv6 reverse mappings are stored in different
DNS data files.
2.3.3 Implementations
Most DNS implementations will be able to deal with the reverse
mapping as used with IPv6 addresses. However the AAAA resource
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 resource record
[DNSLOOKUP] or binary labels [BITLBL].
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 10]
Internet Draft Guide to IPv6 Transition Apr 1999
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.
2.4 Routing issues 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 no implementations at
this moment. 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 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].
3. Migration tools
In this section a short introduction will be given on transition
strategies for IPv6 nodes. In section 3.2 short descriptions
are listed for the various translation and migration tools that
are being developed.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 11]
Internet Draft Guide to IPv6 Transition Apr 1999
3.1 Transition strategies
Basically there are two different mechanisms to allow IPv6 nodes
to maintain compatibility with IPv4 only nodes.
- 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.
+-------------------+ +--------+
| application | | IPv6 |
+-------------------+ | domain | +--------+
| TCP / UDP | +--------*---* |
+-------------------+ | IPv4 |
| IPv4 | IPv6 | |networks|
+-------------------+ | *---*--------+
| network layer | +--------+ | IPv6 |
| | | domain |
+-------------------+ +--------+
a. dual stack strategy b. route IPv6 over IPv4 only networks
* 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.
* Tunneling
IPv6 nodes that are only connected through IPv4 networks 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
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 12]
Internet Draft Guide to IPv6 Transition Apr 1999
addresses [RFC2373] or IPv4-mapped IPv6 addresses [RFC2373].
3.2 A short characterisation of the different migration tools
A short description of the different translation and migration tools
is listed below. Note that the mentioned "applicability scope"
shows if the tool is intended to be used for an entire site or is to
be implemented on a single host. Listed is further if there are any
general IPv4 related requirements, IPv4 address requirements,
specific IPv6 requirements, IPv6 address requirements or other
requirements.
* [6TO4]:
Applicability scope: site
IPv4 requirements: need IPv4 inter connectivity between
sites
IPv4 address requirements: >= 1 per site
IPv6 requirements: global unique 6to4 prefix (624TLA)
IPv6 address requirements: none
Host requirements: IPv6 stack
Router requirements: implementation of special forwarding
and decapsulation rules
Other requirements: creation of specific DNS record that
reflects 6TO4 prefix and "IPv4" address
NLA
Description:
The [6TO4] tool is applicable for 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.
* [6OVER4]:
Applicability scope: host
IPv4 requirements: IPv4 multicast inter 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
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 13]
Internet Draft Guide to IPv6 Transition Apr 1999
Other requirements: To connect IPv6 hosts on different
physical links, IPv4 Multicast routing
must be enabled on the routers
connecting the links
Description:
Interconnection of isolated IPv6 hosts in a site is realised through
IPv6 in IPv4 encapsulation. A virtual link is created using an IPv4
multicast group with organisational local scope. IPv6 multicast
addresses are mapped to IPv4 multicast addresses to be able to do
Neighbour Discovery. To route between the IPv6 Internet and the
6OVER4 domain in an organisation, a router needs to be configured as
6OVER4 on at least one interface.
* [NAT-PT]:
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
Description:
[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.
* [SIIT]:
Applicability scope: site
IPv4 requirements: none
IPv4 address requirements: 1 temporary per IPv6 host
IPv6 requirements: none
IPv6 address requirements: IPv4-mapped and IPv4-translated
addresses to identify IPv4 nodes and
IPv6 capable nodes respectively
Host requirements: IPv6 stack
Router requirements: none
Other requirements: none
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 14]
Internet Draft Guide to IPv6 Transition Apr 1999
Description:
The 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.
* [AIIH]:
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
Description:
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 co-located DHCPv6 server (that is co-located with the
DNS server) sends a reconfigure command to the dual stack host to
assign a temporary IPv4 address.
* [SOCKS64]:
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
Description:
The [SOCKS64] tool is a gateway system that accepts [SOCKSv5]
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, SOCKS64 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
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 15]
Internet Draft Guide to IPv6 Transition Apr 1999
hosts to connect to IPv4 hosts, IPv4 hosts over IPv6 networks and
IPv6 hosts over IPv4 networks [SOCKS-TRANS]. The later cases
resemble tunnel techniques without possible problems with
fragmentation or hop limits.
* [BITSv6]:
Applicability scope: host
IPv4 requirements: none
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
Description:
The 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.
* [TunnelBroker]:
Applicability scope: host
IPv4 requirements: none
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 Broker server
Description:
The tunnel 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 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.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 16]
Internet Draft Guide to IPv6 Transition Apr 1999
4. ISP environments
This section describes how different organisations (ISPs, Internet
Exchanges) can start deploying IPv6. It describes how IPv6 can be
setup in the organisation and how to connect to the global IPv6
infrastructure.
4.1 Introducing IPv6 in an ISP environment
The network of an ISP consists of at least three main areas: the
core network, the connections to other IPSs and the customer access
network. The next two sections will discuss how an ISP can
introduce IPv6 in those areas.
For each area a couple of steps must be taken first:
* Request IPv6 address space 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.
4.1.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].
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 17]
Internet Draft Guide to IPv6 Transition Apr 1999
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.
4.1.2 Introducing IPv6 in the customer access network
The customer access network consists of dial up and leased lines
connected to an access router. There are at least two possibilities
to introduce IPv6. The first possibility is to upgrade access
routers to dual stack routers. Both IPv4 and IPv6 customers connect
to these dual stack routers.
Another possibility is to install separate IPv6 or dual stack
routers. IPv4-only customers connect to the old IPv4-only access
routers. IPv6 customers connect to the new access routers.
These IPv6 access routers must be connected to the global IPv6
network. If the core does not support IPv6, one of the transition
mechanisms from section 3 must be used. 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).
4.2 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
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 18]
Internet Draft Guide to IPv6 Transition Apr 1999
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:
* Model 1:
- IE operator requests an NLA
Obtain globally unique address space. This can be an NLA from a
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.
* 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.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 19]
Internet Draft Guide to IPv6 Transition Apr 1999
- 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.
5. End user environments
This section describes how end users can start deploying IPv6 in
their networks. We define an end user environment as a network
consisting of a single routing domain that is not being used to
offer Internet access to others. In the extreme case an end user
can be only one host that dials in to an ISP.
For the cases of end users we can distinguish two main situations,
one where the Internet provider for the end host offers IPv6
connectivity and the other where the Internet provider does not
offer IPv6 connectivity. Next to this distinction the situation is
different for a single dial-in host or for a network. Last we can
distinguish the case where the end user is an Intranet that is not
connected to the Internet.
The general expectation is that the introduction of IPv6 in the
Internet will happen with dual stack hosts and routers. However,
for a very long time (one might consider decades) there will remain
IPv4 only applications, servers and end stations. Also, one might
expect the introduction of IPv6 only stacks in devices that up till
now do not run on IP, for example GSM telephones, PDAs and home
devices. To make inter-operability possible between the IPv6 and
the IPv4 world a number of tools are available.
The sections below discuss the different end user situations
described above and the possibilities to introduce IPv6 in that
particular environment.
5.1 Introducing IPv6 in an Intranet environment
Methods to introduce IPv6 in an Intranet environment depend very
much on the scale and topology of the Intranet. Assumed is that
there is no IPv4 addressing issue in the Intranet. We distinguish
the following situations:
* A number of isolated IPv4/IPv6 dual stack hosts.
- In case the hosts all reside on the same link there is no issue.
- In case the IPv6/IPv4 hosts reside on different links there are
several options for IPv6 communication between these hosts:
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 20]
Internet Draft Guide to IPv6 Transition Apr 1999
- IPv6 routing is turned on on the routers connecting the links.
- if IPv4 multicast routing is enabled between the links,
[6OVER4] can be used to create virtual links.
* A number of isolated IPv6 capable networks can be distinguished in
the Intranet.
- For IPv6 communication between these networks the following could
be applied :
- turn on routing on the routers interconnecting the networks.
- implement [6TO4] on the egress routers connecting the networks
to the Intranet.
In all cases it might be useful to implement [BITSv6] to make it
possible for IPv4 only applications to communicate in the IPv6 world.
5.2 Introducing IPv6 with IPv6 capable upstream provider
To introduce IPv6 in end user networks where the upstream provider
is offering both IPv4 and IPv6 connectivity the implementation
issues are actually the same as in the Intranet environment
described in the previous section. The end user network must be
made capable of routing IPv6. The upstream provider for Internet
connectivity will take care of routing to both the IPv4 and the
IPv6 world.
5.3 Introducing IPv6 without IPv6 capable upstream provider
To introduce IPv6 in an end user network if the upstream provider
is not offering IPv6 connectivity there are two possible
approaches. To implement connectivity for the end user network
to the IPv6 world one can either use [6TO4] or a statically
configured tunnel from the end user network egress router to an
IPv6 provider.
Once there is IPv6 connectivity between the end user network and the
IPv6 world we can have the following situations:
* IPv4/IPv6 hosts
- General availability of IPv4 addresses: in this situation there
is no issue.
- Limited availability of IPv4 addresses: in this case we have no
problems to communicate from the host at the end user network to
an IPv6 capable host in the rest of the world. In order to
communicate with the IPv4 world, assignment of a temporary IPv4
address to a host is necessary. This can be accomplished with
[AIIH].
* IPv6 only hosts
- If there are IPv6 only hosts on the end user network then
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 21]
Internet Draft Guide to IPv6 Transition Apr 1999
[NAT-PT] offers a solution to communicate with the IPv4 world.
In all cases it might be useful to implement [BITSv6] to make it
possible for IPv4 only applications to communicate in the IPv6 world.
5.4 Single host with upstream provider offering IPv6 connectivity
This situation typically applies in the case of a dial-in user
connecting to a dial-in provider. We assume the provider takes full
responsibility to reach both the IPv4 and the IPv6 world at the
network level and the dial-in user should not be concerned with this.
We can distinguish the following situations:
* If the dial-in host gets assigned both an IPv6 and IPv4 address:
full connectivity between both the IPv6 and IPv4 world is possible.
* The dial-in user only gets assigned an IPv6 address:
in case connectivity with an IPv4 hosts is necessary, the ISP might
typically offer interconnectivity services like [AIIH], [SIIT] or
[NAT-PT].
The host might consider implementing [BITSv6] to use IPv4 only
applications to communicate with IPv6 servers.
5.5 Single host without upstream provider offering IPv6 connectivity
This situation typically applies to dial-in users connecting to a
dial-in provider with no IPv6 support or to isolated IPv6 users or
testers in an pure IPv4 environment.
In case of a dual stack host the typical solution for this situation
is use of the web based [TunnelBroker] application to obtain
connectivity to the IPv6 world. The use of the [BITSv6]
implementation can be considered for the use of communicating between
IPv4 only applications on the local host and IPv6 only servers.
6. IPv6 information on the Internet
On various places on the Internet information can be obtained on IPv6
implementations, deployment and transitioning. Some good starting
points are listen below.
* http://playground.sun.com/pub/ipng/html/
Provides general information about the Next Generation Internet
Protocol (IPng). Also contains pointers to other IPv6 resources.
* http://www.6bone.net
Source of information about the 6bone, a virtual network
layered on top of portions of the physical IPv4-based Internet
used as a testbed for IPv6 connectivity and interoperability.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 22]
Internet Draft Guide to IPv6 Transition Apr 1999
Also contains pointers to other IPv6 resources.
* http://www.6ren.net
Source of information about the 6ren, an initiative that wants to
provide production IPv6 transit service to facilitiate high
quality, high performance, and operationally robust IPv6
networks. Also contains pointers to other IPv6 resources.
* http://www.ipv6.org
Contains many pointers to various IPv6 resources.
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.
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 23]
Internet Draft Guide to IPv6 Transition Apr 1999
References
[6BONE] http://www.6bone.net.
[6OVER4] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels",
draft-ietf-ipngwg-6over4-02.txt (work in progress).
[6TO4] B. Carpenter, K Moore, "Connection of IPv6 Domains via
IPv4 Clouds without Explicit Tunnels",
draft-ietf-ngtrans-6to4-01.txt (work in progress).
[AIIH] Jim Bound, "Assignment of IPv4 Global Addresses to IPv6
Hosts (AIIH)", draft-ietf-ngtrans-assgn-ipv4-addrs-01.txt
(work in progress).
[BGP4-IPV6] Pedro R. Marques and Francis Dupont, "Use of BGP-4
Multiprotocol Extensions for IPv6 Inter-Domain Routing",
draft-ietf-idr-bgp4-ipv6-02.txt, (work in progress).
[BITLBL] Matt Crawford, "Binary Labels in the Domain Name System",
draft-ietf-dnsind-binary-labels-04.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-00.txt
(work in progress).
[DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration
Protocol for IPv6", draft-ietf-dhc-dhcpv6-14.txt
(work in progress).
[DHCPv6-EXT] C. Perkins, J. Bound, "Extensions for the Dynamic Host
Configuration Protocol for IPv6",
draft-ietf-dhc-v6exts-11.txt (work in progress).
[DNAME] Matt Crawford, "Non-Terminal DNS Name Redirection",
draft-ietf-dnsind-dname-03.txt (work in progress).
[DNSLOOKUP] Matt Crawford, Christian Huitema, Susan Thomson, "DNS
Extensions to Support IP Version 6",
draft-ietf-ipngwg-aaaa-03.txt (work in progress).
[IRALLOC] Regional IRs, "IPv6 assignment and allocation policy
document (5th draft)", ipv6policy-draft-160499.txt
(work in progress).
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 24]
Internet Draft Guide to IPv6 Transition Apr 1999
[NAT-PT] George Tsirtsis, Pyda Srishuresh, "Network Address
Translation - Protocol Translation (NAT-PT)",
draft-ietf-ngtrans-natpt-05.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.
[RFC1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC2080] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2081] G. Malkin, "RIPng Protocol Applicability
Statement", RFC 2081, January 1997.
[RFC2185] R. Callon, D. Haskin, "Routing Aspects of IPv6
Transition", RFC 2185, September 1997.
[RFC2283] T. Bates, R. Chandra, D.Katz, Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283, February 1998.
[RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2374] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format", RFC 2374, July 1998.
[SIIT] Erik Nordmark, "Stateless IP/ICMP Translator",
draft-ietf-ngtrans-siit-05.txt (work in progress).
[SOCKS64] A. Jinzaki and S. Kobayashi, "SOCKS64: An IPv4-IPv6
intercommunication gateway using SOCKS5 protocol",
draft-jinzaki-socks64-00.txt (work in progress).
[SOCKS-TRANS] H. Kitamura, "A SOCKS-based IPv6/IPv4 Translator
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 25]
Internet Draft Guide to IPv6 Transition Apr 1999
Architecture",
draft-kitamura-socks-ipv6-trans-arch-00.txt
(work in progress).
[SOCKSv5] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[TunnelBroker] http://www.freenet6.net/.
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
E-mail: Wim.Biemolt@sec.nl
Marijke Kaat
SURFnet ExpertiseCentrum bv
P.O. Box 19115
3501 DC Utrecht
The Netherlands
Phone: +31 30 230 5305
Fax: +31 30 230 5329
E-mail: Marijke.Kaat@sec.nl
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
E-mail: Ronald.vanderPol@surfnet.nl
Henk Steenman
AT&T, ICoE
Laarderhoogtweg 25
1101 EB Amsterdam
The Netherlands
Phone: +31 20 409 7656
Fax: +31 20 453 1574
E-mail: Henk.Steenman@icoe.att.com
Biemolt, Kaat, van der Pol, Steenman Expires October 1999 [page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 16:11:04 |