valdis.kletnieks@vt.edu wrote:
And you tell the rest of the world that customer A's SMTP port is on 125, and B's is on 225, and Z's is up at 2097, how?
How? In draft-ohta-e2e-nat-00.txt, I already wrote: A server port number different from well known ones may be specified through mechanisms to specify an address of the server, which is the case of URLs. However, port numbers for DNS and SMTP are, in general, implicitly assumed by DNS and are not changeable. When an ISP operate a NAT gateway, the ISP should, for fairness between customers, reserve some well know port numbers and assign small port numbers evenly to all the customers. Or, a NAT gateway may receive packets to certain ports and behave as an application gateway to end hosts, if request messages to the server contains information, such as domain names, which is the case with DNS, SMTP and HTTP, to demultiplex the request messages to end hosts. However, for an ISP operating the NAT gateway, it may be easier to operate independent servers at default port for DNS, SMTP, HTTP and other applications for their customers than operating application relays.
(HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff)
As you can see, there is no such problem.
(Totally overlooking the debugging issues that arise when a customer tries to run a combination of applications that in aggregate have 101 ports open..)
The applications are broken, if they can't handle temporally error of EAGAIN to use the 101st port. Unlike legacy NAT, where no error can be returned for failed port allocation, end to end NAT can take care of the situation. Masataka Ohta