> > Similarly, a TURN server being behind a NAT is irrelevant as long as
> > both peers can contact it. A peer that wishes to be a TURN
> > server but
> > is behind a bad NAT is probably better off not being a TURN server,
> > but that is about it.
>
> The following is another story. For peer to be a TURN server,
> how could TURN
> clients get their allocated transport address belonging to
> the TURN server
> if the TURN server is behind NAT? Because in TURN, the
> allocated address is
> encapsulated in the message and then communicated with the
> clients, but due
> to NAT, the allocated address could not be contacted by the
> clients in the future.
>
> Am I missing soothing?
The TURN server is responsible for obtaining a publicly-routable
address, and giving that address to the TURN client. The TURN
specification, as currently written, expects the TURN server
itself to be on a publicly-routable network ("on the Internet").
If, however, the TURN server is behind a NAT, and we want the
TURN server to still be responsible for obtaining a
publicly-routable IP address, you could do that. Here is a
new technique that could be used: the TURN server could use
STUN (or NAT-PMP or UPnP, if there is only one NAT between
the TURN server and the Internet), and obtain a publicly-
routable mapping:
TURN client STUN server NAT TURN server
| | | |
1. |------give me a TURN address------->|----->|
2. | |<--STUN Request--------|
3. | |-STUN Response->|----->|
4. |<-----here is your TURN address------------|
Messages 2-3 are normal STUN request/response messages, and
tell the TURN server a publicly-routable IP address and UDP
port. The IP address and UDP port returned in in the STUN
Response (message 3) is the TURN server's publicly-routable
transport address, and is given to the TURN client in message
4.
For the above message flow to work, the NAT has to be
p2p-friendly, of course -- that is a requirement for a
successful TURN server behind a NAT.
-d
> >
> >
> > The reload-02 section I pointed you to describes this very briefly,
> > but let me try to provide more details. In almost all cases, A and B
> > will be behind friendly NATs. In your particular example, no matter
> > how many STUN servers B uses, it will know two candidate addresses.
> > In A's case, it will know two or maybe three if it has C in its list
> > of STUN servers.
>
> >
> > Two points to note here. First, for peer protocol
> connections, there
> > is no need to gather candidate addresses when you wish to
> establish a
> > new connection because you can do that over time. Second, reload-02
> > suggests that you maintain sets of peers grouped according to the
> > reflexive address they return, then make one query to each when you
> > gather candidates for media connections (or refresh your
> peer protocol
> > addresses).
>
> Thanks for your explanations. You mean that reload-2 uses the
> reflexive
> address from its peers as its peer reflexive address candidate?
>
> What my concern is how the peer learns the reflexive address
> when it just
> joins the overlay? It should find a bootstrap peer? Must the
> bootstrap peer
> have a public address? If not, how could the peer contact
> directly with the
> bootstrap peer?
>
> Another concern is: although a peer could gather candidates
> over time, the
> first reflexive address SHOULD be on the public Internet (If
> bootstrap peer
> has to have a public address). The peer must actively find
> the STUN servers
> and only passively relying on the packets from its peers to
> get reflexive
> candidate is not enough because its peers could not contact
> him directly due
> to NAT.
>
> One more question here is: how do you define p2p-friendly NAT
> in terms of
> filtering behavior? Do you refer to end-point independent filtering or
> others? If it is the case, the security property would be
> sacrificed.
>
> >
> > Now the less common, but important case, is when A or B is behind a
> > p2p unfriendly NAT. Any of your NAT1, NAT2, NAT3 could be
> unfriendly.
> > In this case, what will happen is that A or B will discover that as
> > they make connections with new peers, the number of different
> > reflexive addresses that they see grows. In B's case, it will
> > probably grow infinitely large. In A's case, assuming there is more
> > than Peer C behind NAT 2 with it, if NAT 2 is the
> unfriendly NAT A may
> > observe several peers reporting the same reflexive address because
> > they are also behind NAT2. In these cases, A and B should provide
> > addresses they see repeated as ICE candidates, but there's
> unlikely to
> > be any point in providing a list of every reflexive address
> ever seen.
> >
> > In any event, when ordering the candidates for an ice offer, start
> > with the local address and list the learned addresses in
> the order of
> > their frequency. That will very rarely be more than two.
>
> Whatever method being used to sort the candidate, if two
> candidates in the
> candidate pair is not within the same realm, the connectivity
> check must
> fail, hence the connectivity check time will be prolonged.
>
>
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
