rfc3022.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

5.2. Private address space recommendation

   [RFC 1918] has recommendations on address space allocation for
   private networks.  Internet Assigned Numbers Authority (IANA) has
   three blocks of IP address space, namely 10.0.0.0/8, 172.16.0.0/12,
   and 192.168.0.0/16 for private internets.  In pre-CIDR notation, the
   first block is nothing but a single class A network number, while the
   second block is a set of 16 contiguous class B networks, and the
   third block is a set of 256 contiguous class C networks.

   An organization that decides to use IP addresses in the address space
   defined above can do so without any coordination with IANA or an
   Internet registry.  The address space can thus be used privately by




Srisuresh & Egevang          Informational                     [Page 11]

RFC 3022                    Traditional NAT                 January 2001


   many independent organizations at the same time, with NAT operation
   enabled on their border routers.

5.3. Routing Across NAT

   The router running NAT should not advertise the private networks to
   the backbone.  Only the networks with global addresses may be known
   outside the stub.  However, global information that NAT receives from
   the stub border router can be advertised in the stub the usual way.

   Typically, the NAT stub router will have a static route configured to
   forward all external traffic to service provider router over WAN
   link, and the service provider router will have a static route
   configured to forward NAT packets (i.e., those whose destination IP
   address fall within the range of NAT managed global address list) to
   NAT router over WAN link.

5.4. Switch-over from Basic NAT to NAPT

   In Basic NAT setup, when private network nodes outnumber global
   addresses available for mapping (say, a class B private network
   mapped to a class C global address block), external network access to
   some of the local nodes is abruptly cut off after the last global
   address from the address list is used up.  This is very inconvenient
   and constraining.  Such an incident can be safely avoided by
   optionally allowing the Basic NAT router to switch over to NAPT setup
   for the last global address in the address list.  Doing this will
   ensure that hosts on private network will have continued,
   uninterrupted access to the external nodes and services for most
   applications.  Note, however, it could be confusing if some of the
   applications that used to work with Basic NAT suddenly break due to
   the switch-over to NAPT.

6.0. NAT limitations

   [NAT-TERM] covers the limitations of all flavors of NAT, broadly
   speaking.  The following sub-sections identify limitations specific
   to traditional NAT.

6.1. Privacy and Security

   Traditional NAT can be viewed as providing a privacy mechanism as
   sessions are uni-directional from private hosts and the actual
   addresses of the private hosts are not visible to external hosts.

   The same characteristic that enhances privacy potentially makes
   debugging problems (including security violations) more difficult. If
   a host in private network is abusing the Internet in some way (such



Srisuresh & Egevang          Informational                     [Page 12]

RFC 3022                    Traditional NAT                 January 2001


   as trying to attack another machine or even sending large amounts of
   spam) it is more difficult to track the actual source of trouble
   because the IP address of the host is hidden in a NAT router.

6.2. ARP responses to NAT mapped global addresses on a LAN interface

   NAT must be enabled only on border routers of a stub domain.  The
   examples provided in the document to illustrate Basic NAT and NAPT
   have maintained a WAN link for connection to external router (i.e.,
   service provider router) from NAT router.  However, if the WAN link
   were to be replaced by a LAN connection and if part or all of the
   global address space used for NAT mapping belongs to the same IP
   subnet as the LAN segment, the NAT router would be expected to
   provide ARP support for the address range that belongs to the same
   subnet.  Responding to ARP requests for the NAT mapped global
   addresses with its own MAC address is a must in such a situation with
   Basic NAT setup.  If the NAT router did not respond to these
   requests, there is no other node in the network that has ownership to
   these addresses and hence will go unresponded.

   This scenario is unlikely with NAPT setup except when the single
   address used in NAPT mapping is not the interface address of the NAT
   router (as in the case of a switch-over from Basic NAT to NAPT
   explained in 5.4 above, for example).

   Using an address range from a directly connected subnet for NAT
   address mapping would obviate static route configuration on the
   service provider router.

   It is the opinion of the authors that a LAN link to a service
   provider router is not very common.  However, vendors may be
   interested to optionally support proxy ARP just in case.

6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup

   Translation of outbound TCP/UDP fragments (i.e., those originating
   from private hosts) in NAPT setup are doomed to fail.  The reason is
   as follows.  Only the first fragment contains the TCP/UDP header that
   would be necessary to associate the packet to a session for
   translation purposes.  Subsequent fragments do not contain TCP/UDP
   port information, but simply carry the same fragmentation identifier
   specified in the first fragment.  Say, two private hosts originated
   fragmented TCP/UDP packets to the same destination host.  And, they
   happened to use the same fragmentation identifier.  When the target
   host receives the two unrelated datagrams, carrying same
   fragmentation id, and from the same assigned host address, it is
   unable to determine which of the two sessions the datagrams belong
   to.  Consequently, both sessions will be corrupted.



Srisuresh & Egevang          Informational                     [Page 13]

RFC 3022                    Traditional NAT                 January 2001


7.0. Current Implementations

   Many commercial implementations are available in the industry that
   adhere to the NAT description provided in this document.  Linux
   public domain software contains NAT under the name of "IP
   masquerade".  FreeBSD public domain software has NAPT implementation
   running as a daemon.  Note however that Linux source is covered under
   the GNU license and  FreeBSD software is covered under the UC
   Berkeley license.

   Both Linux and FreeBSD software are free, so you can buy CD-ROMs for
   these for little more than the cost of distribution.  They are also
   available on-line from a lot of FTP sites with the latest patches.

8.0. Security Considerations

   The security considerations described in [NAT-TERM] for all
   variations of NATs are applicable to traditional NAT.

References

   [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

   [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
              1700, October 1994.

   [RFC 1122] Braden, R., "Requirements for Internet Hosts --
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, October 1989.

   [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers",  RFC
              1812, June 1995.

   [FTP]      Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL
              (FTP)", STD 9, RFC 959, October 1985.

   [TCP]      Defense Advanced Research Projects Agency Information
              Processing Techniques Office, "TRANSMISSION CONTROL
              PROTOCOL (TCP) SPECIFICATION", STD 7, RFC 793, September
              1981.



Srisuresh & Egevang          Informational                     [Page 14]

RFC 3022                    Traditional NAT                 January 2001


   [ICMP]     Postel, J., "INTERNET CONTROL MESSAGE (ICMP)
              SPECIFICATION", STD 5, RFC 792, September 1981.

   [UDP]      Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC
              768, August 1980.

   [RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
              Behaviour Today", RFC 2101, February 1997.

Authors' Addresses

   Pyda Srisuresh
   Jasmine Networks, Inc.
   3061 Zanker Road, Suite B
   San Jose, CA 95134
   U.S.A.

   Phone: [phone]
   EMail: [e-mail]


   Kjeld Borch Egevang
   Intel Denmark ApS

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   http:  //www.freeyellow.com/members/kbe























Srisuresh & Egevang          Informational                     [Page 15]

RFC 3022                    Traditional NAT                 January 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Srisuresh & Egevang          Informational                     [Page 16]