[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tunneling scenarios and mechanisms evaluation
On Sat, Mar 13, 2004 at 09:23:24AM +0200, Pekka Savola wrote:
> There has been very little 6to4 relay deployment.
Hating to bang on about it, but I've written up my count of 6to4
relay routers. I'd written it in a style that might suit the Cisco
IPJ, but I'm not sure how well suited it is. I guess it might be
of interest to the working group, if it were in a different format?
Any comments welcome.
David.
Counting 6to4 Relay Routers
David Malone, CNRI, Dublin Institute of Technology.
Introduction
------------
In the IPv6 world, significant effort has been spent devising ways
for people to use IPv6 in the absence of a complete IPv6 infrastructure.
Maybe the best known example of this involves forming a virtual
point-to-point link by encapsulating IPv6 packets in IPv4 packets
and sending them from one point in the existing Internet to another.
This is technology that we can all relate to: it looks just like
any other point-to-point link.
Some issues have become apparent with the use of point-to-point
tunnels. First, they have properties like the traditional links on
which they are based: they need the agreement of parties at either
end regarding configuration details and arrangements must be come
to over addressing and routing. The second issue is that, unlike
real point-to-point links, a tunnel can stretch between arbitrary
points in the Internet resulting in highly unpredictable link
properties. This can lead to packets taking a scenic route, and
so people now prefer to only use tunnels between topologically
close sites.
6to4 is another way of routing IPv6 packets over the IPv4 Internet.
6to4 has been described elsewhere[1], so we will just give a flavour
of it here. Much like point-to-point tunnelling, sites using 6to4
have a router responsible for decapsulating and encapsulating
packets. However, 6to4 assigns IPv6 addresses based on a public
IPv4 address of this 6to4 router. Thus, when a 6to4 aware node gets
an IPv6 packet destined to any 6to4 address, it immediately knows
which IPv4 address the packet should be tunnelled to. 6to4 aware
nodes that are willing to perform this tunnelling advertise a route
to 2002::/16, the IPv6 prefix containing all 6to4 addresses. These
nodes are known as 'relay routers' and form a bridge between the
IPv6 and IPv4 Internet.
This explains how packets make their way from the IPv6 Internet to
6to4 networks, and also how packets are routed between 6to4 networks
associated with different IPv4 addresses. The remaining part of the
puzzle is how packets from 6to4 networks get back to the IPv6
Internet. Originally, you had to know the IPv4 address of a relay
router[2] and you would configure your 6to4 router to encapsulate
any traffic to the IPv6 Internet and send it to a specific 6to4
router. Naturally it would be better if this could be done
automatically, without having to choose a relay. In a similar way
to how relay routers advertise themselves in the IPv6 network, a relay
router can now advertise itself in an IPv4 network by advertising
the address 192.88.99.1[3]. This is an IPv4 anycast address that
could be thought of as representing the IPv6 Internet in the IPv4
network.
6to4's design does work around some of the problems that have come
up with point-to-point tunnels. First, it can be automatically
configured once you have a public IPv4 address without any configuration
to be performed "at the other end". Second, it uses the existing
IPv4 and IPv6 routing infrastructure to find the nearest 6to4 relay
router, providing some automatic adaptation to the state of the
network. Note that this may not completely eliminate scenic routing
as the relay router may be some distance from the packet's eventual
destination.
From this picture of 6to4, it should be clear that the relay routers
are essential to the operation of 6to4, in a similar way that the
DNS root servers are essential to the operation of DNS. The more
relay routers that are available throughout the network, the smoother
and more reliable the operation of 6to4 will be. Consequently, the
the number of 6to4 relay routers available is something that impacts
on the ability of 6to4 to provide IPv6 connectivity.
How to count relay routers
--------------------------
There are a small number of 6to4 relay routers that make themselves
very obvious by advertising themselves in the IPv4 BGP routing
tables using the anycast address 192.88.99.1. Perhaps the best known
of these is the one at SWITCH, the Swiss Education and Research
Network, but on any day there are a number of networks offering
6to4 relay services. One snapshot from the Route Views project[4]
shows the following autonomous systems (ASs) advertising 192.88.99.0/24:
AS559 SWITCH
AS1741 FUNET
AS3246 SONGNETWORKS
AS8379 CYBERNET-AG
AS9033 ECIX-AS
AS12859 NL-BIT
AS17832 SIXNGIX-AS-KR
AS30155 KLU
However, this is not the whole story. To begin with, the list of visible
relay routers in IPv6 BGP may not be the same, for example, by looking at
several IPv6 looking-glasses we see the following ASs advertising routes
to the 6to4 prefix, 2002::/16:
AS109 CISCOSYSTEMS
AS559 SWITCH
AS786 JANET
AS9264 ASNET
AS12859 NL-BIT
AS17715 CHTTL-TW
AS24895 FUBAR
More interesting is that some network providers may choose to provide
a 6to4 relay that is only available internally, by advertising the
192.88.99.0/24 and/or 2002::/16 within their own AS (or possibly
only to selected BGP peers). In these cases it is less likely that
these routes will ever be visible in a project like Route Views.
However, if 6to4 turns out to be a popular method for the connection
of IPv6 end sites, it seems a significant number of 6to4 users could
be supported by such private relays.
So, how can we estimate the number of 6to4 relays that are actually
in service? The ideal way would be to traceroute to 192.88.99.1
from various points in the Internet and see where those traceroutes
lead. Similarly, tracerouting from points in the IPv6 Internet to
some address in the 2002::/16 range would reveal the IPv6 side of
6to4 routers. This could be undertaken using a facility like
PlanetLab[5].
However, a practical way presents itself that does not require any
special facilities. Consider what happens if we traceroute in with
a source address that is a 6to4 address. As packets (ICMP TTL
exceed) are sent from each hop, they will make their way to the
nearest relay router accepting packets for 2002::/16. This router
will encapsulate the packet and send it to the appropriate IPv4
address. By collecting these IPv4 packets at their destination and
examining the source address used for encapsulation, we will get
the addresses of the 6to4 relays along the path we are tracerouting.
Targets for such a traceroute are relatively easy to find. In the
IPv6 world a network provider is generally represented by a single
prefix in the global IPv6 BGP tables. This routing table is still
relatively compact, containing less than 1000 prefixes. By
tracerouting to the first address in each range, it seems likely
that a packet will make its way into the organisation's network and
the ICMP message will make its way to the nearest relay to that
organisation.
Doing the count
---------------
Performing the count described above is relatively straight forward.
A list of prefixes can be obtained from your nearest friendly IPv6
BGP speaker. Packets can be collected on a target 6to4 host using
tcpdump, and traceroute can be run with appropriate options. The
IPv4 addresses can then easily be extracted. The whole process can
be completed in a few hours without stressing a modest DSL connection.
In practice, most of the returned packets are accounted for by a
rather small number of encapsulating IPv4 addresses. Among these
is 192.88.99.1, which obviously may account for a number of relays.
As an anycast address, 192.88.99.1 should probably not appear as a
source address, however for reasons related to both operational and
software it does.
Trying to resolve the relays replying using 192.88.99.1 seems
important, as it may account for a significant number of relays.
This can also be done with traceroute. Consider a node that traceroutes
to a 6to4 address - the last hop before the decapsulating router
will be the relay router. Just as with IPv4 loose source routing,
IPv6 provides a way to traceroute via a particular node (using
routing headers). So, by tracerouting via nodes whose relay router
replied using the the anycast address, we can find IPv6 addresses
associated with that relay router.
Note that a single relay router may have many IPv4 and IPv6 addresses.
Manual inspection suggested that IPv4 addresses (other than
192.88.99.1) represented distinct single relays. This is probably
due to source address selection being applied consistently for a
fixed IPv4 destination when encapsulation takes place on a particular
router.
For the relay routers that replied using the anycast IPv4 address,
we also determined their IPv6 addresses. This list contained groups
of addresses that obviously belonged to the same router. This is
due to the traceroute replies being generated by a particular
interface, probably the one on which the expiring packet arrived.
To account for these duplicates, only the first 32 bits of the IPv6
address was considered, and then these were checked in the whois
database to eliminate duplicates caused by relays that use both
6bone (3ffe::) and production (2001::) prefixes.
Results of the count
--------------------
The first count was performed in July 2003 and produced a list of
26 different IPv4 addresses, including 192.88.99.1. Trying to
resolve 192.88.99.1, using the technique we described above, produced
a list of 12 /32s. Of these 12, two were SWITCH. This gives a total
of 37 different relay routers identified by the count. One relay
router was systematically missed because it was within two hops of
the node performing the count.
The count was repeated in January 2004 and again produced a list
of 26 different IPv4 addresses. However, this time a 18 different
/32s were found behind the anycast address (without the duplication
of SWITCH). Interestingly, a number of distinct relays were found
in the same /32, in space assigned by RIPE to IXPs. This suggests
a figure around 44 relay routers. In this second count, two relay
routers were missed because they were within two hops of the node
performing the count.
The following breakdown was produced by attempting to assign relay
routers to countries using whois. The breakdown includes the relays
that were systematically missed.
July '03 January '04
AU 1 1
CA 0 1
CH 1 2
CZ 1 0
DE 4 9
EE 1 1
ES 0 1
EU 0 2
FI 2 2
GR 0 1
IE 3 3
IT 0 1
JP 2 1
KR 3 2
LT 2 2
LU 0 1
NL 4 1
NO 1 1
PT 1 2
SE 2 2
TH 1 3
TW 2 1
UK 3 4
US 4 2
Total 38 46
Conclusions and Remaining Issues
--------------------------------
It seems that, in addition to the handful of publicly advertised
6to4 relays that are available, there are also quite a number of
additional private relays in operation. This is good news for
people using 6to4, meaning they are more likely to get a router
close to them.
The list of countries does seem to be biased towards Europe. At
least part of this is likely to be systematic bias - the count was
performed from a European IPv6 network, and packets are more likely
to take transit through European networks, and so find European
relays. It is also possible that the deployment of native IPv6 is
further ahead in other parts of the world, and consequently 6to4
relays are consequently less common.
What isn't clear from this count is how wide the domain of attraction
for each of these relays is, how many clients each serves and how
the traffic load is distributed between them. As commented earlier,
a large number of packets are being returned through a small number
of relays, particularly one relay in Japan.
Perhaps the biggest weakness of this count is that it is possible
(though unlikely) that the relays that take packets from the IPv6
Internet to the IPv4 Internet are completely unrelated to the relays
that send packets in the opposite direction. Some asymmetry has
already been noticed in this area, where publicly advertised
relays often see much more traffic going from IPv4->IPv6 than
IPv6->IPv4. A reasonable explanation for this is that many sites
with native IPv6 connectivity also have some IPv4 connectivity, and
so can run a private relay. Consequently, it would certainly be
interesting to know how many hops the average user has to go to
find a machine listening on 192.88.99.1.
References
----------
[1] Connecting IPv6 Routing Domains Over the IPv4 Internet
Carpenter, Moore and Fink,
Cisco Internet Protocol Journal Volume 3, Number 1, March 2000
[2] Public 6to4 Relay Routers
Sayer,
http://www.kfu.com/~nsayer/6to4/
[3] An Anycast Prefix for 6to4 Relay Routers
Huitema,
RFC 3068, June 2001.
[4] University of Oregon Route Views Project,
Advanced Network Technology Center,
http://www.routeviews.org/
[5] PlanetLab,
http://www.planet-lab.org/