Page 1 of 1

[ADC-Ext 1.0.8] Improvements to the NATT description

Posted: 11 Jan 2013, 08:44
by Ayo
I've complained a bit about the description of the NATT extension in the DC Dev hub, here are some notes where it can be improved or clarified.

Rather than pointing to the blog entry, which only gives an overview, I propose that the spec links directly to the paper on which the NAT traversal technique is based. E.g. Change:
For more information about NAT traversal, see Passive Mode C-C Connections and NAT Traversal.
Into
This specification is based on the TCP hole punching algorithm described in [1].
1. B. Ford, P. Srisuresh, and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference, pages 179–192, 2005. Online version: http://www.brynosaurus.com/pub/net/p2pnat/
Then, I think it's good to define how the ports work, exactly. Insert this before the "BASE RCM updates". I'm using the same terminology as the paper to avoid confusion.
The "private endpoint" refers to the outbound port to the connected hub, as seen by the client. Each client must listen for incoming connections on this port. Note that this protocol extension uses only this port for the TCP hole punching, the use of the "public endpoint" as specified in [1] is not supported.
I propose that every instance of "outbound port" is replaced with "private endpoint", for the same reason.

Re: Improvements to the NATT description

Posted: 14 Jan 2013, 19:41
by Pretorian
cologic agreed that this is a sane change and the following is how NATT will be in the future (if you agree). (Note that I changed the reference part since no other section uses that type of syntax.) (Bold are changes)
NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in http://www.brynosaurus.com/pub/net/p2pnat/[Peer-to-Peer Communication Across Network Address Translators].

If a client does not support TCP4 or TCP6, it will send an RCM to the client it is trying to connect to. If the other client also doesn't support TCP4 (or TCP6 correspondingly), NAT traversal may instead be used. Signal NATT in the INF's SU field.

Do note that the hub must forward I4 or I6 for respective clients' INF.

The "private endpoint" refers to the outbound port to the connected hub, as seen by the client. Each client must listen for incoming connections on this port. Note that this protocol extension uses only this port for the TCP hole punching, the use of the "public endpoint" as specified in the reference specification is not supported.

==== BASE RCM updates
When receiving an RCM and the client does not support TCP4 or TCP6, and if NAT-T is supported in the remote client, a NAT command should be sent repeating the protocol and token. The port shall be the private endpoint to the connected hub.

==== NAT
NAT protocol port token

Contexts: T

States: NORMAL

Upon receiving this, try and connect to the specified port. An RNT command should be sent repeating the protocol and token. The port shall be the private endpoint to the connected hub. Upon receiving this, try and connect to the specified port.

==== RNT
RNT protocol port token

Contexts: T

States: NORMAL

Upon receiving this, try and connect to the specified port.

==== Example
Client A is connected to hub A with the private endpoint 1000 and client B is connected to hub A with the private endpoint 2000. Client A has the SID AAAA and client B has the SID BBBB.

Re: Improvements to the NATT description

Posted: 14 Jan 2013, 20:36
by Pretorian
If I use the following, I can make a reference... It looks pretty all right...
This specification is based on the TCP hole punching algorithm described in footnoteref:[Peer-to-Peer Communication Across Network Address Translators, B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: http://www.brynosaurus.com/pub/net/p2pnat/].
This will appear in the text as:
This specification is based on the TCP hole punching algorithm described in [1].
This will appear as the following foot note:
1. B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: http://www.brynosaurus.com/pub/net/p2pnat/

Re: Improvements to the NATT description

Posted: 14 Jan 2013, 20:57
by poy
the paper defines an endpoint as an (IP, port) pair, not just a port.

Re: Improvements to the NATT description

Posted: 06 Feb 2013, 16:08
by terminator
hello
nat traversal c-c passive.
i have a problem with the connection:

i'm in one student campus,and the only connections possible is the passive mode n i was trying to make a hub for more students campus n we confront a problem!
if u take a look on the picture from the next link:

Image
CASE 1: we realize than the green line,represent the passive connection with NAT traversal,beetween 2 campus wat it's working is the way passive-passive,
n then we can see the red line what it's represent the same connection passive-passive with NAT traversal,wat is not working because the access on router is limited,n port forward is not possible!
CASE 2: i was trying than 1 client to be in active mode n the other client to be in passive mode,n i realize than the red line working,n the green line is not working!
i want a explanation how is working the CASE 2,n if there is any possibility than in the mode passive-passive with NAT traversal ,to work also the red line?

Re: Improvements to the NATT description

Posted: 23 Feb 2013, 19:05
by Pretorian
I take the no comments as an agreement and I have subsequently added the posted changes to the ADC document for ADC-Ext 1.0.8. See here for the SVN changes.