The device could also have an IPv6 interface via a tunnel or VPN client.
- Erik
[Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
On Thu, Aug 29, 2019, 5:44 AM Naveen Kottapalli <naveen.sa...@gmail.com>
wrote:
> My query was about the behavior we observed on a gateway where a pure v4
> subscriber (not dual-stack) has sent both A and AAAA query for the same
> domain simultaneously. Just wanted to know why would a pure v4 subscriber
> which cannot use the resolved AAAA domain addresses is trying to resolve
> the v6 addresses of the domain.
>
> Yours,
> Naveen.
>
>
> On Thu, 29 Aug 2019 at 12:09, Viktor Dukhovni <ietf-d...@dukhovni.org>
> wrote:
>
>> On Wed, Aug 28, 2019 at 05:53:26AM +0530, Naveen Kottapalli wrote:
>>
>> > Can one of you tell why would a v4 client send AAAA query or a by client
>> > send a A query when the resolved address cannot be used?
>>
>> One answer I did not see, but seems to me to be the most likely,
>> is that the library interface used by the application to learn the
>> peer's addresses asks for and returns all the v4 and v6 addresses,
>> and then the application tries each address in turn, until one
>> succeeds, the library is address-family agnostic.
>>
>> Often the address resolution is many layers down below the actual
>> application code, e.g. in an HTTP request library that uses a
>> connection pool, that, as needed, establishes connections in a
>> generic way, by using getaddrinfo(3) with AF_UNSPEC as the address
>> family. The library code many layers down below the application
>> code making an HTTP request, has no prior knowledge that on this
>> particular system IPv6 may not be available. It just tries the
>> returned addresses in order until one works.
>>
>> My system has IPv6, but only via a GRE tunnel to Hurricane Electric
>> (many thanks to HE for the pretty good free service) and IPv6
>> performance is consequently not nearly as good as IPv4. So I've
>> configured my (FreeBSD) system to prefer IPv4:
>>
>> $ cat /etc/ip6addrctl.conf
>> # Prefer IPv4
>> ::ffff:0.0.0.0/96 100 4
>> ...
>>
>> $ grep -i addrctl /etc/rc.conf
>> ip6addrctl_enable="YES"
>> ip6addrctl_policy="AUTO"
>>
>> With that, getaddrinfo(3) returns the IPv4 addresses first, and I
>> only use IPv6 when none of the IPv4 addresses work, or the application
>> chooses to also use the IPv6 addresses (e.g. the DANE survey code
>> checks the validity of the certificate chain at every address of
>> each MX host).
>>
>> For example (python):
>>
>> from socket import getaddrinfo, SOCK_STREAM
>> for ai in getaddrinfo('www.ietf.org', 'https', type=SOCK_STREAM):
>> print(ai)
>>
>> outputs:
>>
>> (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '',
>> ('104.20.1.85', 443))
>> (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '',
>> ('104.20.0.85', 443))
>> (<AddressFamily.AF_INET6: 28>, <SocketKind.SOCK_STREAM: 1>, 6, '',
>> ('2606:4700:10::6814:55', 443, 0, 0))
>> (<AddressFamily.AF_INET6: 28>, <SocketKind.SOCK_STREAM: 1>, 6, '',
>> ('2606:4700:10::6814:155', 443, 0, 0))
>>
>> If I use python's HTTP client code to fetch content from:
>>
>> https://www.ietf.org/...
>>
>> code similar to the above will look up both the IPv4 and IPv6
>> addresses, and then, if all goes well, use just the first one to
>> make an IPv4 TCP connection to www.ietf.org (port 443), perform a
>> TLS handshake, ...
>>
>> So the AAAA lookup is only used for IPv6-only sites, but that's the
>> cost of all the layering and abstraction of address order preference,
>> ..... An efficient implementation of getaddrinfo() can do the A and
>> AAAA lookups concurrently.
>>
>> --
>> Viktor.
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
