[Asterisk-Dev] Re: [Bounty] IPv6 support in Asterisk

[Bernhard Schmidt]

On 2005-05-31, Olle E. Johansson <oej at edvina.net> wrote:

> I have IPv4, you have IPv6/v4 with dual stacks. My Asterisk queries DNS
> in IPv4,
> gets an IPv6 address in the first SRV record, IPv4 in the next. (You
> have a IPv6/ipv4 proxy/gw somewhere)
> Asterisk will only read the first (another bug) and fail since I haven't
> got IPv6.
> -- If we fix the SRV record issues, we should propably use the second
> one in this case, so we need to be protocol aware.

As far as I understood Asterisk cannot fall back and retry at another
server at all currently, so that would probably the general approach for
that. If your stack is correctly configured you should get immediate
"Adress family not supported" (when you don't have IPv6 in your kernel)
or "Connection refused" (when you're not connected to an IPv6 router),
which wouldn't add too much delay to the call setup.

> I have IPv4, you have only IPv6. My Asterisk queries DNS in IPv4, gets
> an IPv4 answer with an IPv6 address as the first and only SRV record.
> The call will fail.
> -- Is there a standard way of using an IPv4 to IPv6 proxy/gw in this case?

I think I read a draft about IPv4/IPv6 SIP gateway somewhere at the
IETF, I'll have a look.

> I have IPv6, you have IPv6 - both have dual stacks.
> I call you, get SRV records with IPv4 and IPv6. Asterisk only reads the
> IPv4 (first one ) and sets up the call on IPv4.
> -- If we fix the SRV record problem - how should we prioritize, or
> should we at all?

This is definitely a hard one. The usual stacks prefer IPv6 over IPv4 in
the order of addresses returned by getaddrinfo(), which is the most seen
behaviour in applications. These times you can rely on connection
quality in IPv6 being almost as good as IPv4, so as long as you allow
the user to enable/disable the whole IPv6 thing by himself IMHO there is
no obligation to change that.

> There are a lot of other issues when there are IPv4/IPv6 gateways in the
> network, especially when it comes to how chan_sip picks an interface to
> send on and addresses to use. It's a challenging topic!

It indeed is. Maybe the whole thing should be split up, make chan_sip
and chan_iax2 support both address families and allow the use of IPv6
optional (either by having the user-agent register through IPv6, or by
specifying an IPv6 address in the peer-configuration or the SIP URI) and
put that into CVS HEAD (the patch posted in April is doing that, so
getting that cleaned up and imported would be the first task). Normal
SIP URIs could still be the current "one IPv4-address only"-thing.

When this infrastructure is in place maybe someone can (independently
from the above changes) add some fallback logic into the channel
modules.

Bernhard