IPv6 using ULAs

[Brent W. Baccala]

Hi -

As part of my effort to get BBB 2.5.0 working with private addresses, I'm trying to test IPv6 using a Unique Local Address (ULA) block in fd00::/8 and it's not working.

My web browsers (both Chrome and Firefox) are on an Ubuntu 20 virtual machine that has a valid IPv6 address, as does the BBB server on a separate VM.  Yet I don't get any IPv6 addresses in the SIP INVITEs.

I found this little gem on the 'net:

function gather()  {
    const pc = new RTCPeerConnection();
    navigator.mediaDevices.getUserMedia({audio: true, video: false}).then(stream => {
        pc.onicecandidate = (ev => console.log('icecandidate event:', ev.candidate));  
        pc.addStream(stream);  
        pc.createOffer().then(offer => pc.setLocalDescription(offer));
    });
}

When plugged into the browser's development console, it shows only the local IPv4 address being reported.

Has anybody seen anything like this?  Any idea why the browsers aren't reporting IPv6 addresses?

I've also tried changing to a fake 2600::/8 address space with no luck.

    agape

    brent

[Paulo Lanzarin]

Hi Brent

Certainly some libwebrtc network interface filtering/candidate gathering heuristic.
If I had to guess I'd say they will not gather (nor factor as valid IPs) ULA addresses if there are any other

ipv4/ipv6 regular addresses that can be gathered.

I'll have to check the current libwebrtc code and get back to you.

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/4130cd5c-55a7-4cda-9590-1b1916f5df03n%40googlegroups.com.

[Brent W. Baccala]

OK, some more information.

The problem isn't limited to ULAs.  I've now configured a fully working IPv6 tunnel with global connectivity.  Firefox only reports IPv6 addresses in the SIP INVITEs if I completely disable IPv4 on the system.  Switching DNS to an IPv6 server isn't enough.

The only other way I know of to get IPv6 addresses in my INVITEs is to use my cellphone, which is on Verizon Wireless.

Once I do get IPv6 addresses in my INVITEs, BBB ignores them.  The cellphone uses the public IPv4 address that it's NATed behind, and the VM with no IPv4 connectivity can't connect audio at all.

This isn't too surprising when you look at our current FreeSWITCH SIP profile in external.xml:

    <param name="apply-candidate-acl" value="localnet.auto"/>
    <param name="apply-candidate-acl" value="wan_v4.auto"/>
    <param name="apply-candidate-acl" value="rfc1918.auto"/>
    <param name="apply-candidate-acl" value="any_v4.auto"/>

This is used to prioritize candidate IP addresses.  The first ACL (access control list) that matches is the one that is used.  Since IPv6 doesn't appear anywhere on this list, IPv6 addresses are never used.

Don't be fooled by the appearance of external-ipv6.xml in our SIP profiles directory.  Since all of our SIP sessions from the clients are proxied through nginx, it never gets used.

So... I'm still hoping for a better way to test IPv6 connectivity other than turning off IPv4 completely, and it looks to me now like BBB currently can't operate on an IPv6-only client.

Does this sound right to everyone?  In particular, does anybody know for sure if BBB works on IPv6-only clients?

    agape

    brent

[Gilles Pietri]

Hi,

I haven't looked at 2.5, but I do run 2.4 over IPv6, with the mapping
changed in nginx for freeswitch as documented here:
https://docs.bigbluebutton.org/support/troubleshooting#configure-bigbluebuttonfreeswitch-to-support-ipv6

And... IPv6 sure works, and is properly advertised to Firefox.

You can see the about:webrtc result here (for a month) :
https://fichiers.nantes.cloud/f.php?h=2KRRlpOS&p=1

Regards,
Gilou

[Brent W. Baccala]

Dear Gilou,

Thanks for pointing out that section in the documentation; I hadn't noticed it and it makes a lot of sense.

The image link you posted only shows IPv6 addresses.  Is that system IPv6-only?

If you've make the changes in that documentation link, I'm sure it'll work, and what I'm seeing is that firefox and chrome have to be on an IPv6-only client to use IPv6 addresses for audio.

It sounds like that's consistent with what you're seeing.  Am I correct?

    agape

    brent

[Gilles Pietri]

Le 10/05/2022 à 00:11, Brent W. Baccala a écrit :
> Dear Gilou,
>
> Thanks for pointing out that section in the documentation; I hadn't
> noticed it and it makes a lot of sense.
>
> The image link you posted only shows IPv6 addresses.  Is that system
> IPv6-only?

Hi,

No, this is a dual stack system, but it works the same if I disable
IPv4, IPv6 is tried first by configuration to my knowledge, and
according to what is displayed there! IPv4s (including ULAs) are listed
in the raw candidates, but were discarded.

>
> If you've make the changes in that documentation link, I'm sure it'll
> work, and what I'm seeing is that firefox and chrome have to be on an
> IPv6-only client to use IPv6 addresses for audio.
>
> It sounds like that's consistent with what you're seeing.  Am I correct?

Doesn't seem to be correct, at least Firefox 99 on Ubuntu 20.04 prefers
IPv6, even though IPv4 is available.

Regards,

Gilou

> https://docs.bigbluebutton.org/support/troubleshooting#configure-bigbluebuttonfreeswitch-to-support-ipv6 <https://docs.bigbluebutton.org/support/troubleshooting#configure-bigbluebuttonfreeswitch-to-support-ipv6>

>
> And... IPv6 sure works, and is properly advertised to Firefox.
>
> You can see the about:webrtc result here (for a month) :
> https://fichiers.nantes.cloud/f.php?h=2KRRlpOS&p=1

> <https://fichiers.nantes.cloud/f.php?h=2KRRlpOS&p=1>
>
> Regards,
> Gilou

>
> --
> You received this message because you are subscribed to the Google
> Groups "BigBlueButton-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bigbluebutton-...@googlegroups.com

> <mailto:bigbluebutton-...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bigbluebutton-dev/4b6cec0e-c22c-4a39-9486-decc56674been%40googlegroups.com <https://groups.google.com/d/msgid/bigbluebutton-dev/4b6cec0e-c22c-4a39-9486-decc56674been%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Gilles Pietri
29 avenue de la Libération, F-44400 Rezé
0634745199

[Brent W. Baccala]

On Monday, May 9, 2022 at 6:25:38 PM UTC-4 Gilles Pietri wrote:

> The image link you posted only shows IPv6 addresses.  Is that system
> IPv6-only?

Hi,

No, this is a dual stack system, but it works the same if I disable
IPv4, IPv6 is tried first by configuration to my knowledge, and
according to what is displayed there! IPv4s (including ULAs) are listed
in the raw candidates, but were discarded.

>
> If you've make the changes in that documentation link, I'm sure it'll
> work, and what I'm seeing is that firefox and chrome have to be on an
> IPv6-only client to use IPv6 addresses for audio.
>
> It sounds like that's consistent with what you're seeing.  Am I correct?

Doesn't seem to be correct, at least Firefox 99 on Ubuntu 20.04 prefers
IPv6, even though IPv4 is available.

I've also got Firefox 99 on Ubuntu 20.04.

However, I'm using auto-configured IPv6 addresses that embed the MAC address in the IPv6 address.

Looking at the Firefox source code, there is stuff in there to filter MAC-based addresses and, sure enough, if I add an IPv6 address that isn't auto-configured, then it is reported in the SIP INVITE.

Those addresses are probably filtered for the same privacy issues that gave us ".local" addresses.

Can you confirm that you're not using auto-configured addresses?

    agape

    brent

[Brent W. Baccala]

Possibly relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1661059

[Paulo Lanzarin]

> Possibly relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1661059

FS sticking profiles to signaling transport origin is a FreeSWITCH bug, after all,
and that behavior doesn't work across the board in dual stack environments.
I (and others) haven't found a way to circumvent that in FS itself with either a dual stack
profile of sorts, altered ACLs or traversing through undocumented flags.

What Steffen mentioned in his last comment is true: one of the reasons (but not the only one)
the experimental full audio bridge is being introduced is to circumvent that profile stickiness.

You may want to try it out and see if it works on the setup you're currently debugging - it'd

provide good feedback for the developers involved in that new bridge [me :)].