[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tunneling scenarios and mechanisms evaluation
How do you know how many relay routers exist? All you can count are ones
that ISPs/NRENs choose to advertise beyond their borders?
Tim
On Sat, Mar 13, 2004 at 11:33:16AM +0000, David Malone wrote:
> 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/