From nobody Tue Oct 6 15:10:04 2015 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62E71B382E for ; Tue, 6 Oct 2015 15:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvUYiU5p0aLx for ; Tue, 6 Oct 2015 15:10:00 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939701B4113 for ; Tue, 6 Oct 2015 15:10:00 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so186739419wic.1 for ; Tue, 06 Oct 2015 15:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xXtkjbGE4XbLg6eBcPtvJU0XIcsuhzP0xhoqCw6AtJU=; b=eFIfh1t6zq1Q/kdc0/hQUaB3iPG7HKcF82ulug0KVzS32VP1oujpaPabtHHyQQJkdF pg9WgZbPKZZcmTboUFPSd9IJF82TfIdXB1wtBvDXgBhzIHgc3i9Ud9AU119QjKYEHvrH 2d+kgYVsoRJZ0Af5sSVWbe6KJJCI1om6DR0HpTETafBXBf/yt7ubVQbNOTeM7N3WibY/ B8TYVMhItSpgjtNYtDscR2Y911nGptLDYLBb/Yi1WEsfVpq8E9sGqhVQVrqXpHoLKOCn B1ajnt6atsxPl4h4ykLqRE4AdfemO/YIK32tS/GtmKQCUhbBk9dk/DgnhpRpwIuDKkGg O9hw== MIME-Version: 1.0 X-Received: by 10.194.80.71 with SMTP id p7mr36963363wjx.83.1444169399236; Tue, 06 Oct 2015 15:09:59 -0700 (PDT) Received: by 10.28.130.194 with HTTP; Tue, 6 Oct 2015 15:09:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Oct 2015 06:09:59 +0800 Message-ID: From: GangChen To: Alberto Leiva Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-sunset4-nat64-port-allocation@tools.ietf.org, sunset4@ietf.org Subject: Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 22:10:02 -0000 Hello Alberto, Thank you for reading the draft. 2015-09-25 4:15 GMT+08:00, Alberto Leiva : > Hi > > Regarding Port Randomization: > > Isn't hole punching worth mentioning? This being an analysis and all. Hole > punching is like the "good" counterpart of TCP port-guessing attacks. > > It seems port randomization trumps simultaneous open of TCP connections > (RFC 6146 pp. 28-30), so a random NAT64 could even forego or optional-out > their implementation to avoid its complexity and performance hit (due to > packet storage). > > See > http://ietf.10.n7.nabble.com/Re-Last-Call-draft-ietf-behave-v6v4-xlate-stateful-Stateful-NAT64-Network-Address-and-Protocol > and > http://ietf.10.n7.nabble.com/Re-Review-of-the-NAT64-document-td214997.html I read the discussion you pointed. It seems talking about the impacts of TCP state change on NAT64 to the hole punching (I miss the first link, it's invalid any more). It would be helpful if you could elaborate more on the relation of port randomization and hole punching. Not sure I understand correctly, it seems you prefer using port randomization to facilitate the hole punching process, in which simultaneous open of TCP connections are involved. 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. Would be good to hear you more;) > ------------------------------ > > Also a small nitpick, feel free to ignore: > > Isn't the terminology a bit all over the place? > > In particular > >> Stateless NAT is performed in compliance with [RFC6145]. >> (...) Thus the NAT64 can directly extract the address and has >> no need to record mapping states. > > What do you mean? RFC 6145 is SIIT, which to my knowledge is only > informally (and some might say incorrectly) known as "Stateless NAT64" > (much less "Stateless NAT")... even if it's "network address translating". > > Through the whole document the word "NAT64" is used where "IPv4/IPv6 > translation" would perhaps be more appropriate. > > "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 ..." BRs Gang > Alberto > From nobody Tue Oct 6 22:20:53 2015 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF701A8986 for ; Tue, 6 Oct 2015 22:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAEFMVqp-WYh for ; Tue, 6 Oct 2015 22:20:49 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437801A8981 for ; Tue, 6 Oct 2015 22:20:49 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=42779 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Zjh9e-0006gW-9m; Wed, 07 Oct 2015 07:20:42 +0200 Date: Wed, 7 Oct 2015 07:20:41 +0200 From: Tore Anderson To: GangChen Message-ID: <20151007072041.68bcd4dd@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alberto Leiva , sunset4@ietf.org, draft-ietf-sunset4-nat64-port-allocation@tools.ietf.org Subject: Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 05:20:51 -0000 * GangChen > 2015-09-25 4:15 GMT+08:00, Alberto Leiva : > > "Stateless NAT64" doesn't exist. Or, at the very least, it isn't > > defined in any standards that I have seen. >=20 > 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 =C2=ABstateless NAT64=C2=BB. As it happens= , the only occurrence of the string =C2=ABNAT64=C2=BB in RFC6145 is in a referenc= e to RFC6146. Any draft could potentially include a sentence such as =C2=ABblah blah, the Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah=C2=BB. But that doesn't mean that =C2=ABABBP=C2=BB from that point on becomes a officially = correct name for the protocol specified in RFC2460, now does it? Tore From nobody Wed Oct 7 07:33:28 2015 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28FC1AC430 for ; Wed, 7 Oct 2015 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3jyQCrA7I5J for ; Wed, 7 Oct 2015 07:33:13 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343491AC3FD for ; Wed, 7 Oct 2015 07:33:13 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so215651229wic.1 for ; Wed, 07 Oct 2015 07:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qJ0ccfRIkWzWUPm//pY+ptGom1vxr5fRyBixlFgtVd0=; b=ED5iNC0I+WkZQd6bEqfv7Oxaj1njORxORYlQNHLI2rUHvSAMFuoFop9uaZi5QAOptF cVrNBD6UmWIFNM5kGjiSEMGpOn53d8i/uqZgaQwCzJ/e5XrCxZImz3NjaGRBfjwgaIY0 kB1gl6AS8F2BbVZNf1pzbeyct0jmFWH/evQSW38o/h4m8dbR7Ip0RvsFRbLeij6SejMr reNvUPIgEAsLiBW+7Kg/ub0pw8nppvlJb+MzU1fcpayoT1jIV0NPCizcnGftcHNUykgl MlOlD1HDYp1OSvE7Y2LOK/NjyinZOhTSEVkWL7RdwDJpYQqUpXdFKRS0c4tz3UBjcUsX K2tQ== MIME-Version: 1.0 X-Received: by 10.180.91.194 with SMTP id cg2mr2373852wib.72.1444228391744; Wed, 07 Oct 2015 07:33:11 -0700 (PDT) Received: by 10.28.130.194 with HTTP; Wed, 7 Oct 2015 07:33:11 -0700 (PDT) In-Reply-To: <20151007072041.68bcd4dd@echo.ms.redpill-linpro.com> References: <20151007072041.68bcd4dd@echo.ms.redpill-linpro.com> Date: Wed, 7 Oct 2015 22:33:11 +0800 Message-ID: From: GangChen To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alberto Leiva , sunset4@ietf.org, draft-ietf-sunset4-nat64-port-allocation@tools.ietf.org Subject: Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:33:15 -0000 2015-10-07 13:20 GMT+08:00, Tore Anderson : > * GangChen > >> 2015-09-25 4:15 GMT+08:00, Alberto Leiva : >> > "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 =C2=ABstateless NAT64=C2=BB. As it happe= ns, the > only occurrence of the string =C2=ABNAT64=C2=BB in RFC6145 is in a refere= nce to > RFC6146. > > Any draft could potentially include a sentence such as =C2=ABblah blah, t= he > Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah=C2=BB. But th= at > doesn't mean that =C2=ABABBP=C2=BB from that point on becomes a officiall= y 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 > From nobody Wed Oct 7 15:46:55 2015 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1A81B2A74 for ; Wed, 7 Oct 2015 15:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfHAsrazw1ar for ; Wed, 7 Oct 2015 15:46:51 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283001B2A76 for ; Wed, 7 Oct 2015 15:46:48 -0700 (PDT) Received: by lbbwt4 with SMTP id wt4so27833735lbb.1 for ; Wed, 07 Oct 2015 15:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y1cv+gHyXAQDjplYnjLgZ82CZscUUZwAUp1UZd8JyHA=; b=G3Fz9vQlgGCQnj9v5LujIGwlXuAQA9A0IvHdhJWckOIUqJe2/G9n4E7e0922P3ll49 /wd/5PMHwiOoMPKNbeeRb/0l5yw5NhhCAqP50lukBvkGQWv4XBPSIp0U4fMixZcdb/kS 3XnQqpYeQX4fqvgqZG4QAPg6JoBNZA4mj2cHUSGBCLPrkN8NrXcIaVfBS95h3quLzF4J w/KBwtykg1YrGbi7bF6pDdohulM+Ip9dHqMFw/IHZdbdmwjETAPep+70pnsapMIJiknT ZJuqAEYY/hupkhMN6qf+Apr3SPcW0MxLsaNzoU7vIoLnKJekDrFiYz01V/BDO47O6fu+ MSog== MIME-Version: 1.0 X-Received: by 10.112.157.195 with SMTP id wo3mr1930372lbb.0.1444258006218; Wed, 07 Oct 2015 15:46:46 -0700 (PDT) Received: by 10.112.220.8 with HTTP; Wed, 7 Oct 2015 15:46:46 -0700 (PDT) In-Reply-To: References: <20151007072041.68bcd4dd@echo.ms.redpill-linpro.com> Date: Wed, 7 Oct 2015 17:46:46 -0500 Message-ID: From: Alberto Leiva To: GangChen Content-Type: multipart/alternative; boundary=001a11c3274a6cbe9905218b851e Archived-At: Cc: Tore Anderson , sunset4@ietf.org, draft-ietf-sunset4-nat64-port-allocation@tools.ietf.org Subject: Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 22:46:53 -0000 --001a11c3274a6cbe9905218b851e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D 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 wrote: > 2015-10-07 13:20 GMT+08:00, Tore Anderson : > > * GangChen > > > >> 2015-09-25 4:15 GMT+08:00, Alberto Leiva : > >> > "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 =C2=ABstateless NAT64=C2=BB. As it hap= pens, the > > only occurrence of the string =C2=ABNAT64=C2=BB in RFC6145 is in a refe= rence to > > RFC6146. > > > > Any draft could potentially include a sentence such as =C2=ABblah blah,= the > > Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah=C2=BB. But = that > > doesn't mean that =C2=ABABBP=C2=BB from that point on becomes a officia= lly 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 > > > --001a11c3274a6cbe9905218b851e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You did figure hole punching out. It's my op= inion on it that confuses you.

> Not sure I understand correctly,=
> it seems you prefer using port randomization to facilitate the hol= e
> punching process,

It's the other way around. I do pref= er port randomization, but it makes hole punching difficult.

As an i= mplementor, 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 Simul= taneous Open. So, for the purposes of this discussion, think hole punching = =3D Simultaneous Open.

> I may not able to figure out the hole pu= nching process based
> on port randomization, since port randomizatio= n 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 ca= n'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 referen= ce serving the concept is RFC6145. that's it.

Fine. But re= ally; what is the problem with using official terms in a formal document?

On Wed, O= ct 7, 2015 at 9:33 AM, GangChen <phdgang@gmail.com> wrote:
2015-10-07 13:20 GMT+08:0= 0, Tore Anderson <tore@fud.no>: > * GangChen <phdgang@gmail.com<= /a>>
>
>> 2015-09-25 4:15 GMT+08:00, Alberto Leiva <ydahhrk@gmail.com>:
>> > "Stateless NAT64" doesn't exist. Or, at the ver= y least, it isn't
>> > defined in any standards that I have seen.
>>
>> RFC7599 may help.
>> There are several statements, like "It builds on existing sta= teless
>> NAT64 techniques specified in [RFC6145],...", "A statele= ss 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 =C2=ABstateless NAT64=C2=BB. As i= t happens, the
> only occurrence of the string =C2=ABNAT64=C2=BB in RFC6145 is in a ref= erence to
> RFC6146.
>
> Any draft could potentially include a sentence such as =C2=ABblah blah= , the
> Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah=C2=BB. But= that
> doesn't mean that =C2=ABABBP=C2=BB from that point on becomes a of= ficially 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
>

--001a11c3274a6cbe9905218b851e-- From nobody Fri Oct 9 10:19:06 2015 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347D91B48DA for ; Fri, 9 Oct 2015 10:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwz9kGeHQhoY for ; Fri, 9 Oct 2015 10:19:03 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688991B48DB for ; Fri, 9 Oct 2015 10:19:03 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so76076152wic.1 for ; Fri, 09 Oct 2015 10:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gNe5i9N8SzvFUP2jYZfUJYIagnOCjCd2wjZXKJzO5gw=; b=esdsZBlB1PRK26CBnqOmFP12yvQErN9fgVxdxE/b9r0CzalzwKsirYYBbT9zTj53lm vmhxmVRwy724SCcQSo5sz0Yl8PLT4R5PkaJa+5wuHqly0iuicbnzCTbcKAhaEx5R+vdN q42DlUH0OYcEHSeD0NSL5en1QHSn/i75xWYTWPao/Ofv1h5ngUPJYXp5EOTOVMbXSutl sKPU3adb3q7w2jnoV6hwTInF8RbtULsm4wonHbGzx69SKdWTNkUl9lQCgtsQQgZYLR6z ia6kcaRE+MEVTmbP2j17dd+NoSlQKhxjNwLxp+hTs4F6JeqSenQj4qvVZBGVmbgweXPY 2DxA== MIME-Version: 1.0 X-Received: by 10.180.91.194 with SMTP id cg2mr473750wib.72.1444411142061; Fri, 09 Oct 2015 10:19:02 -0700 (PDT) Received: by 10.28.130.194 with HTTP; Fri, 9 Oct 2015 10:19:01 -0700 (PDT) In-Reply-To: References: <20151007072041.68bcd4dd@echo.ms.redpill-linpro.com> Date: Sat, 10 Oct 2015 01:19:01 +0800 Message-ID: From: GangChen To: Alberto Leiva Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Tore Anderson , sunset4@ietf.org, draft-ietf-sunset4-nat64-port-allocation@tools.ietf.org Subject: Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 17:19:05 -0000 2015-10-08 6:46 GMT+08:00, Alberto Leiva : > 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 =3D 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 th= ey > 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 form= al > document? > > On Wed, Oct 7, 2015 at 9:33 AM, GangChen wrote: > >> 2015-10-07 13:20 GMT+08:00, Tore Anderson : >> > * GangChen >> > >> >> 2015-09-25 4:15 GMT+08:00, Alberto Leiva : >> >> > "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 =C2=ABstateless NAT64=C2=BB. As it ha= ppens, the >> > only occurrence of the string =C2=ABNAT64=C2=BB in RFC6145 is in a ref= erence to >> > RFC6146. >> > >> > Any draft could potentially include a sentence such as =C2=ABblah blah= , the >> > Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah=C2=BB. But= that >> > doesn't mean that =C2=ABABBP=C2=BB from that point on becomes a offici= ally >> > 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 >> > >> >