[atlas]Falling back to IPv4 if IPv6 connectivity is lost?
Greetings, Probers. (Yes, that was the first name that came to mind. :P ) 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? Best regards, Kenneth Aalberg Probe 737.
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
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
On Sun, 10 Jul 2011 02:11:04 +0000 Kenneth Aalberg <kenneaal@abohelse.onmicrosoft.com> wrote:
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?
Hello, Due to security concerns I have my probe plugged in into its own network port on my gateway server, that way I can easily control whether or not the gateway does RA on this port, which DHCP details it sends out, which firewall rules are applied, etc. An alternative would be putting the probe in its own VLAN, but my main switch is not VLAN-capable. In your case you can try firewalling off IPv6 from the probe and then rebooting it, so even though it has an IPv6 address, it can never connect to anything on IPv6, and hopefully it will just use only IPv4 from the start. -- With respect, Roman
Hi,
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.
Regarding this: currently we only really use (and show) the AS of the default connection (v6, if available) even if it's tunnelled. We'll be separating the IPv4/IPv6 ASes and show both on the UI. Regards, Robert
participants (3)
-
Kenneth Aalberg -
Robert Kisteleki -
Roman Mamedov