One document matched: draft-ietf-ngtrans-introduction-to-ipv6-transition-05.txt
Differences from draft-ietf-ngtrans-introduction-to-ipv6-transition-04.txt
INTERNET-DRAFT W. Biemolt, SEC
NGTRANS WG M. Kaat, SEC
November2000 T. Larder, CISCO
H. Steenman, AT&T
R. van der Pol, SURFnet
G. Tsirtsis, BT
Y. Sekiya, ISI
A. Durand, SUN
K. Yamamoto, IIJ
D. Finkerson, UNL
A. Hazeltine, ADVSYS
On overview of the introduction of IPv6 in the Internet
<draft-ietf-ngtrans-introduction-to-ipv6-transition-05.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 transition tools and mechanisms that
translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The
remainder of this document describes how IPv6 can be introduced in
various environments, such as ISPs, Internet Exchanges and end user
environments. Suggestions are given on the use of the different
translation and migration tools in each environment.
Table of Contents
1. Introduction
2. The 6bone
3. Basic transition mechanism
3.1 Dual IP stack
3.2 Tunneling
4. The Tools In System Solutions
4.1 Connecting IPv6 islands
4.1.1 Configured tunnels
4.1.2 Automatic tunnels
4.1.3 Tunnel Broker
4.1.4 6TO4
4.1.5 6OVER4
4.2 Communication between IPv4 and IPv6 nodes.
4.2.1 Dual stack model
4.2.2 Limited Dual stack model
4.2.3 SOCKS64
4.2.4 SIIT
4.2.5 NAT-PT
4.2.6 BIS
4.2.7 Transport Relay Translator
4.2.8 DSTM
5. Case Studies
5.1 Large organization with a lot of global IPv4 addresses
5.1.1 Motivations
5.1.2 Prerequisites
5.1.3 Network infrastructure
5.1.4 dual stack servers
5.1.5 dual stack clients
5.1.6 IPv6 aware applications
5.1.7 Connection to the IPv6 Internet
5.1.8 IPv6 only hosts
5.1.9 IPv6 only node and IPv4 only server
5.2 Large organization with few global IPv4 addresses (a /24 or less)
5.3 The extranet case
5.4 Office or home network with ONE global IPv4 address
5.5 New network with brand new services
5.6 Introducing IPv6 in an ISP environment
5.6.1 Introducing IPv6 in the core network
5.6.2 Introducing IPv6 in the customer access network
5.7 Internet Exchange
5.7.1 The traditional IX model
5.7.1.1 Address space:
5.7.1.2 Addressing infrastructure on IX:
5.7.1.3 Updating the IPv6 registries:
5.7.1.4 BGP announcements:
5.7.2 The addressing IX model
5.7.2.1 Address space:
5.7.2.2 Addressing infrastructure on IX:
5.7.2.3 Updating the IPv6 registries:
5.7.2.4 Contracts with global transit ISPs (TLA ISPs)
5.7.2.5 BGP announcements:
6. Security considerations
7. References
8. Authors' addresses
Appendix A - IPv6 Address Issues
A.1 IPv6 Address Allocation
A.1.1 Site local vs global addresses
A.1.2 Obtaining IPv6 Address Space
A.2 IPv6 Registration Issues
A.3 Example of IPv6 address usage within a site /48 prefix
Appendix B. IPv6 and DNS
B.1 Forward mapping
B.2 Reverse mapping
B.3 Implementations
Appendix C. IPv6 routing issues
1. Introduction
The goal of this document is to provide an overview of several
transition mechanisms developed within the IETF NGtrans
working group. It is not intended to describe the complete
migration from IPv4 to IPv6 for the whole Internet.
It is an attempt to describe the possibilities
of introducing IPv6 in a predominantly IPv4 environment
and having both IPv6 and IPv4 connectivity.
The scope of this document is limited to IPv6 unicast transition.
Migration of IPv4 to IPv6 multicast environments is not
considered.
Section 2 provide some information and pointers about the 6bone,
an IPv6 tested.
Sections 3 and 4 provide short descriptions of the different
transition tools and mechanisms that translate between
IPv6 and IPv4 and/or tunnel IPv6 over IPv4.
Section 5 will discuss how IPv6 can be introduced in
typical environments.
Appendices A, B & C discuss issues about IPv6 address allocation,
IPv6 addresses in the DNS and IPv6 routing protocols.
2. The 6bone
The 6bone is an IPv6 Testbed that is an outgrowth of the
IETF IPng project that created the IPv6 protocols intended
to eventually replace the current Internet network layer
protocols known as IPv4.
The 6bone is currently a world wide informal collaborative
project, informally operated with oversight from the "NGtrans"
(IPv6 Transition) Working Group of the IETF.
The 6bone started as a virtual network (using IPv6 over IPv4
tunneling/encapsulation) operating over the IPv4-based Internet
to support IPv6 transport, and is slowly migrating to native
links for IPv6 transport.
The initial 6bone focus was on testing of standards and
implementations, while the current focus is more on testing
of transition and operational procedures.
The 6bone operates under the IPv6 Testing Address Allocation
(see RFC 2471).
A document describing the 6bone routing guidelines has been
published as RFC 2772.
More information can be found on http://www.6bone.net
By now, the 6bone is not the only IPv6 backbone. Other
backbones, academic and commercial are offering IPv6 services.
3. Basic transition mechanism
[RFC2893] defines some basic mechanism:
- Dual IP stack. Providing complete support for both IPv4 and
IPv6 in hosts or routers.
- IPv6 over IPv4 tunneling. Encapsulating IPv6 packets within
IPv4 headers to carry them over IPv4 routing infrastructures.
+-------------------+ +--------+
| application | | IPv6 |
+-------------------+ | domain | +--------+
| TCP / UDP | +--------*---* |
+-------------------+ | IPv4 |
| IPv4 | IPv6 | |networks|
+-------------------+ | *---*--------+
| network layer | +--------+ | IPv6 |
| | | domain |
+-------------------+ +--------+
a. dual stack node b. route IPv6 over IPv4 only networks
3.1 Dual IP stack
Dual stack nodes will be able to interoperate directly with both
IPv4 and IPv6 nodes. They must provide a resolver library capable of
dealing with the IPv4 A records as well as the IPv6 AAAA or A6 records.
When both A and AAAA or A6 records are listed in the DNS there are three
different options [RFC1933, RFC2893], (i) return only IPv6 address(es), (ii)
return only IPv4 address(es) or (iii) return both IPv4 and IPv6
addresses. The selection of which address type to return, or, in
which order can affect what type of IP traffic is generated.
The appellation "Dual Stack" in itself is somehow misleading.
Most implementation of IPv6 do not offer two completely distinct
TCP/IP stacks, one for IPv4 and one for IPv6, but an hybrid stack
in which most of the code is shared between the two protocol suites.
However, as the term "Dual Stack" is widely used in other documents,
this text will keep on using it.
3.2 Tunneling
IPv6 nodes (or networks) that are separated by IPv4 infrastructures
can build a virtual link by configuring a tunnel. IPv6 packets going
towards another IPv6 domain will then be encapsulated within IPv4
packets. The tunnel end-points are two IPv4 addresses and
two IPv6 addresses. Two types of tunneling can be employed:
configured and automatic. Configured tunnels are created by
manual configuration. The 6bone itself is an example of a network
containing mainly configured tunnels.
Automatic tunnels on the other hand do not need manual configuration.
The tunnel end-points are automatically determined by using IPv4
compatible IPv6 addresses [RFC2373].
Since most of the known tunneling techniques described later
are based on IPv4 addresses at both end of the tunnel,
many of the techniques cannot work if an IPv4 address
translation happens between the two endpoints of the tunnel.
4. The Tools In System Solutions
When introducing IPv6 in the Internet, one faces two different
sets of problems. The first one is related to having IPv6
communications among two or more IPv6 islands isolated in the
IPv4 world. The second set is related to the establishment of
(or some sort of) communications between the existing IPv4 world
and the new IPv6 world.
In the first set of problems, solutions are generally based
on dual stacks routers and IPv6 in IPv4 tunnels.
Mechanism to solve the second set of problems rely on dual stack
techniques, application level gateways, NAT technology or on
temporary allocation of IPv4 address and IPv4 in IPv6 tunneling.
This document define some generic criteria to compare tools.
Applicability scope: where the transition tool applies to:
site, host.
A solution with scope of site generally enables a whole site
to connect, where a scope of a host enables the connection of
a single host.
IPv4 requirements: what is required in the IPv4 context
to make the tool work.
IPv4 address requirements: This tries to identify how many
IPv4 addresses are required. In some contexts, the need
for many IPv4 addresses can be a no-go criteria.
IPv6 requirements: what is required in the IPv6 context
to make the tool work.
IPv6 address requirements: This identifies how many IPv6 addresses
are required for this specific solution.
Host requirements: What is needed for the hosts to participate
in this solution.
Router requirements: What is needed for the routers to enable
this solution.
NAT impact: Will this solution work if deployed behind a NAT box?
Other requirements: other requirements not listed above.
4.1 Connecting IPv6 islands
The mechanisms described here are designed to enable IPv6
communication between IPv6 islands isolated in the IPv4 world.
All of these rely on tunnels.
4.1.1 Configured tunnels
Manually configured tunnels can be used to connect IPv6 hosts or
networks over an IPv4 infrastructure. Typically configured tunnels
are used between sites where traffic will be exchanged regularly.
Note that a site can be limited to a single host.
Applicability scope: site
IPv4 requirements: IPv4 inter connectivity between sites
IPv4 address requirements: >= 1 per site
IPv6 requirements: none
IPv6 address requirements: end node need one IPv6 address
Host requirements: IPv6 stack or IPv4/IPv6 stack
Router requirements: IPv4/IPv6 stack
NAT impact: will not work if the tunnel has to cross
a NAT BOX.
may work if the tunnel endpoint is
collocated with the NAT box
Other requirements: none
4.1.2 Automatic tunnels
Automatic tunnels are used as configured tunnels to connect separated
IPv6 hosts or networks. Automatic tunnels are created when needed
and broken up when no longer necessary. Typically automatic tunnels
are used between individual hosts or between networks where only
incidentally there is a need for traffic exchange. A pre-requisite
for the use of automatic tunnels is the existence of IPv4 compatible
addresses for the IPv6 hosts that need intercommunication. These
addresses allow the hosts to derive the IPv4 addresses of the tunnel
endpoints from the IPv6 addresses.
Applicability scope: host
IPv4 requirements: IPv4 interconnectivity between sites
IPv4 address requirements: 1 per host
IPv6 requirements: none
IPv6 address requirements: IPv4 compatible addresses
Host requirements: IPv4/IPv6 stack
Router requirements: none
NAT impact: will not work if the tunnels have to cross
a NAT BOX
Other requirements: none
As this solution requires one IPv4 address per host, its domain
of application is extremely limited.
4.1.3 Tunnel Broker
Configuring tunnels usually require cooperation of the two parties
to set up the correct tunnel end-points. The tunnel broker model
helps people collect the necessary information to
set up the tunnels. A tunnel broker can be viewed as an IPv6 ISP
offering connectivity through IPv6 over IPv4 tunnels.
Current implementations are web based tools that allows
interactive setup of an IPv6 over IPv4 tunnel. By requesting a
tunnel, the tunnel client gets assigned IPv6 addresses out of the
address space of the tunnel provider.
It can request either a single address or a network prefix
if a site is to be connected.
DNS will be updated automatically.
The created tunnel will provide IPv6 connectivity between the tunnel
provider's IPv6 environment and the isolated host/site.
Applicability scope: host/site
IPv4 requirements: none specific
IPv4 address requirements: 1
IPv6 requirements: none
IPv6 address requirements: none in the isolated client case
a prefix allocation if there is a network
to connect.
Host requirements: IPv4/IPv6 stack, IPv4 Web browser
Router requirements: none
NAT impact: will not work if the tunnel has to cross
a NAT BOX
may work if the tunnel client is
collocated with the NAT box
Other requirements: Tunnel server
4.1.4 6TO4
The 6to4 [6TO4] tool is applicable for the interconnection of
isolated IPv6 domains in an IPv4 world. The egress router of the
IPv6 domain creates a tunnel to the other IPv6 domain.
The IPv4 endpoints
of the tunnel are identified in the prefix of the IPv6 domain. This
prefix is made up of a unique 6TO4 TLA plus an NLA that identifies
the site by the IPv4 address of the translating egress router.
Another interesting effect of 6to4 is that it automatically derives
a /48 IPv6 from an IPv4 address. With this mechanism, sites can
start to deploy IPv6 without having to ask for IPv6 address space
from the registries. It is also very valuable in the absence
of IPv6 ISPs as it reduces to zero the management of tunnels.
Applicability scope: 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
NAT impact: will not work if the tunnel has to cross
a NAT BOX
may work if the 6to4 router is
collocated with the NAT box
Other requirements: creation of DNS record that reflects 6TO4
prefix and "IPv4" address NLA
4.1.5 6OVER4
6over4 [RFC2529] interconnects isolated IPv6 hosts in a site through
IPv6 in IPv4 encapsulation without explicit tunnels. A virtual link
is created using an IPv4 multicast group with organizational local
scope. IPv6 multicast addresses are mapped to IPv4 multicast
addresses to be able to do Neighbor Discovery. To route between the
IPv6 Internet and the 6over4 domain in an organization, a router
needs to be configured as 6over4 on at least one interface.
Applicability scope: host
IPv4 requirements: IPv4 multicast connectivity between hosts
IPv4 address requirements: 1 per host
IPv6 requirements: none
IPv6 address requirements: none
Host requirements: IPv4/IPv6 stack
Router requirements: 6over4 configuration to route between
different virtual links and/or virtual
links and the IPv6 Internet
NAT impact: will probably not work easily.
Will have to make IPv4 multicast
work across NAT first.
Other requirements: To connect IPv6 hosts on different
physical links, IPv4 Multicast routing
must be enabled on the routers connecting
the links
4.2 Communication between IPv4 and IPv6 nodes.
When IPv6 islands are installed and connected together using
one or several of the above mechanism, communication between
IPv6 hosts is enabled. Communication between an IPv4 host and
an IPv6 host may also be important to establish. This can be done
in several ways, either by relaying at the application level,
or translating at the network layer or by temporarily allocating
an IPv4 address to the IPv6 node.
Note on Protocol Translation:
Typically a protocol translator maps the fields in the packets header
of one of the protocols to semantically similar fields in the packet
header of the other protocol.
A set of rules for the translation between IPv4
and IPv6 is defined in the SIIT [RFC2765] proposal discussed
below. It should be noted that in IPv4 applications, it is not uncommon
that the application has knowledge of information from the network
layer (like address length or the address itself). An example of this
is FTP. This makes it necessary not only to translate the network
layer packets but also to translate at the application layer.
4.2.1 Dual stack model
In the dual stack model, all IPv6 nodes, hosts or routers, are
dual stacked. That way, communication to IPv4 nodes takes
place with the IPv4 stack and communication with the IPv6 world
takes place with the IPv6 stack. The limitation of this approach
is the need to allocate an IPv4 address to each new IPv6
enable device.
Applicability scope: site
IPv4 requirements: IPv4 addressing plan and
IPv4 routing plan
IPv4 address requirements: 1 per host, many per router
IPv6 requirements: IPv6 addressing plan and
IPv6 routing plan
IPv6 address requirements: 1 per host, many per router
Host requirements: IPv4/IPv6 stack
Router requirements: IPv4/IPv6 stack, IPv6 routing protocols
NAT impact: IPv6 communications will be end to end.
IPv4 ones won't.
Other requirements:
4.2.2 Limited Dual stack model
In the limited dual stack model, only the "server" nodes are
dual-stacked. The new "client nodes" are IPv6 only. A server node
is defined as a node hosting enterprise Internet services, such as
file sharing, DNS, web... A client node is defined as a node
not offering those services but wanting to use them.
With this approach, many less IPv4 addresses are used,
but the communication between an IPv4 only client node and an IPv6
only server is broken. To re-establish this communication,
proxies are installed for strategic services.
Applicability scope: site
IPv4 requirements: use existing IPv4 infrastructure
IPv4 address requirements: 1 per server node
IPv6 requirements: IPv6 addressing plan and
IPv6 routing plan
IPv6 address requirements: 1 per new host, many per new router
Host requirements: IPv4/IPv6 stack on servers, IPv6 stack
on new clients
Router requirements: IPv4/IPv6 stack, IPv6 routing protocols
NAT impact: ???
box and the proxies.
Other requirements:
4.2.3 SOCKS64
The SOCKS Gateway [SOCKS-GATE] tool is a system that accepts
enhanced [SOCKS-EXT] SOCKS [RFC1928] connections from IPv4 hosts
and relays it to IPv4 or IPv6 hosts. Especially for "socksified"
sites who already use SOCKS aware clients and a SOCKS server, SOCKS
Gateway provides an easy way to let IPv4 hosts connect to IPv6 hosts.
No DNS modifications or address mapping is needed. The principle can
also be used to allow IPv6 hosts to connect to IPv4 hosts, IPv4 hosts
over IPv6 networks and IPv6 hosts over IPv4 networks. The later
cases resemble tunnel techniques without possible problems with
fragmentation or hop limits.
Applicability scope: site
IPv4 requirements: none specific
IPv4 address requirements: 1 per host
IPv6 requirements: >= 1 per site
IPv6 address requirements: none
Host requirements: clients should be "socksified"
Router requirements: none
NAT impact: ???
Other requirements: dual stack SOCKS server
4.2.4 SIIT
The [SIIT] protocol describes a method to translate between IPv6 and
IPv4. Translation is limited to the IP packet header. The work does
not describe a method to assign a temporary IPv4 address to the IPv6
node. The translator is operating in a stateless mode, which means
that translation needs to be done for every packet.
Applicability scope: site
IPv4 requirements: none
IPv4 address requirements: 1 temporary per IPv6 host
IPv6 requirements: none
IPv6 address requirements: IPv4-mapped and IPv4-translated addresses
to identify IPv4 nodes and IPv6 capable
nodes respectively
Host requirements: IPv6 stack
Router requirements: none
NAT impact: ???
Other requirements: none
4.2.5 NAT-PT
NAT-PT, defined in [RFC2766] address the communication between
IPv6 only and IPv4 only hosts. The communication is realized by use
of a dedicated device that does the translation between IPv4 and IPv6
addresses and keeps state during the time of the session.
The NAT-PT device also includes an application layer gateway to make
translation possible between IPv4 and IPv6 DNS requests and answers.
Applicability scope: site
IPv4 requirements: none
IPv4 address requirements: >=1 per site
IPv6 requirements: none
IPv6 address requirements: none
Host requirements: IPv6 stack
Router requirements: none, but the router might be the NAT-PT
device
NAT impact: ???
Other requirements: none
4.2.6 BIS
The Bump-In-The-Stack [RFC2767] model allows for the use of non IPv6
capable applications on an IPv4 host to communicate with
IPv6 only hosts. Added to the IPv4 stack are three modules
that intervene between the application and the network, an
extension to the name resolver, an address mapper and a translator.
The main idea is that when an IPv4 application needs to communicate
with an IPv6 only host, the IPv6 address of that host is mapped into
an IPv4 address out of a pool local to the dual stack hosts. The
IPv4 packet generated for the communication is translated into an
IPv6 packet according to SIIT.
One can view Bump-in-the-stack as a particular implementation
of NAT-PT within the IP stack of a host.
Note that a similar technique can be implemented at the library
level on a dual stack host.
Applicability scope: host
IPv4 requirements: none specific
IPv4 address requirements: pool of private address space per host
IPv6 requirements: none
IPv6 address requirements: none
Host requirements: IPv6/IPv4 stack plus extensions
Router requirements: none
NAT impact: ???
Other requirements: none
4.2.7 Transport Relay Translator
Transport Relay Translator defined in [TRT] enables direct
communication between IPv6 hosts and IPv4 hosts. This
mechanism is somehow similar to NAT-PT, but does the
translation ant the transport layer, not the IP layer.
There should be a dedicated box for a site to relay
a TCP/IPv6 connection and a TCP/IPv4 connection.
Also, there should be a DNS server which
can map IPv4 addresses to IPv6 addresses. No modification is
necessary for IPv6 hosts and IPv4 hosts. For scalability,
multiple dedicated boxes can be installed for a site with
multiple dummy IPv6 prefixes. UDP traffic can be relayed by
the same technique as that of TCP.
Applicability scope: site
IPv4 requirements: none
IPv4 address requirements: 1 per site
IPv6 requirements: none
IPv6 address requirements: One dummy prefix out of the site address
Host requirements: none
Router requirements: none, but an intermediate device must be
a transport relay translator
NAT impact: ???
Other requirements: DNS servers which can map IPv4 addresses
to IPv6 addresses
4.2.8 DSTM
Dual Stack Transition Mechanism [DSTM] is a mechanism that
allows a dual stack node which IPv4 stack is enable but not
yet configured to temporarily acquire an IPv4 address to
communicate with IPv4 only applications.
The main idea is that when an IPv4/IPv6 host needs an IPv4
address, it requests one for the duration of the
communication to a DSTM server. The communication with
the DSTM server is made on top of IPv6.
In the absence of IPv4 internal routing infrastructure,
the dual stack host will encapsulate IPv4 packets in IPv6 packets
to a tunnel endpoint that will decapsulate them and inject them
in the IPv4 infrastructure. This encapsulation is done by a DTI
virtual interface.
Communication initiated from an IPv4 node to a DSTM node
which IPv4 stack is not yet configured is not supported
at the moment but will be defined in future work.
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
NAT impact: ???
Other requirements: IPv4 routing infrastructure or
tunnel end-points to decapsulate
IPv4 in IPv6 packets.
5. Case Studies
This section will describe some possible transitions scenarios
for some typical cases. Neither the list of cases nor the lists
of solutions are exhaustive.
5.1 Large organization with a lot of global IPv4 addresses
The scenario this is intended to address envisions a site
with a substantial number of globally addressable
IPv4 addresses, certainly enough to meet their immediate needs.
We can imagine this to be a fairly large installation,
perhaps using a /16 IPv4 addresses and one that has
a fairly well developed infrastructure.
5.1.1 Motivations
Such a site may be motivated to begin the integration
of IPv6 into their network for a number of reasons:
- They wish to remain at the forefront of technology.
- They wish to maintain and where possible restore end-to-end
connectivity. They see Nat's in their future and wish
to prevent this from happening.
- They believe there will be IPv6 only devices appearing
at their installation and wish to be prepared for this
technology shift.
- Even though they have sufficient address space
to meet their data needs for the immediate future,
they do not have enough to transition their
telephone system to IP.
- They have made a strategic decision to implement IPsec
and believe IPv6 is the best platform.
5.1.2 Prerequisites
There are considerations that need to be met for this to be a workable
installation. Any attempt to integrate IPv6 cannot disrupt their current
network. All of the IPv4 connectivity and functionality must continue
to operate. This would include for instance not putting code into key
routers that would cause them to fail. Installing IPv6 must not impact
performance of anyone but those selected to test the IPv6 infrastructure.
It is all right that their v6 performance does not match their v4
performance, for the moment.
5.1.3 Network infrastructure
Given that they are so motivated and have those conditions how might this
integration begin to take place? The most likely situation is that
there will be a small section of their network that will be made IPv6
capable. Various tools and configurations can be tested in this area
and as they prove stable and useful they will be extended until
they cover the entire infrastructure. It is likely that this will
happen from the core of the network out, at least where installation
is driven by the existing networking staff.
Let us suppose that the network is made of a core set of routers
that are redundantly interconnected. This may be an ATM core,
it may utilize a gigabit or 100 megabit switched core,
and it may have some POS or be some combination of all of these.
In general each router will serve multiple wiring closets where
the layer 2-switched infrastructure resides. Again for redundancy
these switches are often connected to multiple routers.
Within this structure the decision to incorporate IPv6 might
well proceed in the following manner. The first step would be
to obtain and address range from some provider. This might be
the 6bone or it might be from the sites network provider.
Increasingly there are options for the allocation of addresses,
in any case asking providers for such space is a good idea as
it will tend to motivate them to obtain the space to make
available to customers.
Most likely the site will be allocated a /48 range,
e.g. 3FFE:3700:0101::/48. This is an example of a 6bone
allocation. This would give that manager the equivalent
of the IPv4 /16 they are already in possession of.
With the difference of course that each subnet now
has 64 bits of host space available.
Having obtained the network number (and note that they
may even get more then one prefix if they have multiple
connectors) the next step would be to determine which
of the core or edge router nodes will be upgraded to
a dual stack IP implementation that supports both IPv4
and IPv6. Often the router selected will not be a
critically important router, perhaps one somewhat on
the periphery of the network. This is because the code
that supports IPv6 may not be believed to be as stable
as the mainstream code used in critical routers.
However we may reasonably assume that the code is stable
enough that a router running that load and configured
to support IPv6 is stable enough to be attached to the
core of the network.
We would now have a situation that looks something like this:
____________
/ \
/ \
/ IPv4 routed \
\ core /
\ /
\ /
------------
||
||
||
||
||Int1
||
-------- Int0 -------------
| Router |____________| IPv6switch |
| R4/6 | -------------
-------- | | | | | | |
| | | | | | |
Hosts
The configuration in the router called R4/6 would allow
both IPv4 and IPv6 traffic to pass to hosts attached
to IPv4 and IPv6 enabled interfaces. For instance on
the interface labeled Int0 (assumed to be Ethernet)
the following statements
would both be in the interface configuration:
ip address xxxx.xxxx.xxxx.xxxx/16
ip address 3ffe:3700:101::0/64 eui-64.
These jointly provide IPv4 and IPv6 connectivity.
The IPv6 address instructs the router to determine
its host address based on its mac address. This would
not be necessary; the actual host address could be manually
configured as well. Router R4/6 might also be configured
to do prefix-advertisement out of that Ethernet interface.
While this leaves out some detail of the router configuration,
details will of course be platform dependant; fundamentally
that Ethernet is now IPv6 capable.
Assuming that there is a backbone network to connect to,
the interface labeled Int1 might also be configured with
both IPv4 and IPv6 addresses. If this is an ATM network,
with an ATM connected provider a point-to-point PVC could
be configured that allowed native IPv6 connectivity to that
router from the provider. Any other layer 2 technologies
can also bring native IPv6 service to R4/6.
If a native IPv6 connection can not be set up, a tunnel
could be constructed out of that router using the Int1
interface at the local tunnel end point.
Once the router is configured to forward IPv6 traffic
routing must also be configured. This can be as simple
as a static default route pointing to the IPv6 provider.
External routing can also be done using BGP4+.
There is nothing particularly different about configuring
an IPv4 BGP session and an IPv6 BGP session, aside of course
from understanding how the addresses have been allocated.
Should there be more then one internal IPv6 router an IGP
will also have to be configured. Again this is not different
from setting up an IPv4 IGP. Which IGP is chosen will be
determined by the implementations available in the router,
the preferences of the network administrator and the
complexity of the topology.
Having done this much one final step remains before hosts
are introduced to this network. As should be obvious,
dealing with IPv6 addresses is difficult. It is much
better to construct names. The next step should be to
obtain and operate a DNS server that is capable of
handling both A records and AAAA records.
There are a couple of ways DNS can be handled within
the network. One approach is to create an IPv6 specific
sub-domain, for instance v6test.xxx.yyy, point the primary
name server at the site toward one specifically for this
domain and populate it with AAAA records.
The DNS administrator should work with the provider to get
the reverse delegations done. It would also be possible
to have hosts within the domain xxx.yyy and have both A
and AAAA records populating the existing nameserver.
This does now make the community aware of the IPv6
availability of systems.
At this point then there is an operational IPv6 network
at this site. Anyone connecting to the switch labeled
ipv6switch can send and receive IPv6 traffic as well as
IPv4 traffic. Other links in the site network can be
also upgraded to support IPv6. At this stage, some
IPv6 internal routing must be in place.
This scenario will now introduce a step by step approach
To introduce hosts and services in this network.
5.1.4 Dual stack servers
The first step is to upgrade some enterprise servers to support
a dual stack, IPv4 and IPv6.
The dual stack servers will still serve the existing IPv4 clients.
Note: It may be a good practice not to use stateless auto-configuration
on the servers when the applications they run store IP addresses
in configuration files. If the IPv6 addresses are
derived from the MAC address of the NIC card and this one is
changed, the IPv6 addresses of the server will change and the
application may very well be confused if the configuration files are
not updated as well.
5.1.5 dual stack clients
The second step is to get a dual stack IPv4/IPv6 on some clients which are
on the IPv6 ready link.
Stateless auto-configuration is very convenient for those clients to lower
the administration burden.
At this stage, the enterprise DNS should be populated with IPv6 addresses.
5.1.6 IPv6 aware applications
Now that some clients and some servers can communicate with IPv6,
it is time to obtain, setup and configure IPv6 aware applications.
In the dual stack model, these same application serve IPv4 and IPv6,
so there is no need to run two distinct applications,
one for IPv4 and one for IPv6.
Where IPv6 aware versions are not available, a last resource solution
will be to run the IPv4 versions with a wrapper implementing
the Bump in the API technique. This solution is far from perfect,
but allows early deployment to happen.
5.1.7 Connection to the IPv6 Internet
The organization may now think about a connection to the IPv6 Internet.
If its ISP can not deliver a IPv6 native link, a configured tunnel
to an IPv6 network or a 6to4 tunnel are possible alternatives.
That tunnel will originate from a dual stack router at the border of
the organization site.
Punching holes in the organization firewall may be necessary to dig the tunnel.
However, in such a case, setting up an IPv6 firewall may be mandated
by the organization security policy.
5.1.8 IPv6 only hosts
When all IPv6 service and all critical IPv6 applications
are available, one can think about deploying IPv6 only nodes
and IPv6 only links.
At this stage, those nodes will communicate only with other IPv6 hosts,
IPv6 only or dual stacks.
Getting a 'pure' IPv6 only node may in practice not be possible. Removing
the IPv4 part of a dual stack may not be possible. However, one can use
a dual stack node and only configure the loopback address 127.0.0.1
on the IPv4 stack. That way, this node will not consume any global
IPv4 addresses, and will behave very much like an IPv6 only node.
5.1.9 IPv6 only node and IPv4 only server
Those IPv6 only nodes will eventually need to talk to IPv4 only servers,
within the organization or on the Internet. To achieve this,
several techniques can be used:
- deploying proxies per critical applications
- deploying SIIT, NAT-PT or TCP-Relays
- deploying DSTM
The choice the right mechanism to deploy will depend from organization
to organization.
5.2 Large organization with few global IPv4 addresses (a /24 or less)
==> Note: this section needs to be extended.
This case is very similar to 5.1 except that,
global IPv4 address are a scarce resource.
Most of the time, private IPv4 addresses are used internally
behind a NAT box.
A big incentive to move to IPv6 is to re-establish
end to end IP connectivity with other IPv6 hosts on the Internet.
5.3 The extranet case
NAT techniques make it easy for a client using an internal address
to initiate a connection to a server using an external address,
however, the opposite, that is a client using an external address
trying to connect to a server using an internal address,
is a very difficult case. This makes communication between hosts
that are behind two different NAT domains even more difficult.
An organization that has a fairly large number of
branch offices which are, each of them, using the same IPv4 private
address space and NAT techniques, will face a very difficult problem
to connect them over the public Internet.
It even get worse when data have to be exchanged with all the
organization suppliers and customers if those ones are also
using IPv4 private addresses and NAT techniques.
Re-establishing end to end IP connectivity for some applications
could become an important goal.
One way to achieve this is to deploy IPv6 in each sites as
describe in 5.2. The 6to4 mechanism will manage automatically all the
necessary tunnels between the various sites, provided that each of them
has, at least, one global IPv4 address.
5.4 Office or home network with ONE global IPv4 address
This is an extreme case of 5.2 and similar techniques apply.
Typically this type of environment consists of one network
segment with a small number of hosts using IPv4 private
addresses. The one global IPv4 address is assigned to a NAT box
that connects the network to an ISP. Most organizations of this
size do not use routers internally although some may have a few
internal network segments connected by a router.
5.4.1 Step 1: Upgrade the NAT box and connect to the IPv6 Internet
The first step is to upgrade or replace the NAT box with a device
supporting a dual stack, 6to4, and NAT-PT. In the way the NAT
device becomes an IPv6 router while still performing the NAT
function for IPv4. There are several possible methods of
connecting to the IPv6 Internet without affecting the existing
IPv4 service:
- a native IPv6 connection if the ISP supports both IPv4 and
native IPv6 connections
- a 6to4 connection
- a configured tunnel to an IPv6 provider
- a connection to an IPv6 tunnel broker
A 6to4 connection is recommended since it is likely to be some
time before most ISPs will offer native IPv6 services. A
configured tunnel requires more administrative effort both
locally and at the IPv6 provider's end. Tunnel broker
connections are better suited to individual hosts or to small
sites with infrequent connectivity requirements.
At this point the organization will have a global IPv6 prefix and
the NAT box acting as an IPv6 router will advertise this prefix
to the internal systems. This 6to4 global prefix is derived from
the single global IPv4 address.
If the IPv4 address is a DHCP-assigned or other transient
address, then the resulting 6to4 prefix will also be transient.
In this case, the IPv6 router should also be configured to
advertise a site-local prefix. The site-local addresses for
internal hosts can then be used in an internal DNS or similar
naming service. Using site-local addresses will promote easier
communication among internal hosts since these internal addresses
will not change when the global prefix changes.
5.4.2 Step 2: Dual stack clients and servers
Clients and servers should be upgraded to support a dual stack
once an IPv6 infrastructure exists. Dual stack support will
allow the use of IPv6 to begin while still supporting existing
IPv4 services.
5.4.3 Step 3: IPv6 aware applications
Once IPv6 is supported by the organization, IPv6 aware
applications can be developed and installed. Using the dual
stack model, one application can support both IPv4 and IPv6
connections.
5.4.4 Step 4: IPv6 only hosts
IPv6 only hosts can be deployed after the important applications
have become IPv6 aware. The private IPv4 addresses can be removed
from the dual stack systems so that IPv6 is used for all
communications. The IPv4 NAT box upgraded in step 1 also includes
NAT-PT to allow communication between IPv6 only internal hosts and
the IPv4 Internet.
5.5 New network with brand new services
[to be completely rewritten or deleted ???]
5.6 Introducing IPv6 in an ISP environment
The network of an ISP consists of at least three main areas: the
core network, the connections to other IPSs and the customer access
network. The next two sections will discuss how an ISP can introduce
IPv6 in those areas.
For each area a couple of steps must be taken first:
- Request IPv6 address space
- Register the IPv6 site, routing and delegations
- Setup DNS
5.6.1 Introducing IPv6 in the core network
It is not really necessary to introduce IPv6 into the core of the
network. An ISP may decide to tunnel IPv6 over its existing IPv4
infrastructure. But if the ISP decides to introduce IPv6 into the
core, this can be done in several ways.
An ISP might decide to install separate dual stack or IPv6-only
routers in the core. These will be interconnected by dedicated
lines (ATM PVCs, leased lines, etc.) or (if the routers are dual
stack) by IPv6 in IPv4 tunnels over the existing IPv4 core
infrastructure. Tunnels may be necessary to established
if some of the intermediary routers can not be upgraded to
IPv6 or if dedicated lines are either not possible to install or
simply not cost effectives.
Routing can be setup such that IPv4 packets are
routed through the old IPv4 infrastructure and IPv6 packets are
routed through the new IPv6 infrastructure.
When dual stack routers are stable enough to be used in the core,
things become simpler. The ISP can configure the core routers as
dual stack routers which will route both IPv4 and IPv6 packets.
Next a connection to the global IPv6 network should be made. This
can be done by a direct IPv6 connection or by some tunneling
mechanism. If the core of the network supports IPv6 and the other
ISP also supports IPv6 a direct link can be used to transport IPv6
packets.
When there is no direct IPv6 connection tunneling mechanisms must be
used to reach the global IPv6 network.
An ISP might decide to setup one or more routers at the edge of its
network to act as 6to4 gateways. This enables other IPv6 islands to
reach the ISP by 6to4 tunneling. An alternative to the use of
dynamic tunnels is the use of static ones as is the case of the
6Bone.
5.6.2 Introducing IPv6 in the customer access network
The customer access network consists of dial up and leased lines
connected to an access router. There are at least two possibilities
to introduce IPv6. The first possibility is to upgrade access
routers to dual stack routers. Both IPv4 and IPv6 customers connect
to these dual stack routers.
Another possibility is, as in the core network, to install separate
IPv6 or dual stack routers. IPv4-only customers connect to
the old IPv4-only access routers. IPv6 customers connect to
the new access routers.
These IPv6 access routers must be connected to the global IPv6
network. If the core does not support IPv6, one of the transition
mechanisms from section 3 must be used. Dynamic tunneling can be
done with for example [6TO4]. An alternative to the use of dynamic
tunnels is the use of statically configured ones. When the core
network does support IPv6 the access routers can be connected to the
nearest IPv6 core router (either by IPv4/IPv6 link, dedicated link
or tunneling over IPv4).
When the customer is an IPv6-only site, the ISP might decide to
provide some transition mechanisms to help the customer reach
IPv4-only nodes.
5.7 Internet Exchange
Based on address space distribution we can distinguish two models
for the setup of an IPv6 Internet eXchange (IX).
1. The traditional model commonly used in the IPv4 world.
In this case each ISP connecting to the IX arranges
its own IPv6 address space. In peering arrangements between ISPs
the prefix for this address space is exchanged.
2. An addressing model where the IX acts as an address space
provider. In this case the IX obtains a TLA and can assign NLAs
from this TLA address space to connected ISPs. In order to
obtain global connectivity for the Internet Exchange TLA, the IX
needs to arrange for global transit through one or more global
transit providers (TLA ISPs) which are connected to the IX.
Implicitly, this means that the IX arranges transit for all
connected ISPs that use the address space assigned to the IX.
This requires quite a different business model for an IX than in
model 1.
5.7.1 The traditional IX model
5.7.1.1 Address space:
The IX obtains some globally unique address space.
This can be an NLA from a transit provider (TLA provider)
that offers connectivity for the IX infrastructure.
A global prefix is preferred as next hop attribute in BGP4 [BGP4-IPV6].
5.7.1.2 Addressing infrastructure on IX:
Addresses are assigned from the obtained address space to the
interfaces of the routers connecting to the IX infrastructure.
5.7.1.3 Updating the IPv6 registries:
The sites, allocations and route objects should be registered as
described in appendix A2.
5.7.1.4 BGP announcements:
ISPs connecting to the IX advertise to their peers their own
address space which is independent of the IX. This address space
can either be a TLA or an NLA.
5.7.2 The addressing IX model
5.7.2.1 Address space:
The IX requests a (sub-)TLA from its regional IR. Customers on
the Internet Exchange get a next level NLA from this (sub-)TLA.
5.7.2.2 Addressing infrastructure on IX:
Addresses are assigned from the obtained address space to the
interfaces of the routers connecting to the IX infrastructure.
5.7.2.3 Updating the IPv6 registries:
The sites, allocations and route objects should be registered as
described in section 2.
5.7.2.4 Contracts with global transit ISPs (TLA ISPs)
The IX should contract several TLA ISPs that will provide
connectivity to the global IPv6 network. Such a TLA ISP must
agree to transit traffic from all customers connected to the IX.
5.7.2.5 BGP announcements:
The transit providers for the IX address space announce the
(sub-)TLA from the IX to the global IPv6 network. To the IX
customers they announce all prefixes that can be reached by them
and for which they have a contract with the IX. Customers (NLA
ISPs) get a next level NLA from the IX. The NLA ISPs announce
their NLA to the TLA ISPs. They also announce their NLA to other
NLA ISPs of the IX if there is a peering agreement between them.
6. Security considerations
There are no specific security issues introduced by this document.
For the specific security issues with the different translations
and migration tools that are discussed in section 4 of this document
the reader is referred to the referenced documents.
7. References
[6BONE] http://www.6bone.net/
[6TO4] B. Carpenter, K Moore, "Connection of IPv6 Domains via
IPv4 Clouds without Explicit Tunnels",
draft-ietf-ngtrans-6to4-07.txt (work in progress).
[6PAPA] R. Fink,
"6BONE Pre-Qualification for Address Prefix Allocation (6PAPA)",
draft-ietf-ngtrans-6bone-6papa-01.txt (work in progress)
[BROKER] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6
Tunnel Broker", draft-ietf-ngtrans-broker-06.txt
(work in progress).
[DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration
Protocol for IPv6", draft-ietf-dhc-dhcpv6-14.txt
(work in progress).
[DHCPv6-EXT] C. Perkins, J. Bound, "Extensions for the Dynamic Host
Configuration Protocol for IPv6",
draft-ietf-dhc-v6exts-11.txt (work in progress).
[DNAME] Matt Crawford, "Non-Terminal DNS Name Redirection",
draft-ietf-dnsind-dname-03.txt (work in progress).
[DNSLOOKUP] M. Crawford, C. Huitema, S. Thomson, "DNS Extensions to
Support IP Version 6",
draft-ietf-ipngwg-dns-lookups-05.txt (work in progress).
[DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition
Mechanism (DSTM)", draft-ietf-ngtrans-dstm-03.txt
(work in progress).
[IRALLOC] Regional IRs, "Provisional IPv6 assignment and allocation
policy document (Draft 6; 27 May 1999)",
ipv6policy-draft-090699.txt (work in progress).
[RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
RFC 1034, November 1987.
[RFC1035] P. Mockapetris, "Domain names - implementation and
specification", RFC 1035, November 1987.
[RFC1886] S. Thomson and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot
and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996.
[RFC1928] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC2080] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2081] G. Malkin, "RIPng Protocol Applicability Statement",
RFC 2081, January 1997.
[RFC2185] R. Callon, D. Haskin, "Routing Aspects of IPv6
Transition", RFC 2185, September 1997.
[RFC2283] T. Bates, R. Chandra, D.Katz, Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283, February 1998.
[RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2374] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format", RFC 2374, July 1998.
[RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC2529, March 1999.
[RFC2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC2545,
March 1999.
[RFC2546] A. Durand, B. Buclin, "6Bone Routing Practice",
RFC 2546, March 1999.
[RFC2673] Matt Crawford, "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2740] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC2765] E. Nordmark, "Stateless IP/ICMP Translator",
RFC 2765, xxxx
[RFC2766] G. Tsirtsis, P. Srisuresh,
"Network Address Translation - Protocol Translation (NAT-PT)",
RFC 2766, February 2000.
[RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
using the Bump-in-the-Stack technique",
RFC 2767, February 2000.
[RFC2772] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines"
RFC 2772, February 2000.
[RFC2893] R. Gilligan and E. Nordmark,
"Transition Mechanisms for IPv6 Hosts and Routers",
RFC 2893, August 2000
[SOCKS-EXT] H. Kitamura, "SOCKSv5 Protocol Extensions for IPv6/IPv4
Communication Environment",
draft-kitamura-socks-ipv6-01.txt (work in progress).
[SOCKS-GATE] H. Kitamura, A. Jinzaki, S. Kobayashi, "A SOCKS-based
IPv6/IPv4 Gateway Mechanism",
draft-ietf-ngtrans-socks-gateway-05.txt
(work in progress).
[TRT] J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport
relay translator",
draft-ietf-ngtrans-tcpudp-relay-01.txt,
(work in progress).
8. 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
Ronald van der Pol Henk Steenman
SURFnet bv AT&T, ICoE
P.O. Box 19035 Laarderhoogtweg 25
3501 DA Utrecht 1101 EB Amsterdam
The Netherlands The Netherlands
Phone: +31 30 230 5305 Phone: +31 20 409 7656
Fax: +31 30 230 5329 Fax: +31 20 453 1574
Email: Ronald.vanderPol@surfnet.nl Email: Henk.Steenman@icoe.att.com
Tim Larder
Cisco Systems Ltd.
3, The Square,
Stockley Park,
Uxbridge,
UB11 1BN,
United Kingdom.
Phone +44 (0)20 8756 8846
email tlarder@cisco.com
Alain Durand
SUN Microsystems, Inc.
901 San Antonio road
UMPK17-202
Palo Alto, CA 94303-4900
USA
Phone: +1 650 786 7503
Email: Alain.Durand@sun.com
Kazu Yamamoto
IIJ
Dale Finkerson
29 WSEC
University of Nebraska
Lincoln, Ne. 68588
Phone: +1 402 472 0450
Email: dmf@unl.edu
Andy Hazeltine
Advanced Systems Consulting, Inc.
4A Eves Drive, Suite 114
Marlton, NJ 08053
Phone: (856) 983-3888
Email: andy@advsys.com
Appendix A. IPv6 Address Issues
The IPv6 Global Unicast Address format is described in [RFC2374].
It defines entities such as TLA (Top Level Aggregator), NLA
(Next Level Aggregator) and SLA (Site Level Aggregator).
This address format splits the 128 bit IPv6 addresses into
three level of hierarchy, the public topology, the site private
topology, and the interface identifier.
The public topology is described in the 48 first bits of an
IPv6 address. Those 48 bits are made of:
- 3 bits prefix to identify the IPv6 Global Unicast Address format
- 13 bits TLA ID
- 8 bits reserved
- 24 bits NLA ID
The site private topology is a 16 bit field.
The interface identifier is a 64 bit field.
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
<--Public Topology---> Site
<-------->
Topology
<------Interface Identifier----->
A.1 IPv6 Address Allocation
IPv6 address space is very large. Much, much larger than the
IPv4 address space. So the objective of IPv6 address allocation
is more focused on route aggregation that address conservation.
However, even though IPv6 address space is very large, it is an
important resource that must be carefully managed for the good
of the whole Internet. IPv6 address allocation follows
strict rules that are discussed by the regional registries
(RIPE-NCC, ARIN, APNIC) with guidance from the IETF.
A.1.1 Site local vs global addresses
Without special registration a site can deploy IPv6 site local
addresses which are similar to IPv4 private addresses [RFC1918].
However, site local addresses do not allow for communication over
the Internet. For this, sites need to apply for globally routable
IPv6 addresses. Most sites will get a /48 prefix with 16 bits
for subnetting and 64 bits for interface ID addressing. This
means that each site will have 65536 subnets to define its
internal topology and in each subnet almost 20 trillion hosts
can be numbered.
0 48 64 127
+---------------------------------+--------+--------------------+
| prefix | subnet | Interface ID |
+---------------------------------+--------+--------------------+
A.1.2 Obtaining IPv6 Address Space
IPv6 addresses can be obtained from the same organizations as the
ones who register IPv4 addresses. Regional IRs delegate
a part of the IPv6 address space to local IRs who further delegate
parts of the address space to their ISP customers. Site will
obtain IPv6 addresses directly from their ISP.
The regional IRs use a slow start mechanism [IRALLOC] to
allocate address space (TLA) to ISPs. A special
pre-qualification procedure [6PAPA] can be used by ISP
participating in the 6bone.
A.2 IPv6 Registration Issues
In the current IPv4 world address space allocations are registered
in the various databases managed by the regional IRs. Autonomous
System (AS) information and routing policies are registered in the
distributed Internet Routing Registry database (IRR). The IRs, LIRs
and ISPs are supposed to register address space allocations and
assignments, contact persons, AS numbers, routing policies and other
useful data for network management in the various databases.
A special IPv6 registration database has been setup for the 6bone
community, on the whois server named "whois.6bone.net". This is a
special version of the RIPE database software and it is referred to
as the "6bone database". This database has special objects, the
"inet6num:" object for assigned IPv6 prefixes, and the "ipv6-site:"
object which is used to register specific information about a site
connected to the 6bone, such as the configured tunnels and the
origin AS. In the ipv6-site objects the IPV6 applications that are
supported on that specific site can be found. The database can be
queried by using a modified whois client or the web-based "whois"
service at http://www.6bone.net/whois.html. At this time only the
6bone database supports the special IPv6 objects. Currently, there
are no database objects to register IPv6 routing policies.
A.3 Example of IPv6 address allocation within a site /48 prefix
In this example a site is allocated prefix 3FFE:1234:5678::/48.
3FFE:1234:5678::/48
|
|
I1 +-----+-----+ I2
+-------+ R1 +-------------------+
| +---------+-+ |
| | I3 |
+-------+-------+ +----+ +-----+----+
| | | | R2 |
| | | +----------+
+----+----+ +----+----+ +----+----+ ||||||||||
| R3 | | R4 | | R5 | links
+---------+ +---------+ +---------+
| | | | | | | | | |
links links links
R[1-5] are routers and I[1-3] are the interfaces of R1. Suppose the
expected number of hosts on the links is:
router immediate year 1 year 2
R2 34 50 70
R3 19 20 25
R4 9 10 15
R5 3 5 10
A number plan could be like the one shown in the table below. On R1
the following prefixes will be used on the interfaces:
I1 3FFE:1234:5678:2000::/50
I2 3FFE:1234:5678:0000::/49
I3 3FFE:1234:5678:2300::/50
Initially, R2 will get 256 /64s, R3 will get 48 /64s, R4 will get 32
/64s and R5 will get 16 /64s.
3FFE:1234:5678:0000::/50
------------------------
3FFE:1234:5678:0000::/49 I2
3FFE:1234:5678:1000::/49 free
3FFE:1234:5678:2000::/49 I1 + I3
3FFE:1234:5678:3000::/49 free
..... ...
3FFE:1234:5678:F000::/49 free
3FFE:1234:5678:0000::/49
------------------------
3FFE:1234:5678:0000::/64 interfaces of R2
..... ...
3FFE:1234:5678:00FF::/64 interfaces of R2
3FFE:1234:5678:0100::/64 reserved for R2
..... ...
3FFE:1234:5678:02FF::/64 reserved for R2
3FFE:1234:5678:0300::/64 free
..... ...
3FFE:1234:5678:2000::/49
------------------------
3FFE:1234:5678:2000::/50 I1
3FFE:1234:5678:2100::/50 reserved for I1
3FFE:1234:5678:2200::/50 reserved for I1
3FFE:1234:5678:2300::/50 I3
3FFE:1234:5678:2400::/50 reserved for I3
3FFE:1234:5678:2500::/50 reserved for I3
3FFE:1234:5678:2600::/50 free
..... ...
3FFE:1234:5678:2F00::/50 free
3FFE:1234:5678:2000::/50
------------------------
3FFE:1234:5678:2000::/64 interfaces of R3
..... ...
3FFE:1234:5678:202F::/64 interfaces of R3
3FFE:1234:5678:2030::/64 reserved for R3
..... ...
3FFE:1234:5678:204F::/64 reserved for R3
3FFE:1234:5678:2050::/64 interfaces of R4
..... ...
3FFE:1234:5678:206F::/64 interfaces of R4
3FFE:1234:5678:2070::/64 reserved for R4
..... ...
3FFE:1234:5678:209F::/64 reserved for R4
3FFE:1234:5678:20A0::/64 free
..... ...
3FFE:1234:5678:20FF::/64 free
3FFE:1234:5678:2300::/50
------------------------
3FFE:1234:5678:2300::/64 interfaces of R5
..... ...
3FFE:1234:5678:230F::/64 interfaces of R5
3FFE:1234:5678:2310::/64 reserved for R5
..... ...
3FFE:1234:5678:231F::/64 reserved for R5
3FFE:1234:5678:2320::/64 free
..... ...
3FFE:1234:5678:23FF::/64 free
Appendix B. IPv6 and DNS
B.1 Forward mapping
A host's 128 bit IPv6 address can be stored with an AAAA record.
For example:
$ORIGIN ipv6.surfnet.nl.
...
zesbot IN AAAA 3FFE:0604:0000:0001:02C0:4FFF:FEC6:9CC7
This is similar to the use of the A record in IPv4, for example:
$ORIGIN ipv6.surfnet.nl.
...
zesbot IN A 192.87.110.60
Note that both A and AAAA records for a given zone are stored in
the same DNS data file.
If a node has more than one IPv6 address it must have more than one
AAAA record. For example:
$ORIGIN ipv6.surfnet.nl.
...
amsterdam9 IN AAAA 3FFE:0600:8000:0000::0001
IN AAAA 3FFE:0600:8000:0000::0005
IN AAAA 3FFE:0600:8000:0000::0009
IN AAAA 3FFE:0600:8000:0000::000D
A new record type, A6, is being defined to map a domain
name to an IPv6 address, containing a reference to a "prefix"
[DNSLOOKUP]. The aim of the A6 record is to facilitate network
renumbering and multihoming. Domains employing the A6 record for
IPv6 addresses can have automatically generated AAAA records to ease
transition. After the A6 records are widely deployed it is expected
that the AAAA records are no longer needed.
B.2 Reverse mapping
IPv4 uses the "in-addr.arpa" domain for the reverse mapping. An
IPv4 address is represented as a name in the in-addr.arpa domain by
a sequence of bytes, written as decimal digits, separated by dots
with the suffix ".in-addr.arpa". The sequence of bytes is encoded in
reverse order, i.e. the low-order bytes is encoded first, followed
by the next low-order bytes and so on. For example the IPv4 address
192.87.110.60 is represented as a name in the in-addr.arpa domain as:
60.110.87.192.in-addr.arpa.
This name is stored in a DNS data file as follows:
$ORIGIN 110.87.192.in-addr.arpa.
...
60 IN PTR zesbot.ipv6.surfnet.nl.
For IPv6 addresses the special domain "ip6.int" is defined to look
up a record given an IPv6 address. The process works exactly the
same as with IPv4. Except that an IPv6 address is represented by
nibbles, written as hexadecimal digits, separated by dots. For
example the IPv6 address 3FFE:0604:0000:0001:02C0:4FFF:FEC6:9CC7
is represented as a name in the ip6.int domain as:
7.c.c.9.6.c.e.f.f.f.f.4.0.c.2.0.1.0.0.0.0.0.0.0.4.0.6.0.e.f.f.3.ip6.int.
This name is stored in the a DNS data file as follows (assuming
a /64 prefix):
$ORIGIN 1.0.0.0.0.0.0.0.4.0.6.0.e.f.f.3.ip6.int.
...
7.c.c.9.6.c.e.f.f.f.f.4.0.c.2.0 IN PTR zesbot.ipv6.surfnet.nl.
Note that the IPv4 and IPv6 reverse mappings are stored in different
DNS data files.
B.3 Implementations
Most DNS implementations will be able to deal with the reverse
mapping as used with IPv6 addresses. AAAA record is implemented
in recent DNS implementations and support for A6 record [DNSLOOKUP]
or binary labels [RFC2673] is implemented in the most recent ones.
Note that although these DNS servers implement extensions to support
the use of IPv6 addresses they are not necessarily IPv6 applications
themselves, some use IPv4 transport.
For IPv6 only nodes, an IPv6 resolver and an IPv6 DNS server
are crucial.
Appendix C. IPv6 routing issues
To exchange reachability information routing protocols are used.
There are two types of routing protocols, the intra-domain (IGP) and
inter-domain (EGP) routing protocols. In the IPv4 world commonly
used IGPs are RIP, OSPF and IS-IS and the EGP that is used is
mostly BGP4. Besides the use of routing protocols, static routing can
also be used.
Routing protocols have been adapted to handle IPv6 routing
information. RIP (RIPng) [RFC2080, RFC2081], BGP4 (BGP4+)
[RFC2283, BGP4-IPV6] and OSPF [RFC2740] have IPv6 extensions
defined.
On the core of the 6bone, BGP4+ is mandated. More information
about 6bone routing guidelines can be found in [RFC2772].
| PAFTECH AB 2003-2026 | 2026-04-23 22:47:26 |