Original copyright: CopyRight (c) The Internet Society (2003) .all Rights Reserved.
Original address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
The translation copyright has declaration: Please refer to the author or website of this article indicate: http://blog.9cbs.net/hxhbluestar to respect the translator's labor results! With the arrival of IPv6 era, I have been suspected that there is still necessary to learn NAT technology - because the resources of the network are no longer lacking, and NAT technology exists for the shortage of IP addresses. In this way, NAT does not exist.
However, with the translation of this article, my suspicion slowly turned into a fortunate, gradually became affirmation, through the translation of things, no longer just translating the sense of accomplishment, more More than translation, to understand the wisdom and experience of technical predals, but also to develop the habit of obtaining information from the first-hand information, so that the perspective is wider, let the understanding thoroughly - at least Many things are to truly convert to part of their thoughts after careful consideration. Something, I am firmly to translate this article, as mentioned before, if time is allowed, I will write some examples with C #, let everyone better understand NAT technology, master NAT technology (Mainly involved in instant messaging, document peer transmission and voice application).
This article mainly introduces the cause of the "agent" mechanism and the inconvenience caused by the P2P application, does not need any basic knowledge :)
INTRODUCTION
1 Introduction
Key words:
Middleboxe (s) - I translated into "agent", maybe there is a better translation
Host - I translated into "host", I hope everyone should not understand that the server is a normal terminal.
Present-day Internet has seen ubiquitous deployment of "middleboxes" such as network address translators (NAT), driven primarily by the ongoing depletion of the IPv4 address space. The asymmetric addressing and connectivity regimes established by these middleboxes, however, have created unique problems for peer-to-peer (P2P) applications and protocols, such as teleconferencing and multiplayer on-line gaming. These issues are likely to persist even into the IPv6 world, where NAT is often used as an IPv4 compatibility mechanism [NAT-PT] And FireWalls Will Still Be Commonplace Even After Nat Is No longer Required.
In today's Internet, there is generally used "proxy" device to perform network address translation (NAT), which causes this phenomenon because of the resource depletion crisis of IPv4 address space. Although the address allocation and connectivity system of asymmetric Asymmetric have been defined in the agent, some special issues have been made to the end-to-pending application and protocol. Like a conference and multimedia online games. These problems still exist even in the IPv6 world, because NAT is often used as an IPv4, and [NAT-PT] is often used, and the firewall will still exist, even if NAT technology is no longer required. Currently deployed middleboxes are designed primarily around the client / server paradigm, in which relatively anonymous client machines actively initiate connections to well-connected servers having stable IP addresses and DNS names.
Most middleboxes implement an asymmetric communication model in which hosts on the private internal network can initiate outgoing connections to hosts on the public network, but external hosts can not initiate connections to internal hosts except as specifically configured by the middlebox's administrator. In the common case of NAPT , a client on the internal network does not have a unique IP address on the public Internet, but instead must share a single public IP address, managed by the NAPT, with other hosts on the same private network.The anonymity and inaccessibility of the internal Hosts Behind A Middlebox Is Not a Problem for Client Software Such AS Web Browsers, Which Only Need To Initiate Outgoing Connections. THIS INACCESSIBILITY IS SOMETIMES Seen as a privacy benefits.
The "agent" technology currently used is mainly designed for client / server C / S structures, in order to achieve those clients that need to connect but not fixed IP addresses, can connect to a configuration with fixed IP and DNS domain names. Server. Most "agent" uses an ASYMMTRIC communication model, that is, the host of the private network (LAN) can initiate a "outgoing" connection to connect the host on the public. However, the host on the public online cannot send information to the private network host (unless special configuration for "agent"), NAPT (Network address port conversion) is that a private network client does not need a public security The IP address, but you must share a fixed IP address of the public network controlled by NAPT (of course this NAPT is in the same private network). In this case, these anonymous and seemingly difficult to touch the internal network host after NAT is not a problem for the software like a web browser, because the host of the intranet only needs to initiate a connection to the outside. . In this way, it is impossible to touch or have his advantages - that is to have confidentiality. In the peer-to-peer paradigm, however, Internet hosts that would normally be considered "clients" need to establish communication sessions directly with each other. The initiator and the responder might lie behind different middleboxes with neither endpoint having any permanent IP address or other form of public network presence. A common on-line gaming architecture, for example, is for the participating application hosts to contact a well-known server for initialization and administration purposes. Subsequent to this, the hosts establish direct connections with each other for Fast And Efficient Propagation of Updates During Game Play.
Similarly, a file sharing application might contact a well-known server for resource discovery or searching, but establish direct connections with peer hosts for data transfer. Middleboxes create problems for peer-to-peer connections because hosts behind a middlebox normally have no permanently usable Public Ports on the Internet to Which Incoming TCP OR UDP Connections from Other Peers Can Be Directed.
RFC 3235 [NAT-appl] Briefly Addresses this Issue, But Does Not Offer Any General Solutions.
However, in the application of P2P, "clients" on the Internet need to create a communication session directly. Inviters and responders may be behind different NATs, maybe they do not have IP or even if there is an IP address of the public network. For example, in an ordinary network gaming architecture, it is initialized through a server that initializes a server with a public network fixed IP. At the same time, it is necessary to establish a direct connection between the client, so that the speed of the network is accelerating, ensuring the data instant update (otherwise can't be equipped, huh, huh). Similarly, a file sharing application must also find it to find the resources it wants, and then download (BT website, walking a mediation), "agent" has caused a lot of P2P straight to the host with this data. The problem, because the host hidden after "agent" usually does not have a fixed port to make the TCP or UDP connection initiated by other clients can finally arrive. RFC 3235 [NAT-Appl] briefly refers to this problem, but no solution is given.
In this document we address the P2P / middlebox problem in two ways. First, we summarize known methods by which P2P applications can work around the presence of middleboxes. Second, we provide a set of application design guidelines based on these practices to make P2P applications operate more robustly over currently-deployed middleboxes. Further, we provide design guidelines for future middleboxes to allow them to support P2P applications more effectively. Our focus is to enable immediate and wide deployment of P2P applications requiring to traverse middleboxes.
In this article, we discussed the P2P / agent problem in two ways. First, the outline of the existing P2P applications can work in the existing proxy mechanism. We then provide a set of application design guides, based on existing practices, in existing configuration agents, make P2P application operation more organized. Finally, we provide design guidelines that make it more convenient for the P2P application for future proxy mechanisms. The focus of discussion is how direct, extensive configuration of those P2P applications that need to pass through "agents."
The next chapter will introduce academic terminology
