|
applications preference for IPv4 or IPv6 (tunnel or 6to4)
![[be]](/s/countries/be.gif) Carmen Sandiego on Monday, 25 June 2007 16:19:58
Gegroet,
I have been trying out all ways to use IPv6, and one of the things I wanted to try was 6to4.
The configuration of IPv6 6to4 is not the problem and the basic tools (ping6, traceroute6) all work OK.
However, I noticed that -when connected using 6to4- my applications (telnet, ftp, firefox, ...) do not use IPv6 unless I "force" them to use IPv6 (e.g. when doing "telnet -6 hostname").
When I am connected to the IPv6 backbone using a tunneled system (like sixxs), these same applications DO default to IPv6 without spectial option-settings.
Some additional remarks:
- Using tcpdump, I found that these applications (like telnet) actually DO do a DNS-query for both the "AAAA" and the "A" record and the DNS-answer is OK.
- I also compaired the setting of "sysctl" in either mode and they are the same (except for the additional interfaces which are created on demand of course).
So, why do these applications not use IPv6 by default when using a 6to4 configuration?
What exactly is it that triggers preference of IPv6 over IPv4 in these applications and why does my system behave differently when using 6to4 over when using a tun-interface to sixxs or GO6?
BTW. The system is ubuntu feisty, 2.6.20-16-generic kernel on i686.
Cheerio! Kr. Bonne.
applications preference for IPv4 or IPv6 (tunnel or 6to4)
![[de]](/s/countries/de.gif) Shadow Hawkins on Monday, 25 June 2007 15:32:54
Perhaps the same glibc related problem like <https://noc.sixxs.net/forum/?msg=apps-537249>?
Which libc6 Version you are using?
applications preference for IPv4 or IPv6 (tunnel or 6to4)
Carmen Sandiego on Monday, 25 June 2007 16:09:48
Stoyan,
The version of libc is 2.5-0ubuntu14, so it might be affected by this bug, althou I don't think so.
The issue of that bug is that it prefers IPv4 over IPv6 because the IPv4 IP-address was "directly connected".
This is not the case here as the hosts are on the internet (e.g. www.ripe.net or www.ipv6;surfnet.nl, two hosts which show you your IP-address so you can check if you are connecting using IPv4 or IPv6).
Cheerio! Kr. Bonne.
applications preference for IPv4 or IPv6 (tunnel or 6to4)
(Btw, do not mix up 6to4 (RFC3056) with what SixXS actually provides: AYIYA, Proto-41 and Proto-41-heartbeat tunnels)
6to4 is seen as 'inferior' connectivity wise. Thus when glibc (and other DNS resolvers) ask for a hostname for an application it will ask for AAAA and A records for that hostname. When the source or target of the connection is in 2002::/16 it will be considered _after_ IPv4 as the connection is going over IPv4 anyway. Using 6to4 would thus be more costly, requiring the data to be tunneled, while the endresult is the same: a connection from A to B.
See also RFC 3484 on Linux which also learns you that you can tweak this using /etc/gai.conf.
applications preference for IPv4 or IPv6 (tunnel or 6to4)
Carmen Sandiego on Monday, 25 June 2007 21:36:41
Hi Jeroen,
Very interesting information. Thanks!
The way I see it from an ISP point-of-view, 6to4 would be interesting as it would allow it to migrate one leg of the network (the part from the end-user to the central backbone) to IPv6, with relative little configuration.
I've seen that the apple airport extreme now supports IPv6 6-to-4 (and it is enabled by default) so if you would the same thing for other CPE-routers, it would introduce IPv6 on the customer local network (and her computer) quite easily.
If we would then install a couple 6-to-4 gateways in the core backbone and announce specific prefixes of the 2002:xxxx:yyyy::/zz domain in the IPv6 BGP matric (where xxyy:yyyy would match the IPv4 subnets we currently own), this would enable us to limit the "tunnel"ed part as much as possible.
Do you have any information on how other OSs behave? Does windows and mac follow the same rule (I guess macOS does not as this would be counter-productive for apples efforts to implement IPv6 using 6to4 on their airport extreme).
Cheerio! Kr. Bonne.
applications preference for IPv4 or IPv6 (tunnel or 6to4)
Carmen Sandiego on Monday, 25 June 2007 22:36:44
Hi Jeroen,
I just did some additional tests and it seams to be a different issue.
I just set up my laptop (ubuntu) for 6to4 as gateway for my local LAN, with my old computer (running the same version of ubuntu) as client.
The second computer got its IP-address over the LAN from the router announcement from my laptop.
And, on that computer, the application (firefox, telnet, ftp, ...) all now do take the IPv6 connection.
So I guess the issue is not related to a pure "IP-address preference" as this applies just as much for my "gateway" machine as for the other computer. But they seams to act differently, althou they run exactly the same version of ubuntu.
So it must be something else; perhaps due to the fact that the "gateway" computer has two different "outbound" interfaces (ppp0 for IPv4 and sit0 for IPv6). I'll experiment a little more.
Cheerio! Kr. Bonne.
applications preference for IPv4 or IPv6 (tunnel or 6to4)
You are correct 6to4 is a relatively good mechanism for that scenario and that is the scenario that it was made for.
BUT more specifics for 2002::/16 are *NOT* allowed. If those are seen you will be shot on site. This is mostly to avoid having the IPv6 BGP tables get flooded with the 200k entries from the IPv4 tables.
You can limit how far your 2002::/16 and 192.88.99.1 propagate in BGP, but that is it. Most likely you will be providing a service to other users too, and this might cause you to become a redirect for traffic to bandwidth heavy sites like newszilla6.xs4all.nl :)
All OS's should behave like the above method, some do not have it implemented fully yet though. It should nevertheless not cause any major issues. The bigger problem is when the IPv6 connectivity is available but broken, then it tends to result into timeouts because it actually not works, and that results in annoyed customers who only think that IPv6 is slow and broken, thus they disable it. Which is another point, people have to enable IPv6 on XP for it to work.
One of the largest drawbacks of 6to4, or more-over protocol-41 in general is that it is NAT unfriendly. Most people are using a NAT on their CPE, and as those CPE's don't support IPv6 in most cases (unless you use eg OpenWRT/DD-WRT etc on those platforms) one either has to upgrade the CPE or do some protocol-forwarding to a host that understands IPv6 tunnels. This is all very tricky though, which is why mechanisms like Teredo exist. Or for the Tunnel Broker world: AYIYA and Hexago's 6udp4 (TSP spec).
applications preference for IPv4 or IPv6 (tunnel or 6to4)
Carmen Sandiego on Tuesday, 26 June 2007 22:57:10
Jeroen,
I understand the argument of an explosion of IPv6 prefixes in the BGP routing-table, I -as a ISP engineer- have another responability.
For 6to4 traffic to non-2002 IPv6 addresses, you need to go over a 6to4 relay so I consider the "relays" as "part of the service". As a ISP engineer, I want the traffic of my customer to go over MY boxes, where I can intervene in case of problems and which are MY responsability.
Now, by annoucing the 192.88.99.1 anycase IP-address in the internal routing table, I can force the traffic of my customers to go over my own boxes, but for the return traffic things are different.
If I would (e.g.) account a IPv6 BGP-prefix of (say) 2002:81f4::/30 (which matches, 81.244.0.0/14, one of out prefixes) I could force the return traffic to my "6to4 users" to MY box.
As the situation is now, traffic from a non-2002 IPv6 address to a 6-to-4 user of me will go over "some" 6to4 relay, somewhere on the internet, where I have absolutely no control over.
Even worse, as there are multiple 6to4 relays on the internet, I have absolutely no idea which one is used for this particular connection so I have no idea who I should complain to if one of my customers come to me complaining his IPv6-connections are bad/slow/whatever, ...
One example:
yesterday I noticed that when I use the 6to4 relay at fh-regensburg.de instead of the default 192.88.99.1 anycase IP-address, certain websites could not be reached.
After doing some checks, I traced down the problem to a MTU-size issue, .. well .. I guess it is that as the 6to4 relay of fh-regensburg does not reply to pings (not in V4, nor in V6) so I'm not really sure about this.
Now, this was indeed a problem in the "forward" path and not in the "return" path (so could be solved by annoucements of 192.88.99.1 in the internal routing matrix), but the basic argument stays the same: If a service is effects the overall quality delived to my customers, I want to be in control of that service/box/...
As you said yourself, the IPv6 connectivity needs to be good, or people will just disable it.
Cheerio! Kr. Bonne.
applications preference for IPv4 or IPv6 (tunnel or 6to4)
If you want "Good IPv6 Connectivity" then simply do NOT rely on 6to4 or Teredo as, due to their design, the path of the traffic is completely unknown.
That is why other mechanisms exist which can help you out. You might also want to look into ISATAP which might solve that problem, or the usage of TSP or TIC.
As for you wanting to announce more specifics in 2002::/16, RFC3056 clearly covers this on page 10/11, section 5.2:
--------------------------------------------------------
3. A relay router MUST advertise a route to 2002::/16 into the native
IPv6 exterior routing domain. It is a matter of routing policy how
far this routing advertisement of 2002::/16 is propagated in the
native IPv6 routing system. Since there will in general be multiple
relay routers advertising it, network operators will require to
filter it in a managed way. Incorrect policy in this area will lead
to potential unreachability or to perverse traffic patterns.
6to4 prefixes more specific than 2002::/16 must not be propagated in
native IPv6 routing, to prevent pollution of the IPv6 routing table
by elements of the IPv4 routing table. Therefore, a 6to4 site which
also has a native IPv6 connection MUST NOT advertise its 2002::/48
routing prefix on that connection, and all native IPv6 network
operators MUST filter out and discard any 2002:: routing prefix
advertisements longer than /16.
----------------------------------------------------------
Note the explicit MUST in there. As you see it also notes that more specifics MUST be filtered and this is also what is happening as no more specific 6to4 prefix has been seen in a long time (there was one but that went away really quickly after they didn't respond and got depeered by their upstream).
|
![[ch]](/s/countries/ch.gif)
on Monday, 25 June 2007 18:10:35
Posting is only allowed when you are