Secure* address family option

[Trolan]

I haven't been able to find anything like the following in SecureCRT or SFX:

A means of forcing a connection to use IPv4 or IPv6, akin to the -4 and -6 command line options to OpenSSH. I've started to run into certain policy issues connecting to some systems which have acquired AAAA records, but ssh access is restricted to IPv4 connections only. With v6 enabled, the AAAA is the one being tried, and there's no way to try to use the v4 address without hardcoding the IP into the session.

[tnygren]

Hi Trolan,

SecureCRT 5.x and SecureFX 3.x and higher support IPv6 addresses.

Not setting is need to enable this option. If the IPv6 address is entered or the hostname of the session resolves out to a IPv6 address, that address will automatically be used.

Have there been issues with using IPv6 addresses in SecureCRT or SecureFX?

[gan]

In some cases a hostname could resolve to both a IPv4 and IPv6 address. One example could be if you have two PC's running Vista and the default settings where selected during install (which means both IPv4 and IPv6 as well as Netbios is enabled). If those two PC's is connected to the same subnet some applications might use netbios to resolve the hostname. In that case if you ping host1 from host2 (Ex: "ping host1" in a dos window) you might see that the resolved IP is the IPv6 and not the IPv4 address. The ping.exe have the parameters -4 to force the use of IPv4 and -6 to force the use of IPv6. So in this example using "ping -4 host1" will force host1 to be resolved to IPv4 and not IPv6. Using the -6 parameter will do the opposite.

Below is an example using ping with and without the -4 parameter where both hosts is running Windows Vista, IPv4, IPv6 and netbios is enabled:

C:\>ping host1

Pinging host1 [fe80::9597:b1a1:f16e:c0e5%14] from fe80::8cad:b886:f5e5:2e2b%14 with 32 bytes of data:
Reply from fe80::9597:b1a1:f16e:c0e5%14: time=1ms
Reply from fe80::9597:b1a1:f16e:c0e5%14: time=1ms
Reply from fe80::9597:b1a1:f16e:c0e5%14: time<1ms
Reply from fe80::9597:b1a1:f16e:c0e5%14: time<1ms

Ping statistics for fe80::9597:b1a1:f16e:c0e5%14:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:\>ping -4 host1

Pinging host1 [10.1.1.207] with 32 bytes of data:
Reply from 10.1.1.207: bytes=32 time=2ms TTL=128
Reply from 10.1.1.207: bytes=32 time<1ms TTL=128
Reply from 10.1.1.207: bytes=32 time<1ms TTL=128
Reply from 10.1.1.207: bytes=32 time<1ms TTL=128

Ping statistics for 10.1.1.207:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 2ms, Average = 0ms

In the first example the hostname is resolved to a IPv6 address, but the second example uisng the "-4" parameter ping is forced to use IPv4.

Lets say that i want to use SCRT to connect to host1 in this example. Will SCRT use the IPv6 or the IPv4 address? What if SCRT use the IPv6 and the ssh/telnet server running on host1 does not work with IPv6 for some reason. In that case it could be useful to have a option in SCRT to force the use of IPv4 like using ping with the "-4" parameter.

I have never really seen any cases where this is a issue and i had to use IPv4 while the resolved address is IPv6, but i can imagine this could happen. I believe this is what Trolan is asking to be able to force SCRT to use either IPv4 or IPv6 in these kind of cases. I guess the option to specify IPv4 or IPv6 for the default session as well as each created session to override the defaults could be an idea in these kind of cases. Also a command line parameter to specify either IPv4 or IPv6 (for example "/4" and "/6"). As far as i understand SCRT and SFX will only use whatever resolved and you do not have the option to specify that you want to use the IPv4 address or the the opposite.


Gan

[tnygren]

Hi Gan,

Thanks for the information!

I have entered a request to see if an option could be added to SecureCRT to specify if the IPv4 or IPv6 address should be used.

If this option is added, a post will be made here.

If you would prefer to be contacted via email, please send me a message and reference forum thread 3067.

Trolan,

If this was not exactly what you were requesting, please let me know.

[Trolan]

gan's reply expanded on the topic perfectly. The ability to connect to 4 or 6 specifically when both types of addresses are returned from DNS is exactly what I'm talking about. The common case someone might need this is in the case where they have v6 name resolution, but no reachability to the other v6 host for some reason (local policy, home LAN with autoconfigging v6, v6 tunnel when the tunnel may be down, etc.)

[tnygren]

Hi Trolan,

I have added your comments to the request I created earlier.

If you would also prefer to be contacted via email, please use the information from my previous post to send me an email.

[stian]

Originally Posted by Trolan

I haven't been able to find anything like the following in SecureCRT or SFX:

A means of forcing a connection to use IPv4 or IPv6, akin to the -4 and -6 command line options to OpenSSH. I've started to run into certain policy issues connecting to some systems which have acquired AAAA records, but ssh access is restricted to IPv4 connections only. With v6 enabled, the AAAA is the one being tried, and there's no way to try to use the v4 address without hardcoding the IP into the session.

For the record, I would also find this useful. I've been able to work around it by hardcoding an IP address (rather than a hostname) in the session, but this is clunky. A checkbox would be much nicer and more elegant.

I would suggest implementing it as a threeway selection:

- Automatic (use IPv6 if available, fall back to IPv4)
- IPv6 only
- IPv4 only

[kbarnette]

Hi stian,

Thanks for the feedback.

I have added your comments to the feature request regarding this capability.

As was mentioned previously, we will post here in the event that such a feature becomes available in a future release of SecureCRT. If you would like to be contacted personally, feel free to contact us with your request and include a reference to this forum thread (3067).

[SirParadox]

I came here today as I have a very similar problem. I have both V4 and V6 enabled, and many of my hosts have dns for both, yet my v6 network isn't fully deployed... and I don't want to connect via v6.

So I wanted to request a global option or session option to force IPv4. And I found this nice thread..


However this thread hasn't been updated since 08-06-2008. Can we get some update / action ASAP please? IPv6 is in the wild....

[miked]

Hello,

Thanks for posting the problem you're experiencing. As of SecureCRT 6.6 it is not possible to force IPv4. I have updated our request database with your post, and if forcing IPv4 is an option added to a future release we'll post a follow up message to this thread. Please let us know if you would like to receive e-mail notification if this option is added, and refer to forum thread 3067.

[jdev]

Originally Posted by SirParadox

my v6 network isn't fully deployed... and I don't want to connect via v6.

If your ipv6 network isn't yet "fully deployed" and you're on a Windows machine, perhaps you could consider making a change to policy preference system-wide (on your machine) so that all apps (not just SecureCRT) will use preferred ipv4 instead of ipv6.

Microsoft provides a fairly easy method to accomplish this preference switch by way of a registry modification: http://support.microsoft.com/kb/929852

Such a preference switch might just help you bide time until an internal "Prefer ipv4 over ipv6" option is implemented not only in SecureCRT, but in all TCP applications you might ever need to run as long as your ipv6 network remains incomplete.

Alas, if you're using SecureCRT on Mac OS X or Linux I haven't yet been able to locate any dependable way to prefer ipv4 over ipv6 using an OS-level configuration setting, but perhaps there's someone else in this forum community that can chime in with additional info in this area.

FYI.
--Jake

[ddx]

Any news on this option ?
Or better: option to fallback to ipv4 when ipv6 connection isn't succeeding ?