IPv6 incorrect setup (or resolver bug? or http client bug?)

[Ingela Anderton]

Matthias Lang wrote:
> Hi,
> 
> I know very little about IP6.
> 
> The 'inet' man page:
> 
>   http://www.erlang.se/doc/doc-5.4/lib/kernel-2.10/doc/html/inet.html
> 
> says that inet:getaddr/2 is prepared for inet6. Trying it out on some
> debian machines I have, none of which are configured for IP6, by
> evaluating 
> 
>   inet:getaddr("172.16.2.2", inet6)
> 
> gives me varying results:
> 
>   Host        Erlang release     Result
>   ----------------------------------------------------------------------
>   antilipe    R9C                {ok,{172,16,2,2}}
>   cors        R10B               {ok,{172,16,2,2}}
>   cors        R9C                {error, timeout}
> 
> Is 172.16.2.2 an ip6 address?
No, it is a ipv4 address.

> Why am I asking this?
> 
> I tried to use the http client (on cors, with R10B). Here's what
> happened:
> 
>   http:request(get, {"http://172.16.2.2:1234", []}, [], []).
>   {error,eafnosupport}
> 
> digging in the http client code a bit, I can see that
> http_transport:connect() calls inet:getaddr(Host, inet6), apparently
> to decide whether the host supports IP6 or not.
This is the most reasonable way for the http-client to determine this.
We want it to be transparent to the user if the hostname they give
happens to translate into an ipv4 or ipv6-address. 

> Things which seem wrong:
> 
>    1. inet:getaddr(Host, inet6) doesn't seem to be a reliable
>       way to determine whether the TCP socket should use inet6
>       option, but http_transport thinks it is.
It works on solaris, windows, freebsd and on some linux platforms. We have
lately become aware that on some other linuxplatforms and on 64-bit
platforms it does not seem to work. We are looking in to this.

>    2. the inet documentation seems to say that inet_getaddr(Host,
>       inet6) isn't implemented yet, yet http_transport uses it
It is supposed to be implemented but the documentation is lagging.
It was implemented some time ago by a person no longer working with
OTP. It appears some more extensive testing of this functionality is
needed and also the documentation needs updating.


You can always work around the problem for now by changing
the call in  http_transport:connect/0 to inet:getaddr(Host, inet) 

-- 
/m.v.h Ingela

Ericsson AB - OTP team