> Hi, I was reading RFC3022 about Napt last night, and I still dont
>understand one thing about it. From what I understand is that Napt allows
>you to use one single globally unique IP address on the WAN interface of
>your router, and then a large number of local addresses inside your network
>which aren't globally unique.
> Now the router will be able to translate the different traffic streams
>coming from the WAN according to the port on the packet. So if host A inside
>the network wanted to communicate with Host B which is on a different
>outside network, it would directly address the outside site, and the router
>would catch the packet enroute and change the source IP address to the
>router WAN interface IP address and also change the source port to a port of
>the router's discretion.
> Normally, from what I understand, ports are used to multiplex streams
>of traffic across a link. If Host A was using two applications and wanted to
>start a second session with Host B. Would the router allow this? The RFC
>states "While not a common practice, it is possible to have an application
>on a private host establish multiple simutaneous sessions originating from
>the same tuple of (private address, private TU port). In such a case, a
>single binding for the tuple of (private address, private TU port) may be
>used for translation of packets pertaining to all sessions originating from
>the same tuple on a host. How exactly would the applications know which
>traffic stream was for itself?
There's got to be some additional multiplexing above transport.
> Also, how many local hosts can the router assign to a single IP address
>before it has to use a second IP address? Could a company of 100000 use a
>single IP address for NAPT? or would it need to use more than one?
Initial answer: No.
Let's look further. In TCP and UDP, the port field is 16 bits. That
gives a maximum of 64K possible ports. It's generally reasonable to
assume the first 2K are well known, so that leaves a maximum
(ignoring performance issues) of 62K per IP address.
That is a reasonable theoretical maximum for TCP. UDP, however, gets
uglier. Once a given TCP port is committed to a session, it will be
locked to that session until either the session is cleared or there
is a session failure.
For a simple transaction protocol over UDP (e.g., DNS restricted to
one query and a one packet response), you can release the port number
after getting the response. But what if there can be multiple
packets in response, or if there is a quasi-session such as you'd see
with RPC/NFS or SNMP with GET-BULK? Either the NAT has to understand
the higher-layer protocol to know when it can release a port number,
or it can control access with timers. A timer structure might say
"once a port number has been accessed, it can't be reused for N
minutes/hours/etc/, N being a time beyond the reasonable duration of
a quasi-session."
Time-based lockups of port numbers certainly will restrict the number
of ports you have available at any given moment.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
