Add IPv6 support #6
Comments
|
The networking code is in much worse shape than I expected - IP addresses and ports kept and passed as hardcoded long and short (in host byte order) all around the place. A cleanup will be necessary to be able to start with IPv6, it's going to take some time and careful testing. All in all, this should defintely not block the first Qt4/Qt5 based release. |
|
Personal note - how to indicate both IP4 and IP6 in SDP: https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-May/016579.html |
|
It seems the idea is that if IPv6 is used to contact the SIP server, then IPv6 is to be used for SDP and consequently RTP. Alas, I cannot find any public SIP servers with IPv6. |
|
Dropping this note as I am searching for another IP6 SIP client that supports peer to peer. For me, the killer application of SIP with IPv6 is peer to peer mode. There is no need for SIP servers when you dispense with IP4 and the %^$#&*% NAT. I am using linphone for peer to peer calls, but the configuration is very fragile. For instance, if it doesn't find an IPv6 default route, it thinks "network is inaccessible" . (It is common to use 2000::/3 for IANA ips and IP6 VPNs will use a subnet of FC00::/7.) Linphone refuses to believe that an IP6 VPN IP is a real reachable IP - unless I tell it "Behind NAT gateway with this public IP" (even though IP6 doesn't need or in most cases have NAT). Anyway, a peer to peer VPN SIP address looks like this: sip:username@[fcba:e4bd:848c:31ad:ce90:1f89:7907:1521] Those are just as convenient as any other SIP address when added to an addressbook/contacts. Peer to peer is especially powerful when using an end to end encrypted VPN with authenticated IPs like Cjdns. The above is a Cjdns IP - it is the double sha512 hash of the public key. So you know your calls are end-to-end encrypted and not MITMed. There is no central IP assignment and no VPN concentrator. |
SIP server? Where we're going, we don't need SIP servers! (Or STUN servers.) |
|
issue is open since 2015 nowadays more and more SIP servers Support IPv6. Still would be nice future feature. |
|
And baresip 2.0.2 supports IPv6 properly. (Older versions, like the one I found in Debian stable, do unlogical things such as trying to respond to IPv6 offers with an IPv4 counterpart.) There is an RFC detailing the transition, I've skipped Twinkle for quite a while because it does not handle IPv6, but I really thought it was a pitty. I agree that, given IPv6 support, it is possible to dial directly between phones or, which is my purpose, between domains. Telcos are an optional extra for those with nostalgic tendencies. And wiretapping by media gateways can also be avoided without such gateways. Passive observation of traffic passing by can also be avoided because SDP (with an SRTP key in it) may be encrypted if it does not need to give in to rewriting by NAT traversal helpers. There are plenty of reasons to make IPv6 possible in a SIP phone. (In general, IPv6 blooms in peer-to-peer protocols, and always leaves IPv4 use cases behind. IPv4 is the model of the world that needs central servers to bring users together. This is not a perfect model of the Internet and its supposed freedom, I suppose.) I've setup a structure for an IPv6-only SIP server in Kamailio. Its local accounts work, and can call back and forth, |
|
Thanks @sdgathman and @vanrein for helping me better understand the usefulness of this feature. (Since I, like many people, don't actually use IPv6, this was not exactly at the top of my priority list.) Still, this looked like an interesting challenge, so I've spent the last week working on this. While I've cleared most of the hurdles so far, I'm currently blocked by a big one that has got me quite stumped, so I'm still uncertain on whether or not this is actually doable. We'll see how it goes from there. |
Man, that's the easy part! 😏 (Long and tedious, sure, but not very complex.) Then you've got addresses passed as strings, sometimes empty, sometimes set to While the assumption throughout the code that everybody speaks IPv4 is an issue, the most problematic is the assumption that everybody speaks the same protocol (whether IPv4 or v6). This results in us crafting a SIP message (with our local IP address in it) in one part of Twinkle and passing it to the networking part along with a list of destination addresses. This works fine if we only stick to IPv4 (or v6), but mixing them both results in two messages, and each recipient must be sent the right one according to their address. I fear I'll have to dig deep to figure out a solution for this one. |
|
Yeah, that's actually the approach I'm going for, but it's far easier said than done, trust me. 😄 |
Yes, that is the most difficult part. Generally it should be safe to stick with the same protocol once it has been used. So an INVITE over IPv4 can be handled completely over IPv4, and an INVITE over IPv6 can be handled competely over IPv6. Likewise, for outgoing traffic, you can make a choice based on DNS addresses (preferring IPv6 to avoid NAT traversal issues I suppose) and stick with it.
The golden path is indeed to be flexible, and follow along when the other changes AF, with SIP over IPvN and RTP over IPv(10-N). You could offer flexibility of that kind if you are able and willing, by sending both IP4 and IP6 offers in SDP. When the other side has sent an SDP offer, you are probably best off making a choice (and then certainly IPv6 is helpful to avoid single-sided calls).
Talk, and ask, if you need help. Meanwhile, I have a tool SIPproxy64 now closing in on 1.0 release that might be useful. This is a proxy that sits between IPv4-only and IPv6-only elements, mirrorring back and forth. Purpose is to use IPv4-only hardware phones in an IPv6 environment (such as the entire Internet, domain-based calling). It is run near one's IPv4 elements, so it does not crossover NAT. Actually, SIPproxy64 is a kind of NAT, except that it pokes out to to world using IPv6 so there's only firewall transition, not 3rd-party, SIP-unaware address translation. I also have older work named This work was funded by NLnet 10 years ago. They might also be interested in seeing Twinkle moving this way. |
|
+1 on the importance of this family of addresses.
These addresses are not fit for global routing, and in some places that is a strength. They are 192.168./16 or the IPv6 world, except that nobody in their right mind should try translating them to routable addresses. That makes them better, in some ways :) It is quite possible to use fc00::/8 for a group of friends or inside a company, fd00::/8 is a popular choice in peer-to-peer networks, where they might add 56 bits of a public-key derived hash as an insecure hint towards the owner of a remote party with a given public key.
+1 on the strong words, except that NAPT is to blame, not NAT without port translation. It ports that jump all over the place that break the peer-to-peer idea(l)s. It has long been my goal to go IPv6-only, and I am now developing the containers to make this possible for SIP, including PSTN trunking. Pardon my enthousiasm. I've waited 10 years until IPv6 finally grew up :-) and Twinkle back then was at its end, and not going to do this. |
|
The compromise I'm seriously considering would be to limit each SIP message (or transaction, or dialog, depending on what Twinkle's code will allow) to only one IP version. Basically, when a FQDN resolves to both IPv4 and IPv6 addresses, only the v4 ones would be retained, and the v6 ones would be ignored. (I'd favor this order as the default to avoid the usual "things break when IPv6 is enabled" issues¹, though I suppose there should be a user-profile option to switch it around.) IPv4-only and IPv6-only hosts (including bare IP addresses) would therefore not be affected. While not a perfect solution, this would certainly lift a huge boulder off my shoulders. Are there any objections? ¹ Don't count on |
You can't offer both So, "4 with 4" and "6 with 6" it will be.
Since we don't support the previously-mentioned add-ons, we don't have any choice and must abide to whatever is in the offer. At least this makes things simple. 😄 (Though I'll have to remember, if we ever get an |
On further examination, this would probably need to be a global system setting. (That's not where it should be, but I don't think I'll be able to shoehorn it into a user profile without breaking the whole carton of eggs.) |
|
This makes sense, especially the last one about preferences. Twinkle could be used on a mixed network but connected to an IPv6-only telephony service.
The default should be one of those "Prefer" I think, and which is a matter of taste (where one's taste is likely to develop over time). If you want to go for extra mileage, you might consider these settings separately
Thank you for working on this! I would love to be able to use Twinkle again (and advise it to friends). |
|
Oh, great. It turns out that, despite all appearances, ccRTP never properly worked with IPv6 in the first place; no progress has been made since partial support was added back in 2006. 😞 This is actually what prompted SFLphone (now Jami) to drop ccRTP back in 2015. (Thus leaving Twinkle as its only remaining user, and making it even less likely that further development will ever take place.) Bummer. I suppose the next course of action would be to do like Jami and replace ccRTP with something else; I'll eventually create a separate issue to look at the alternatives. In the meantime, don't hold your breath for a quick resolution, as the bar has now been raised by several notches. |
|
It turns out that, despite all appearances, [ccRTP](https://www.gnu.org/software/ccrtp/) never properly worked with IPv6 in the first place;
I had similar experiences with libosip2; it did not clarify who should remove
what memory, and diving into the code took so much effort that I went on to
code my own SIP parser (which allocates no memory at all, it merely points
into the message).
Bummer.
That sounds like a lot of wasted time/effort :'-(
I suppose the next course of action would be to do like Jami and replace ccRTP with something else; I'll eventually create a separate issue to look at the alternatives. In the meantime, don't hold your breath for a quick resolution, as the bar has now been raised by several notches.
I suggest once more that NLnet.nl has a tendency to support such
efforts. These vital-software-missing problems are a bit part of
what they are hoping to resolve.
I will look into ccRTP and let you know if I know of alternatives.
|
|
I'm starting to feel that this discussion is ending on too-much-work due to the ccRTP stack. Is it an idea to invite the people from this project, and/or related GNU projects, to this discussion and ask them for input? The things being discussed here are usually very motivating for people who embrace the GPL, and it might help them find the motivation to (re)start this work on ccRTP. It's sad if an underlying library stagnates progress towards online freedom, because it gives an impasse to the layers built on top of it. But if the people who built the underlying library are aware of this it may bring the project back to life. I sent an email inviting a small number of people from GNU and ccRTP to this issue. |
|
One work around is to use NAT64 to map an internal private IP to a public IPv6. But this requires a way to tell the SIP engine about the public IPv6 the ip4 is mapped to - i.e. a UI configuration thing. (Or even just a poor documented line in the text config file added with an editor for proof of concept :0) ) |
|
We may have different goals in mind, or we may understand the implications
differently, but:
One work around is to NAT64 to map an internal private IP to a public IPv6.
I think the purpose is to *avoid* NAT and let traffic pass transparantly.
That brings many beneficial changes to SIP telephony.
Adding a layer of NAT is always a hack that usually makes you dependent
of passing traffic through the mapping, reading out traffic to be able
to configure it, possibly writing it to make it work, and you risk
suffering from renaming trouble and so on.
But this requires a way to tell the SIP engine about the public IPv6 the ip4 is mapped to
That sounds like DNS64, the usual companion to NAT64.
I built two solutions for IPv4/IPv6 transition of SIP, and both are better
than the ones you propose. But, given a softphone with presumed IPv6
conncetivity, it's silly. (That's why I've tried to connect to the people
behind ccRTP, and asked them to comment here or, if nothing else remains,
to be explicit about abandoning their stack.)
The two hacks I devised in the past are
- 6bed4 allow the use of IPv6 on any network, including IPv4-only.
It will reach direct connections when the parties are not behind
symmetric NAT, simply by probing if this works, and otherwise
they fall back to a tunnel server (having no other option).
- SIPproxy64 translates SIP-over-IPv4 to/from SIP-over-IPv6 and
also proxies RTP traffic. It can be used to connect phones in
hardware with aged firmware to an IPv6 network. (I am doing
that now, I finally found a telco with a clue about this.)
Both are terrible solutions for a softphone, precisely because it is
SOFT. It's a bad idea to depend an open source libraries that stifle
the software, I suppose. (But let's hope I convinced the ccRTP folks
to make IPv6 support work.)
|
|
I've never actually had to implement NAT64, generally installing tunnels/vpn to bring IPv6 to IP4 only networks and ditching IP4 only apps. So I greatly appreciate your detailed description from experience on why that was probably for the best - despite losing my favorite VOIP desktop app, twinkle. |
|
Hehe:
So I greatly appreciate your detailed description from experience on why that was probably for the best
Yes, pulling in a tunnel is the best bet after having native IPv6.
I think he.net still provides them for free, too.
Tunnels are great but may lower your MTU to below IPv4 habits, while they
often share the same interface. That brings along its own trouble, which
I am discussing elsewhere,
kamailio/kamailio#3119
despite losing my favorite VOIP desktop app, twinkle.
Yes, that is painful for me too. Hence my energy in this thread ;-)
I really would like to see it come alive in this respect!
…-Rick
|
Any migration towards IPv6 (LubosD#6) will require identifying all IP addresses currently represented as `unsigned long`. To this end, we now change their type to one of two newly-introduced `typedef`s: - `IPaddr` for IPv4 addresses in host byte order - `IPNaddr` for IPv4 addresses in network byte order (This also happens to fix a few instances where `unsigned int` was erroneously used.)
|
The discussion of Path MTU discovery in Kamailio came to an interesting conclusion:
|
|
I tried a few angles to tickle the RTP people, and clearly nothing was the result. Is it a wild idea to not depend on abandonware and move to a mature alternative? Then, you might want to look into the libraries underneath baresip,
My suspicion is that you would end up mostly removing code, and doing a very big cleanup. I continue to believe that this project needs IPv6 but am aware that this is an opinion, and therefore personal. But every phone software that holds back the shift to IPv6 represents a user base that is incompatible with free, direct media flows. This means continued care for remote parties who yet have to mature, and falling back on IPv4 as a terrible default platform. And though baresip is a wonderful alternative, not everyone will want to reserve a terminal for their phone. |
|
As an entrance point, the redemo project and specifically its user agent demo give an idea of the work involved. Plenty of callbacks to work with. I had to look a bit for documentation, but found Doxygen annotations inside the source code of the libraries. |
No description provided.
The text was updated successfully, but these errors were encountered: