> Am I missing something? No, I was.
Thank you for your time. On Fri, Oct 9, 2015 at 11:19 AM, GangChen <[email protected]> wrote: > 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
