Re: IPV6 address support on exit nodes

[coderman <coderman@xxxxxxxxx>]

On Wed, Feb 9, 2011 at 3:08 AM, Bjoern A. Zeeb
<bzeeb-lists@xxxxxxxxxxxxxxxxxx> wrote:
> ...
> When it comes to AAAA lookups and what to do, I'd do whatever the
> resovler on the host does. I talked to ayourtch last weekend.  Some
> people have plans to implement draft-wing-v6ops-happy-eyeballs-ipv6
> but I think we'll still see adjustments to the draft.

it would be nice to "pass the buck" for resolver behavior to host,
however, this exposes partitioning and functional difficulties. Tor
must be consistent and resilient in its resolver behavior.

the happy eyeballs approach is aggressive but effective. downside is
roughly twice the circuit creation per stream on average than the
current case.

pragmatically some sane mostly common resolver compromises will be
needed. i am fond of relying on out-of-band hinting or other context
to suggest a preference for one type of resolution over another and
completing accordingly.

for example, when domains return both A and AAAA records for a given
FQDN, ignore/mask the A responses so that IPv6 connectivity is
default. there are other details that may differ from host resolver
behavior, but worth handling explicitly. [0]

these are mostly covered in the proposal sections listed below,

https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/proposals/117-ipv6-exits.txt
1.3. DNS name resolution of IPv6 addresses (AAAA records)
1.4.2. SOCKSv5 IPv6 client behavior
1.4.3. MAPADDRESS behavior
1.4.4. DNSProxy IPv6 client behavior
1.4.5. TransPort IPv6 client behavior
3.1. DNS A6 records
3.2. IPv4 and IPv6 preference
3.3. Support for IPv6 only transparent proxy clients


0. regarding the AAAA preference when a domain has both A and AAAA
records associated. ideally the webhosts would do things like google
does, where an ipv6 resource only returns AAAA records, or a CNAME and
AAAA record configuration for usability. returning both A and AAAA
records to ipv6 preferred servers is not useful default behavior,
particularly considering the limitations of some client resolvers.

in any case, the devil in clearly in these many details. i am glad to
see progress being made and interest picking up!

best regards,