|
Ticket ID: SIXXS #555407 Ticket Status: Won't fix PoP: nlams05 - SURFnet (Amsterdam)
poor routing of 6to4 destinations
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Sunday, 29 July 2007 12:24:54
I noticed that I have very poor throughput with 6to4 destinations from my native IPv6 subnet. I would expect my tunnel broker to efficiently route 2002::/16 addresses to its nearest 6to4 relay. For example, I set up a 6to4 host which I know to be "nearby" both geographically as well as IPv4 network topological (a XS4ALL colocation site, which is very near the surfnet backbone).
so I do:
native IPv6 host <--> local IPv6 brokered gateway <--> nlams05 broker <--> (???) <--> 6to4 host
and I got this:
Route traceren tot: 6to4.livesafer.net [2002:525e:bba2::1]
vanaf: 2001:610:66d:1:a182:29e4:d61b:4094 via maximaal 30 hops:
1 3 ms < 1 ms < 1 ms 2001:610:66d:1:20e:2eff:fe6a:61f4
2 11 ms 11 ms 11 ms gw-582.ams-05.nl.sixxs.net [2001:610:600:245::1]
3 11 ms 11 ms 11 ms vl163.sw14.amsterdam1.surf.net [2001:610:1:80bb:192:87:102:97]
4 11 ms 12 ms 12 ms v2-1-1.1661.XSR01.Amsterdam2A.surf.net [2001:610:f01:9168::174]
5 13 ms 11 ms 11 ms FT-500.XSR03.Asd001A.surf.net [2001:610:e08:32::34]
6 11 ms 12 ms * ge-0.ams-ix.amstnl02.nl.bb.verio.net [2001:7f8:1::a500:2914:1]
7 111 ms 111 ms 110 ms p64-1-1-0.r20.asbnva01.us.bb.gin.ntt.net [2001:418:0:2000::105]
8 110 ms * 110 ms xe-1-1.r01.stngva01.us.bb.gin.ntt.net [2001:418:0:2000::1e6]
9 111 ms 112 ms 112 ms fa-0-0.gw.stngva.ameri.ca [2001:418:0:5000::36]
10 * 103 ms 103 ms 6to4.livesafer.net [2002:525e:bba2::1]
now, that's quite a detour...
I would expect surfnet to have a more efficient route for 2002::/16 internally to some nearby 6to4 relay of its own.
I tested this "the other way around" too, i.e. make my local network 6to4 instead of native, and the XS4ALL site native IPv6 with XS4ALL as the IPv6 provider. In that case XS4ALL *does* provide a short path to a 6to4 relay router of their own, resulting in only 4 hops @ 11ms.
State change: wontfix
The state of this ticket has been changed to wontfix
poor routing of 6to4 destinations
That is simply because 6to4 is a protocol which is very nasty. The forward and return path are uncontrollable due to the anycast nature of the protocol. It is also why we recommend NOT to use 6to4. (One can request quality IPv6 connectivity by using the SixXS PoPs anyway)
Sorry can't fix this in anyway.
Simple solution: don't use 6to4
Other solution: install your own 6to4 relay
Also, XS4all has native IPv6 in their colo's and other places, thus request direct IPv6 connectivity from them.
poor routing of 6to4 destinations
Shadow Hawkins on Sunday, 29 July 2007 21:09:08
Ok, I see. Of course I am not using 6to4 myself, and the colocated site has native IPv6. That was just to demonstrate the "problem". But in order to get at least a bit better routes to 6to4 users I will try to set up my own 6to4 relay.
I would still like to point out, however, that many users that have a public IPv4 address through their ISP on their windows machines (using dial-in, or USB adsl modems) will also get automatic 6to4 IPv6 addresses (even without them knowing). So I still think it would be nice if us native IPv6 folks would at least try a little bit harder, instead of routing 2002::/16 across the ocean in hopes of someone there relaying it.
XS4ALL has such a relay for their natively connected IPv6 clients (it is called 6to4.xs4all.nl). I still think SixXS brokers should have such a relay as well, but I realize it is not a must, that I can't force them, and that you don't agree with me.
poor routing of 6to4 destinations
ISP do not want to route other ISP's traffic. Also 6to4 only causes problems which are untraceable as anything can be causing it.
There where a number of 6to4 relays in Europe, but due to ddos attacks targeting bogus 6to4 routers a number of them have been shutdown.
Also do note that SixXS is not an ISP.
Very simple solution: don't use 6to4.
|
![[ch]](/s/countries/ch.gif)
on Sunday, 29 July 2007 17:25:22
Posting is only allowed when you are