On Thu, Dec 25, 2025 at 11:04 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
On 25.12.2025 10:28 William Herrin <bill@herrin.us> wrote:
- Using any form of NAT / packet translation with IPv6 (not including nat64 / other v4 transition related)
Don't do that, there is enough address space for the customers.
It depends on the price. When you're trying to minimize the price of your service, IPv4 addresses have become one of the expenses you can tweak.
I agree on CGNAT (or other forms of NAT) for IPv4, but not IPv6.
My error; I misread the question.
- TCP MSS - MSS Clamping all connections
- TCP MSS - MSS Clamping, but you instead (accidentally?) set MSS to your desired value even if it was lower before
This is crap. ICMP exists for this and also works for UDP.
With due respect, it's no secret that PMTUD on the Internet is broken. There are just too many ways for that ICMP packet from the middle box to get lost and not all of them are a result of ignorant configuration. PMTUD is one of the very few places that IPv4's designers broke with the end-to-end principle and it shows.
IPv4 is indeed nasty because if the DF bit is not set, a router might fragment and the receiver might not handle that properly. Everything else is handled by ICMP. If people are blocking that, it is their fault.
That's not really on the list of Internet problems with PMTUD. Not a lot of packets without the DF bit set any more. No, the problem is there's lots of reasons for that ICMP packet to get dropped. * No valid route from the complaining router to the packet origin. IP is end-to-end. You're only supposed to have to guarantee routes between the endpoints, not between the midpoints and endpoints. * Complaining router's interface is numbered with RFC1918. Your firewall drops Internet packets FROM RFC1918 space, right? Most folks' do. * Or even 240/4 for large ISPs who've run out of IPv4 addresses. After all, nobody's supposed to be talking TO the router except ISP staff, right? And I haven't even touched the stupid firewall admins who erroneously block all ICMP "because it's ping." There are a lot of them. No, if you don't want the headache of having to deal with every goofy little situation where PMTUD doesn't work and you _know_ you have a link with an MTU under 1500 (common with ISPs using PPPOE to the customer premise equipment) then you clamp the TCP MSS. You don't like it. But you do it anyway because tech support hours are expensive and that results in fewer of them.
- Related to above - Network accepts TCP connection which it will intercept (sends SYN/ACK to user) before it confirms that the destination is reachable
Are you a crappy ISP that really needs to do this?
Geostationary satellite. You HAVE to do things to speed up TCP or the customer feels the pain.
If the customer agrees to that - fine. But as a customer I want to know what interception is being done.
If you're on a geostationary satellite and your TCP connections don't crawl along at kilobits per second then you know something about your TCP connections is being tampered with. TCP doesn't like half-second RTTs. Really doesn't like it. If you're paying the big bucks for a frequency band you can do whatever you want, but if you're on commodity shared satellite you get the service they provide and if you "do not agree" then you can pound sand. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/