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.
Do not post admin requests to the list. They will be ignored.
Ipv6-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden