2015-10-08 6:46 GMT+08:00, Alberto Leiva <[email protected]>: > You did figure hole punching out. It's my opinion on it that confuses you. > >> Not sure I understand correctly, >> it seems you prefer using port randomization to facilitate the hole >> punching process, > > It's the other way around. I do prefer port randomization, but it makes > hole punching difficult. > > As an implementor, I prefer port randomization over hole punching. But > that's just my opinion. > >> in which simultaneous open of TCP connections are >> involved. > > People achieves hole punching by doing a Simultaneous Open. So, for the > purposes of this discussion, think hole punching = Simultaneous Open. > >> I may not able to figure out the hole punching process based >> on port randomization, since port randomization may not can help users >> to discover their exact NAT mapping, also it can't replace outbound >> signalling, e.g., SIP. > > Exactly. Since the port mapping is random, people can't predict it, so they > can't punch the hole.
People could use behave technologies (stun/turn/ice) to determine the port mapping even there is random port mapping. I can't see the difficulty. Am I missing something? > Therefore, a random NAT64 has little reason to have to deal with the > trouble of supporting Simultaneous Open. > > "Dealing with the trouble of supporting Simultaneous Open" is having to > store a fake session and a packet for 6 seconds, and then answer an ICMP > error to the packet. > >> I guess it's similar meaning as for "STATELESS NAT64". There is the >> term. Best reference serving the concept is RFC6145. that's it. > > Fine. But really; what is the problem with using official terms in a formal > document? > > On Wed, Oct 7, 2015 at 9:33 AM, GangChen <[email protected]> wrote: > >> 2015-10-07 13:20 GMT+08:00, Tore Anderson <[email protected]>: >> > * GangChen <[email protected]> >> > >> >> 2015-09-25 4:15 GMT+08:00, Alberto Leiva <[email protected]>: >> >> > "Stateless NAT64" doesn't exist. Or, at the very least, it isn't >> >> > defined in any standards that I have seen. >> >> >> >> RFC7599 may help. >> >> There are several statements, like "It builds on existing stateless >> >> NAT64 techniques specified in [RFC6145],...", "A stateless NAT64 >> >> function [RFC6145] is extended to allow stateless mapping of IPv4 ..." >> > >> > Except for the fact that the RFC7599 is making a false claim here: >> > RFC6145 simply *doesn't* specify «stateless NAT64». As it happens, the >> > only occurrence of the string «NAT64» in RFC6145 is in a reference to >> > RFC6146. >> > >> > Any draft could potentially include a sentence such as «blah blah, the >> > Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah». But that >> > doesn't mean that «ABBP» from that point on becomes a officially >> > correct >> > name for the protocol specified in RFC2460, now does it? >> >> Completely agree. >> >> In another words, RFC2460 may not represent the entire ABBP, but that >> is first thing people flash in their mind, isn't it? >> >> I guess it's similar meaning as for "STATELESS NAT64". There is the >> term. Best reference serving the concept is RFC6145. that's it. >> >> BTW, the statement in this draft is "Stateless NAT is performed in >> compliance with [RFC6145]." So, that is not saying RFC6145 is complete >> stateless nat, but the algorithm for stateless processing is referring >> the RFC6145. >> >> BRs >> Gang >> >> >> >> > Tore >> > >> > _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
