Asterisk IPv6 fundamentally broken

Asterisk Asterisk Support
1

The most polite thing I can say about the Asterisk 11 IPv6 implementation is that “the developer can’t read”. The incoming call from Xlite on OSX works fine over IPv6 or IPv4, then the dialplan points to a name that resolves IPv4-only for the 3102. The IPv4 address for the 3102 is acquired correctly from DNS, because it shows up in the most significant 32 bits of the subsequent IPv6 connect attempt (even in the cases of the incoming call from X-lite being IPv4). At best, the IPv4 address should be stored in IPv6 format as a “mapped” address in the form ::ffff:IPv4/96, and that format should not appear in the outer header on the wire, but could be passed as data. The entire point of that format was to allow for internal storage of 128 bit values for IPv4-only endpoints, so it would make sense if that address format showed up in a log somewhere. What should never happen is that the IPv4 address would be on-the-wire as the most significant 32 bits of an address. That implies that the implementation is ‘unaware’ of the fact that the answer it got from DNS was IPv4, and just jammed the answer plus random crap into the address field. The flip side of that lack of awareness would be that an IPv6-only answer came back from DNS and the 128 bits was jammed into a buffer meant for 32 bits, so something ends up overwritten. Snippets of the SIP debug output:
<— Reliably Transmitting (no NAT) to 172.16.144.46:43968 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.144.46:43968;branch=z9hG4bK-d8754z-f553c96682293764-1—d8754z-;received=172.16.144.46;rport=43968
From: "Tony"sip:X-lite@fqdn;tag=1bf0cd06
To: sip:123@fqdn;tag=as3755e173
Call-ID: YjM3MzVmYWFkMDRmZTU4ZmI2N2UxMmE3MzA4MjI2Mzc
CSeq: 1 INVITE
Server: HGC PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:123@172.16.144.62:5060
Content-Type: application/sdp
Content-Length: 289

v=0
o=root 604546809 604546809 IN IP4 172.16.144.62
s=Asterisk PBX 11.3.0
c=IN IP4 172.16.144.62
…
ACK sip:123@172.16.144.62:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.144.46:43968;branch=z9hG4bK-d8754z-2f015734fce4183e-1—d8754z-;rport
Max-Forwards: 70
Contact: sip:X-lite@172.16.144.46:43968
To: sip:123@fqdn;tag=as3755e173
From: "Tony"sip:X-lite@fqdn;tag=1bf0cd06
Call-ID: YjM3MzVmYWFkMDRmZTU4ZmI2N2UxMmE3MzA4MjI2Mzc
CSeq: 1 ACK
User-Agent: X-Lite release 4.5 stamp 69608
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Audio is at 15364
Video is at [2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:10006
Adding codec 100003 (ulaw) to SDP
Adding codec 100002 (gsm) to SDP
Adding codec 100004 (alaw) to SDP
Adding codec 100017 (testlaw) to SDP
Adding video codec 200002 (h263) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to [ac10:903c:989d:bf7a::800:0]:5060:
INVITE sip:3102FXS@3102.fqdn SIP/2.0
Via: SIP/2.0/UDP [2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060;branch=z9hG4bK65197241
Max-Forwards: 70
From: “Tony” sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71];tag=as6bae6195
To: sip:3102FXS@3102.fqdn
Contact: sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060
Call-ID: 6a0a34a2594ff7e57d81a13e14aadd3d@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060
CSeq: 102 INVITE
…

Retransmitting #1 (no NAT) to [ac10:903c:989d:bf7a::800:0]:5060:
INVITE sip:3102FXS@3102.fqdn SIP/2.0
Via: SIP/2.0/UDP [2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060;branch=z9hG4bK65197241
Max-Forwards: 70
From: “Tony” sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71];tag=as6bae6195
To: sip:3102FXS@3102.fqdn
Contact: sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060
Call-ID: 6a0a34a2594ff7e57d81a13e14aadd3d@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060
CSeq: 102 INVITE
…
Maybe X-lite is doing something stupid, but the only change between working and not was to upgrade Asterisk from 1.8 to 11, so Asterisk would have to be feeding X-lite something different. Even then, the IPv6 address in the INVITE is for an interface on the Asterisk box.
Maybe it is possible that whoever built the Optware image (Asterisk 11.3.0 built by slug @ imitron on a i686 running Linux on 2013-04-24 19:39:03 UTC) had something misconfigured, but even so there are clearly no sanity checks in the core code to make sure the address length matches the protocol being spoken. There is no AAAA record for the 3102, so there should never be an attempt to connect to it using IPv6, and particularly with a malformed address. There never was an attempt to connect over IPv4, just retransmits on IPv6 until the call timed out and closed.

2

This is better taken up on te dev mailing list, as you are not looking for a assistance but making a statement.

Also Im sure you are aware, for any testing you should build from source yourself so that you are 100% sure that the build is correct.

3

Ian,

It wasn’t my plan to do testing. The Google voice connection to 1.8 died awhile back, then this week a build of 11 for Optware was finally available, and it wasn’t even a .0 early build. Other than fixing the jingle/motif conversion, there should not have been any need to ‘test’, particularly the IPv4-only connection between Astrisk and the 3102. The interface configuration of the Asterisk box didn’t change, only the version switch, uninstalling 1.8 then installing 11. IPv6 functionality is something I would expect to ‘test’ before relying on it much, but the braindead functionality of the current code in taking an IPv4 A record response from DNS, then generating an illegitimate IPv6 address and only trying to connect to the target over IPv6 is not something that creating my own build environment would resolve. If slug @ imitron didn’t get something right, it is unlikely my hacked together from scratch build environment would get it right either.

I looked at the Dev board that said it was the place dev’s hang out, but the only post there was in 2006 when it was set up. Clearly operational practice and the expected usage of these forum boards has diverged, and nobody has bothered to document proper process. In any case, the support I am looking for is for someone to fix the code to actually use IPv4 to connect to devices that only have an IPv4 address. That doesn’t seem like an unreasonable request, and one that I would expect everyone else would want resolved. Clearly nobody in the dev team bothered to test that IPv4 continued to work once an IPv6 address was configured on the box, or they would have tripped over this before 11 was ever released.

4

The 2006 article tells you how to get development support. The tag line for the forum expands on that. Basically you use the mailing list, or IRC channel.

Ian quite clearly said “mailing list”, not “forum”.