Simon Perreault wrote:
draft-ford-shared-addressing-issues-02
The Ford Draft is quite liberal in its statements regarding issues with
NAT. Unfortunately, in the real-world, those examples are somewhat fewer
and farther between than the draft RFC would lead you to believe.
Considering how many end-users sit behind NAT firewalls and non-firewall
gateways at home, at work, and at public access points all day without
issue, this is a particularly good example of the IETF's ongoing issues
with design-by-committee, particularly committees short on security
engineering and long on special interest. While LECs and ISPs may or may
not feel some pain from LSN, they're equally sure feel better after
crying all the way to the bank.
IMO,
Roger Marquis
Roger Marquis wrote:
Considering how many end-users sit behind NAT firewalls and non-firewall
gateways at home, at work, and at public access points all day without
issue, this is a particularly good example of the IETF's ongoing issues
with design-by-committee, particularly committees short on security
engineering and long on special interest. While LECs and ISPs may or may
not feel some pain from LSN, they're equally sure feel better after
crying all the way to the bank.
Remove uPNP from those home user nat boxes and see how well the nat to nat connections work. Office firewalls often are heavily restrictive, use proxy layers to deal with connectivity issues and tend to have less typical types of traffic.
Jack
uPNP will not likely be feasible on LSN. So, yes, you need to do your NAT
testing in preparation for LSN on the basis of what works without uPNP.
Owen