Hi Matus, Thanks once again.
That seems to be it. After reading RFC4787 section 4.1 REQ 1, their mention of PAP (Paired-Address-Pooling) seems to be on-point. As they mention: > > NATs that use an "IP address pooling" behavior of "Arbitrary" can cause > issues for applications that use multiple ports from the same endpoint, > but that do not negotiate IP addresses individually (e.g., some > applications using RTP and RTCP). and the REQ 2 mentions the standard recommendation: > > It is RECOMMENDED that a NAT have an "IP address pooling" behavior of > "Paired". Note that this requirement is not applicable to NATs that do not > support IP address pooling. That's the issues we've faced and are attempting to avoid, since it would seem that arbitrary address pooling causes issues for a lot of services when we use multiple external addresses. Are there any plans to implemented PAP? I'm unsure how a clean and efficient implementation would look since we don't want to reserve the entire public IP for a single internal IP, but still attempt to keep traffic over the same external IP. Would a feasible implementation perhaps reserve a number of slots for the internal IP (wasteful)? Would it perhaps make it so that for each new internal user, we bump them to the least-used external address in the vector, so that we lessen the likelihood of running out of ports? It's sadly extremely frustrating that a lot of services depend so much on all connections being from the same IP in order to maintain user authentication, as I'd imagine more service providers migrating to NAT-based solutions (such as for CGN), and PAP doesn't seem to be as efficient as AAP. Thanks, John
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12188): https://lists.fd.io/g/vpp-dev/message/12188 Mute This Topic: https://lists.fd.io/mt/29639823/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
