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.

Cheers,

Amos
Sent from my iPhone

On 3 Feb 2025, at 14:41, Dobbins, Roland <roland.dobb...@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.

Reply via email to