Hello Roman. You raise very valid points, and I'm removing the IPv6 static address I put on the probe. However, won't it still configure an autonomous IPv6 address from radvd information even if I remove the IPv6 IP? Is there any way to disable IPv6 completely on the probe? Or do I have to do something to ensure it doesn't get autonomously configured on the radvd side? Best regards, Kenneth Aalberg -----Opprinnelig melding----- Fra: Roman Mamedov [mailto:rm@romanrm.ru] Sendt: 9. juli 2011 22:39 Til: Kenneth Aalberg Kopi: ripe-atlas@ripe.net Emne: Re: [atlas]Falling back to IPv4 if IPv6 connectivity is lost? On Thu, 7 Jul 2011 16:40:01 +0000 Kenneth Aalberg <kenneaal@abohelse.onmicrosoft.com> wrote:
I've joined the probecloud, and it is working fine. However, I am on an IPv6 tunnel behind a NAT that doesn't let me configure protocol 41 to be forwarded to one specific host (my linux router). Thus, the AYIYA tunnel is in a NAT table as a normal connection, and will sometimes be cycled out if it is the oldest connection and a new one is attempted, regardless of whether the NAT entry has seen traffic recently or not. The probe receives an IPv6 address, and uses this correctly. However, if the tunnel should go down, the probe will also be marked as down, even if it is actually still alive and can communicate through IPv4. Is there any kind of fallback option to try IPv4 connections before declaring a probe host down? Or would it make more sense for me to disable IPv6 on the probe to ensure it accurately represents the actual state of my connectivity?
Hello, In my opinion it does not make sense to provide IPv6 to the probe if it is a tunnelled and not a native connection. Also last time I checked the map display still only showed the IPv6 AS even when IPv6 and IPv4 ASes differ, marking me as being in AS6939 if I turn on IPv6 to the probe, which is not exactly useful to anyone, IMHO. -- With respect, Roman