Subject: RE: Automatic tunnels

From: "Christian Huitema" <[email-masked]>
Date: Fri, 25 Jul 2003 09:57:19 -0700

> We also need to understand if and how a home ISP can deploy gradually
> IPv6
> for its customer. Does providing a 6to4 relay helps? Does providing a
> tunnel broker
> in in core/access networks help? Does this makes it easier to go
> gradually to native?

I guess we agree that the main priority for ISP ought to be, "provide
native IPv6 services". The question then is what should an ISP do when
it wishes to provide IPv6 but is not quite ready. I would expect the ISP
design team to tell us more about the constraints and the
practicalities, but there are clearly three possibilities: do nothing,
provide support for automatic tunneling, or provide configured tunnels.
The support for automatic tunneling is simple: just provide a
6to4-to-native service and advertise a route to 192.88.99.1; to avoid
abuse, make sure that 192.88.99.1 is only reachable by subscribers of
this ISP. The support for configured tunnels is somewhat more complex:
if the ISP really want to provide additional benefits compare to
automatic tunnels, it needs to do some form of customer management to
ensure that customers get stable prefixes, that they use the tunnel end
point closest to home, etc. Frankly, I don't know whether the additional
complexity is worth the cost.

> The issue with with an ISP deploying an internal 6to4-to-native relay
> is that
> it will help its customers who are using 6to4 to send packets to
native
> IPv6
> destination, but won't do much to make sure that the same packets will
> return any quicker. As 6to4 to native and back is fundamentally
> asymmetric routing,
> somebody, preferably close to the native IPv6 node has to have a route
> for 2002::/16.

Deploying a "native to 6to4" relay is actually very easy -- its is a
matter of turning on 6to4 relaying on a dual-stack router, or even on a
dual-stack host. I would expect that these relays will be plentiful.

> As one can not realistically expect to have every single IPv6 network
> maintaining
> a local native-to-6to4 gateway, we would have to rely on public,
> open native-to-6to4 relays to exist and advertise 2002::/16 in the
DFZ.

We should precisely aim for having at least one native to 6to4 router in
every dual stack ISP. These routers are very easy to control: just don't
propagate 2002::/16 in BGP. They provide an immediate added value to the
local IPv6 users.

> So far, I have identified only a few of those public native-to-6to4
> relays.
> My understanding is that, expect from the willingness to promote the
> technology,
> there is actually little incentive to operate such a relay, as it will
> just attract transit traffic
> that has nothing to do with the ISP customers.

I believe it is a whole lot easier to provide "private" relays, for
local use only, rather than public relays, for the whole Internet.
However, backbone ISP have a built-in incentive to provide these relays:
the relays create traffic, and that traffic ends up being billed to the
second tier ISP who send packets to the backbone.

-- Christian Huitema

---

From: Alain Durand <[email-masked]>
Date: Fri, 25 Jul 2003 16:31:32 -0700

>dual-stack host. I would expect that these relays will be plentiful.
Do you have any data that shows that this is happening?

>propagate 2002::/16 in BGP. They provide an immediate added value to the
So, if I understand you correctly, what you're aiming at is that
everytime a 6to4 user A with a IPv4 ISPa wants to communicate
with an native IPv6 user B with an IPv6 ISPb:
- IPv4 ISPa has deployed a 6to4-to-native relay
- IPv6 ISPb has deployed a native-to-6to4 relay or has a peering agreement
   with someone who offer native-to-6to4 relay service.

This is an operational issue, are IPv6 ISPs doing this today?
If not, why?

    - Alain.

---

From: David Malone <[email-masked]>
Date: Sat, 26 Jul 2003 10:03:58 +0100

> Do you have any data that shows that this is happening?

I did some measurements of the number of 6to4 relays, including
private ones. I've included relevant part of my message to v6ops
below. The count was done on 2 July. (If anyone would like this
written up in more detail, let me know...)

	David.

If anyone is interested, I had a go at counting 6to4 relay routers
from the IPv6 side. I did this by tracerout6ing with a 6to4 source
address and then using tcpdump to catch the IPv4 addresses of
relay-routers that was used to encapsulate the replies. To decide
where to traceroute to, I used the ::1 addresses of each prefix in
the IPv6 BGP table (as seen from HEAnet this morning).

After doing this, I got replies encapsulated 26 different source
IPv4 addresses. One was the anycast address and I had a go at
guessing the countries of the remainder (AU:1 CZ:1 DE:1 FI:1 IE:1
JP:1 KR:3 LT:2 NL:3 NO:1 PT:1 SE:2 TH:1 TW:1 UK:2 US:3).

About 1/4 of the response packets came from the 6to4 anycast address,
so it seems to be worth trying to figure out how many relays it
represents. Looking at the histogram of TTLs in the IPv4 header,
it looks like there are at least 3 or 4.

To try to get a better idea, I tracerout6ed to a 6to4 address using
a routing header to get the packet to first go to nodes that had
had replies encapsulated with the anycast address. The second last
hop of these traceroutes should help identify the 6to4 relay.

This produced 27 IPv6 addresses, but sevral of them looked like
they were assigned to the same machine. Looking at the /32s that
these IPv6 addresses are in suggests that there are actually about
12 distinct relays in this group. Looking them up in whois shows
that two of the /32s are in switch, so we're probably looking at
11 (CH:1 DE:3 EE:1 FI:1 IE:1 JP:1 NL:1 UK:1 US:1).

In total, that's about 33, if you take into account a possible
overlap of 2 or 3.

[Naturally, I may have missed lots of relays that aren't visable
from the route to the ::1 address within a prefix...]

---

From: [email-masked]
Date: Thu, 31 Jul 2003 17:46:28 +0900

>complexity is worth the cost.

	for native-to-6to4, there's no way to protect from abuse (since
	2002::/16 has to be advertised, more-specific route is not permitted).
	how do you address the problem? (pekka's draft outlines the problem
	very well)

	seriously, with ISP hat on, we have been talking about putting 6to4
	relay router in our backbone, but we end up rejecting it due to the
	possibility of abuse, and the impact of abuse (and the lack of human
	resource to monitor/track down the source of abuse).  i'm very
	pessimistic about 6to4 relay router deployment.

itojun