daima.txt

P2P 编程：UDP穿透NAT的原理与实现（附C++源代码）daima.txt

Ford, Srisuresh & Kegel                                         [Page 5]

Internet-Draft     P2P applications across middleboxes      October 2003


   Symmetric NAT
      A symmetric NAT, in contrast, does not maintain a consistent
      port binding  between (private IP, private port) and (public IP,
      public port) across all sessions. Instead, it assigns a new
      public port to each new session.  For example, suppose Client A
      initiates two outgoing sessions from the same port as above, one
      with S1 and one with S2.  A symmetric NAT might allocate the
      public endpoint 155.99.25.11:62000 to session 1, and then allocate
      a different public endpoint 155.99.25.11:62001, when the
      application initiates session 2.  The NAT is able to differentiate
      between the two sessions for translation purposes because the
      external endpoints involved in the sessions (those of S1
      and S2) differ, even as the endpoint identity of the client 
      application is lost across the address translation boundary.



           Server S1                                     Server S2
        18.181.0.31:1235                              138.76.29.7:1235
               |                                             |
               |                                             |
               +----------------------+----------------------+
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          v 155.99.25.11:62000 v      |      v 155.99.25.11:62001 v
                                      |
                                 Symmetric NAT
                                 155.99.25.11
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          v   10.0.0.1:1234    v      |      v   10.0.0.1:1234    v
                                      |
                                   Client A
                                10.0.0.1:1234

   The issue of cone versus symmetric NAT behavior applies equally 
   to TCP and UDP traffic. 

   Cone NAT is further classified according to how liberally the NAT
   accepts incoming traffic directed to an already-established (public
   IP, public port) pair.  This classification generally applies only to
   UDP traffic, since NATs and firewalls reject incoming TCP
   connection attempts unconditionally unless specifically configured to
   do otherwise.

   Full Cone NAT



Ford, Srisuresh & Kegel                                         [Page 6]

Internet-Draft     P2P applications across middleboxes      October 2003


      After establishing a public/private port binding for a new
      outgoing session, a full cone NAT will subsequently accept
      incoming traffic to the corresponding public port from ANY
      external endpoint on the public network.  Full cone NAT is
      also sometimes called "promiscuous" NAT.

   Restricted Cone NAT
      A restricted cone NAT only forwards an incoming packet directed to
      a public port if its external (source) IP address matches the
      address of a node to which the internal host has previously sent
      one or more outgoing packets.  A restricted cone NAT effectively
      refines the firewall principle of rejecting unsolicited incoming
      traffic, by restricting incoming traffic to a set of "known" 
      external IP addresses.

   Port-Restricted Cone NAT
      A port-restricted cone NAT, in turn, only forwards an incoming
      packet if its external IP address AND port number match those of
      an external endpoint to which the internal host has previously
      sent outgoing packets.  A port-restricted cone NAT provides 
      internal nodes the same level of protection against unsolicited
      incoming traffic that a symmetric NAT does, while maintaining a
      private port's identity across translation.

   Finally, in this document we define new terms for classifying
   the P2P-relevant behavior of middleboxes:

   P2P-Application
      P2P-application as used in this document is an application in
      which each P2P participant registers with a public
      registration server, and subsequently uses either its 
      private endpoint, or public endpoint, or both, to establish
      peering sessions.

   P2P-Middlebox
      A P2P-Middlebox is middlebox that permits the traversal of
      P2P applications. 

   P2P-firewall
      A P2P-firewall is a P2P-Middlebox that provides firewall
      functionality but performs no address translation.

   P2P-NAT
      A P2P-NAT is a P2P-Middlebox that provides NAT functionality, and
      may also provide firewall functionality. At minimum, a
      P2P-Middlebox must implement Cone NAT behavior for UDP traffic,
      allowing applications to establish robust P2P connectivity using
      the UDP hole punching technique.



Ford, Srisuresh & Kegel                                         [Page 7]

Internet-Draft     P2P applications across middleboxes      October 2003



   Loopback translation
      When a host in the private domain of a NAT device attempts to
      connect with another host behind the same NAT device using
      the public address of the host, the NAT device performs the 
      equivalent of a "Twice-nat" translation on the packet as
      follows. The originating host's private endpoint is translated
      into its assigned public endpoint, and the target host's public
      endpoint is translated into its private endpoint, before 
      the packet is forwarded to the target host. We refer the above
      translation performed by a NAT device as "Loopback translation".
  
3. Techniques for P2P Communication over middleboxes

   This section reviews in detail the currently known techniques for
   implementing peer-to-peer communication over existing middleboxes,
   from the perspective of the application or protocol designer.

3.1. Relaying

   The most reliable, but least efficient, method of implementing peer-
   to-peer communication in the presence of a middlebox is to make the
   peer-to-peer communication look to the network like client/server
   communication through relaying.  For example, suppose two client
   hosts, A and B, have each initiated TCP or UDP connections with a
   well-known server S having a permanent IP address.  The clients
   reside on separate private networks, however, and their respective
   middleboxes prevent either client from directly initiating a
   connection to the other.

                                Server S
                                   |
                                   |
            +----------------------+----------------------+
            |                                             |
          NAT A                                         NAT B
            |                                             |
            |                                             |
         Client A                                      Client B

   Instead of attempting a direct connection, the two clients can simply
   use the server S to relay messages between them.  For example, to
   send a message to client B, client A simply sends the message to
   server S along its already-established client/server connection, and
   server S then sends the message on to client B using its existing
   client/server connection with B.

   This method has the advantage that it will always work as long as



Ford, Srisuresh & Kegel                                         [Page 8]

Internet-Draft     P2P applications across middleboxes      October 2003


   both clients have connectivity to the server.  Its obvious
   disadvantages are that it consumes the server's processing power and
   network bandwidth unnecessarily, and communication latency between
   the two clients is likely to be increased even if the server is well-
   connected.  The TURN protocol [TURN] defines a method of implementing
   relaying in a relatively secure fashion.













































Ford, Srisuresh & Kegel                                         [Page 9]

Internet-Draft     P2P applications across middleboxes      October 2003


3.2. Connection reversal

   The second technique works if only one of the clients is behind a
   middlebox.  For example, suppose client A is behind a NAT but client
   B has a globally routable IP address, as in the following diagram:

                                Server S
                            18.181.0.31:1235
                                   |
                                   |
            +----------------------+----------------------+
            |                                             |
          NAT A                                           |
    155.99.25.11:62000                                    |
            |                                             |
            |                                             |
         Client A                                      Client B
      10.0.0.1:1234                               138.76.29.7:1234

   Client A has private IP address 10.0.0.1, and the application is
   using TCP port 1234.  This client has established a connection with
   server S at public IP address 18.181.0.31 and port 1235.  NAT A has
   assigned TCP port 62000, at its own public IP address 155.99.25.11,
   to serve as the temporary public endpoint address for A's session
   with S: therefore, server S believes that client A is at IP address
   155.99.25.11 using port 62000.  Client B, however, has its own
   permanent IP address, 138.76.29.7, and the peer-to-peer application
   on B is accepting TCP connections at port 1234.

   Now suppose client B would like to initiate a peer-to-peer
   communication session with client A.  B might first attempt to
   contact client A either at the address client A believes itself to
   have, namely 10.0.0.1:1234, or at the address of A as observed by
   server S, namely 155.99.25.11:62000.  In either case, however, the
   connection will fail.  In the first case, traffic directed to IP
   address 10.0.0.1 will simply be dropped by the network because
   10.0.0.1 is not a publicly routable IP address.  In the second case,
   the TCP SYN request from B will arrive at NAT A directed to port
   62000, but NAT A will reject the connection request because only
   outgoing connections are allowed.