IPv6 traffic data in Asian networks?

Fri Mar 23 12:46:52 CET 2007

There are many factors here, right now from the IETF meeting, my RTT to
www.ietf.org is:

IPv4 ->
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 114.180/115.935/116.696/1.023 ms

IPv6 -> 
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 101.548/105.093/113.216 ms

>From my office:

IPv4 ->
5 packets transmitted, 5 received, 0% packet loss, time 4048ms
rtt min/avg/max/mdev = 118.184/129.360/140.393/8.643 ms

IPv6 ->
5 packets transmitted, 5 received, 0% packet loss, time 4043ms
rtt min/avg/max/mdev = 122.019/153.300/189.574/22.979 ms

(using our LG at http://www.ipv6tf.org/using/connectivity/looking_glass.php)

I think it is really difficult to qualify for a generic consideration here.
If networks are correctly deployed, it should be more or less the same. I'm
even happy to tolerate a slightly higher RTT with IPv6 because I've the
advantage of being able to access end-to-end to any device in my home, for
example.

Regards,
Jordi

> De: Carlos Friacas <cfriacas at fccn.pt>
> Responder a: <ipv6-ops-bounces+jordi.palet=consulintel.es at lists.cluenet.de>
> Fecha: Fri, 23 Mar 2007 08:14:16 +0000 (WET)
> Para: <ipv6-ops at lists.cluenet.de>
> Asunto: Re: IPv6 traffic data in Asian networks?
> 
> On Thu, 22 Mar 2007, JORDI PALET MARTINEZ wrote:
> 
>> I don't agree, I get almost same RTT to IETF with IPv6 than IPv4, just a
>> couple of milliseconds difference/average.
> 
> AS1930->IETF in v4 = 108ms avg, ASPATH = 20965 1299 7018 7786
> AS1930->IETF in v6 = 176ms avg, ASPATH = 20965 3356 30071 7786
> 
> almost the same doesn't apply here :-(((
> 
> 
>> I think when you have this problem with many sites, it may be a problem at
>> your side, not the content providers side ?
>> 
>> Also don't agree about your statement for favoring IPv4, it depends on the
>> OS policy table and/or the applications when they ignore it. I've looked at
>> this in many scenarios, and is not like that. For example Opera in windows
>> prefers Teredo if no other IPv6 connectivity is available, even if IPv4 is
>> available.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Rémi Denis-Courmont <rdenis at simphalempin.com>
>>> Organización: Remlab.net
>>> Responder a: <ipv6-ops-bounces+jordi.palet=consulintel.es at lists.cluenet.de>
>>> Fecha: Thu, 22 Mar 2007 18:26:05 +0200
>>> Para: <ipv6-ops at lists.cluenet.de>
>>> CC: Kevin Loch <kloch at kl.net>
>>> Asunto: Re: IPv6 traffic data in Asian networks?
>>> 
>>> On Thursday 22 March 2007 18:05:35 Kevin Loch wrote:
>>>> With the exception of the ARIN website itself,
>>> 
>>> www.ietf.org has pretty bad reachability too.
>>> 
>>> On the backbone sides, I have seen problems with TeliaSonera
>>> 
>>> And then, on the client side, I cannot say FranceTelecom DSL native IPv6
>>> service was very stable.
>>> 
>>> And that's for those I have been trying to use.
>>> 
>>>> I have not seen "much
>>>> more" transient reachability problems on IPv6.  I have seen IPv6 enabled
>>>> on commercial websites without any problems.  I'm not saying
>>>> it's perfect but it's alot better than "NO NO NO".
>>> 
>>> It will definitely cause problems to some users, adds extra cost (HW/SW
>>> updates, maintenance). And it does not bring any advantage to the other
>>> ones,
>>> because HTTP works fine with NATs and proxies.
>>> 
>>> I am a bit bored with the "If only Google advertised IPv6 on their websites"
>>> statements that show up every now and then, every here and there. *HTTP* is
>>> simply NOT a good use-case for switching to IPv6 at the moment. Or well,
>>> IPv6-only may make sense if you cannot afford an IPv4 address, but
>>> dual-stack
>>> HTTP server really looks useless to me from a business perspective.
>>> 
>>> Fortunately, there are other application-layer protocols where IPv6 makes a
>>> lot more sense.
>>> 
>>>> As for transition mechanisms, sites will find that having their own
>>>> local 6to4 and teredo relays will help alot.
>>> 
>>> If you do RFC3484, I think it does not matter, IPv4 will be favored over
>>> 6to4<->native or Teredo<->native connections. They really only matter if you
>>> do not have IPv4 at all on one side (or if the client is legacy
>>> non-RFC3484).
>>> 
>>> --
>>> Rémi Denis-Courmont
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>> 
>> 
>> 
>> 
> 
> 
> -------------------------------------------------------------------------
> Carlos Friac,as                                            See:
> Wide Area Network Working Group (WAN)                      www.gigapix.pt
> FCCN - Fundacao para a Computacao Cientifica Nacional      www.ipv6.eu
> Av. do Brasil, n.101                                       www.6diss.org
> 1700-066 Lisboa                                            www.geant2.net
> Tel: +351 218440100 Fax: +351 218472167
> www.fccn.pt
> -------------------------------------------------------------------------
>     The end is near........ see http://www.potaroo.net/tools/ipv4/index.html
>     "Internet is just routes (214049/730), naming (billions) and... people!"
> 
> 
> Aviso de Confidencialidade
> Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo
> conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente
> vedada nos termos da lei. Caso tenha recepcionado indevidamente esta
> mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta
> via ou para o telefone +351 218440100 devendo apagar o seu conteudo
> de imediato.
> 
> Warning
> This message is intended exclusively for its addressee.
> It may contain CONFIDENTIAL information protected by law. If this
> message has been received by error, please notify us via e-mail or by
> telephone +351 218440100 and delete it immediately.

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.