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.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. >
