[SAFE] Addressing nested NAT issues for STUN control

[Magnus Westerlund <[e-mail]>]

Hi,

Isn't there a related issue to what is brought up in section 8.1 in that
the STUN client will be able to send packets to that NAT.

If a NAT on the path has the same address as another NAT then you can
only send to the closest one.

STUN Client 192.168.1.2

NAT-A 192.168.1.1/10.0.0.45

NAT-B 10.0.0.1/192.168.1.2

NAT-C 192.168.1.1/192.0.2.53

In this case the STUN client can't send to NAT-B as there is no external
address which routes from STUN client to NAT-B.

Have you thought of this problem? I think this one is more serious as
private address spaces used on the internal side are limited to a few
common ones. And here it is likely that even if the client in the above
example wasn't using 192.168.1.2 then another host in his private
network would.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------


_______________________________________________
SAFE mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/safe