Print

[bartgrefte]

Just recently I managed to get a virtualized IPFire (Linux) to use my IPv6 tunnel, even though IPv6 is not officially supported. Turned out that the IPv6-related modules were present, just not loaded and had to edit a couple of configuration files because IPv6 was set disabled.

Unfortunately there's no (easy) way to get radvd and/or DHCPv6 installed and working. That will involve cross compiling and might not even work. There's no radvd or DHCPv6 addon available, there is also no C-compiler for IPFire, which makes ./configure and make useless. So if I want to try that, I'll have to try IPFire's build-environment or use a different operating system to compile everything and pray it might work.

So I figured I'd try a static-config first, but can't get that to work and that is why I made this topic. I cannot get the host of the virtual machine (Windows 7 Ultimate x64) to connect to websites or IPFire using IPv6. Pings to the IPv6 address of IPFire's green0(=LAN) interface fail with timeout errors, the other way round as well. Although from IPFire's end, I'm using My Traceroute since ping6 wasn't compiled into the kernel

Now the strange part: if I ping -6 IPFire using the fe80 address of the green0/LAN-interface then pings are successful. Although the 1st one always fails, after the one fail it works. The other way round it only works if I use the fe80 address of "VMware Network Adapter VMnet1" on the host, can't reach the fe80 address of the physical LAN-interface of the host.

I'm guessing that being able to ping the fe80 addresses rules out firewall issues, although I disabled it on the host to be sure. I also checked if forwarding is enabled:

Code: [Select]

[root@ipfire-test ~]# cat /proc/sys/net/ipv6/conf/all/forwarding
1
The only other cause I can think of is that VMware Workstation 9.0.0 is being a pain in the butt. The reason I virtualized this is because I want to test it first and make sure nothing gets broken in the process of getting IPFire to support IPv6 even though it, officially, is not supported.
I've set the virtualized LAN-interface of IPFire to "host-only", the WAN-interface to bridged. IPFire demands the WAN (red0) and LAN interface to be in different subnets/ranges, so I cannot set them both to bridged. Maybe the host-only setting is preventing IPv6 access? But then I shouldn't have been able to ping the fe80 addresses(?).

But first let's make sure all the settings check out. This is what I got:

Code: [Select]

Server IPv4 Address:216.66.84.46
Server IPv6 Address:2001:****:**14:***8::1/64
Client IPv4 Address:IP-address of IPFires virtualized WAN-interface
Client IPv6 Address:2001:****:**14:***8::2/64

Routed IPv6 Prefixes
Routed /64:2001:****:**15:***9::/64
Routed /48:Assign /48

Available DNS Resolvers
Anycasted IPv6 Caching Nameserver:2001:470:20::2
Anycasted IPv4 Caching Nameserver:74.82.42.42
IPFire: (Someone was kind enough to put a pre-compiled ifconfig with IPv6 support online )

Code: [Select]

[root@ipfire-test ~]# ifconfig
green0    Link encap:Ethernet  HWaddr 00:50:56:26:A9:A5  
          inet addr:10.0.0.2  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe26:a9a5/64 Scope:Link
          inet6 addr: 2001:****:**15:***9::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:56 errors:0 dropped:0 overruns:0 frame:0
          TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6371 (6.2 Kb)  TX bytes:10961 (10.7 Kb)
          Interrupt:16 Base address:0x2080

he-ipv6   Link encap:UNSPEC  HWaddr C0-A8-01-29-FF-00-00-00-00-00-00-00-00-00-00-00  
          inet6 addr: fe80::c0a8:129/128 Scope:Link
          inet6 addr: 2001:****:**14:***8::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:28 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3474 (3.3 Kb)  TX bytes:3474 (3.3 Kb)

red0      Link encap:Ethernet  HWaddr 00:50:56:27:7F:B1  
          inet addr:192.168.1.41  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe27:7fb1/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:101 errors:0 dropped:2 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16244 (15.8 Kb)  TX bytes:8793 (8.5 Kb)
          Interrupt:19 Base address:0x2000

Code: [Select]

[root@ipfire-test ~]# ip -6 route
2001:****:**14:***8::/64 via :: dev he-ipv6  proto kernel  metric 256
2001:****:**15:***9::/64 dev green0  proto kernel  metric 256
fe80::/64 dev green0  proto kernel  metric 256
fe80::/64 dev red0  proto kernel  metric 256
fe80::/64 via :: dev he-ipv6  proto kernel  metric 256
default dev he-ipv6  metric 1024
The host, with these two being relevant:
LAN-verbinding = physical LAN-interface
VMware Network Adapter VMnet1 = IPFire's host-only LAN-interface

Code: [Select]

Windows IP-configuratie


Draadloos LAN-adapter voor Draadloze netwerkverbinding:

   Mediumstatus. . . . . . . . . . . : medium ontkoppeld
   Verbindingsspec. DNS-achtervoegsel: localdomain

Ethernet-adapter voor LAN-verbinding:

   Verbindingsspec. DNS-achtervoegsel:
   IPv6-adres. . . . . . . . . . . . : 2001:****:**15:***9::2
   Link-local IPv6-adres . . . . . . : fe80::ac25:6ddb:20b6:ad66%11
   IPv4-adres. . . . . . . . . . . . : 192.168.1.11
   Subnetmasker. . . . . . . . . . . : 255.255.255.0
   Standaardgateway. . . . . . . . . : 2001:****:**15:***9::1
                                       192.168.1.1

Ethernet-adapter voor VMware Network Adapter VMnet1:

   Verbindingsspec. DNS-achtervoegsel:
   Link-local IPv6-adres . . . . . . : fe80::bc3c:537f:4e2d:e2f1%19
   IPv4-adres. . . . . . . . . . . . : 10.0.0.1
   Subnetmasker. . . . . . . . . . . : 255.255.255.0
   Standaardgateway. . . . . . . . . :

Ethernet-adapter voor VMware Network Adapter VMnet8:

   Verbindingsspec. DNS-achtervoegsel:
   Link-local IPv6-adres . . . . . . : fe80::dce7:db34:44c9:112a%20
   IPv4-adres. . . . . . . . . . . . : 192.168.85.1
   Subnetmasker. . . . . . . . . . . : 255.255.255.0
   Standaardgateway. . . . . . . . . :

Tunnel-adapter voor isatap.localdomain:

   Mediumstatus. . . . . . . . . . . : medium ontkoppeld
   Verbindingsspec. DNS-achtervoegsel:

Tunnel-adapter voor isatap.{5CFD9F22-6CEA-43BB-B6C6-D3CAFBDD5CC3}:

   Mediumstatus. . . . . . . . . . . : medium ontkoppeld
   Verbindingsspec. DNS-achtervoegsel:

Tunnel-adapter voor LAN-verbinding* 9:

   Mediumstatus. . . . . . . . . . . : medium ontkoppeld
   Verbindingsspec. DNS-achtervoegsel:

Tunnel-adapter voor isatap.{56D84449-E100-440D-9BB2-AA495539F069}:

   Mediumstatus. . . . . . . . . . . : medium ontkoppeld
   Verbindingsspec. DNS-achtervoegsel:

Tunnel-adapter voor isatap.{8555E581-1A7E-4875-8FBC-3EC34E065FFB}:

   Mediumstatus. . . . . . . . . . . : medium ontkoppeld
   Verbindingsspec. DNS-achtervoegsel:

Unless I overlooked something, everything checks out. Can anyone confirm that?

[bartgrefte]

The solution turned out to be simple, I had to give VMware Network Adapter VMnet1 a static address, not the LAN-interface. IPFire and the host can now ping -6 each other and I can also ping -6 ipv6.google.com , www.kame.net and other websites from the host.

But IE, Firefox and Chrome cannot connect using IPv6. ipv6.google.com is not found and the other does not show a dancing kame, same with using the IPv6 address. http://test-ipv6.com/ says everything is okay with the connection (10/10), but it says that my browsers refuse to use IPv6

edit: Weird, http://ipv6.tunnelbroker.net/ seems to work (Firefox shows IPv6 address), but http://ipv6.he.net/ shows an IPv4 address.

So it seems the only website working is http://ipv6.tunnelbroker.net/ , even though I can ping -6 other websites without problems.

[kcochran]

Many browsers implement what is called 'Happy Eyeballs', and if they get replies from v4 first, they'll prefer that.  ipv6.tunnelbroker.net is an IPv6-only site, so Happy Eyeballs can't enter into it.

[bartgrefte]

But still, never had this before (when I was using pfSense as router till a while a go) plus ipv6.google.com should work, but it does not, not found error, also with Facebook's v6 hostname. And in four different browsers?

edit: Finally found an IPv6 capable website, besides http://ipv6.tunnelbroker.net/ , that works: http://www.solo-buon-umore.com/

[bartgrefte]

I think I'm on to something:

I can connect to Googles IPv6 website using telnet ipv6.google.com 80 on IPFire, but not on the host. So looks like something is being blocked. But where?

edit: telnet ipv6.l.google.com 80 works
And using the IPv6 address I got from running telnet ipv6.google.com 80 on IPFire works as well

edit2: If I use the IPv6 addresses of IPv6-websites I can seem to connect to them using telnet.

And test-site http://[2001:7b8:3:32:213:136:0:22]/ , that seems to work, says:

BETA -This tab is a work in progress.
Your Internet help desk may ask you for the information below.
Dual Stack - but no Quad-A's (AAAA's)
IPv4: Good, AS12871 - NL-CONCEPTS Concepts ICT Autonomous System
IPv6: no
IPv4 address: *.*.*.*
IPv6 address: 2001:****:**15:***9::3

edit3: Got it! Changed the IPv4 DNS-server of the physical LAN-interface to the ones from Google. Now everything seems to work

[mpetch]

Many browsers implement what is called 'Happy Eyeballs', and if they get replies from v4 first, they'll prefer that.  ipv6.tunnelbroker.net is an IPv6-only site, so Happy Eyeballs can't enter into it.

This isn't necessarily true. With Happy Eyeball if both IPv6 and IPv4 respond then preference is given to the one that has higher precedence in the policy table (RFC 3484) on the client. The policy order is inferred by the order of IP addresses that are obtained by the call to resolve the DNS names (ie. getaddrinfo() ). If getaddrinfo() returns a list of IPv4 and IPv6 addresses and the first one is IPv4 then the preference is given to IPv4. If an IPv6  address is returned at the top of the list through getaddrinfo() then it takes precedence if both IPv4 and IPv6 attempts succeed. On most dual stacked systems IPv6 is generally (not always) given priority to IPv4, and of course the default tables can usually be overridden by an administrator/user on the client.

If a stateful Happy Eyeballs system is created then if either IPv6 or IPv4 are found to not be responding on prior attempts it may override the behaviour mentioned above.

[kcochran]

OS X Lion and above have a stateful Happy Eyeballs implementation for applications using CFSocket/NSSocketStream.  Routing metrics persist for their dual stack connectivity attempts.

As many major browsers implement their own resolver libraries as well, they might not entirely follow the OS getaddrinfo() configuration.  As noted at https://labs.ripe.net/Members/emileaben/hampered-eyeballs, Chrome, when it sees a AAAA and an A, will try the AAAA, set a 300ms timer on the connect(), and fire off a v4 connect() if the v6 hasn't returned, then will handle whichever one succeeds.  This would appear to be regardless of any gai() preferences.

[mpetch]

OS X Lion and above have a stateful Happy Eyeballs implementation for applications using CFSocket/NSSocketStream.  Routing metrics persist for their dual stack connectivity attempts.

You need to read more closely what Apple said (in the quote at your link below) "CF and NS layer frameworks that use CFSocketStream do not use getaddrinfo.
Those APIs use something similar to happy eyeballs.". Something similar IS not happy eyeballs, but they are trying to resolve a similar issue. Happy eyeballs is actually an internet standard with its own RFC (6555) and it can be read here: http://tools.ietf.org/html/rfc6555 . Apple's algorithm is considerably different than that of the RFC so I see why they didn't say they actually implemented Happy Eyeballs. I have recently implemented Happy Eyeballs for one open source product I work on (GNUBG) so I am well versed in RFC 6555.

As many major browsers implement their own resolver libraries as well, they might not entirely follow the OS getaddrinfo() configuration.

Happy Eyeballs has no dependency on getaddrinfo(), and my original post to you said "ie. getaddrinfo()" IE. meaning example. A lot of software now uses getaddrinfo and it is among the base specifications for many OSes (including  Windows, Linux/Unix/BSD etc). gettaddrinfo can return a list of IP addresses (or any address family for that matter) in an order preferred by the underlying OS (And that is usually based upon some policy tables).

What Happy Eyeballs does need to run properly is a list (however generated) of IP addresses in an ORDER that is preferred by the underlying OS. Failure to get a reasonable list can make a proper Happy Eyeballs implementation problematic.

You said:

As noted at https://labs.ripe.net/Members/emileaben/hampered-eyeballs, Chrome, when it sees a AAAA and an A, will try the AAAA, set a 300ms timer on the connect(), and fire off a v4 connect() if the v6 hasn't returned, then will handle whichever one succeeds.  This would appear to be regardless of any gai() preferences.

and your original message said:

Many browsers implement what is called 'Happy Eyeballs', and if they get replies from v4 first, they'll prefer that

This still isn't true, and not what Happy Eyeballs RFC actually requires and not even what Chrome does in all cases. In the article you linked to there was a quote that came from chromium SVN repository which said this:

When a hostname has both IPv6 and IPv4 addresses, and the IPv6 address is listed first, we start a timer (300ms) [...]. If the timer fires, that means the IPv6 connect() hasn't completed yet, and we start a second socket connect() where we give it the same AddressList, except we move all IPv6 addresses that are in front of the first IPv4 address to the end. That way, we will use the first IPv4 address. We will race these two connect()s and pass the first one to complete to ConnectJob::set_socket()

Chrome's default host resolver uses getaddrinfo as seen in this code: https://chromium.googlesource.com/chromium/src/net/+/44f223940ff866d0ff2a0c59fd04fd1598172957/dns/host_resolver_proc.cc . This code applies to the default host resolver on OS/X, Windows, BSD, Linux, Unix Chrome builds.

What we care about is that the list has some order where the first IP address is of the preferred family type that we wish to query. With such a list this is what happens in recent Chrome and Mozilla code bases:

  1.  Call getaddinfo(), which returns a list of IP addresses sorted by
       the host's address preference policy.

   2.  Initiate a connection attempt with the first address in that list
       (e.g., IPv6).

   3.  If that connection does not complete within a short period of
       time (Firefox and Chrome use 300 ms), initiate a connection
       attempt with the first address belonging to the other address
       family (e.g., IPv4).

   4.  The first connection that is established is used.  The other
       connection is discarded.

It just so happens that RFC 6555 was amended last year and that algorithm snippet came from the RFC 6555 link I posted earlier. That is pretty much what the Chrome code for Happy Eyeballs does if you review the Chromium code in SVN.

So if multiple IP addresses are returned and there is an AAAA record first it will connect to the IPv6 address first. After 300ms it then attempts for the other address family (IPv4) and tries the first A record. If however an A record is first it tries that first (for 300ms) and then attempts the other addressl family (IPv6) next.

Order of the list passed to a Happy Eyeballs implementation matters for an effective implementation. Which address family is preferred is determined by Happy Eyeballs by examining the type of record in the FIRST entry.