ArchiveOrangemail archive

Discussion about IPv6 in Mac OS X


ipv6-dev.lists.apple.com
(List home) (Recent threads) (100 other Apple lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 657 messages, beginning Nov 2009
  • 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Lion and IPv6

Ad
Andre-John Mas 1311258313Thu, 21 Jul 2011 14:25:13 +0000 (UTC)
Hi,

Has anyone played around with IPv6 since installing Lion. Any interesting observations?

Andre _______________________________________________
Do not post admin requests to the list. They will be ignored.
Ipv6-dev mailing list      
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/ipv6-d...

This email sent to 
Jeroen Massar 1311260248Thu, 21 Jul 2011 14:57:28 +0000 (UTC)
On 2011-07-21 16:24 , Andre-John Mas wrote:
> Hi,
> 
> Has anyone played around with IPv6 since installing Lion. Any interesting observations?See: http://lists.cluenet.de/pipermail/ipv6-ops/20...

Or the summary: IPv6 stack is much newer, but some stuff is broken....

Greets,
 Jeroen
Josh Graessley 1311266039Thu, 21 Jul 2011 16:33:59 +0000 (UTC)
On Jul 21, 2011, at 7:24 AM, Andre-John Mas wrote:

> Has anyone played around with IPv6 since installing Lion. Any interesting observations?There are some significant changes in Lion.

Results from getaddrinfo are now sorted using routing statistics (destination with the lowest min round trip time wins). If the statistics can not determine which destination is better, an implementation of RFC3484 is used. The default RFC3484 policy is read only.

CF and NS layer frameworks that use CFSocketStream do not use getaddrinfo. Those APIs use something similar to happy eyeballs. The A and AAAA queries are started at the same time but the responses are handled as they are received. When an answer is received, it is sorted in to a list of destination addresses. If there are no more addresses coming in (this was the last answer in the DNS packet or mDNSResponder has no more answers in the cache), a connection is started to the first destination on the sorted list. The DNS resolve operation is left running and more answers are processed as they arrive. A timer is setup for a period of time in which we would expect the connection to complete, based on the routing statistics. If the timer fires before the connection is established, a connection to the next best address will be started while the existing connection continues to try and make progress. A similar timer is setup and the process repeats until a connection is established or we run out of addresses to try. The code keeps track of whether or not it has received both A and AAAA response (whether the answer was a list of addresses or no address). If the connection is established before both A and AAAA responses come back, the resolve is kept open for up to a second to allow mDNSResponder to receive a slow response and store it in the cache. This way, subsequent connections to the same host in a short period of time will have all answers in the cache.

Most users that aren't on this list don't care if they connect over IPv4 or IPv6. They just care that they connect. The code in CF and NS aims to make sure the user always gets a connection quickly. The code above also addresses issues where a AAAA response is never received (doesn't hold up connecting to IPv4) and issues where the user has some busted equipment that sends routing advertisements for a prefix even though the equipment has no way to route IPv6 traffic. The trade off is that it may be hard to predict whether a connection will occur over IPv6 or IPv4. If an option were added to prefer one address family over the other, it would need to indicate how much longer the user was willing to wait to get the address family of their choice.

You can use the command line tool "nettop -n -m route" to dump a live view of the routing statistics. You can use "nettop -n" to dump a live view of all TCP and UDP sockets on the system.

-josh
Jeroen Massar 1311266825Thu, 21 Jul 2011 16:47:05 +0000 (UTC)
On 2011-07-21 18:32 , Josh Graessley wrote:
> 
> On Jul 21, 2011, at 7:24 AM, Andre-John Mas wrote:
> 
>> Has anyone played around with IPv6 since installing Lion. Any
>> interesting observations?
> 
> There are some significant changes in Lion.
> 
> Results from getaddrinfo are now sorted using routing statistics
> (destination with the lowest min round trip time wins). If the
> statistics can not determine which destination is better, an
> implementation of RFC3484 is used. The default RFC3484 policy is read
> only.Is there a way to either:
 - turn the routing stats check off
 - always prefer IPv6 over IPv4?

It is a neat trick but it is annoying if one wants to connect per
default to an IPv6 host just like every other OS does.

Now if the metric was 'there is a lot of broken/slow IPv6 connections'
then I would fully agree to also start depreffing IPv6.

The fun thing is that both Safari & Chrome always lend up on the IPv6
side, while simple 'ssh' does not.

Greets,
 Jeroen
Rui Paulo 1311268508Thu, 21 Jul 2011 17:15:08 +0000 (UTC)
On Jul 21, 2011, at 9:46 AM, Jeroen Massar wrote:

> On 2011-07-21 18:32 , Josh Graessley wrote:
>> 
>> On Jul 21, 2011, at 7:24 AM, Andre-John Mas wrote:
>> 
>>> Has anyone played around with IPv6 since installing Lion. Any
>>> interesting observations?
>> 
>> There are some significant changes in Lion.
>> 
>> Results from getaddrinfo are now sorted using routing statistics
>> (destination with the lowest min round trip time wins). If the
>> statistics can not determine which destination is better, an
>> implementation of RFC3484 is used. The default RFC3484 policy is read
>> only.
> 
> Is there a way to either:
> - turn the routing stats check off
> - always prefer IPv6 over IPv4?
> 
> It is a neat trick but it is annoying if one wants to connect per
> default to an IPv6 host just like every other OS does.
> 
> Now if the metric was 'there is a lot of broken/slow IPv6 connections'
> then I would fully agree to also start depreffing IPv6.
> 
> The fun thing is that both Safari & Chrome always lend up on the IPv6
> side, while simple 'ssh' does not.Before running ssh to the host, please try to run 'dns-sd -G v4v6 <host>'. This will populate the DNS cache with the IPv4 + IPv6 address. You should then be able to ssh via IPv6 now.
ssh should use the first address found so that it establishes a connection faster. If you want to use IPv6 only you need to:
1) populate the cache (use dns-sd or ssh)
2) use ssh -6

Note that the first connection, even if it goes through v4, should populate the DNS cache.

Regards,--
Rui Paulo
Rui Paulo 1311269415Thu, 21 Jul 2011 17:30:15 +0000 (UTC)
On Jul 21, 2011, at 10:13 AM, Rui Paulo wrote:

> On Jul 21, 2011, at 9:46 AM, Jeroen Massar wrote:
> 
>> On 2011-07-21 18:32 , Josh Graessley wrote:
>>> 
>>> On Jul 21, 2011, at 7:24 AM, Andre-John Mas wrote:
>>> 
>>>> Has anyone played around with IPv6 since installing Lion. Any
>>>> interesting observations?
>>> 
>>> There are some significant changes in Lion.
>>> 
>>> Results from getaddrinfo are now sorted using routing statistics
>>> (destination with the lowest min round trip time wins). If the
>>> statistics can not determine which destination is better, an
>>> implementation of RFC3484 is used. The default RFC3484 policy is read
>>> only.
>> 
>> Is there a way to either:
>> - turn the routing stats check off
>> - always prefer IPv6 over IPv4?
>> 
>> It is a neat trick but it is annoying if one wants to connect per
>> default to an IPv6 host just like every other OS does.
>> 
>> Now if the metric was 'there is a lot of broken/slow IPv6 connections'
>> then I would fully agree to also start depreffing IPv6.
>> 
>> The fun thing is that both Safari & Chrome always lend up on the IPv6
>> side, while simple 'ssh' does not.
> 
> Before running ssh to the host, please try to run 'dns-sd -G v4v6 <host>'. This will populate the DNS cache with the IPv4 + IPv6 address. You should then be able to ssh via IPv6 now.
> ssh should use the first address found so that it establishes a connection faster.Just need to clarify this point: getaddrinfo() will wait for a while to get more addresses and will then sort them. If the addresses are not in mDNSResponder's cache, getaddrinfo() will never know about it. By manually populating the cache, we can identify where the problem lies.

Regards,--
Rui Paulo
Jeroen Massar 1311277625Thu, 21 Jul 2011 19:47:05 +0000 (UTC)
On 2011-07-21 19:13 , Rui Paulo wrote:
[..]

> Before running ssh to the host, please try to run 'dns-sd -G v4v6
> <host>'. This will populate the DNS cache with the IPv4 + IPv6
> address. You should then be able to ssh via IPv6 now. ssh should use
> the first address found so that it establishes a connection faster.Still goes over IPv4, even though it is in the cache (as can be seen
with a kill -SIGINFO to mDNSResolver)> If you want to use IPv6 only you need to:
> 1) populate the cache (use dns-sd or ssh)
> 2) use ssh -6
>
> Note that the first connection, even if it goes through v4, should
> populate the DNS cache.But every connection after will also go over IPv4 it seems unless I use
"-6" or "AddressFamily inet6", but that is not really optimal.

Note that there is nearly no latency difference on a local ethernet
connection to a host, still IPv4 gets picked (unless -6 given...)

Greets,
 Jeroen
Rui Paulo 1311278328Thu, 21 Jul 2011 19:58:48 +0000 (UTC)
On Jul 21, 2011, at 12:46 PM, Jeroen Massar wrote:

> On 2011-07-21 19:13 , Rui Paulo wrote:
> [..]
> 
>> Before running ssh to the host, please try to run 'dns-sd -G v4v6
>> <host>'. This will populate the DNS cache with the IPv4 + IPv6
>> address. You should then be able to ssh via IPv6 now. ssh should use
>> the first address found so that it establishes a connection faster.
> 
> Still goes over IPv4, even though it is in the cache (as can be seen
> with a kill -SIGINFO to mDNSResolver)
> 
>> If you want to use IPv6 only you need to:
>> 1) populate the cache (use dns-sd or ssh)
>> 2) use ssh -6
>> 
>> Note that the first connection, even if it goes through v4, should
>> populate the DNS cache.
> 
> But every connection after will also go over IPv4 it seems unless I use
> "-6" or "AddressFamily inet6", but that is not really optimal.
> 
> Note that there is nearly no latency difference on a local ethernet
> connection to a host, still IPv4 gets picked (unless -6 given...)Ok, so I guess what's happening here is what Josh described. Can you check if nettop -m route shows a better rtt for the IPv4 destination that the IPv6 destination?

Regards,--
Rui Paulo
Josh Graessley 1311272417Thu, 21 Jul 2011 18:20:17 +0000 (UTC)
On Jul 21, 2011, at 9:46 AM, Jeroen Massar wrote:

> On 2011-07-21 18:32 , Josh Graessley wrote:
>> 
>> On Jul 21, 2011, at 7:24 AM, Andre-John Mas wrote:
>> 
>>> Has anyone played around with IPv6 since installing Lion. Any
>>> interesting observations?
>> 
>> There are some significant changes in Lion.
>> 
>> Results from getaddrinfo are now sorted using routing statistics
>> (destination with the lowest min round trip time wins). If the
>> statistics can not determine which destination is better, an
>> implementation of RFC3484 is used. The default RFC3484 policy is read
>> only.
> 
> Is there a way to either:
> - turn the routing stats check offNo.

> - always prefer IPv6 over IPv4?

No.

-josh
Tore Anderson 1311319165Fri, 22 Jul 2011 07:19:25 +0000 (UTC)
* Josh Graessley

> There are some significant changes in Lion.

This is fantastic news!

Congratulations and thanks to you, James Woodyatt, and everyone else
involved in implementing all of these improvements. It appears to me
that Mac OS X has in a very short while gone from being the worst
problem child of them all (<= 10.6.4) to being the best in class when it
comes to providing an optimal user experience for dual-stacked users
and/or services. Outstanding indeed!

One question, though: Will these improvements find their way into iOS as
well? In particular I can imagine they would nicely fix the bug where
the iOS browser throws an error message and gives up after about 60
seconds, when attempting to connect to a dual-stacked destination from a
network where IPv6 is present, but does not work. This prevents
fail-over to working IPv4 from ever occurring (see bug #8702877).

Best regards,-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
Josh Graessley 1311352653Fri, 22 Jul 2011 16:37:33 +0000 (UTC)
On Jul 22, 2011, at 12:18 AM, Tore Anderson wrote:

> * Josh Graessley
> 
>> There are some significant changes in Lion.
> 
> This is fantastic news!
> 
> Congratulations and thanks to you, James Woodyatt, and everyone else
> involved in implementing all of these improvements. It appears to me
> that Mac OS X has in a very short while gone from being the worst
> problem child of them all (<= 10.6.4) to being the best in class when it
> comes to providing an optimal user experience for dual-stacked users
> and/or services. Outstanding indeed!
> 
> One question, though: Will these improvements find their way into iOS as
> well? In particular I can imagine they would nicely fix the bug where
> the iOS browser throws an error message and gives up after about 60
> seconds, when attempting to connect to a dual-stacked destination from a
> network where IPv6 is present, but does not work. This prevents
> fail-over to working IPv4 from ever occurring (see bug #8702877).Thank you Tore.

We can only discuss publicly available iOS builds. As soon as there's a new publicly available iOS build, please ping us ;)

If you have an iOS developer account you can discuss any software that may be in beta on the devforums:
https://devforums.apple.com/community/ios/ios...

-josh
Sabahattin Gucukoglu 1311370767Fri, 22 Jul 2011 21:39:27 +0000 (UTC)
On 21 Jul 2011, at 19:32, Josh Graessley wrote:
> Most users that aren't on this list don't care if they connect over IPv4 or IPv6. They just care that they connect. The code in CF and NS aims to make sure the user always gets a connection quickly. The code above also addresses issues where a AAAA response is never received (doesn't hold up connecting to IPv4) and issues where the user has some busted equipment that sends routing advertisements for a prefix even though the equipment has no way to route IPv6 traffic. The trade off is that it may be hard to predict whether a connection will occur over IPv6 or IPv4. If an option were added to prefer one address family over the other, it would need to indicate how much longer the user was willing to wait to get the address family of their choice.I'm not sure this works for me.  If we expect that IPv4 will degrade over time, doesn't it follow that the default should be a preference for IPv6 with a short timeout (I'd use 250 ms)?  Otherwise Mac systems will contribute to the degradation as long as IPv4 continues to be faster, while not assisting IPv6 until the time comes for it to be preferable to an already intolerably slow IPv4.  We shouldn't just penalise whichever is the slower.  We do expect that tunnels and transition mechanisms will be penalised as well, even when it's not under user control (EG third-party broker, ISP-supplied 6rd prefix).

But then again, users are users.

Cheers,
Sabahattin
Josh Graessley 1311371715Fri, 22 Jul 2011 21:55:15 +0000 (UTC)
On Jul 22, 2011, at 2:39 PM, Sabahattin Gucukoglu wrote:

> On 21 Jul 2011, at 19:32, Josh Graessley wrote:
>> Most users that aren't on this list don't care if they connect over IPv4 or IPv6. They just care that they connect. The code in CF and NS aims to make sure the user always gets a connection quickly. The code above also addresses issues where a AAAA response is never received (doesn't hold up connecting to IPv4) and issues where the user has some busted equipment that sends routing advertisements for a prefix even though the equipment has no way to route IPv6 traffic. The trade off is that it may be hard to predict whether a connection will occur over IPv6 or IPv4. If an option were added to prefer one address family over the other, it would need to indicate how much longer the user was willing to wait to get the address family of their choice.
> 
> I'm not sure this works for me.  If we expect that IPv4 will degrade over time, doesn't it follow that the default should be a preference for IPv6 with a short timeout (I'd use 250 ms)?  Otherwise Mac systems will contribute to the degradation as long as IPv4 continues to be faster, while not assisting IPv6 until the time comes for it to be preferable to an already intolerably slow IPv4.  We shouldn't just penalise whichever is the slower.  We do expect that tunnels and transition mechanisms will be penalised as well, even when it's not under user control (EG third-party broker, ISP-supplied 6rd prefix).
> 
> But then again, users are users.Could you elaborate on what you mean by:

> Mac systems will contribute to the degradation as long as IPv4 continues to be faster.

In what way is using IPv4 when it is faster than IPv6 a "degradation"?

The decision to always prefer IPv6 over IPv4 is, in my opinion, hampering efforts to migrate to IPv6. IPv6 day is a great example. Why was it just a day? A lot of users that have IPv6 connectivity have crummy connectivity or completely broken networks with no IPv6 connectivity despite the fact there's a device on their network advertise a default route and prefix. Companies that want to provide AAAA answers and IPv6 connectivity to their services will be penalized by clients that always prefer IPv6. The end user perception of companies that support IPv6 will be that those companies are slower than their competitors that have only IPv4 connectivity. The user doesn't realize the fault is with their own internet connection or their computer that keeps insisting on using IPv6 over IPv4.

Modifying Mac OS to be better about selecting the best protocol given the current situation will prevent companies from being penalized for providing services over IPv6. As supporting IPv6 will no longer put a companies at a competitive disadvantage, they will be more inclined to deploy IPv6.

-josh
Iljitsch van Beijnum 1311377050Fri, 22 Jul 2011 23:24:10 +0000 (UTC)
On 22 jul 2011, at 23:54, Josh Graessley wrote:

> The decision to always prefer IPv6 over IPv4 is, in my opinion, hampering efforts to migrate to IPv6.I'm sorry, but you guys seriously screwed the pooch on this. Believe me that I'm being much more polite that I feel like being here.

People who build networks can't do an effective job if OSes are second guessing them every step of the way. With a "read only RFC 3484 policy table" to boot. In other words: the OS always knows better, admistrators can go [...] themselves.

This is what you get when software engineers make decisions about networking.

> IPv6 day is a great example. Why was it just a day? A lot of users that have IPv6 connectivity have crummy connectivity or completely broken networks with no IPv6 connectivity

Untrue. I think the press and blogosphere managed to scare up ONE twitter post with someone having problems. Virtually zero problems were reported.

In the mean time I've been living with an OS that couldn't run IPv6 only for two years because Apple engineers felt the need to be the smartest guy in the room.

> Companies that want to provide AAAA answers and IPv6 connectivity to their services will be penalized by clients that always prefer IPv6.

Ok, here's some networking bootcamp: networks break all the time because there are always at least two sides running different hard/software under different administrative domains involved. Building a network that isn't used under routine circumstances means that the network won't work when it's finally called upon to do something.

So enabling IPv6, not using it, and then expecting it to work when finally IPv4 goes away (by design or by accident) is setting yourself up for a huge disaster.

Nobody is forcing anyone to enable IPv6 today. But it's imperative that those of us who build and test networks get to use IPv6 so we can see where it doesn't work and fix it so it DOES work when the masses arrive.
Sander Steffann 1311377239Fri, 22 Jul 2011 23:27:19 +0000 (UTC)
Hi,

> Modifying Mac OS to be better about selecting the best protocol given the current situation will prevent companies from being penalized for providing services over IPv6. As supporting IPv6 will no longer put a companies at a competitive disadvantage, they will be more inclined to deploy IPv6.

I don't know is 'lowest rtt' == 'best protocol' in all situations, but it definitely helps. For the near future the same service should be offered over both IPv4 and IPv6 and it should make no difference to the user which one is used. I like it that Mac OS tries to choose the best experience for the user. And as soon as IPv4 becomes slower because of all the NATs it will use more and more IPv6.

For debugging, collecting statistics etc. it makes life a bit more difficult. It will take a bit more effort. But we should optimize for user experience and not for debugging…

- Sander
Sabahattin Gucukoglu 1311382762Sat, 23 Jul 2011 00:59:22 +0000 (UTC)
On 23 Jul 2011, at 00:54, Josh Graessley wrote:
> On Jul 22, 2011, at 2:39 PM, Sabahattin Gucukoglu wrote:
>> On 21 Jul 2011, at 19:32, Josh Graessley wrote:
>>> Most users that aren't on this list don't care if they connect over IPv4 or IPv6. They just care that they connect. The code in CF and NS aims to make sure the user always gets a connection quickly. The code above also addresses issues where a AAAA response is never received (doesn't hold up connecting to IPv4) and issues where the user has some busted equipment that sends routing advertisements for a prefix even though the equipment has no way to route IPv6 traffic. The trade off is that it may be hard to predict whether a connection will occur over IPv6 or IPv4. If an option were added to prefer one address family over the other, it would need to indicate how much longer the user was willing to wait to get the address family of their choice.
>> 
>> I'm not sure this works for me.  If we expect that IPv4 will degrade over time, doesn't it follow that the default should be a preference for IPv6 with a short timeout (I'd use 250 ms)?  Otherwise Mac systems will contribute to the degradation as long as IPv4 continues to be faster, while not assisting IPv6 until the time comes for it to be preferable to an already intolerably slow IPv4.  We shouldn't just penalise whichever is the slower.  We do expect that tunnels and transition mechanisms will be penalised as well, even when it's not under user control (EG third-party broker, ISP-supplied 6rd prefix).
>> 
>> But then again, users are users.
> 
> Could you elaborate on what you mean by:
> 
>> Mac systems will contribute to the degradation as long as IPv4 continues to be faster.
> 
> In what way is using IPv4 when it is faster than IPv6 a "degradation"?It means that if there is contention for IPv4 access, EG NATs, OS X will just add to the load, not ease it over to IPv6.  Effectively, you just change the situation from "Very fast and slow" to "Somewhat slow and slow".  Given what we know about the likely advance of address sharing, this seems rather unfortunate.  Of course, right now, that is today, that's not the case.

> The decision to always prefer IPv6 over IPv4 is, in my opinion, hampering efforts to migrate to IPv6. IPv6 day is a great example. Why was it just a day? A lot of users that have IPv6 connectivity have crummy connectivity or completely broken networks with no IPv6 connectivity despite the fact there's a device on their network advertise a default route and prefix. Companies that want to provide AAAA answers and IPv6 connectivity to their services will be penalized by clients that always prefer IPv6. The end user perception of companies that support IPv6 will be that those companies are slower than their competitors that have only IPv4 connectivity. The user doesn't realize the fault is with their own internet connection or their computer that keeps insisting on using IPv6 over IPv4.

I understand the thinking, but this solution provides absolutely no positive influence in the direction of IPv6.  A 250 ms upper bound doesn't seem like much to offset the problems caused by IPv6 brokenness (if done right), and it puts the burden of traffic where it belongs, on IPv6, where the work is expected to be done to improve the network, to positive outcome that is vastly greater than any IPv4 LSN environment.

> Modifying Mac OS to be better about selecting the best protocol given the current situation will prevent companies from being penalized for providing services over IPv6. As supporting IPv6 will no longer put a companies at a competitive disadvantage, they will be more inclined to deploy IPv6.

The flip side of the coin, of course, is that because there is no *disadvantage* to not deploying IPv6, companies will continue to endure an IPv4-only presence, and will expect the network of NATs to solve their problems for them.  I hope we can both agree that this is a very, very bad thing.

Cheers,
Sabahattin
Tore Anderson 1312372069Wed, 03 Aug 2011 11:47:49 +0000 (UTC)
* Josh Graessley> Results from getaddrinfo are now sorted using routing statistics
> (destination with the lowest min round trip time wins). If the
> statistics can not determine which destination is better, an
> implementation of RFC3484 is used. The default RFC3484 policy is read
> only.Hi Josh,

I've played a bit around with Lion now, and from what I can tell it
appears that connection failures aren't recorded as an infinite RTT. I'm
synthesizing «IPv6 brokenness» by dropping all IPv6 traffic to
www.ripe.net in an upstream router here:

$ ./gai-test www.ripe.net; ./gai-test www.ripe.net
[         0us] begin gai_and_connect(www.ripe.net)
[+   367864us] getaddinfo(www.ripe.net) done
[+       41us] dest = 2001:67c:2e8:22::c100:68b (AF_INET6)
[+        9us] about to connect()
[+ 75275031us] connect() fails: Operation timed out
[+       75us] dest = 193.0.6.139 (AF_INET)
[+        8us] about to connect()
[+    23164us] connect() suceeds

[         0us] begin gai_and_connect(www.ripe.net)
[+     2715us] getaddinfo(www.ripe.net) done
[+       27us] dest = 2001:67c:2e8:22::c100:68b (AF_INET6)
[+        8us] about to connect()
[+ 75638263us] connect() fails: Operation timed out
[+       75us] dest = 193.0.6.139 (AF_INET)
[+       11us] about to connect()
[+    23115us] connect() suceeds

The test program does getaddrinfo() for the provided hostname and
attempts to establish a TCP connection to port 80 for all the results in
the order returned. Even though the first IPv6 connection attempt failed
with a 75-sec timeout, while the IPv4 connection attempt succeeded, this
did not change the ordering of the getaddrinfo() result set the second
time around - broken IPv6 was still preferred.

My conclusion is therefore that the RTT-based ordering does not help
diminish the «IPv6 brokenness» problem, and I'm wondering if this is an
oversight or the intended behaviour?

I can confirm, however, that the RTT-based ordering works as advertised
when IPv6 is working, but is slower than IPv4, and the RTT of both
addresses has been learned.

However, the behaviour when the RTT of only one address is known seems
rather odd and non-deterministic to me. Consider the following test with
three connection attempts in rapid succession, where the RTT for the
IPv6 address of the test domain is significantly faster for me than IPv4
(<1ms vs 250ms):

Attempt #1 - no RTTs known:
---------------------------
bash-3.2$ echo hei | telnet liontest.fud.no 80
Trying 2001:67c:21e0::16...
Connected to liontest.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

Attempt #2 - IPv6 RTT known:
----------------------------
bash-3.2$ echo hei | telnet liontest.fud.no 80
Trying 220.181.111.147...
Connected to liontest.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

Attempt #3 - both RTTs known:
-----------------------------
bash-3.2$ echo hei | telnet liontest.fud.no 80
Trying 2001:67c:21e0::16...
Connected to liontest.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

Any subsequent attempts from now on prefer IPv6, as expected.

Why did it fail over to IPv4 after having successfully and quickly
connected using IPv6 the first time around, only to fail back to IPv6
after IPv4 proved a success as well?

I was thinking at first that the algorithm might consider unknown RTT =
0ms RTT, but it does not match what happens the other way around, when
IPv4 is initially preferred (e.g. when the AAAA record is pointing to a
6to4 address), in that case it prefers IPv4 every time (even if IPv4 is
causing connection timeouts).

BTW: Is there a way to flush all cached RTT information?

Best regards,-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Josh Graessley 1312390196Wed, 03 Aug 2011 16:49:56 +0000 (UTC)
On Aug 3, 2011, at 4:47 AM, Tore Anderson wrote:

> * Josh Graessley
> 
>> Results from getaddrinfo are now sorted using routing statistics
>> (destination with the lowest min round trip time wins). If the
>> statistics can not determine which destination is better, an
>> implementation of RFC3484 is used. The default RFC3484 policy is read
>> only.
> 
> Hi Josh,
><snip>> 
> The test program does getaddrinfo() for the provided hostname and
> attempts to establish a TCP connection to port 80 for all the results in
> the order returned. Even though the first IPv6 connection attempt failed
> with a 75-sec timeout, while the IPv4 connection attempt succeeded, this
> did not change the ordering of the getaddrinfo() result set the second
> time around - broken IPv6 was still preferred.
> 
> My conclusion is therefore that the RTT-based ordering does not help
> diminish the «IPv6 brokenness» problem, and I'm wondering if this is an
> oversight or the intended behaviour?Changing the sort order of getaddrinfo is only half of the answer. The other half is a connect-by-name API that implements something like happy eyeballs. You may have noticed that Safari does not have a problem with broken IPv6 anymore. Safari uses higher level APIs. Instead of one API that converts the hostname to a list of addresses and a separate set of APIs for connecting to an address, Safari uses webkit which uses a single API that combines the functionality of getaddrinfo and the connect. All third party applications that are using the higher level APIs (CFSocketStream and above) get the new behavior.> I can confirm, however, that the RTT-based ordering works as advertised
> when IPv6 is working, but is slower than IPv4, and the RTT of both
> addresses has been learned.
> 
> However, the behaviour when the RTT of only one address is known seems
> rather odd and non-deterministic to me. Consider the following test with
> three connection attempts in rapid succession, where the RTT for the
> IPv6 address of the test domain is significantly faster for me than IPv4
> (<1ms vs 250ms):
> 
> Attempt #1 - no RTTs known:
> ---------------------------
> bash-3.2$ echo hei | telnet liontest.fud.no 80
> Trying 2001:67c:21e0::16...
> Connected to liontest.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> Attempt #2 - IPv6 RTT known:
> ----------------------------
> bash-3.2$ echo hei | telnet liontest.fud.no 80
> Trying 220.181.111.147...
> Connected to liontest.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> Attempt #3 - both RTTs known:
> -----------------------------
> bash-3.2$ echo hei | telnet liontest.fud.no 80
> Trying 2001:67c:21e0::16...
> Connected to liontest.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> Any subsequent attempts from now on prefer IPv6, as expected.
> 
> Why did it fail over to IPv4 after having successfully and quickly
> connected using IPv6 the first time around, only to fail back to IPv6
> after IPv4 proved a success as well?This was a decision to try an address the case where we don't have an RTT estimate. We were concerned about the case with the connect-by-name APIs where IPv4 DNS came back first and we tried to connect to IPv4 first. The next time around, we will have an RTT for IPv4 but no RTT for IPv6. If we preferred IPv4 because we had an RTT, that would be bad. There is also a connection attempt/connection success count for each route. If the connection success count is zero and the connection attempt count is greater than some arbitrary number, we will stop using the route.

It may be better to fall back to RFC3484 policy if we don't have an RTT for both addresses - unless we don't have a RTT for IPv6 because IPv6 connectivity is broken. We could detect that by looking at the connection attempts/success statistics on the route, but the number of failures over IPv6 required to get us to sort IPv6 to last multiplied by the 75 second TCP connection timeout is way too long. All of this stuff works a lot better when combined with the connect-by-name APIs. Fortunately, most Applications on the Mac and iOS use the high level APIs.> I was thinking at first that the algorithm might consider unknown RTT =
> 0ms RTT, but it does not match what happens the other way around, when
> IPv4 is initially preferred (e.g. when the AAAA record is pointing to a
> 6to4 address), in that case it prefers IPv4 every time (even if IPv4 is
> causing connection timeouts).
> 
> BTW: Is there a way to flush all cached RTT information?Sort of. The RTT hangs off the route entry in the kernel. If you get rid of the route(s), the RTT and all routing statistics will go with them. The easiest way to do this is to bring the interface down for four seconds (turn off WiFi/unplug ethernet) and then back up again.

You can watch a live view of the routing statistics using "nettop -n -m route" to confirm.

-josh
Tore Anderson 1312454069Thu, 04 Aug 2011 10:34:29 +0000 (UTC)
Hi Josh,

* Josh Graessley> Changing the sort order of getaddrinfo is only half of the answer.
> The other half is a connect-by-name API that implements something
> like happy eyeballs. You may have noticed that Safari does not have a
> problem with broken IPv6 anymore. Safari uses higher level APIs.
> Instead of one API that converts the hostname to a list of addresses
> and a separate set of APIs for connecting to an address, Safari uses
> webkit which uses a single API that combines the functionality of
> getaddrinfo and the connect. All third party applications that are
> using the higher level APIs (CFSocketStream and above) get the new
> behavior.Fully agreed - the getaddrinfo() RTT sorting cannot help with the
initial 75-sec penalty for a new destination, however limiting the
amount of such timeouts to one per destination is better than nothing.

I'm primarily thinking about applications like Firefox, which use the
traditional while(getaddrinfo()) connect() loop instead of the higher
level APIs available in OS X.

BTW I've seen numbers that confirm that Safari on Lion has a much much
lower brokenness figure than Firefox, so the HE implementation in Lion
is doing its job very well.>> Why did it fail over to IPv4 after having successfully and quickly 
>> connected using IPv6 the first time around, only to fail back to
>> IPv6 after IPv4 proved a success as well?
> 
> This was a decision to try an address the case where we don't have an
> RTT estimate. We were concerned about the case with the
> connect-by-name APIs where IPv4 DNS came back first and we tried to
> connect to IPv4 first. The next time around, we will have an RTT for
> IPv4 but no RTT for IPv6. If we preferred IPv4 because we had an RTT,
> that would be bad.Ok, so if understand correctly, you're saying is that you essentially
always prefer an address with a unknown RTT over an address with a known
RTT. Right?

However, this does not always appear to happen in my testing. In this
case, the IPv6 destination address is not preferred by the initial
RFC3484 sorting, as it's a 6to4 address:

dtrace:~ tore$ host liontest3.fud.no
liontest3.fud.no has address 202.12.29.211
liontest3.fud.no has IPv6 address 2002:d43e:4417::1

dtrace:~ tore$ echo | telnet liontest3.fud.no 80
Trying 202.12.29.211...
Connected to liontest3.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

dtrace:~ tore$ echo | telnet liontest3.fud.no 80
Trying 202.12.29.211...
Connected to liontest3.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

dtrace:~ tore$ echo | telnet liontest3.fud.no 80
Trying 202.12.29.211...
Connected to liontest3.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

So in this case, as far as I can tell, it did *not* «try an address the
case where we don't have an RTT estimate» - the RTT estimate for
2002:d43e:4417::1 remains unknown all the time, but it's never tried.

If I now force the RTT for the IPv6 address to be discovered so that
both are known, it goes on to prefer the faster IPv6 address as expected:

dtrace:~ tore$ echo | telnet 2002:d43e:4417::1 80
Trying 2002:d43e:4417::1...
Connected to ipv6.ogris.de.
Escape character is '^]'.
Connection closed by foreign host.

dtrace:~ tore$ echo | telnet liontest3.fud.no 80
Trying 2002:d43e:4417::1...
Connected to liontest3.fud.no.
Escape character is '^]'.
Connection closed by foreign host.

Note that I'm not trying to imply that this behaviour is sub-optimal in
any way - I just want to get a complete understanding on how the
algorithm works.> There is also a connection attempt/connection success count for each
> route. If the connection success count is zero and the connection
> attempt count is greater than some arbitrary number, we will stop
> using the route.Okay. This arbitrary number is 11? At least, for me, when attempting to
connect to a dual-stacked destination with IPv6 broken, the telnet
command didn't start trying IPv4 first until the 12th time. The first 11
attempts tried IPv6 first, timed out for 75 seconds, before falling back
to IPv4.

I think I'd prefer to instead see Lion record the initial failure as an
infinite RTT for the destination (or 75 sec RTT), so that IPv4 would be
tried first already on the second attempt (and stuck to on any
subsequent attempts). It doesn't make much sense to me to wait so long
with preferring IPv4 when IPv6 is consistently failing - especially when
you take into account the fact that when IPv6 actually succeeded on the
first attempt, IPv4 is always preferred on the second one.

Best regards,-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
james woodyatt 1312482020Thu, 04 Aug 2011 18:20:20 +0000 (UTC)
On Aug 4, 2011, at 03:34 , Tore Anderson wrote:
> 
> This arbitrary number is 11?No, the arbitrary number is *arbitrary*.  Josh was being very precise when he used that word.  "All these worlds are yours except Europa.  Attempt no landings there."--
james woodyatt 
member of technical staff, core os networking
Josh Graessley 1312493115Thu, 04 Aug 2011 21:25:15 +0000 (UTC)
On Aug 4, 2011, at 3:34 AM, Tore Anderson wrote:

> Hi Josh,
> 
> * Josh Graessley
> 
>> Changing the sort order of getaddrinfo is only half of the answer.
>> The other half is a connect-by-name API that implements something
>> like happy eyeballs. You may have noticed that Safari does not have a
>> problem with broken IPv6 anymore. Safari uses higher level APIs.
>> Instead of one API that converts the hostname to a list of addresses
>> and a separate set of APIs for connecting to an address, Safari uses
>> webkit which uses a single API that combines the functionality of
>> getaddrinfo and the connect. All third party applications that are
>> using the higher level APIs (CFSocketStream and above) get the new
>> behavior.
> 
> Fully agreed - the getaddrinfo() RTT sorting cannot help with the
> initial 75-sec penalty for a new destination, however limiting the
> amount of such timeouts to one per destination is better than nothing.
> 
> I'm primarily thinking about applications like Firefox, which use the
> traditional while(getaddrinfo()) connect() loop instead of the higher
> level APIs available in OS X.
> 
> BTW I've seen numbers that confirm that Safari on Lion has a much much
> lower brokenness figure than Firefox, so the HE implementation in Lion
> is doing its job very well.It would be nice if we could do a better job for all applications.>>> Why did it fail over to IPv4 after having successfully and quickly 
>>> connected using IPv6 the first time around, only to fail back to
>>> IPv6 after IPv4 proved a success as well?
>> 
>> This was a decision to try an address the case where we don't have an
>> RTT estimate. We were concerned about the case with the
>> connect-by-name APIs where IPv4 DNS came back first and we tried to
>> connect to IPv4 first. The next time around, we will have an RTT for
>> IPv4 but no RTT for IPv6. If we preferred IPv4 because we had an RTT,
>> that would be bad.
> 
> Ok, so if understand correctly, you're saying is that you essentially
> always prefer an address with a unknown RTT over an address with a known
> RTT. Right?Yes. Although we could change that. We can provide a different search order for applications using getaddrinfo+connect vs applications that are using the connect-by-name API. We could be more conservative with the getaddrinfo sort order since a bad first address in that case is significantly more disruptive that a bad first address for the connect-by-name API.> However, this does not always appear to happen in my testing. In this
> case, the IPv6 destination address is not preferred by the initial
> RFC3484 sorting, as it's a 6to4 address:
> 
> dtrace:~ tore$ host liontest3.fud.no
> liontest3.fud.no has address 202.12.29.211
> liontest3.fud.no has IPv6 address 2002:d43e:4417::1
> 
> dtrace:~ tore$ echo | telnet liontest3.fud.no 80
> Trying 202.12.29.211...
> Connected to liontest3.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> dtrace:~ tore$ echo | telnet liontest3.fud.no 80
> Trying 202.12.29.211...
> Connected to liontest3.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> dtrace:~ tore$ echo | telnet liontest3.fud.no 80
> Trying 202.12.29.211...
> Connected to liontest3.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> So in this case, as far as I can tell, it did *not* «try an address the
> case where we don't have an RTT estimate» - the RTT estimate for
> 2002:d43e:4417::1 remains unknown all the time, but it's never tried.Without a debug version of the library, it may be hard to know exactly what's going on. There is always the off chance getaddrinfo didn't wait long enough for the AAAA answer. You can eliminate that as being a possible problem by pre-populating mDNSResponder's DNS cache using "dns-sd -G v4v6 liontest3.fud.no".

To help understand the behavior you're seeing, I've included the complete algorithm as implemented in Lion (10.7.0). We may change this at any time without notice. It's important to understand that the routing statistics collection applies to host routes and host route statistics are blended with their parent (subnet/default) route's statistics. The route statistics collection code is in xnu-1699.22.73 <http://www.opensource.apple.com/release/mac-o...> in bsd/net/ntstat.c. Look for the "-- Route Collection --" section. When looking up route statistics for a destination, we don't clone a host route entry if one doesn't exist. We will instead use statistics for the subnet or default route that the host route would be cloned from. The algorithm of sa_dst_compare appears below.

-- route statistics based --
if destination 1 min rtt and destination 2 min rtt
	if destination 1 min rtt is less than destination 2 min rtt
		prefer destination 1
	if destination 2 min rtt is less than destination 1 min rtt
		prefer destination 2
else if only one destination has a min rtt and
	the destination with no rtt has 0 connection successes and
	less than 10 connection attempts
		prefer destination without min rtt

if we have routes for both
	if only one destination goes through a p2p interface
		prefer destination not going through p2p interface
	if only one destination goes through a gateway
		prefer destination not going through gateway

if we have a route for only one
	prefer the destination we have a route for

-- rfc3484 --
determine source for each destination, lookup sources and destinations in policy table - the kernel has a read only copy of the I-D.ietf-6man-rfc3484-revised-02 default policy table.

if only one destination is unreachable (no source to reach destination)
	prefer the reachable one

if the scope of the source for destination 1 and the scope of destination1 matches but that's not true for destination 2
	prefer destination 1
if the scope of the source for destination 2 and the scope of destination2 matches but that's not true for destination 1
	prefer destination 2

if the source for only one of the destinations is deprecated
	prefer the destination that doesn't use a deprecated source

if the label of the source for destination 1 and the label of destination 1 matches but that's not true for destination 2
	prefer destination 1
if the label of the source for destination 2 and the label of destination 2 matches but that's not true for destination 1
	prefer destination 2

if destination 1 precedence is greater than destination 2 precedence
	prefer destination 1
if destination 2 precedence is greater than destination 1 precedence
	prefer destination 2

if the source for destination 1 is non-native (6to4 or Teredo) and the source for destination 2 is native
	prefer destination 2
if the source for destination 2 is non-native (6to4 or Teredo) and the source for destination 1 is native
	prefer destination 1

if the scope of destination 1 is less than the scope of destination 2
	prefer destination 1
if the scope of destination 2 is less than the scope of destination 1
	prefer destination 2

if the length of prefix in common between the source for destination 1 and destination 1 is great than the length of prefix in common between the source for destination 2 and destination 2
	prefer destination 1
if the length of prefix in common between the source for destination 2 and destination 2 is great than the length of prefix in common between the source for destination 1 and destination 1
	prefer destination 2

Hope this helps shed some light on what's going on. We are open to improving this if you are running in to problems. Please file a bug report as soon as possible with the details. The sooner we get a bug report, the sooner we can evaluate it and determine which release (if any) we can try and get a fix in.> If I now force the RTT for the IPv6 address to be discovered so that
> both are known, it goes on to prefer the faster IPv6 address as expected:
> 
> dtrace:~ tore$ echo | telnet 2002:d43e:4417::1 80
> Trying 2002:d43e:4417::1...
> Connected to ipv6.ogris.de.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> dtrace:~ tore$ echo | telnet liontest3.fud.no 80
> Trying 2002:d43e:4417::1...
> Connected to liontest3.fud.no.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> Note that I'm not trying to imply that this behaviour is sub-optimal in
> any way - I just want to get a complete understanding on how the
> algorithm works.I wouldn't suggest our behavior is perfect, but I do believe it's better that it was.>> There is also a connection attempt/connection success count for each
>> route. If the connection success count is zero and the connection
>> attempt count is greater than some arbitrary number, we will stop
>> using the route.
> 
> Okay. This arbitrary number is 11? At least, for me, when attempting to
> connect to a dual-stacked destination with IPv6 broken, the telnet
> command didn't start trying IPv4 first until the 12th time. The first 11
> attempts tried IPv6 first, timed out for 75 seconds, before falling back
> to IPv4.So close. It is 10. In practice this may not be quite as bad as the test case where you telnet to the same destination multiple times. When you do try to connect to an address, the subnet/default route is cloned to create a host route. Each host route will have an individual count that will take a long time to increment. However, the parent route will also have the attempts/successes counts incremented. If you try to connect to 10 different IPv6 destinations, the subnet/default route will accumulate 10 connection attempts and zero successes. From then on we will prefer other destinations over any destination that matches that subnet/default route but does not have a host route with a lower attempts count. This is a little fragile as something connecting by address instead of name will cause the route to be cloned for that host and that host entry will have a low connection attempt account. It may be better if the routing statistics took host routes and parent routes in to account or treated host routes differently.> I think I'd prefer to instead see Lion record the initial failure as an
> infinite RTT for the destination (or 75 sec RTT), so that IPv4 would be
> tried first already on the second attempt (and stuck to on any
> subsequent attempts). It doesn't make much sense to me to wait so long
> with preferring IPv4 when IPv6 is consistently failing - especially when
> you take into account the fact that when IPv6 actually succeeded on the
> first attempt, IPv4 is always preferred on the second one.File a bug request and I'll see what I can do. Our other concern was that we didn't want to avoid IPv6 because the first IPv6 destination you tried to connect to was down. If we use a different arbitrary number for the host route (say 1 attempt/0 success = avoid) from the subnet/default route (10 attempt/0 success = avoid), that would probably be a better solution.

-josh
Iljitsch van Beijnum 1314041121Mon, 22 Aug 2011 19:25:21 +0000 (UTC)
On 3 Aug 2011, at 18:48 , Josh Graessley wrote:

> It may be better to fall back to RFC3484 policy if we don't have an RTT for both addresses - unless we don't have a RTT for IPv6 because IPv6 connectivity is broken. We could detect that by looking at the connection attempts/success statistics on the route, but the number of failures over IPv6 required to get us to sort IPv6 to last multiplied by the 75 second TCP connection timeout is way too long.Doing all of this per route only is probably unnecessarily granular. If you only got failures in recent memory for a certain address family (maybe discounting local stuff) then it's a good bet the connectivity for that address family is broken and you can push it to the back of the list.
Andre-John Mas 1311267925Thu, 21 Jul 2011 17:05:25 +0000 (UTC)
Looks like "Network Utility" still isn't IPv6 aware. For example can't ping an IPv6 host.On 21-Jul-2011, at 10:24, Andre-John Mas wrote:

> Hi,
> 
> Has anyone played around with IPv6 since installing Lion. Any interesting observations?
> 
> Andre _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Ipv6-dev mailing list      
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/ipv6-d...
> 
> This email sent to 
>
Tsuyoshi MOMOSE 1311315061Fri, 22 Jul 2011 06:11:01 +0000 (UTC)
On 2011/07/21, at 23:24, Andre-John Mas wrote:

> Hi,
> 
> Has anyone played around with IPv6 since installing Lion. Any interesting observations?Though I don't install lion yet, as far as I see some source code, 
- RFC3484 is integrated.
  ip6addrctl(8) is introduced to set source addr selection policy.
- rtsol(8) is fixed

I don't know whether they actually work.--
Tsuyoshi Momose
Ad
Home | About | Privacy