📄 rfc2993.txt
字号:
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner Networks
------------------ -------------- ----------------
--------
Illustration 2
7.3. TCP state violations
The full range of upper layer architectural assumptions that are
broken by NAT technologies may not be well understood without a very
large-scale deployment, because it sometimes requires the diversity
that comes with large-scale use to uncover unusual failure modes. The
following example illustrates an instance of the problem discussed
above in section 6.
Hain Informational [Page 15]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP|
--------
|
--------
|Internet|
--------
|
---------
| Web |
| Server |
---------
--------
Illustration 3
Host A completes its transaction and closes the web service on TCP
port 80, and the RSIP releases the public side address used for Host
A. Host B attempts to open a connection to the same web service, and
the NAT assigns then next free public side address which is the same
one A just released. The source port selection rules on Host B
happen to lead it to the same choice that A used. The connect
request from Host B is rejected because the web server, conforming to
the TCP specifications, has that 4-tuple in TIME WAIT for 4 minutes.
By the time a call from Host B gets through to the helpdesk
complaining about no access, the requested retry will work, so the
issue is marked as resolved, when it in fact is an on-going, but
intermittent, problem.
7.4. Symmetric state management
Operational management of networks incorporating stateful packet
modifying device is considerably easier if inbound and outbound
packets traverse the same path. (Otherwise it's a headache to keep
state for the two directions synchronized.) While easy to say, even
with careful planning it can be difficult to manage using a
connectionless protocol like IP. The problem of creating redundant
connections is ensuring that routes advertised to the private side
reach the end nodes and map to the same device as the public side
route advertisements. This state needs to persist throughout the
lifetime of sessions traversing the NAT, in spite of frequent or
simultaneous internal and external topology churn. Consider the
following case where the -X- links are broken, or flapping.
Hain Informational [Page 16]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr|
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS|
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
--------
Illustration 4
To preserve a consistent view of routing, the best path to the
Internet for Routers 1 & 2 is via NAT1, while the Internet is told
the path to the address pool managed by the NATs is best found
through NAT1. When the path X1 breaks, Router 2 would attempt to
switch to NAT2, but the external return path would still be through
NAT1. This is because the NAT1 device is advertising availability of
a pool of addresses. Directly connected routers in this same
situation would advertise the specific routes that existed after the
loss. In this case, redundancy was useless.
Consider the case that the path between Router 1 & 2 is up, and some
remote link in the network X2 is down. It is also assumed that DNS
returns addresses for both NATs when queried for Hosts A or B. When
Host D tries to contact Host B, the request goes through NAT2, but
due to the internal routing, the reply is through NAT1. Since the
state information for this connection is in NAT2, NAT1 will provide a
new mapping. Even if the remote path is restored, the connection
will not be made because the requests are to the public IP of NAT2,
while the replies are from the public IP of NAT1.
Hain Informational [Page 17]
RFC 2993 Architectural Implications of NAT November 2000
In a third case, both Host A & B want to contact Host D, when the
remote link X2 in the Internet breaks. As long as the path X1 is
down, Host B is able to connect, but Host A is cut off. Without a
thorough understanding of the remote topology (unlikely since
Internet providers tend to consider that sensitive proprietary
information), the administrator of Hosts A & B would have no clue why
one worked and the other didn't. As far as he can tell the redundant
paths through the NATs are up but only one connection works. Again,
this is due to lack of visibility to the topology that is inherent
when a stateful device is advertising availability to a pool rather
than the actual connected networks.
In any network topology, individual router or link failures may
present problems with insufficient redundancy, but the state
maintenance requirements of NAT present an additional burden that is
not as easily understood or resolved.
7.5. Need for a globally unique FQDN when advertising public services
The primary feature of NATs is the 'simple' ability to connect
private networks to the public Internet. When the private network
exists prior to installing the NAT, it is unlikely and unnecessary
that its name resolver would use a registered domain. As noted in
RFC 1123 [12] DNS queries may be resolved via local multicast.
Connecting the NAT device, and reconfiguring it's resolver to proxy
for all external requests allows access to the public network by
hosts on the private network. Configuring the public DNS for the set
of private hosts that need inbound connections would require a
registered domain (either private, or from the connecting ISP) and a
unique name. At this point the partitioned name space is
concatenated and hosts would have different names based on inside vs.
outside queries.
Hain Informational [Page 18]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS|
--- ---
|NAT|
---
|
-------- ---
|Internet|----|DNS|
-------- ---
|
---
|NAT|
--- ---
|-------------|DNS|
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
--------
Illustration 5
Everything in this simple example will work until an application
embeds a name. For example, a Web service running on Host D might
present embedded URL's of the form http://D/bar.html, which would
work from Host C, but would thoroughly confuse Host A. If the
embedded name resolved to the public address, Host A would be happy,
but Host C would be looking for some remote machine. Using the
public FQDN resolution to establishing a connection from Host C to D,
the NAT would have to look at the destination rather than simply
forwarding the packet out to the router. (Normal operating mode for
a NAT is translate & forward out the other interface, while routers
do not send packets back on the same interface they came from.) The
NAT did not create the name space fragmentation, but it facilitates
attempts to merge networks with independent name administrations.
7.6. L2TP tunnels increase frequency of address collisions
The recent mass growth of the Internet has been driven by support of
low cost publication via the web. The next big push appears to be
support of Virtual Private Networks (VPNs) frequently accomplished
using L2TP. Technically VPN tunnels treat an IP infrastructure as a
multiplexing substrate allowing the endpoints to build what appear to
be clear pathways from end-to-end. These tunnels redefine network
visibility and increase the likelihood of address collision when
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -