Re: Use of NPTv6 in a mobile service provider network

[Ca By <cb.list6 () gmail com>]

On Mon, Feb 3, 2025 at 12:15 PM Amos Rosenboim via NANOG <nanog () nanog org>
wrote:

> Roland,
>
> Thanks for your comments.
>
> As much as I love to be a network purist who hates state maintenance in
> the core of the network, the sad reality is that these devices are there
> and will remain there for the foreseeable future.
>
> Mobile operators need IPv4 address sharing and many of them choose to do
> it with CGNAT.
>
> Even with IPv6, many of the operators I know of do not allow internet
> initiated traffic towards their subscribers.
> Some of their reasons are even surprisingly valid, such as avoiding
> unnecessary paging in the network.
>
> Regardless of this, my original message as looking to get some deployment
> feedback on NPTv6 in service provider networks.
> Any such feedback is appreciated.


I do not think any service providers have deployed NPTv6 at any scale.

That’s my feedback. You are building something quite bespoke , not best
practice, and should anticipate novel problems.



> Cheers,
>
> Amos
> Sent from my iPhone
>
> On 3 Feb 2025, at 14:41, Dobbins, Roland <Roland.Dobbins () netscout com>
> wrote:
>
>  *External sender - pay attention*
>
> On Feb 3, 2025, at 17:03, Amos Rosenboim via NANOG <nanog () nanog org>
> wrote:
>
> The requirement for state full traffic flow is given by the customer.
>
>
> Organizations sometimes state that they’ve requirements in specializesd
> contexts which are in fact counterproductive; in such cases, they can often
> benefit from education in order to make contextually optimal decisions.
>
> The logic behind it is to avoid unnecessary paging procedures for idle
> mobile devices.
>
>
> ‘Paging procedures’?
>
> It protects both signaling resources of the network and also battery life
> of devices.
>
>
> There are other ways to accomplish this.
>
> This was very relevant in the early 2000s, not sure if it’s relevant for
> today.
>
>
> It was a huge mistake in the late 1990s and early 2000s, as the early GPRS
> and EDGE wireless broadband networks which were implemented in the same
> fashion as poorly-designed, state-ridden enterprise networks constantly
> experienced severe operational problems until they were remediated, one way
> or another.
>
> However it remains a customer requirement.
>
>
> See above.
>
> As for clients recovery from flow interruption - from incidents we had in
> the last few years and observing how fast connection ramp up on the
> alternate devices it seems that clients are recovering very quickly.
>
>
> Introducing stateful firewalls in front of a population of Internet
> broadband clients is a Very Bad Idea.  DDoS attacks are attacks agains
> capacity and/or state; and outbound/crossbound attacks can be just as
> disruptive as inbound attacks.
>
> This precise scenario has played out many times, over the years.  Networks
> which were suboptimally designed in this fashion were either completely
> re-designed in order to be scalable and resilient, removing unnecessary and
> harmful state; were acquired and their brittle, fragile, non-scalable
> state-ridden infrastructure was decommissioned; or went out of business.
>
> The few holdouts in the present day inevitably experience the problems
> described above, and then proceed through the same evolution as other
> network operators with similar architectures.
>
> My main concern is that this customer has pretty traditional mind set and
> never like being the first deployment of any technology.
>
>
> NAT64/DNS64 with 464XLAT  or something along these lines isn’t new
> technology; on the contrary, it’s quite mature, and deployed around the
> world.   It isn’t stateless, but it’s much more scalable than sticking
> stateful firewalls everywhere, heh.
>
> Designing and implementing a broadband access network with this sort of
> architecture isn’t going to end well.  It isn’t beyond the realm of
> possibility that these ‘requirements’ are largely driven by a supplier of
> stateful firewalls, or an internal advocate for same.
>
>
> If you have received this e-mail in error, please notify the system
> manager. This message contains confidential information and is intended
> only for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please notify the
> sender immediately by e-mail if you have received this e-mail by mistake
> and delete this e-mail from your system. If you are not the intended
> recipient you are notified that disclosing, copying, distributing or taking
> any action in reliance on the content of this information is strictly
> prohibited.