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. 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 <phdg...@gmail.com> wrote: > 2015-10-07 13:20 GMT+08:00, Tore Anderson <t...@fud.no>: > > * GangChen <phdg...@gmail.com> > > > >> 2015-09-25 4:15 GMT+08:00, Alberto Leiva <ydah...@gmail.com>: > >> > "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 sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4
