p2p开发文档 穿透

Internet Draft B. Ford Document: draft-ford-midcom-p2p-01.txt M.I.T. Expires: April 27, 2004 P. Srisuresh Caymas Systems D. Kegel kegel.com October 2003 Peer-to-Peer (P2P) communication across middleboxes Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents the methods used by the current peer-to-peer (P2P) applications to communicate in the presence of middleboxes such as firewalls and network address translators (NAT). In addition, the memo suggests guidelines to application designers and middlebox implementers on the measures they could take to enable immediate, wide deployment of P2P applications with or without requiring the use of special proxy, relay or midcom protocols. Ford, Srisuresh & Kegel [Page 1]  Internet-Draft P2P applications across middleboxes October 2003 Table of Contents 1. Introduction ................................................. 2. Terminology .................................................. 3. Techniques for P2P communication over middleboxes ............ 3.1. Relaying ............................................... 3.2. Connection reversal .................................... 3.3. UDP Hole Punching ...................................... 3.3.1. Peers behind different NATs .................. 3.3.2. Peers behind the same NAT .................... 3.3.3. Peers separated by multiple NATs ............... 3.3.4. Consistent port bindings ....................... 3.4. UDP Port number prediction ............................. 3.5. Simultaneous TCP open .................................. 4. Application design guidelines ................................ 4.1. What works with P2P middleboxes ......................... 4.2. Applications behind the same NAT ........................ 4.3. Peer discovery .......................................... 4.4. TCP P2P applications .................................... 4.5. Use of midcom protocol .................................. 5. NAT design guidelines ........................................ 5.1. Deprecate the use of symmetric NATs ..................... 5.2. Add incremental Cone-NAT support to symmetric NAT devices 5.3. Maintaining consistent port bindings for UDP ports ..... 5.3.1. Preserving Port Numbers ........................ 5.4. Maintaining consistent port bindings for TCP ports ..... 5.5. Large timeout for P2P applications ...................... 6. Security considerations ...................................... 1. Introduction 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. 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 Ford, Srisuresh & Kegel [Page 2]  Internet-Draft P2P applications across middleboxes October 2003 communication model in which hosts on the private internal network can initiate outgoing connections to hosts on the public network, but external hosts cannot 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 benefit. 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. 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. 2. Terminology In this section we first summarize some middlebox terms. We focus here on the two kinds of middleboxes that commonly cause problems for P2P applications. Ford, Srisuresh & Kegel [Page 3]  Internet-Draft P2P applications across middleb