IPv6 support in Apple's OS X 10.7
There are some significant changes to IPv6 Support in Apple's OS X 10.7 (Lion).
- SMB is supported over IPv6.
- Privacy/temporary IPv6 addresses are enabled by default
- There is a DHCPv6 client enabled. It's behavior is controlled by the 'M' and 'O' flags in the router's advertisements.
- It is possible to disable 6to4.
On the command line one type this command:
sudo sysctl -w net.inet6.icmp6.nd6_accept_6to4=0
That will make the IPv6 stack treat all Prefix Information Options with 2002::/16 prefixed addresses in them as if the A bit is always zero. The system will not auto-configure any 6to4 addresses on any interface.
To make the change permanent, add a line to /etc/sysctl.conf
- In a dual stack (both v4 and v6) environment, applications that
use the Apple API's will dynamically choose which protocol to use
to connect to a dual-stack server.
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.Source: http://lists.apple.com/archives/Ipv6-dev/2011/Jul/msg00009.html
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.