IPv6 report 2000
1 Introduction
This is one of the work items from UNINETT's IPv6 project for the year
2000. The goal is to get some ideas about how and when IPv6 should be
deployed in UNINETT's network. The report discusses both IPv6 in general
terms, and how it applies to UNINETT. The general part should be of
interest to anyone, but we also think that the UNINETT specific part might
be of interest to people outside UNINETT.
We start by discussing the general need for IPv6, considering the
end-to-end principle, NATs and lack of addresses. Next we look at
transition techniques and discuss how to introduce IPv6 in existing
IPv4 networks. Then we discuss how this applies to UNINETT, and
finally a quick summary of the status of IPv6 by the end of year 2000.
2 Terminology
- link
- A communication facility or medium over which hosts communicate at
the link layer. This might be for instance Ethernet, but can also
be IPv4 when using IPv4 tunnels
- IPv4-only
- IPv4 but not IPv6. An IPv4-only host is a host
with IPv4 stack, but no IPv6 stack. An IPv4-only network is a network
that can transport IPv4 packets, but not IPv6 packets
- IPv6-only
- IPv6 but not IPv4
3 Why IPv6?
The basic principles for the design of the Internet
are transparency, that packets may flow from source to destination essentially
unaltered, and a single universal logical addressing scheme so that the
source and destination addresses can serve as unique identifiers for the
end systems. This is reflected in the design of the internet protocols and
fits well with the end-to-end argument, see [TRANS].
This is also discussed in [ARCH], which states:
The network's job is to transmit datagrams as efficiently and flexibly as
possible. Everything else should be done at the fringes.
The main reason for IPv6 is that it is getting hard to give every
device that wishes to connect to the Internet a globally unique address.
We are simply running out of addresses due to the growing popularity
of the Internet. If the Internet is to follow the end-to-end principle
and remain transparent we need more addresses. The use of NATs
(Network Address Translation devices) on the Internet today, is
partly motivated by lack of addresses. NATs help since one doesn't need
one globally unique address per host, but as a consequence they break
transparency. Other reasons are to
avoid renumbering and ease multihoming. Renumbering is easier with IPv6
due to autoconfiguration [ARCH6], router renumbering [RRENUM], and new DNS
record types [DNSEXT], and is
still being worked on. Multihoming is currently a hot topic. The focus
is on how to multihome without getting too large routing tables, see
below.
For more details on NATs, see the discussion in 5.1 and [NAT].
As we will see later, there might be a need for NAT in the transition
phase when we have IPv4-only and IPv6-only hosts that wish to
communicate, but in the long run they will not be needed, and it will
be possible to again have the Internet follow the end-to-end principle.
Another problem is the way IPv4 addresses are allocated. When say a
company connects to the Internet, they typically get assigned some
block of IPv4 addresses that they keep forever. When they switch
providers they keep the addresses; this makes aggregation difficult.
There are now around 100 000 routes in the default-free zone (the
core Internet routers which have no default routes).
This number is rapidly growing and requires faster and faster routers
with more and more memory. See [BGPSIZE] for a graph showing the
growth of the routing tables.
There are advantages of IPv6 not related to these factors, but these
are the main reasons.
4 How long can we manage without IPv6?
There are many estimates for how long we can manage without IPv6.
By looking at the growth of hosts registered in the DNS,
Christian Huitema estimates in [HOWLONG] that we will use all available IPv4
addresses by 2009. It's nearly impossible to utilize all addresses
though, one measure of how many addresses one can expect to use is
the so called H-ratio [HRATIO]. He concludes that due to the H-ratio it
will be hard to use more than 200 million of the 3.7 billion addresses,
and that we will reach that
limit spring 2002 if the current trend continues. This means that it
will be very hard to get IPv4 addresses by then. The use of NAT technology
can help, but it breaks end-to-end, and has other disadvantages as
described in 5.1 and in [NAT].
There are other arguments for why we need more addresses. The early
users of the Internet, the US and Western Europe, owns most of the
IPv4 addresses. Internet is getting very popular in Japan and also
other countries that haven't got that many addresses. If over time
the popularity of Internet in Asia approaches what we have in the
US and Western Europe, huge amounts of addresses will be needed.
The number of mobile devices like phones and PDAs is increasing much
faster than the number of computers, and there are currently more
mobile phones than computers. People will want to access the Internet
from their mobile phones. If people are to be always on, and have
end-to-end Internet connectivity, they will need globally unique
addresses for their phones. Similarly one will need more addresses when
people are always on from home, using ADSL, cable modems, etc., and
wish to have full end-to-end connectivity.
An organization that has enough IPv4 addresses should consider IPv6
anyway, in order to communicate with external IPv6-only hosts without
the use of translation devices.
5. IPv6-only to IPv4-only communication
There will be a long transition phase, with significant amounts of both
IPv4-only and IPv6-only hosts on the Internet. It's hard to guess how
long, but a decade is probably the minimum. We want of course these hosts
to communicate with each other. This requires some intermediate
component translating between IPv4 and IPv6. If possible one should avoid
translators and use the same IP protocol at both ends, but there are cases
where this is not possible, and that is what we discuss here.
Common problems with translation devices are single point of failure and
scaling. One might be able to have multiple translation devices to avoid
single point of failure, but this is not always easy to achieve.
Translation devices have relatively low throughput, so they must be placed
near the edges of the network.
The translation can be done on three levels: IP, transport and application
level, see also [TRANS64]. For convenience we briefly discuss them
below.
5.1 IP level
This is done by rewriting headers, IPv6 headers are converted to IPv4
headers and vice versa. In its basic form, it doesn't need to care about
anything at transport or application level. This is much like ordinary NAT,
and also has all its disadvantages.
Many application level protocols will not work through a NAT without
specific support for each protocol which means that the packet payloads
are inspected, and it's not strictly IP level.
NATs also prevent some
types of end-to-end IP-level security, and will often require two-faced
DNS or similar tricks.
For more details on NATs, and both advantages and disadvantages, see [NAT].
There are also problems with fragmentation and handling the different
semantics of ICMP and ICMPv6.
5.2 Transport level
This is done by relaying sessions. When one host tries to set up a
session to another, the session will be terminated by the translation
device, and the device initiates a new session to the destination.
Thus there are two sessions, both terminated at the translation device.
This is not as commonly used as IP level translation, but it has been
used for instance between Chaosnet and TCP/IP. Some firewalls do TCP
and UDP relaying, and we can do the same even though the sessions we
relay are over different IP protocols.
When two hosts are to communicate using say TCP, there are two TCP
sessions, one using IPv4 and the other IPv6, both terminated at the
translation device.
UDP is problematic, but one may try to identify "sessions" by looking
at address/port pairs, just like NAT does.
Except for the ICMP and fragmentation problems, it has the same problems
as IP level translation.
5.3 Application level
The final alternative is application level gateways (ALGs), which must have
both IPv4 and IPv6 support. In this case there is no address mapping, so one
doesn't need any extra addresses, and there is no need for DNS tricks.
An example of an application level gateway is a web proxy. The client
specifies the web server by name, so there is no address mapping.
In addition to being a proxy, the
gateway may do caching, access control etc. One problem with this
alternative is often how to make the applications contact the gateway,
depending on both the protocol and the application. In some cases this
is easy though. Many firewalls are ALGs; thus one with both IPv4 and IPv6
support could do the job.
6. Dynamic IPv4 address allocation
An IPv6 host that is to communicate with an IPv4-only host, can avoid
translation problems provided it has an IPv4
address and IPv4 connectivity. If the host is only connected to
an IPv6-only network, it can still use IPv4, but IPv4 packets must be tunneled
to a dual-stack router on the border or outside of the IPv6-only network.
If there are not enough IPv4 addresses for all the
hosts, one possible solution is to allocate IPv4 addresses dynamically
when needed.
This can be done by using DSTM (Dual Stack Transition Mechanism) which is
a combination of two mechanisms, AIIH (Assignment of IPv4 Global Addresses
to IPv6 Hosts) and DTI (Dynamic Tunneling Interface). See [DSTM] for
details. The main idea is for the host to dynamically request an IPv4
address from a DHCPv6 server, see [DHCP], when it is about to contact an
IPv4 host. One would also like to dynamically assign an IPv4 address
to an IPv6 host when an IPv4 host is about to initiate a connection to it.
This is a much harder problem. One suggestion for solving this, is to have
DNS interact
with DHCPv6 so that an IPv4 address is handed out once someone tries to
look up an IPv4 address in DNS, see [DSTMEXT]. DHCPv6 may also provide other
information. If tunneling is used, one might obtain the address of the
tunnel end point from DHCPv6. A somewhat similar solution is RSIP,
Realm Specific IP [RSIP].
7. Tunneling
When IPv6 nodes want to communicate and part of the network between
them is IPv4-only, one can use tunnels, encapsulating IPv6 packets in
IPv4 packets. Conversely one can encapsulate IPv4 packets in IPv6 when
IPv4 nodes want to communicate across an IPv6-only network. For
encapsulating IPv6 into IPv4 there are several techniques. For details
on tunneling including configured and automatic tunnels described
below, see [TM].
7.1 Configured tunnels
These are perhaps the most straightforward tunnels, they are configured
manually typically by a network administrator and they are typically used
over a long period of time.
7.2 Automatic tunnels
This is typically used for hosts and will require an
IPv4 address for each host.
The IPv6 addresses for the hosts are IPv4-compatible
addresses derived from the hosts IPv4 addresses, see [TM] for details.
7.3 Tunnel broker
A tunnel broker is a way of setting up configured tunnels, but with
an easy to use interface (for instance web) where end users can get a
configured tunnel by simply supplying some information, the idea is that
the tunnel should be configured immediately with no human intervention.
Tunnel brokers are particularly useful when giving IPv6 access to end
users in IPv4-only environments. See [TB] for details on tunnel brokers.
7.4 6to4
6to4 allows for stateless automatic tunneling between IPv6 sites. A site
that wants to use 6to4 will need a 6to4 gateway that is reachable from
IPv4 hosts on the Internet, thus the site will need one globally reachable
IPv4 address. All the IPv6 hosts that are to be reachable through the 6to4
gateway will all share a 2002:IPv4address::/48 prefix where IPv4address
is an IPv4 address assigned to the 6to4 gateway. Communication
between 6to4 sites is very simple. When a host sends a packet with a
6to4 prefixed destination address, it should be forwarded according to the
sites internal routing to the sites 6to4 gateway. By looking at the prefix
the gateway will know the IPv4 address of the 6to4 gateway of the site
which the destination host belongs to. It then encapsulates the IPv6
packet within an IPv4 packet with this destination address. The gateway
at the destination site receives the packet, removes the IPv4 header, and
forwards the packet to the host.
We denote a site that only has IPv6 connectivity to other sites through
6to4, a 6to4-only site. A 6to4-only site will want to be able to reach
IPv6 hosts at other sites not using 6to4. Assume that the host to be
reached belongs to an IPv6 network spanning several sites. If there is a
6to4 gateway in that network willing to forward packets from anyone (or at
least from our 6to4-only site) to the entire network (or at least the
destination), we can tell our 6to4 gateway to forward all
packets to that network, to that other 6to4 gateway.
A site that is connected to a large IPv6 network will probably want to
reach hosts at 6to4-only sites. For this to work, the routers must be
configured to forward packets with 6to4 destination address to a 6to4
gateway. This gateway could be located at the site itself, or some other
place in the network. For details see [6TO4].
7.5 6over4
6over4 is also based on encapsulating IPv6 in IPv4. It uses IPv4
multicast with organizational local scope to create a virtual link.
The effect is that all 6over4 hosts in the same organizational local
multicast domain will be on the same link.
This is quite useful for a site with several IPv6
hosts spread out on different links, since one only needs
one router with IPv6 support at the site (depending on multicast
configuration). The router and the hosts must have 6over4 support though.
This is further described in [6OVER4]. A new technique called ISATAP,
see [ISATAP], has been suggested. In practice it solves much the same
problems as 6OVER4, but doesn't require IPv4 multicast.
8. What to use, when and how?
We will first look at what to do within a site, and then how to
interconnect sites.
8.1 Dual-stack hosts
We recommend having dual stacked hosts with both IPv4 and IPv6 addresses,
in order to avoid translators. If there is a lack of IPv4 addresses one
could consider DHCPv6 or DSTM to allocate them dynamically. Normally this
would imply that the number of hosts using IPv4 at any given time cannot
exceed the number of addresses. It has been proposed though that hosts
could share IPv4 addresses. One can still avoid translation by handing
out port numbers to hosts and use of tunneling. This is very similar
to RSIP, [RSIP]. These solutions should only be used if there is a
severe shortage of IPv4 addresses, but they avoid some of the problems
caused by translation. See next section for what to do with hosts that
are not dual-stacked. This includes hosts that cannot use IPv4 due to
lack of addresses.
Following the dual stack model, one could envision a scenario where every
link with IPv4 hosts had an IPv4 router, and every link with IPv6 hosts
had an IPv6 router; one router could route both IPv4 and IPv6 of course.
In this case one has native IPv4 and IPv6 on the same link. This could be
hard to accomplish in practice though. There might be routers that are
not IPv6 capable, and the cost of setting up new routers might be too
high. One solution could be to have IPv4 routers bridge packets
(for instance Ethernet) that contain IPv6 datagrams. The common
solution though is to use encapsulation. If the routers on a link only
support say IPv4, IPv6 packets will have to be encapsulated in IPv4.
In theory it is possible to solve this with all the tunneling mechanisms
listed above. Configured tunnels are awkward since it takes some effort
to configure all the hosts, and packets will often follow paths that are
far from optimal. For example two hosts at a site that are to communicate
might have to go through some central router where their tunnels terminate,
while with the other alternatives the packet follows the same
path an IPv4 packet between the two would. 6to4 might be used for each
host, but each host need to have a globally unique IPv4 address if they
are to be globally reachable, while with 6over4 they need only have
private IPv4 addresses [PRIV]. Another advantage of 6over4 is that the
site can use delegated IPv6 addresses, and not change prefixes when
they stop using it. ISATAP solves the same problems as 6over4, and
doesn't need IPv4 multicast, so this could be a good solution. ISATAP
is quite new and we're not aware of any implementations yet. There are
very few implementations of 6over4 too though, and ISATAP is easier to
implement.
8.2 IPv4-only and IPv6-only hosts
If an IPv6-only host is to communicate with an IPv4-only host,
one will need some translation device. For translation one
could use NAT, but a combination of proxies (possibly also caching) for
some protocols and TCP/UDP-relaying should account for most uses. We
recommend transport-relaying as the general solution, and the use of proxies
when it is easy to implement or useful for other purposes. For instance a
web cache might be useful for other purposes, and could easily do the
translation as well. When it comes to applications like mail, printing
and DNS, it is not unusual to have clients always go through some central
servers at the site. The central servers could easily to translation
if they are dual stacked.
8.3 Connecting sites together
A site will probably want to have both IPv4 and IPv6 connectivity to the
outside world as long as there are significant amounts of both IPv4-only
and IPv6-only hosts on the Internet. As we said before, it's very hard
to guess for how
long this will be the case, but a decade is probably the minimum.
To get this connectivity without relying on translation
devices outside the site, the site will need to have some way of
transporting IPv4 and IPv6 packets between the site and the
outside world. This means that the site will need to have at least one
border router with IPv4, and at least one with IPv6; this could be the
same router. On the external links one can run IPv4 and IPv6 on separate
or common links. In the latter case IPv4 and IPv6 can either be
used natively side by side or one encapsulated within the other.
Note that this will require at least one IPv4 address and one
IPv6 address, which
both are globally routable. Provided the site has an IPv4 address, it
could get the necessary IPv6 addresses using 6to4. 6to4 might be a nice
way of starting out with IPv6, but 6to4 is only an interim solution, in
the long term the site should try to find someone that can provide them
with IPv6 connectivity and delegate addresses. The IPv6 provider does
not need to be the same as the IPv4 provider. The IPv6 traffic could
be tunneled over IPv4 to a provider almost anywhere. One should choose
the location with some care though. When going through multiple tunnel hops,
the path may be far from optimal. One of the advantages of 6to4 is that
IPv6 packets will follow the IPv4 topology between 6to4 sites. It might
make sense for a site to have both delegated IPv6 addresses and 6to4.
9. What should UNINETT do?
Rather than looking at providers in general, we will look at what
UNINETT, the Norwegian NREN (national research and education network),
might do to obtain connectivity to the outside world, and how to provide
IPv6 services to the member institutions.
9.1 External Connectivity
Today NORDUnet interconnects the Nordic NRENs and connects them to the
rest of the world. We think this would be a good model for IPv6 as well.
We propose setting up one NORDUnet router (later one should have at least
two for reliability), and make this the main peering and transit point
for the Nordic NRENs. This may be done with partly native IPv6 links and
partly IPv4 tunnels. The NRENs will then only need a link, native or
tunnel, to the NORDUnet router, in order to reach both the other
Nordic NRENs and the rest of the world. If this is not done by NORDUnet,
each Nordic NREN can do this on their own, by setting up a router
with both connections to the other Nordic NRENs and to others.
In the long run one should have native connectivity between the Norwegian
providers. As with IPv4, it might be good to establish some exchanges
for this.
UNINETT should actively take part in or support these activities.
As a first step UNINETT should set up tunnels to other Norwegian IPv6
providers.
9.2 Internal Connectivity
IPv6 deployment in the production network should start as soon as possible.
There are a few reasons preventing full IPv6 deployment at the moment.
First of all there must be IPv6 router software available that supports
the hardware and features that are needed. The current routers have no
hardware IPv6 support which limits the throughput. Also, there is a lack
of interior routing protocols. Only RIP is available for current UNINETT
routers, but IS-IS will be available soon. Due to this, deployment should
be done in a
few selected parts at first, and later extended when the software and
hardware improves. Hence we propose a pilot service offering production
IPv6 to a few sites and enabling IPv6 on a small part of the production
network. The experiences from this will be important when one extends the
service later on.
UNINETT also has an IPv6 backbone testbed which might be used for some of
the production traffic.
Institutions that want to deploy IPv6 must have at least one IPv6 enabled
router at the site, the only exception is single hosts that can be
connected using 6to4 or UNINETT's tunnel broker. They must then connect
to one of the UNINETT IPv6 backbone routers. If this is a neighbor router,
native IPv6 can be used; if not one must use tunneling. Since only a few
UNINETT routers will have IPv6 in the short term, tunneling will be widely
used.
Production addresses should be used in both the production network and
the testbed.
We suggest giving each institution a /48 prefix as recommended in
[ADDRREC]. For large institutions this may prove to be
too small, prefixes should be chosen such that they can be extended
later if possible. See [ASSIGN] for details on how this can be done.
In the future we foresee the need for multiple peering points with
other national or local network providers at many places in Norway.
This might be easier if the prefixes are distributed in a hierarchical
manner. We are not sure if it's worth the effort though. One might
start out with a prefix per region (all institutions inside that
region get a prefix within the regional prefix), and then decide
later if it's worthwhile. If one do this, one should again try
to follow the practice described in [ASSIGN].
9.3 New services and support
UNINETT should as soon as possible offer basic services like IPv6
connectivity with delegated production addresses, and 6to4 by use
of a 6to4 relay operated by UNINETT.
Existing UNINETT services should be IPv6 enabled over time. UNINETT
provides web caching services today. UNINETT should set up caches with IPv6
support. They can work as gateways between IPv4 and IPv6 for normal
web use, and to some extent FTP. UNINETT also operates LDAP servers,
web servers, etc. These should also be IPv6 enabled. Some of this has
already been done for testing purposes, but should be part of the normal
service soon.
It's important that UNINETT gets early experiences with IPv6 and new
services in order to have necessary experience to give advise to its
members. Techniques like encapsulation and translation makes it harder
to manage the network, and might also create some new security issues.
UNINETT has for a long time offered multicast in the core network and
multicast services, these should also be offered with IPv6. Mobility is
going to be important, mobile IPv6 should be studied.
10. Status by the end of year 2000
The core IPv6 specifications are draft standards.
Most common operating systems offer IPv6 to some extent. Some of these
are experimental add-ons, but a growing number now ship IPv6 as part
of their official releases. Many router vendors also have some degree
of IPv6 support. Applications are starting to get IPv6 support
in the official releases. Actually, more and more people have systems
with basic IPv6 support without their knowing.
There is a growing number of IPv6 exchanges, at least four in Europe,
six in the US and one in Japan. There are at least eight ISPs
offering IPv6. RIPE, ARIN and APNIC have allocated 62 /35 prefixes
(SUBTLAs).
References
[TRANS] RFC 2775 Internet Transparency
[ARCH] RFC 1958 Architectural Principles of the Internet
[ARCH6] RFC 2373 IP Version 6 Addressing Architecture
[RRENUM] RFC 2894 Router Renumbering for IPv6
[DNSEXT] RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and
Renumbering
[NAT] RFC 2993 Architectural Implications of NAT
[BGPSIZE] http://www.telstra.net/ops/bgp/
[HOWLONG] http://www.huitema.net/ipv6/howlong.html
[HRATIO] RFC 1715 The H Ratio for Address Assignment Efficiency
[TRANS64] draft-ietf-ngtrans-translator-03.txt
[DSTM] draft-ietf-ngtrans-dstm-04.txt
[DSTMEXT] draft-ietf-ngtrans-dstmext1-aiih-00.txt
[RSIP] draft-ietf-nat-rsip-framework-05.txt
[DHCP] draft-ietf-dhc-dhcpv6-17.txt
[TM] RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers
[TB] RFC 3053 IPv6 Tunnel Broker
[6TO4] RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
[6OVER4] RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit
Tunnels
[ISATAP] draft-ietf-ngtrans-isatap-00.txt
[PRIV] RFC 1918 Address Allocation for Private Internets
[ADDRREC] draft-iesg-ipv6-addressing-recommendations-01.txt
[ASSIGN] draft-ietf-ipngwg-ipaddressassign-02.txt