[v6ops] OSX Lion IPv6 changes

"Dan Wing" <dwing@cisco.com> Sat, 23 July 2011 07:56 UTC

From: Dan Wing <dwing@cisco.com>
To: v6ops@ietf.org
Date: Sat, 23 Jul 2011 00:56:06 -0700
Message-ID: <025b01cc490d$fa73b030$ef5b1090$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcxJDfotbwsqfGrMR1iZBRQMRXlHTQ==
Content-Language: en-us
Subject: [v6ops] OSX Lion IPv6 changes
Precedence: list

http://lists.apple.com/archives/Ipv6-dev/2011/Jul/msg00009.html

    > 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

-d

[v6ops] OSX Lion IPv6 changes Dan Wing