PF submission stuck waiting for nearly 4 years

[Kristof Provost]

How about pfSense guys

Go convince them that it's useful.

But again, you'll need to come with a justification for the feature request, and we're five pages into this thread and I haven't seen one yet.

 

[zirias@]

you'll need to come with a justification for the feature request, and we're five pages into this thread and I haven't seen one yet.

To be fair, I don't miss the "justification" here. As the purpose of NAT is to make shared IP(v4) addresses as transparent as possible (which means, route as many packets as possible), it just improves NAT. Whether that's still "useful" nowadays, I'll put a question mark there ...

I guess the other problems you mentioned are the real issues: Complex changes to complex code and an old patch that already exhibits quite some bit-rot.

 

[Kristof Provost]

To be fair, I don't miss the "justification" here. As the purpose of NAT is to make shared IP(v4) addresses as transparent as possible (which means, route as many packets as possible), it just improves NAT. Whether that's still "useful" nowadays, I'll put a question mark there ...

I guess the other problems you mentioned are the real issues: Complex changes to complex code and an old patch that already exhibits quite some bit-rot.

"It just improves NAT" is too vague for a justification. What use cases do not work without it? What actual traffic flows are improved by this change? Which application will suddenly work? What performance improvement is there?

Technical issues I can work through, but the question I have is "Is it worth is?". There are any number of other issues I could be working on instead. Why is this more important than a reported panic or potential improvement in packets per second handled?

 

[zirias@]

"It just improves NAT" is too vague for a justification.

Sure, cause that was just my summary/conclusion but then, I'll try to phrase it even more to the point: It allows more packets to find a (sic!) destination that might expect that packet. That's an improvement because NAT typically stands in the way for some sorts of communication (and, always will, as, after all, it's still a "hack").

What use cases do not work without it? What actual traffic flows are improved by this change?

Most likely the typical candidates, like multiplayer games, maybe VOIP stuff, ...

Which application will suddenly work?

IIRC, there was an example in this thread?

What performance improvement is there?

None.

Technical issues I can work through, but the question I have is "Is it worth is?".

Most likely: no? Which I also tried to reason about ... I just tried to draw a clear line between "justification" (why should you consider it at all?), "usefulness" (who would need it for what?) and, well, "is it worth it" (where you compare both the former to the effort of doing it).

There are any number of other issues I could be working on instead. Why is this more important than a reported panic or potential improvement in packets per second handled?

All I can say is: it isn't, and I certainly never claimed it was....

 

[tingo]

Most private customers (mobile and landline) don't even get IPv4 any more. They often don't notice it in typical consumer usage scenarios because they get some tunneled IPv4 with provider-side NAT (CGNAT) instead.

So, this statement is very questionable. It at least depends on what you're looking at.

Your statement is questionable also - it depends on where in the world you look. Here in Norway for example, most customers get a real IPv4 address - unless they are on mobile broadband service. What's more annoying to me is that a few ISP's here don't even provide IPv6 yet - not even when asked. But enough distraction in this thread.

 

[msplsh]

The patch is small enough to review, but wholesale changing from symmetric to full-cone for purposes of STUN assistance seems like it would need a config switch to enable.