On 16/07/2023 11:19, The Natural Philosopher wrote:
> You probably could. SIP works *behind* router NAT.

SIP wasn't designed to work behind NAT. There are various kludges in
SIP implementations to cope with it, and at least one in SIP itself.
Not setting up those kludges properly is the biggest reason for getting
one way, or no way audio, and calls that drop after 32 seconds.

The kludge in SIP itself is rport, which tells the other end to ignore
what it is being told about the initial signalling address, and just
reply to wherever the request appears to have come from.

The cleanest operation tends to happen when the user agents are either
told, or work out, what their public address is and send that in the
protocol.

Other old kludges, are pretending rport was used even when it was not,
ignoring contact headers and using the de facto signalling address, and
assuming media goes to where it comes from, rather than where the
signalling says it goes (only one side can use this tactic).

For WebRTC, there is ICE, which seems to be that the user agent makes
guesses as to the possible correct address for media, and the other side
tries them in turn, stopping if it finds one that works. That can
sometimes result in very slow starts.

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 16/07/2023 11:19, The Natural Philosopher wrote:
>> You probably could. SIP works *behind* router NAT.
>
> SIP wasn't designed to work behind NAT. There are various kludges in
> SIP implementations to cope with it, and at least one in SIP itself.
> Not setting up those kludges properly is the biggest reason for getting
> one way, or no way audio, and calls that drop after 32 seconds.
>
> The kludge in SIP itself is rport, which tells the other end to ignore
> what it is being told about the initial signalling address, and just
> reply to wherever the request appears to have come from.
>
> The cleanest operation tends to happen when the user agents are either
> told, or work out, what their public address is and send that in the
> protocol.
>
> Other old kludges, are pretending rport was used even when it was not,
> ignoring contact headers and using the de facto signalling address, and
> assuming media goes to where it comes from, rather than where the
> signalling says it goes (only one side can use this tactic).
>
> For WebRTC, there is ICE, which seems to be that the user agent makes
> guesses as to the possible correct address for media, and the other side
> tries them in turn, stopping if it finds one that works. That can
> sometimes result in very slow starts.
>

I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
bothered by NAT.

On 28/07/2023 16:53, Tweed wrote:
> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
> bothered by NAT.

They are newer, and at least WhatsApp's protocol in not published.
However one of the ways they are made to work is by going through a
public server, which is, itself, not-natted.

I suspect, also, that ICE came from the tactics they used.

They were designed, from the start, to work with over a consumer
oriented web browsing service, whereas SIP was designed to work on the
internet.

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 28/07/2023 16:53, Tweed wrote:
>> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
>> bothered by NAT.
>
> They are newer, and at least WhatsApp's protocol in not published.
> However one of the ways they are made to work is by going through a
> public server, which is, itself, not-natted.
>
> I suspect, also, that ICE came from the tactics they used.
>
> They were designed, from the start, to work with over a consumer
> oriented web browsing service, whereas SIP was designed to work on the
> internet.
>

ICE?

On Sun, 16 Jul 2023 21:59:20 +1000, Marco Moock <mo01@posteo.de> wrote:

> Am 16.07.2023 um 10:22:08 Uhr schrieb David Wade:
>
>> Just a quick question. I know many of the new Fibre suppliers use
>> CGNAT on their services. I also know this can cause issues with VOIP
>> and SIP in particular, as, for example A&A have a VPN service
>> designed to get round this issue.
>
> Use IPv6 for VoIP and you don't need to care.

> CGNAT makes incoming calls with VoIP mostly impossible.

Bullshit. I joined MyRepublic as soon as they started to get an FTTN
service and they have always used CGNAT and have always provided
a VOIP service which has always worked fine. I also had another VOIP
service with MyNetFone from before that and it continued to work fine,

MyRepublic chose to leave the country and sold their local operation
to SuperLoop which has always used CGNAT and their VOIP and
the MyNetFone VOIP continued to work fine over the CGNAT service.

Never had any setup problem with either of them, completely
automatic with both and the MyNetFone sevice was easy to
setup and use on the iphones too.

On 28/07/2023 16:53, Tweed wrote:
> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>> On 16/07/2023 11:19, The Natural Philosopher wrote:
>>> You probably could. SIP works *behind* router NAT.
>>
>> SIP wasn't designed to work behind NAT. There are various kludges in
>> SIP implementations to cope with it, and at least one in SIP itself.
>> Not setting up those kludges properly is the biggest reason for getting
>> one way, or no way audio, and calls that drop after 32 seconds.
>>
>> The kludge in SIP itself is rport, which tells the other end to ignore
>> what it is being told about the initial signalling address, and just
>> reply to wherever the request appears to have come from.
>>
>> The cleanest operation tends to happen when the user agents are either
>> told, or work out, what their public address is and send that in the
>> protocol.
>>
>> Other old kludges, are pretending rport was used even when it was not,
>> ignoring contact headers and using the de facto signalling address, and
>> assuming media goes to where it comes from, rather than where the
>> signalling says it goes (only one side can use this tactic).
>>
>> For WebRTC, there is ICE, which seems to be that the user agent makes
>> guesses as to the possible correct address for media, and the other side
>> tries them in turn, stopping if it finds one that works. That can
>> sometimes result in very slow starts.
>>
>
> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
> bothered by NAT.
>
They are not peer to peer. A server of a known address is involved that
relays the calls.

The problem with NAT is that it allows outbound connections but makes
very little provision for inbound ones.

SIP worked flawlessly on my VOIP equipped router though, and works on
the new one too. They *are* the NAT, not behind it!

I suspect that is the way it will go, Phone ports in the router for
third party VOIP/SIP or in the fibre modem thingie for locked into
BT/ISP shit
There are boxes that will work inside NAT, and there are ways to accept
incoming connections behind NAT. PnP is one ghastly one.

As with things like ftp transfers in the early days, the router needs to
understand the protocol and accept incoming SYN packets and allow a
remote peer to set up a connection.

Or we all go IPV6 for voip and forget NAT

--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

Tweed wrote:

> David Woolley wrote:
>
>> I suspect, also, that ICE came from the tactics they used.
>
> ICE?

<https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment>

I've never used it, but some SBCs I've installed offer it, either not
using NAT or using STUN has always worked for me.

In uk.telecom Andy Burns <usenet@andyburns.uk> wrote:
> Tweed wrote:
>
> > David Woolley wrote:
> >
> >> I suspect, also, that ICE came from the tactics they used.
> >
> > ICE?
>
> <https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment>
>
> I've never used it, but some SBCs I've installed offer it, either not
> using NAT or using STUN has always worked for me.

I found this useful in understanding:
https://wayback.archive-it.org/20635/20230207091459/https://www.ietfjournal.org/interactive-connectivity-establishment/

Briefly, STUN asks a server on the internet to tell you what IP your packets
came from (roughly like https://whatismyipaddress.com/ but for machines).
Then you can embed that in your packets.

TURN acts as a proxy for your packets, so you send all your audio to the
TURN server and that forwards it. That's expensive.

ICE tries both STUN and TURN at the same time at each end and the sides
then negotiate over which method is best.

This does sound a little like the protocol Skype used in its original P2P
implementation, except that clients were also servers. A client would try
to decide if it was on the public internet and if so announce itself as a
'supernode', and non-internet clients would funnel their traffic through the
nearest supernode. This was a big headache for network managers who
suddenly found somebody running Skype on one of their machines would
suddenly generate a massive spike in traffic.

Theo

On 16/07/2023 14:11, The Natural Philosopher wrote:
> On 16/07/2023 13:26, Jeff Gaines wrote:
>> On 16/07/2023 in message <u90jop$ogqd$1@dont-email.me> The Natural
>> Philosopher wrote:
>>
>>> On 16/07/2023 12:07, Jeff Gaines wrote:
>>>> On 16/07/2023 in message <u90flo$o11e$1@dont-email.me> David Wade
>>>> wrote:
>>>>
>>>>> Its not the Fibre but the suppliers. They were late on the scene in
>>>>> IP terms and so don't have enough routable IPV4 addresses to give
>>>>> one to every user.
>>>>
>>>> What happened to IPV6? It's been here for years but nobody seems to
>>>> use it.
>>>>
>>> It's pretty horrible really.
>>
>> Isn't it just bigger numbers so a lot more available?
>>
> Yes, but no one uses it because no one uses it :-)
>

I use it, alongside IPv4. Quite a few of the UK ISPs will give you both
either by default, or if you ask. BT, Sky, Zen...

--
Brian Gregory (in England).

On 16/07/2023 11:14, David Wade wrote:
> On 16/07/2023 10:28, The Natural Philosopher wrote:
>> On 16/07/2023 10:22, David Wade wrote:
>>> Folks,
>>>
>>> Just a quick question. I know many of the new Fibre suppliers use
>>> CGNAT on their services. I also know this can cause issues with VOIP
>>> and SIP in particular, as, for example A&A have a VPN service
>>> designed to get round this issue.
>>>
>>> So, is this an issue in practice?
>>>
>>> Don't mobile networks also use CGNAT ? is this also an issue for
>>> mobile apps?
>>>
>>> Dave
>>
>> The issue with NAT is that it makes *incoming* opening of TCP/UDP
>> connections harder.
>>
>> Normally an outgoing app will have no issues.
>>
>> Incoming listeners have to register, and maybe keep registering, their
>> (translated) port/IP addresses with some centralised server.
>>
>> That's no different, however, between local NAT and CGNAT...
>>
>>
> SIP needs inbound connections.
> My router has SIP detection and opens and routes the ports as needed.
> I can't do that on the ISPs CGNAT

If the telco that provides you SIP knows what they are doing they will
set things up so that it works fine through NAT and CGNAT. Nearly all
customers are behind NAT now.

You have to set up your telephone or ATA to make an outgoing SIP
connection when powered on and send keep alive packets at intervals, but
it'd be unusual if you have equipment that can't do that.

--
Brian Gregory (in England).

On 16/07/2023 11:48, David Wade wrote:
> On 16/07/2023 11:19, The Natural Philosopher wrote:
>> On 16/07/2023 11:14, David Wade wrote:
>>> SIP needs inbound connections.
>>> My router has SIP detection and opens and routes the ports as needed.
>>> I can't do that on the ISPs CGNAT
>>
>> You probably could. SIP works *behind* router NAT.
>
> If thats the case why do A&A offer a VPN service specially to allow VOIP
> users to by-pass NAT?
>

Maybe there are still some daft SIP providers that refuse to use the
modified versions of SIP and RTP at their end which will work fine
through NAT?

Maybe some users of VoIP like to allow anyone who knows their IP address
to call them for free without involving any phone company?

--
Brian Gregory (in England).

On 16/07/2023 12:59, Marco Moock wrote:
> Am 16.07.2023 um 10:22:08 Uhr schrieb David Wade:
>
>> Just a quick question. I know many of the new Fibre suppliers use
>> CGNAT on their services. I also know this can cause issues with VOIP
>> and SIP in particular, as, for example A&A have a VPN service
>> designed to get round this issue.
>
> Use IPv6 for VoIP and you don't need to care.
> CGNAT makes incoming calls with VoIP mostly impossible.
>

No it doesn't.
Most SIP telcos now accept SIP connection from any port (so NAT doesn't
matter) so you just need to make your equipment keep the SIP connection
to the telco open all the time it is powered on.

--
Brian Gregory (in England).

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 28/07/2023 16:53, Tweed wrote:
>> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>>> On 16/07/2023 11:19, The Natural Philosopher wrote:
>>>> You probably could. SIP works *behind* router NAT.
>>>
>>> SIP wasn't designed to work behind NAT. There are various kludges in
>>> SIP implementations to cope with it, and at least one in SIP itself.
>>> Not setting up those kludges properly is the biggest reason for getting
>>> one way, or no way audio, and calls that drop after 32 seconds.
>>>
>>> The kludge in SIP itself is rport, which tells the other end to ignore
>>> what it is being told about the initial signalling address, and just
>>> reply to wherever the request appears to have come from.
>>>
>>> The cleanest operation tends to happen when the user agents are either
>>> told, or work out, what their public address is and send that in the
>>> protocol.
>>>
>>> Other old kludges, are pretending rport was used even when it was not,
>>> ignoring contact headers and using the de facto signalling address, and
>>> assuming media goes to where it comes from, rather than where the
>>> signalling says it goes (only one side can use this tactic).
>>>
>>> For WebRTC, there is ICE, which seems to be that the user agent makes
>>> guesses as to the possible correct address for media, and the other side
>>> tries them in turn, stopping if it finds one that works. That can
>>> sometimes result in very slow starts.
>>>
>> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely
>> seem
>> bothered by NAT.
>>
> They are not peer to peer. A server of a known address is involved
> that relays the calls.
>
> The problem with NAT is that it allows outbound connections but makes
> very little provision for inbound ones.
>
> SIP worked flawlessly on my VOIP equipped router though, and works on
> the new one too. They *are* the NAT, not behind it!
>
> I suspect that is the way it will go, Phone ports in the router for
> third party VOIP/SIP or in the fibre modem thingie for locked into
> BT/ISP shit
> There are boxes that will work inside NAT, and there are ways to
> accept incoming connections behind NAT. PnP is one ghastly one.
>
> As with things like ftp transfers in the early days, the router needs
> to understand the protocol and accept incoming SYN packets and allow a
> remote peer to set up a connection.
>
> Or we all go IPV6 for voip and forget NAT

I think without NAT one would need a firewall. So using a software phone
or a mobile app there probably is a firewall which might prevent
incoming connections.

On 01/08/2023 12:25, Richmond wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 28/07/2023 16:53, Tweed wrote:
>>> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>>>> On 16/07/2023 11:19, The Natural Philosopher wrote:
>>>>> You probably could. SIP works *behind* router NAT.
>>>>
>>>> SIP wasn't designed to work behind NAT. There are various kludges in
>>>> SIP implementations to cope with it, and at least one in SIP itself.
>>>> Not setting up those kludges properly is the biggest reason for getting
>>>> one way, or no way audio, and calls that drop after 32 seconds.
>>>>
>>>> The kludge in SIP itself is rport, which tells the other end to ignore
>>>> what it is being told about the initial signalling address, and just
>>>> reply to wherever the request appears to have come from.
>>>>
>>>> The cleanest operation tends to happen when the user agents are either
>>>> told, or work out, what their public address is and send that in the
>>>> protocol.
>>>>
>>>> Other old kludges, are pretending rport was used even when it was not,
>>>> ignoring contact headers and using the de facto signalling address, and
>>>> assuming media goes to where it comes from, rather than where the
>>>> signalling says it goes (only one side can use this tactic).
>>>>
>>>> For WebRTC, there is ICE, which seems to be that the user agent makes
>>>> guesses as to the possible correct address for media, and the other side
>>>> tries them in turn, stopping if it finds one that works. That can
>>>> sometimes result in very slow starts.
>>>>
>>> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely
>>> seem
>>> bothered by NAT.
>>>
>> They are not peer to peer. A server of a known address is involved
>> that relays the calls.
>>
>> The problem with NAT is that it allows outbound connections but makes
>> very little provision for inbound ones.
>>
>> SIP worked flawlessly on my VOIP equipped router though, and works on
>> the new one too. They *are* the NAT, not behind it!
>>
>> I suspect that is the way it will go, Phone ports in the router for
>> third party VOIP/SIP or in the fibre modem thingie for locked into
>> BT/ISP shit
>> There are boxes that will work inside NAT, and there are ways to
>> accept incoming connections behind NAT. PnP is one ghastly one.
>>
>> As with things like ftp transfers in the early days, the router needs
>> to understand the protocol and accept incoming SYN packets and allow a
>> remote peer to set up a connection.
>>
>> Or we all go IPV6 for voip and forget NAT
>
> I think without NAT one would need a firewall. So using a software phone
> or a mobile app there probably is a firewall which might prevent
> incoming connections.

I find I do not need incoming connections to receive calls via my VoIP
service. I just set my end to keep a SIP connection to my VoIP service
open all the time.

--
Brian Gregory (in England).

On 01/08/2023 18:10, Brian Gregory wrote:
> I find I do not need incoming connections to receive calls via my VoIP
> service. I just set my end to keep a SIP connection to my VoIP service
> open all the time.
I dont think you exactly understand how TCP/IP works...

SIP does not proxy.

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

On 02/08/2023 17:51, The Natural Philosopher wrote:
> On 01/08/2023 18:10, Brian Gregory wrote:
>> I find I do not need incoming connections to receive calls via my VoIP
>> service. I just set my end to keep a SIP connection to my VoIP service
>> open all the time.
> I dont think you exactly understand how TCP/IP works...

I don't think you understand how modern VoIP works.

Do you seriously think that I have to open a port to the world for any
and all spammers to just connect to my phone and spam me for free?

> SIP does not proxy.
Irrelevant and wrong. Nothing "doesn't proxy" if you build the right proxy.

I receive incoming calls though NAT (or through an IPv6 firewall)
without problems.

--
Brian Gregory (in England).

On 03/08/2023 00:10, Brian Gregory wrote:
> On 02/08/2023 17:51, The Natural Philosopher wrote:
>> On 01/08/2023 18:10, Brian Gregory wrote:
>>> I find I do not need incoming connections to receive calls via my
>>> VoIP service. I just set my end to keep a SIP connection to my VoIP
>>> service open all the time.
>> I dont think you exactly understand how TCP/IP works...
>
> I don't think you understand how modern VoIP works.
>
> Do you seriously think that I have to open a port to the world for any
> and all spammers to just connect to my phone and spam me for free?
>
You already have exactly that on a land line or mobile phone

>> SIP does not proxy.
> Irrelevant and wrong. Nothing "doesn't proxy" if you build the right proxy.
>
Starw man. its not a matter of what you could do, its a matter of how it
currently works

> I receive incoming calls though NAT (or through an IPv6 firewall)
> without problems.
>
Precisely, but you have no idea how that happens, do you?

--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

On 02/08/2023 17:51, The Natural Philosopher wrote:
> On 01/08/2023 18:10, Brian Gregory wrote:
>> I find I do not need incoming connections to receive calls via my VoIP
>> service. I just set my end to keep a SIP connection to my VoIP service
>> open all the time.
> I dont think you exactly understand how TCP/IP works...
>
> SIP does not proxy.
>

Did you mean to say it was connectionless? Large parts of RFC 3261 are
about using proxies with SIP, and bigger users use Session Border
Controllers, which are, I believe, proxy servers.

SIPS can use TCP and TLS, which are connection oriented.

My guess is that Brian really meant that he keeps the dynamic NAT rules
in router open.

Folks,

Just a quick question. I know many of the new Fibre suppliers use CGNAT
on their services. I also know this can cause issues with VOIP and SIP
in particular, as, for example A&A have a VPN service designed to get
round this issue.

So, is this an issue in practice?

Don't mobile networks also use CGNAT ? is this also an issue for mobile
apps?

Dave

On 16/07/2023 10:22, David Wade wrote:
> Folks,
>
> Just a quick question. I know many of the new Fibre suppliers use CGNAT
> on their services. I also know this can cause issues with VOIP and SIP
> in particular, as, for example A&A have a VPN service designed to get
> round this issue.
>
> So, is this an issue in practice?
>
> Don't mobile networks also use CGNAT ? is this also an issue for mobile
> apps?
>
> Dave

I don't see why fibre would imply a move to CGNAT.

--
The theory of Communism may be summed up in one sentence: Abolish all
private property.

Karl Marx

On 16/07/2023 10:22, David Wade wrote:
> Folks,
>
> Just a quick question. I know many of the new Fibre suppliers use CGNAT
> on their services. I also know this can cause issues with VOIP and SIP
> in particular, as, for example A&A have a VPN service designed to get
> round this issue.
>
> So, is this an issue in practice?
>
> Don't mobile networks also use CGNAT ? is this also an issue for mobile
> apps?
>
> Dave

I dont think fibre networks actally use CG NAT, its just dynamically
allocated IPs.

Its the mobile phone networks that use CG NAT.

Some fibre providers do provide an option to have a Static IP, I have a
FREE static IP address provided upon request, this is with Vodafone
Gigafast that is on the City Fibre ALt-Net.

On 16/07/2023 10:22, David Wade wrote:
> Folks,
>
> Just a quick question. I know many of the new Fibre suppliers use CGNAT
> on their services. I also know this can cause issues with VOIP and SIP
> in particular, as, for example A&A have a VPN service designed to get
> round this issue.
>
> So, is this an issue in practice?
>
> Don't mobile networks also use CGNAT ? is this also an issue for mobile
> apps?
>
> Dave

The issue with NAT is that it makes *incoming* opening of TCP/UDP
connections harder.

Normally an outgoing app will have no issues.

Incoming listeners have to register, and maybe keep registering, their
(translated) port/IP addresses with some centralised server.

That's no different, however, between local NAT and CGNAT...

--
Climate Change: Socialism wearing a lab coat.

On 16/07/2023 10:27, SH wrote:
> On 16/07/2023 10:22, David Wade wrote:
>> Folks,
>>
>> Just a quick question. I know many of the new Fibre suppliers use
>> CGNAT on their services. I also know this can cause issues with VOIP
>> and SIP in particular, as, for example A&A have a VPN service designed
>> to get round this issue.
>>
>> So, is this an issue in practice?
>>
>> Don't mobile networks also use CGNAT ? is this also an issue for
>> mobile apps?
>>
>> Dave
>
> I dont think fibre networks actally use CG NAT, its just dynamically
> allocated IPs.
>
> Its the mobile phone networks that use CG NAT.
>
> Some fibre providers do provide an option to have a Static IP, I have a
> FREE static IP address provided upon request, this is with Vodafone
> Gigafast that is on the City Fibre ALt-Net.

There is simply no reason to dynamically allocate IP addresses to
'always on' services.

My fixed IP address is *de rigeur* with IDNET.

--
Future generations will wonder in bemused amazement that the early
twenty-first century’s developed world went into hysterical panic over a
globally average temperature increase of a few tenths of a degree, and,
on the basis of gross exaggerations of highly uncertain computer
projections combined into implausible chains of inference, proceeded to
contemplate a rollback of the industrial age.

Richard Lindzen

On Sun, 16 Jul 2023 10:30:26 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> There is simply no reason to dynamically allocate IP addresses to
> 'always on' services.
>

Indeed not, but it's not easy to get a fixed IP. Salespeople for many
ISPs don't even know what that means, and BT a few years ago were
charging £10 a month for a fixed address on a *business* account.
And a 'fixed' IP address is simply a dynamic one with a reservation,
which takes about two minutes to set up, as a one-off thing.
I'm on Plusnet (oddly, part of BT) which was one of three ISPs I could
find about five years ago offering fixed, and I couldn't afford A&A.

What you can't generally find out in advance is which ISPs have an
interest in staying off email blacklists, and I know for a fact that BT
doesn't. I've advised three former business clients to move away from
BT, and they all suffered for not doing so.

--
Joe

On 16/07/2023 10:26, The Natural Philosopher wrote:
> On 16/07/2023 10:22, David Wade wrote:
>> Folks,
>>
>> Just a quick question. I know many of the new Fibre suppliers use
>> CGNAT on their services. I also know this can cause issues with VOIP
>> and SIP in particular, as, for example A&A have a VPN service designed
>> to get round this issue.
>>
>> So, is this an issue in practice?
>>
>> Don't mobile networks also use CGNAT ? is this also an issue for
>> mobile apps?
>>
>> Dave
>
> I don't see why fibre would imply a move to CGNAT.
>
>

Its not the Fibre but the suppliers. They were late on the scene in IP
terms and so don't have enough routable IPV4 addresses to give one to
every user.

It would be expensive and challenging to obtain more.

So for example by default both City Fibre and Giganet use CGNAT
addresses. They will sell you a fixed routable IP for a monthly fee.

Dave