Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org