Next: Virtualizing the Network
Up: Problems Common to All
Previous: Protocol Specific Issues
- FTP
- [8]
The FTP-commands PORT and the response to a PASV both send an IP and
a port to the other party. For FTP to work over a translated connection
we have to replace the IP in the message. The most complicated part
of this is that IP and port are transmitted as their(decimal) ASCII
representation, i.e. each single number of the decimal representation
of the IP is a byte in the packet. For this reason the IP does not
have a fixed length in such FTP-packets. When we now try to replace
the IP by another one that has more (less) digits in its decimal representation
the packet gets larger (smaller). This in turn makes it necessary
to adjust the TCP-sequence numbers accordingly, so that we have to
keep some more information about these connections in order to adjust
the numbers in each subsequent packet of that connection. This is
not just a problem of FTP, but of all protocols where exchanging the
IP changes the packets length.
- ICMP
- [9]
Some ICMP messages, depending on the type of the message, include
a part of the header of the original packet that caused this ICMP
message to be generated, including the entire IP header of that packet.
If the packet had been translated, this header will contain the NAT-IP
rather than the real local IP of the host that gets this ICMP message.
Depending on if and how this extra header information is used this
may present a problem or not.
- DNS
-
Obviously, this service is a major problem if nameservice for internal
IPs shall be provided outside the NAT-domain. A solution would be
to have two DNS-services, one with internal IPs for internal address
resolution and an external one with NAT-IPs. Of course, the IPs resolved
by the external server should not be part of a pool of addresses for
dynamic NAT, as one can easily see. Since NAT-routers are mostly placed
on the borderlines of networks separating internal and external DNS
data makes sense anyway and is widely used for security reasons. If
the far more complicated approach of rewriting all DNS data relayed
by the NAT router is used I would suggest an application level gateway
rather than an implementation inside NAT, because DNS is well suited
for being ``gatewayed'' and we should only put code into the kernel
that is really necessary there.
- BOOTP
-
BOOTP should be no problem most times, because it is very unlikely
that this protocol ever has to cross the border of a NATed network.
- Routing-Protocols
- (RIP, EGP,...)
I do not need to explain why routing protocols are a problem. That
there are a lot of different routing protocols doesnot make it any
easier. The three solution are, again,
- not to use these protocols (static routing only), which may be a good
option anyway since mostly there are few connections from our network
to the outside, and this is the place where NAT routers make the most
sense
- to use an application level gateway
- to rewrite the packets.
Next: Virtualizing the Network
Up: Problems Common to All
Previous: Protocol Specific Issues
Michael Hasenstein
8/22/1997