毕设翻译 网络地址转换技术.doc

毕 业 设 计（论 文）外 文 参 考 资 料 及 译 文译文题目: Network Address Translation Technology 网络地址转换技术 学生姓名： 学号： 专业： 通信工程 所在学院： 指导教师： 职称： 2015年 01月 06 日说明：要求学生结合毕业设计（论文）课题参阅一篇以上的外文资料，并翻译至少一万印刷符（或译出3千汉字）以上的译文。译文原则上要求打印（如手写，一律用400字方格稿纸书写），连同学校提供的统一封面及英文原文装订，于毕业设计（论文）工作开始后2周内完成，作为成绩考核的一部分。Network Address Translation TechnologyFrom” RFC2663-Net Technology ”AbstractNetwork Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.1.Introduction and Overview The need for IP Address translation arises when a networks internal IP addresses cannot be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network.Address translation allows hosts in a private network to transparently communicate with destinations on an external network and vice versa. There are a variety of flavors of NAT and terms to match them. This document attempts to define the terminology used and to identify various flavors of NAT. The document also attempts to describe other considerations applicable to NAT devices in general.Note, however, this document is not intended to describe the operations of individual NAT variations or the applicability of NAT devices.NAT devices attempt to provide a transparent routing solution to end hosts trying to communicate from disparate address realms. This is achieved by modifying end node addresses en-route and maintaining state for these updates so that datagrams pertaining to a session are routed to the right end-node in either realm. This solution only works when the applications do not use the IP addresses as part of the protocol itself. For example, identifying endpoints using DNS names rather than addresses makes applications less dependent of the actual addresses that NAT chooses and avoids the need to also translate payload contents when NAT changes an IP address.The NAT function cannot by itself support all applications transparently and often must co-exist with application level gateway (ALGs) for this reason. People looking to deploy NAT based solutions need to determine their application requirements first and assess the NAT extensions (i.e., ALGs) necessary to provide application transparency for their environment.IPsec techniques which are intended to preserve the Endpoint addresses of an IP packet will not work with NAT enroute for most applications in practice. Techniques such as AH and ESP protect the contents of the IP headers (including the source and destination addresses) from modification. Yet, NATs fundamental role is to alter the addresses in the IP header of a packet.2. Terminology and concepts usedTerms most frequently used in the context of NAT are defined here for reference.2.1. Address realm or realm An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. Note that this document is limited to describing NAT in IPv4 environment and does not address the use of NAT in other types of environment. 2.2. Transparent routingThe term transparent routing is used throughout the document to identify the routing functionality that a NAT device provides. Transparent routing refers to routing a datagram between disparate address realms, by modifying address contents in the IP header to be valid in the address realm into which the datagram is routed.2.3. Session flow vs. Packet flowConnection or session flows are different from packet flows. A session flow indicates the direction in which the session was initiated with reference to a network interface. Packet flow is the direction in which the packet has traveled with reference to a network interface. Take for example, an outbound telnet session. The telnet session consists of packet flows in both inbound and outbound directions. Outbound telnet packets carry terminal keystrokes and inbound telnet packets carry screen displays from the telnet server.For purposes of discussion in this document, a session is defined as the set of traffic that is managed as a unit for translation.TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port). ICMP query sessions are identified by the tuple of (source IP address, ICMP query ID, target IP address). All other sessions are characterized by the tuple of (source IP address, target IP address, IP protocol).Address translations performed by NAT are session based and would include translation of incoming as well as outgoing packets belonging to that session. Session direction is identified by the direction of the first packet of that session.Note, there is no guarantee that the idea of a session, determined as above by NAT, will coincide with the applications idea of a session. An application might view a bundle of sessions (as viewed by NAT) as a single session and might not even view its communication with its peers as a session. Not all applications are guaranteed to work across realms, even with an ALG enroute.2.4. TU ports, Server ports, Client portsFor the reminder of this document, we will refer TCP/UDP ports associated with an IP address simply as TU ports.For most TCP/IP hosts, TU port range 0-1023 is used by servers listening for incoming connections. Clients trying to initiate a connection typically select a source TU port in the range of 1024-65535.However, this convention is not universal and not always followed. Some client stations initiate connections using a source TU port number in the range of 0-1023, and there are servers listening on TU port numbers in the range of 1024-65535.2.5. Start of session for TCP, UDP and othersThe first packet of every TCP session tries to establish a session and contains connection startup information. The first packet of a TCP session may be recognized by the presence of SYN bit and absence of ACK bit in the TCP flags. All TCP packets, with the exception of the first packet, must have the ACK bit set.However, there is no deterministic way of recognizing the start of a UDP based session or any non-TCP session. A heuristic approach would be to assume the first packet with hitherto non-existent session parameters as constituting the start of new session.2.6. End of session for TCP, UDP and othersThe end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives a segment with the RST bit in TCP flags field. However, because it is impossible for a NAT device to know whether the packets it sees will actually be delivered to the destination (they may be dropped between the NAT device and the destination), the NAT device cannot safely assume that the segments containing FINs or SYNs will be the last packets of the session (i.e., there could be retransmissions). Consequently, a session can be assumed to have been terminated only after a period of4 minutes subsequent to this detection. The need for this extended wait period is described in RFC 793, which suggests a TIMEWAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes.Note that it is also possible for a TCP connection to terminate without the NAT device becoming aware of the event (e.g., in the case where one or both peers reboot). Consequently, garbage collection is necessary on NAT devices to clean up unused state about TCP sessions that no longer exist. However, it is not possible in the general case to distinguish between connections that have been idle for an extended period of time from those that no longer exist. In the case of UDP-based sessions, there is no single way to determine when a session ends, since UDP-based protocols are application specific.Many heuristic approaches are used to terminate sessions. You can make the assumption that TCP sessions that have not been used for say, 24 hours, and non-TCP sessions that have not been used for a couple of minutes, are terminated. Often this assumption works, but sometimes it doesnt. These idle period session timeouts vary a great deal both from application to application and for different sessions of the same application. Consequently, session timeouts must be configurable. Even so, there is no guarantee that a satisfactory value can be found.Another way to handle session terminations is to timestamp entries and keep them as long as possible and retire the longest idle session when it becomes necessary.2.7. Public/Global/External networkA Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as External network during NAT discussions.2.8. Private/Local networkA private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT router.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/8, 172.16/12, and 192.168/16 set aside 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 coordination with IANA or any other Internet registry such as APNIC, RIPE and ARIN. The address space can thus be used privately by many independent organizations at the same time. However, if those independent organizations later decide they wish to communicate with each other or the public Internet, they will either have to renumber their networks or enable NAT on their border routers.2.9. Application Level gateway (ALG)Not all applications lend themselves easily to translation by NAT devices; especially those that include IP addresses and TCP/UDP ports in the payload. Application Level Gateways (ALGs) are application specific translation agents that allow an application on a host in one address realm to connect to its counterpart running on a host in different realm transparently. An ALG may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms.ALGs may not always utilize NAT state information. They may glean application payload and simply notify NAT to add additional state information in some cases. ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers. Proxies use a special protocol to communicate with proxy clients and relay client data to servers and vice versa. Unlike Proxies, ALGs do not use a special protocol to communicate with application clients and do not require changes to application clients.3. What is NATNetwork Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. There are many variations of address translation that lend themselves to different applications. However, all flavors of NAT devices should share the following characteristics. a) Transparent Address assignment.b) Transparent routing through address translation. (routing here refers to forwarding packets, and not exchanging routing information)c) ICMP error packet payload translation.网络地址转换技术摘自“RFC2663 文档-网络地址转换技术”摘要网络地址转换是一种方法，通过它可以实现IP地址从一个领域到另一个领域的映射，以试图为主机提供透明的路由功能。传统上，NAT设备被用于连接一个有私有非注册地址的隔离地址域到一个有全局统一注册地址的外部域。本文试图描述NAT设备的操作及相关的一般思考，并定义用于识别各种风格NAT的术语。1介绍和概述当网络的内部IP地址不能被外网使用时,既因为它们在网络外部不能使用，也因内部地址必须保持其对外部网络的私密性，IP地址转换的需求将会提高。地址转换允许私有网络的主机与外部网络上的目的地透明地通信，反之亦然。现有各种风格的NAT和术语与其相匹配。本文试图定义使用的术语，并标识各种风格的NAT。本文还试图描述其它可应用到NAT设备上的一般思考。但是请注意，本文并不旨在描述个别的NAT变化的操作或NAT设备的可应用性。NAT设备试图提供一个透明的路由解决方案来终止主机试图从不同的地址的领域进行通信。这是通过修改终端节点地址单向路由并为这些更新维护状态来达成，因此与某个会话有关的数据报将路由到任何域中的正确端点。这种解决方案仅适用应用不使用的IP地址作为其自身协议一部分的情况下。例如，使用DNS域名而非地址来标识端点将使用应用更少依赖于NAT所选择的实际地址，并避免在NAT修改IP地址时还要求转换其负载内容。NAT功能其本身并不能透明地支持所有的应用，且因该原因必须与应用层网关（ALG）共存。希望部署基于NAT的解决方案的用户需要首先判断他们的应用需求，并评估对NAT的必要扩展（如，ALG），以便提供应用级环境透明度。IPsec技术，用于保护IP分组的端点地址，对大多数实践中的应用而言，将不会与NAT端点路由协同工作。这些技术，如AH和ESP保护IP报头的内容（包括源地址和目的地址）不被修改。然而，NAT的基本作用却是改变分组的IP头部中的地址。2使用术语和概念在NAT内容中最经常使用的术语在这里定义作为参考。2.1地址域或域地址域是网络域，其中网络地址是唯一分配给实体们，由此数据报可能路由到他们。在该网络域中所使用的路由协议有负责发现到这些指定了其网络地址的实体们的路由。要注意，本文仅限于描述IPv4的环境中的NAT，而非说明在其它类型环境中的NAT的用途。 2.2透明路由术语“透明路由”用于整个文档中，标识NAT设备提供的路由功能。透明路由提及在全异的地址域间路由数据报，通过修改IP头部中的地址内容，使其在该数据报将被路由到的地址域中有效。2.3会话流与分组流连接或会话流与分组流不同。会话流是会话参照网络接口被发起的方向。分组流是该分组参照网络接口的方式所旅行的方向。举个例子，一个向外的telnet会话。telnet会话由向内和向外的2个方向的分组流组成。向外的telnet分组携带来自telnet服务器的屏幕显示。为了便于在本文中的讨论，会话定义为流量集并作为转换的单位被管理。TCP/ UDP会话是由4元组（源IP地址、源TCP/ UDP端口号、目标IP地址、目标TCP/ UDP端口号）唯一标识。 ICMP查询会话是由3元组（源IP地址、ICMP查询ID、目标IP地址）标识。所有其它会话表现为3元组（源IP地址、目标IP地址、IP协议）。由NAT执行的地址转换是基于会话的，并将包括转换属于该会话的向内和向外分组。会话方向由该会话的首个分组的方向来标识。请注意，不保证会话概念，如上面由NAT所定义的，将与应用的会话概念相一致。应用可以是会话包（NAT所观察的）为单个会话，但不会使其通讯及其端点为一个会话。不保证所有应用都可跨域工作，即使有ALG端点路由。2.4 TU端口，服务器端口，客户端端口在本文的后面，我们将简单地将与IP地址相关联的TCP/ UDP端口引用为“TU端口”。对于大多数的TCP / IP主机，TU端口范围0-1023由服务器监听到来的连接所使用。客户端通常在1024-65535的范围内选择源TU端口来尝试发起一个连接。然而，约定没有统一，而且并不是始终遵守。一些客户工作站使用0-1023范围内的源TU端口号发起连接，并且有服务器监听在1024-65535范围内的TU端口号上。2.5开始TCP，UDP和其他的会话每一个TCP会话的首个分组试图建立一个会话，并包含连接初始化信息。TCP会话的首个分组可通过在TCP标志中存在SYN位并缺少ACK位来识别。所有TCP分组，除了首个分组，必须设置ACK位。然而，没有确定性的方法来识别基于UDP会话或任何非TCP会话的开始。一种启发方式方法是假设首个分组有迄今为止不存在的会话参数，将其任命为新会话的开始。2.6结束TCP，UDP和其他的会话当会话的双方都通知