IPv6 /64 links (was Re: ipv6 book recommendations?)

Tue Jun 19 13:21:11 UTC 2012

valdis.kletnieks at 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