[NAT] [fwd] comments on draft-ietf-nat-app-guide-05.txt

[Keith Moore <[e-mail]>]

Hi.  several weeks ago I wrote these comments and sent them to 
the author of the draft via private mail. a few days later,
at his suggestion, they were forwarded to the nat list address.  
unfortunately they were blocked by the list software in use
at the time.

so now that the list has been moved, and the restrictions on posting 
removed, I'm resubmitting my comments. I'm sorry this has taken so 
long; I hope they're still useful.

Keith

------- Forwarded Message

To: [e-mail]
Subject: comments on draft-ietf-nat-app-guide-05.txt
cc: [e-mail]
From: Keith Moore <[e-mail]>
Date: Mon, 26 Mar 2001 15:07:49 -0500

Hi.  I've read your draft with interest as I had started writing one 
of my own on a similar topic.  I have the following comments to make:


> Preface:
> 
>    While many common Internet applications will operate cleanly in the
>    presence of Network Address Translators, others suffer from a variety
>    of problems when crossing these devices. This document discusses
>    those things that application designers might wish to consider when
>    designing new protocols. Guidelines are presented herein to help
>    ensure new protocols and applications will, to the extent possible,
>    be compatible with NAT.

a secondary goal might be to help designers realize when their approaches
are (of necessity) incompatible with NAT.  

> 1. Introduction
> 
>    Other documents that describe Network Address Translation (NAT)
>    discuss the Terminology and Considerations [RFC2663] and Protocol
>    Issues [RFC3022], [RFC3027] or discuss the perceived implications of
>    NAT [RFC2993]. 

suggest you delete 'perceived' 

>    All of those relate to various issues with the NAT
>    mechanism and its effects on protocols that already exist. 

not true - 2993 talks about architectural issues in general, which are
not limited to already-deployed protocols.

> It is the
>    focus of this document to instruct authors of new protocols what to
>    think about when designing new protocols such that special handling
>    is not required at NAT gateway points.

Instead of 'instruct' I would say 'inform' or 'suggest'

>    When a protocol is unable to pass cleanly through a NAT, the use of
>    an Application Level Gateway (ALG) can still permit operation of the
>    protocol.  Depending on the encoding used in a protocol, the ALG may
>    be difficult or easy to construct. 

this is a bit misleading in two ways:

1. some, but not all, protocols can work through NAT with an ALG.
   the above text could be read as saying that all protocols can work
   through NAT with an ALG, but this isn't the case.
   
   such ALGs might therefore be easy, difficult, or impossible to construct :)

2. it might be useful to make a distinction between ALGs that were 
   designed and specified in conjunction with a protocol and ALGs that
   were designed after the fact.   if an ALG is necessary, the protocol
   is much more likely to work well with NAT if the ALG is part of the
   protocol design.

   one could argue that a generic ALG is needed, though perhaps this
   document is not the place to do it.

> While adjunct to NAT, the
>    formulation of protocols that cannot directly operate through NAT
>    should be considered such that the ALG design may be simple and
>    automated. ALGs typically operate inside small routers along with the
>    NAT component. Ideally, the ALG should be simple and not require
>    excessive computation or state storage.

I suspect that a bit more could be said about limitations placed on ALGs.
it might be worthwhile to make a separate section in the document for
discussion of ALG design.

>    The same issues in application design that create issues for NAT (and
>    thus can require ALG support) are also issues for firewalls. 

this doesn't seem true to me - there is some overlap between the issues
associated with NATs and firewalls but there seem to be far more 
NAT-specific or firewall-specific issues than issues common to both.

OTOH, if your application deals with NAT issues then it has probably 
covered some of the bases for firewalls also - perhaps you would rather 
say something like:

] Many of the same issues associated with deployment of applications 
] in a network containing firewalls are also issues associated with
] deployment of applications in a network containing NATs.  Thus an
] application which is NAT-friendly is more likely to be firewall-friendly.

but even this is a stretch.  in general the issues associated with
administrative prohibitions on traffic are orthogonal to the issues
associated with operating across multiple addressing realms.
the main things that they have in common are 

- - both firewall configurations and NATs often assume that there is an 
  "inside" and an "outside" and that connections are initiated from 
  "inside".  

- - nats and firewalls both employ ALGs, and the problems caused by those
  ALGs in firewalls are similar to the problem caused by ALGs in NATs.

but neither of these support a generalization to the effect that the
issues are the same for NATs and firewalls.

> An
>    application designer would do well to keep this in mind, as any
>    protocol that does require special handling by NAT or firewall
>    products will be more difficult to deploy than those that require no
>    special handling.

very true.

> 2. Discussion
> 
>    Network Address Translation presents a challenge to some existing
>    applications. It should be possible for developers of new
>    applications to avoid problems if they understand the issues
>    involved. 

this is an over-generalization.  NATs do impair the ability of the network
to support some kinds of applications (with or without ALGs); thus, it is 
not always possible for developers to avoid such problems.  of course it
is useful to make developers aware of those fundamental limitations.

> This document aims to provide the application designer with
>    information on what to do, and what to avoid, when building
>    applications.
> 
>    The proliferation of NAT, especially in homes and small offices
>    cannot be dismissed. The emerging technologies for providing high
>    bandwidth to these types of locations often allow only a single IP
>    address per location.  

the first statement is true; the second one is not.  providing high 
bandwidth has nothing to do with providing only a single IP address; 
furthermore, the technologies employed to make high bandwidth available
to homes and small offices often do allow the use of multiple IP 
addresses.  use of a single IP address is a business/marketing decision,
not an inherent limitation of the bearer technology.

(it is unfortunately true that some of the bearer technologies use the
IP address as both a layer 2 and layer 3 address, thus making it 
slightly more difficult to route multiple IP addresses to a single
port.  but this is not true for all or even most of them)

> As such NAT is a clear choice for connecting
>    more than a single system per location.
> 
>    Clearly the most common problem associated with NAT implementations
>    is the passing of addressing data between stations. Where possible,
>    applications should find alternatives to such schemes. Studying a few
>    existing protocols will serve to highlight the different approaches
>    possible.
> 
>    Two common forms of Traditional NAT exist. With Basic NAT, only the
>    IP addresses of packets are altered by the NAT implementation. Many
>    applications will operate correctly with Basic NAT. The other common
>    form is Network Address Port Translation. With NAPT, both the IP
>    addresses and the source and destination ports (for TCP and UDP) are
>    potentially altered by the gateway. As such, applications passing
>    only port number information will work with Basic NAT, but not with
>    NAPT.
> 
>    Application designers should ensure compatibility with NAPT, as this
>    form of NAT is the most widely deployed. This is also the form of NAT
>    that will likely see the greatest penetration in homes and small
>    offices.

I'd recommend that you separate the description of the barriers that
NAT/NAPTs impose to new applications from recommendations to application
designers.  The reason is that every application is different.  Your 
description of NATs limitations and characteristics are likely to be 
useful to all application designers, but for any particular application
the compromise between efficiency/functionality of the application on
one hand and deployability/NAT-compatibility on the other may need to be
made at a different place than you would recommend.  It's simply not 
appropriate for every application to use TCP and DNS names, and be 
client-server with connectiions coming from inside, etc. 

> 3. Recommendations and Examples
> 
>    When possible, applications designers should strive to avoid the
>    necessity of ALG functions in NAT implementations. Since the same
>    issues apply to firewalls, application designers have added incentive
>    to consider these recommendations.

again, I would reword this not to say what designers "should" do but
to say that certain kinds of designs will be more compatible with NATs
than others.  I would delete the second sentence for reasons given above.

>    Applications that work in such fashion as to not need ALG support
>    will be much easier to deploy, and have the greatest chance of
>    operation on a broad spectrum of NAT implementations.

you might give some more generalizations here.  for example:

(most deployable)
applications that are compatible with NAPTs without needing ALGs
applications that are compatible with NATs without needing ALGs
applications that are compatible with NATs or NAPTs but need ALGs
applications that are compatible with NATs or NAPTs but require
 explicit configuration of the NATs
applications that are incompatible with NATs or NAPTs
(least deployable)

>    Each of the areas called out below are examples of issues to consider
>    when building an application. This list is likely not comprehensive,
>    but does cover a number of important issues and considerations.
> 
> 
>     3.1 Issues and Recommendations affecting all types of Network
>       Address Translators
> 
>     3.1.1. Peer-to-Peer Applications Limitations
> 
>       Peer to peer applications are problematic in a NAT world. Client-
>       server applications are more generally workable. Peer-to-peer
>       applications rely on each peer being reachable as a server for the
>       other to connect to. 

the notion of "server" is probably misleading here  since peer-to-peer
implies no distinction between servers and clients - why not say that
peer-to-peer applications rely on each peer being able to accept 
incoming connections from other peers?

> With NAPT, there are likely many machines
>       behind one address. With other types of NAT such as one-to-one
>       mappings, there is a greater chance of making such applications
>       work.
> 
>       Some implementations of NAT can be made to function for UDP-based
>       peer-to-peer applications such as interactive gaming. This
>       capability is dependent on the methodology used to implement the
>       UDP sessions in the NAT device. If the NAT device tracks the tuple
>       (private address, private port, public port) then it is possible
>       for an outbound UDP packet to establish a channel by which
>       incoming traffic can flow from a source other than that originally
>       contacted by the system. NAT devices which track source and
>       destination IP addresses, in addition to port numbers, will not
>       permit third-party packets. The latter implementation is generally
>       more secure.

I think this is confusing two issues, which are better treated separately: 

1) use of UDP across NATs in general

UDP has problems with some NATs because they don't know what to assume
regarding translation lifetime (actually, they don't know this for TCP 
either, but they think they do).  reportedly some NATs do not deal with
UDP at all, while others implement simple timeout mechanisms.

2) from which side of a 'sessions' must be initiated in order to
   allocate a translation in the NAT  (or open up a pinhole in a firewall)

as you state, a lot of NATs and firewalls expect "clients" to initiate
the connection, but it might be more accurate to say that the connections
must be initiated from 'inside' the NAT or firewall.

>       NAT device implementations could be constructed to have a switch
>       within them, permitting the consumer the ability to select whether
>       they want greater security, or greater ability to run peer-to-peer
>       applications.

I don't think this is a security vs. functionality tradeoff.  address 
translation does little to enhance security, and it's not clear how much 
functionality such a switch could add in any case.  absent explicit 
configuration, a NAPT has no idea how to map addresses for incoming traffic 
where no connection/session state has been established.  a NAT *might* have 
an idea if it is either doing entirely static mapping between two addressing 
domains (I gather this is rare) or if it is already processing some other 
traffic for that host.  a switch might be appropriate for a firewall,
but for a NAT, what would such a switch accomplish?

>     3.1.2. Applications Requiring End-to-End IPSec Will Fail
> 
>       Use of IPSec for end-to-end security will not function in the
>       presence of a NAT implementation. Application designers may want
>       to explore the use of TLS as a mechanism that will traverse NAT
>       cleanly. See [RFC2709] for additional discussion on combining NAT
>       with Tunnel-mode IPSec security on the same device.
> 
>       Some vendors have implemented a pass-through capabilty which
>       permits IPSec tunnel mode from a client in the private realm to
>       communicate with an endpoint in the public realm.
>
>     3.1.3. Use DNS Names, Not IP Addresses In Payload
> 
>       Applications should take care to use fully qualified domain names,
>       rather than IP addresses when referring to IP endpoints. 

again, I would avoid giving advice to application designers.  it's not
always appropriate to use DNS names rather than IP addresses, and 
payloads are not the only issue.  rather, the goal should be to make
application designers aware of the tradeoffs when using IP addresses
vs. DNS names.

Compared to IP routing, DNS lookups are slow, ambiguous, unreliable, 
and prone to misconfiguration.   DNS lookups can often take 30 seconds
or more.  DNS names are routinely used as service names pointing to
several hosts, so a DNS name is less likely to be an unambiguous 
identifier for a host than an IP address.  This also means that 
once two processes in a distributed application have begun communicating
with each other and have established distributed state in particular
processes on particular hosts, a DNS name and port number are not 
sufficient to allow one of those processes to be reached.
Another problem with DNS names is that they are also subject to
multiple layers of translation - due to both proxies and DNS ALG -
so a DNS name is not necessarily less ambiguous than an IP address.
Finally, DNS servers can be attacked in different ways than the routing
system - dependence on on DNS increases vulnerability to attack.

> When
>       endpoints are across a NAT gateway, private addresses must not be
>       allowed to leak to the other endpoint. An example of where this
>       can happen today is with the HTTP and HTML protocols. It is
>       possible for web pages to be specified with numeric IP addresses,
>       rather than with names, for example http://192.168.1.10/index.html
>       could be used as a URL, but would likely create a problem if this
>       address is on a server located behind a NAT gateway. Users outside
>       the gateway would not be able to reach the address 192.168.1.10,
>       and so would not see the page.

http is probably a poor example, even if people are familiar with it.
too many people assume that everything works like HTTP - that other 
applications have (or should have) similar connection lifetimes, 
use TCP, have similar lack of state-sharing between transactions,
etc.
 
>       Further exacerbating the problem is the possibility of duplicate
>       addresses between realms. If a server offers a link with a private
>       address space IP address embedded within it, such as 192.168.1.10,
>       the page referenced may resolve to a system on the local network
>       the browser is on, but would be a completely different server. The
>       resulting confusion to end-users would be significant. Sessions
>       involving multiple NAT implementations would be exceptionally
>       vulnerable to address reuse issues of this sort.

this, I think, is the main point that needs to be made.  the fact that in 
a NATted environment IP addresses are ambiguous is reason enough to be
very careful about  using them.  that doesn't mean, however, that DNS names 
are an acceptable substitute in all cases.

>     3.1.4. Multicast Considerations
> 
>       Not all NAT devices implement multicast routing protocols.
>       Application designers  should verify whether the devices in their
>       networks are able to process multicast traffic if their
>       applications rely on that capability.

how often are application designers the same as the operators of the networks?

in general, it might help to distinguish between two cases for application
design w.r.t. NATs:

- - case where the application is only intended to be deployed in a limited
  environment with known characteristics

- - case where the application is intended to be deployed over the entire
  NAT-extended internet

one of the major contrasts between the pure IP network and the IP network
extended with NATs is that the characteristics of the former are relatively
well-defined and well-known. an application written to work over
IP (or over a service layered on IP) will generally work in the former
environment.  by contrast, a NATted network is not a general purpose network
with well-designed or even entirely predictable characteristics, but instead 
each individual NAT is designed based on assumptions about what kinds of 
applications need to be supported, and often incomplete information about
the needs of those applications.  as such, use of such networks with other 
applications that don't fit the NAT designers' models is always going to be 
a bit chancy.  the purpose of this document is to try to describe what 
NAT designers were assuming.  but there are limitations in doing this
description "after the fact" - different NATs assume different things,
and there are corner cases that cause problems but are hard to pin down.

> 
>     3.1.5. Retention Of Address Mapping
> 
>       With the exception of statically configured NAT bindings,
>       applications should not assume address mapping will be maintained
>       from one session to another. 

you might want to say something about the difference in address mapping
lifetimes between TCP, UDP, and other protocols.

also, the word "session" is used different ways by different folks, and
thus is ambiguous.  the IP stack does not have a session protocol, and
many applications are not based on TCP.  


> An example of this is RSVP, which
>       forms one connection to reserve the resources, then the actual
>       session for which resources were reserved is started. The sessions
>       do not necessarily overlap. There is no guarantee that the NAT
>       implementation will keep the binding association.  As such,
>       applications that rely on subsequent sessions being mapped to the
>       same destination system may not function without an ALG.


I would add a few other recommendations to this section:

1. don't assume that there are only two addressing realms.  in general,
   there can be an arbitrary number of addressing realms, and traffic 
   may traverse any number of NATs between endpoints.

2. don't assume that IP addresses are uniquely tied to a particular host
   or process, or that only one host is using a particular IP address at
   a particular time.  you can lose by making such assumptions even if
   you don't pass the IP address in the payload.

3. don't assume that hosts know their own IP addresses.  similarly,
   don't assume that they know their own DNS names.

> 
>     3.2 Recommendations for NAPT
> 
>       As many of the issues specifically address NAPT issues, this
>       section will group these issues. NAPT is the most common form of
>       NAT in actual deployment in routers, especially in smaller offices
>       and home offices.
> 
>     3.2.1 Realm Specific IP Addresses
> 
>       Avoid the use of IP address and port number information within the
>       payload of packets. While in some cases ALGs will permit such
>       protocols to function, this presupposes every NAT device can be
>       updated in a timely fashion to support a new protocol. Since this
>       is unlikely application writers are urged to avoid addressing
>       information in payloads all together.

I would retitle this section - it invites confusion with RSIP.

as with just addresses, it's not only the use of address+port in payloads
that causes problems.  programs should not assume that address+port is
unique at any given time; they should not depend on well-known ports working;
they should not assume that address+port1 and address+port2 are on the
same host and can be shared by the same process, or access the same files, 
etc.

>     3.2.2 Avoid Session Bundles
> 
>       Independent sessions, such as used by HTTP, are preferred to
>       protocols that attempt to manage a bundle of related sessions,
>       such as FTP.

again, you need to define 'session' or better yet, use a different
word.  if you're talking about tcp connections, say so.

>       In the FTP protocol, port information is passed over one TCP
>       connection and is used to construct a second TCP connection for
>       passing the actual data. Use of a separate connection to transfer
>       the file data makes determination of file end quite simple,
>       however other schemes could be envisioned which could use a single
>       connection.
> 
>       The HTTP protocol, for example, uses a header and content length
>       approach to passing data.  In this model, all data is transferred
>       over the single TCP connection, with the header portion indicating
>       the length of the data to follow. HTTP has evolved to allow
>       multiple objects to be passed on a single connection (thereby
>       cutting the connection establishment overhead). Clearly a new file
>       transfer function could be built that would perform most of the
>       functions of FTP without the need for additional TCP connections.
> 
>       The goal is to keep to single connections where possible. This
>       keeps us from needing to pass addressing information of any sort
>       across the network.

this glosses over a couple of things:

1) multiplexing multiple streams over a single connection is hard
   and there are subtle gotchas that can cause deadlocks

2) HTTP 1.1 does implement multiplexing, but it does it very poorly -
   it should not be held up as an example.

> 
>     3.2.3. Session Bundles Originate From Same End
> 
>       Origination of connections is an important consideration. Where
>       possible, the client should originate all connections. The FTP
>       protocol is the most obvious example, where by default the server
>       opens the data connection to a port on the client (the client
>       having specified the port number via a PORT command over the
>       control TCP session).
> 
>       As pointed out in [RFC1579], the use of the passive open option in
>       FTP (PASV) remedies this situation as the client is responsible
>       for opening the connection in this case. With client-opened
>       connections, the standard functions of NAPT will process the
>       request as it would any other simple TCP connection, and so an ALG
>       is not required.
> 
>       In cases where session bundles are unavoidable, each session in
>       the bundle should originate from the same end station.
> 
>     3.2.4. TCP preferred over UDP
> 
>       NAPT gateways must track which sessions are alive, and flush old
>       sessions. TCP has clear advantages in this area, since there are
>       specific beginning and end of session indicators in the packets
>       (SYN and FIN packets).  

problem is, TCP connection lifetime may not be the same as application
'session' lifetime.  the NAT is assuming they're the same, but they're not.
you might want to add a separate section saying this, which is different
than the issue with UDP.  of course it's well to point out that the 
NAT makes different assumptions regarding lifetime of address bindings  
for TCP than for UDP, but both sets of assumptions are just guesses,
and can cause failures

> While UDP works for some types of
>       applications with NAT, there can be issues when that data is
>       infrequent. Since there is no clean way to know when an end
>       station has finished using a UDP session, NAT implementations use
>       timeouts to guess when a UDP session completes. If an application
>       doesn't send data for a long period of time, the NAT translation
>       may time out.
> 
>       Protocols other than TCP and UDP are workable with Traditional NAT
>       in many cases, provided they are not carrying addressing
>       information.  

this is an overgeneralization - there are many more issues than that.

> For NAPT implementations Use of any protocols other
>       than TCP and UDP should be discouraged.

s/should be discouraged/are unlikely to work/

you might say something about this requiring explicit configuration
when it is possible, and not being possible on all NAPTs.

>       It's important to note that NAT deployments are based on the
>       assumption of a client-server application model, with the clients
>       in the private realm.

and also the assumption that there is a 'inside' vs. 'outside' realm.

but is this true for all NATs?  seems like  an over-generalization.

>     3.2.5. IP Fragmentation
> 
>       Applications should attempt to avoid fragmentation when packets
>       pass over NAPT devices. While not always practical or possible,
>       there are failures that can occur with NAPT. Specifically, if two
>       stations in the private realm pick matching fragmentation
>       identifiers, and talk to the same remote host, it will be
>       impossible to determine which fragments belong to which session.
> 
>       Ideally, applications should limit packet size, use Path MTU
>       Discovery or both.

do NATs universally support PMTU discovery?

>       Some implementations of NAT may implement fragment reassembly
>       prior to Forwarding, however many do not. Application designers
>       are advised to examine the devices they plan to deploy, or to
>       design assuming the devices do not Reassemble fragments.

again, do application designers have any control over the choice of
devices in the network?  they might or might not have any knowledge
of the deployment environment (if it's a limited deployment application)
but will rarely have control or even significant influence.

> 
>     3.3 Issues and recommendations for Basic NAT
> 
>       If only Basic NAT implementations are involved, not NAPT, then
>       many of the issues above do not apply. This form of NAT is not a
>       panacea. 

for that matter, neither is NAPT or any other form of NAT.  but you seem 
to be contrasting NAT with NAPT here and thus implying that NAPT is a 
panacea while NAT is not.  I would just delete this sentence.

> In this case many of the issues still remain, and many
>       protocols will not function correctly without assistance.
> 
>     3.3.1. Use IP and TCP/UDP Headers Alone
> 
>       Applications that use only the information in the IP and TCP or
>       UDP headers for communication (in other words, do not pass any
>       additional addressing information in the payload of the packets),
>       are clearly easier to support in a NAT environment. Where
>       possible, applications designers should try to limit themselves in
>       this area.

this needs a clearer statement.  as written it would appear to mean
(for example) 'use the addresses in the headers for communication rather 
than other information (such as DNS names)'.  clearly you need external
addressing information, if only to get started.  and clearly you sometimes
need other information from these headers.

I think what you want to say is something like: addresses and ports
obtained from the IP, TCP, and UDP headers should only be used for 
sending replies to communications received, and then only for a 
limited time (for TCP, the duration of the connection ; for UDP
it's hard to know what to assume)  

and as I'm fond of pointing out, there are many more hazards than just 
putting IP addresses and/or ports in packet payloads.  so IMHO it's better
to state things in terms of what *can* reasonably be done with addresses
by applications than to say "don't do X".  (and then later "don't do X or 
Y"...and then still later "don't do X, Y, or Z, except on Sundays...")

>       The X windowing system, for example, uses fixed port numbers to
>       address X servers. With X, the server (display) is addressed via
>       ports 6000 through 6000 + n. These map to hostname:0 through
>       hostname:n server displays. Since only the address and port are
>       used, the NAT administrator could map these ports to one or more
>       private addresses, yielding a functioning solution.

I think the lesson here is "don't expect well known ports to work
across NAPTs"  which should be separate from advice about how to
use addresses or ports obtained from IP/TCP/UDP headers.

>       The X example, in the case of NAPT, requires configuration of the
>       NAT implementation. This results in the ability for no more than
>       one station inside the NAT gateway to use such a protocol. This
>       approach to the problem is thus OK for NAT but not recommended for
>       NAPT environments.
> 
>     3.3.2. Avoid Addressing In Payload
> 
>       As with NAPT, transporting IP address and/or port number
>       information in the payload is likely to cause trouble. The IP
>       address and/or port information valid in the realm on one side of
>       a NAT may well be invalid or even refer to different resources on
>       the other side of a NAT gateway.
> 
>     3.4 Bi-directional NAT
> 
>       Bi-directional NAT makes use of DNS mapping of names to point
>       sessions originating outside the private realm to servers in the
>       private realm.  Through use of a DNS-ALG [RFC2694], lookups are
>       performed to find the proper host and packets are sent to that
>       host.
> 
>       Requirements for applications are the same as for Basic NAT.
>       Addresses are mapped one-to-one to servers. Unlike Traditional NAT
>       devices, Bi-directional NAT devices (in conjunction with DNS-ALG)
>       are amenable to peer-to-peer applications.

the last sentence is a gross overgeneralization, as peer-to-peer applications 
do not automatically work over bidirectional NAT.  there are still issues with
address lifetimes and expirations, non-unique host addresses, non-routable
host addresses, etc.  this needs considerably more explanation.

I think you are trying to say that bidi nat devices don't do port translation
and so don't have the set of issues associated with port translations.
but they do still have most of the other issues associated with NATs,
and they introduce a few issues of their own. 

>     3.5 Twice NAT
> 
>       Twice NAT is address translation where both source and destination
>       IP addresses are modified due to addressing conflicts between two
>       private realms. Two bi-directional NAT boxes connected together
>       would essentially perform the same task, though a common address
>       space that is not otherwise used by either private realm would be
>       required.
> 
>       Requirements for applications to work in the Twice NAT environment
>       are the same as for Basic NAT. Addresses are mapped one to one.

I have similar problems with this section as with its predecessor.

> 
>     3.6 Multi-homed NAT
> 
>       Multi-homed NAT is the use of multiple NAT implementations to
>       provide redundancy. The multiple implementations share
>       configuration information so that sessions might continue in the
>       event of a fail-over. Unless the multiple implementations share
>       the same external addresses, sessions will have to restart
>       regardless.
> 
>       Requirements for multi-homed NAT are the same as for Basic NAT or
>       NAPT, depending on how the multi-homed NAT is implemented and
>       configured.
> 
>     3.7 Realm Specific IP (RSIP)
> 
>       Realm Specific IP is described in [RFC2663] and defined in [RSIP]
>       and related documents.  Clients within a private realm using RSIP
>       are aware of the delineation between private and public, and
>       access a server to allocate address (and optionally port)
>       information for use in conversing with hosts in the public realm.
>       By doing this, clients create packets that need not be altered by
>       the RSIP server on their way to the remote host. This technique
>       can permit IPSec to function, and potentially makes any
>       application function as if there were no special processing
>       involved at all.

one problem with RSIP is that it assumes that there are only two realms,
and that all peers of interest are in the 'outside' realm.  at best,
it's like a glorified SOCKS setup - it can provide the illusion of
presence for an application on the public internet but it costs a
lot of complexity and doesn't really address the problems of NAT.
(or for that matter, the problems with the shortage of addresses)

>     3.8 Performance Implications of Address Translation Implementations
> 
>       Resource utilization on the NAT gateway should be considered.  An
>       application that opens and closes many TCP connections, for
>       example, will use up more resources on the NAT router than an
>       application performing all transfers over a single TCP connection.
>       HTTP 1.0 opened a connection for each object on a web page,
>       whereas HTTP 1.1 permits the TCP session to be held open for
>       additional objects that may need to be transferred. Clearly the
>       latter imposes a lower overhead on the NAT gateway, as it is only
>       maintaining state on a single connection instead of multiple
>       connections.
> 
>       New session establishment will typically remain a software
>       function even in implementations where the packet-by-packet
>       translation work is handled by hardware forwarding engines. While
>       high-performance NAT boxes may be built, protocols that open many
>       sessions instead of multiplexing will be slower than those that do
>       not.
> 
>       Applications with different types of data, such as interactive
>       conferencing, require separate streams for the different types of
>       data.  In such cases the protocol needs of each stream must be
>       optimized. While the goal of multiplexing over a single session is
>       preferred, clearly there are cases where this is impractical.
> 
>       The latency of NAT translation overhead is implementation
>       dependent. On a per-packet basis, for established sessions only
>       the source or destination IP address is replaced, the source or
>       destination port (for NAPT) and the checksums for IP, and TCP or
>       UDP are recalculated. The functionality can be efficiently
>       implemented in hardware or software.
> 
> 4. Security Considerations
> 
> 
>    Network Address Translators have implications for IPSec, as noted
>    above.  When application developers are considering whether their
>    applications function with NAT implementations, care should be given
>    to selection of security methodology. Transport Layer Security (TLS)
>    [RFC2246] operates across translation boundaries. End-to-end IPSec
>    will prove problematic in many cases.

there are other security considerations, especially because NATs 
impair the ability of IP addresses to be used for trace information.

Keith

------- End of Forwarded Message


_______________________________________________
nat mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/nat