From nobody Fri May 1 13:36:47 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 80CF01A0389 for ; Fri, 1 May 2015 13:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 Wdcy9LInVUg6 for ; Fri, 1 May 2015 13:36:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 959071A017F for ; Fri, 1 May 2015 13:36:43 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6D4BF40411 for ; Fri, 1 May 2015 16:36:45 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_BD406E66-01B7-4205-BEC5-C9DCA50A836D" Message-Id: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Fri, 1 May 2015 16:36:42 -0400 References: To: "sunset4@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [sunset4] WG Adoption call for draft-chen-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, 01 May 2015 20:36:46 -0000 --Apple-Mail=_BD406E66-01B7-4205-BEC5-C9DCA50A836D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 21, 2015, at 1:46 PM, George, Wes = wrote: >=20 > This will start the two week adoption call for = draft-chen-sunset4-nat64-port-allocation. This is the draft that = previously was known as draft-chen-sunset4-cng-port-allocation but was = renamed once the IPR-encumbered text was removed.=20 >=20 > = http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/ = >=20 > Please send support for adoption to the list, as well as any comments = to improve the draft. This is a current charter milestone for the WG. I=E2=80=99ve found the information presented in this document to be = useful for deployers of NAT64s and support its adoption.=20 My general feeling of the document, however, is that many topics are = described very verbosely, sometimes in a confusing manner. It would be = great to use more to-the-point language and descriptions. Having a clear = and focused document on port {block,range} allocations techniques, sizes = and pitfalls would help the reader. Describing the vocabulary, design = goals and tradeoffs would also be useful.=20 I had the following comments regarding the content:=20 2.2.2 "Preassigned port ranges occupy memory even when there are unused = ports." Really? A range with two port numbers is negligible quantity compared to = a five-tuple or other data.=20 2.4.1 "The storage of log information may pose a challenge to operators, = since it requires additional resources and data inspection processes to = identify users." The data inspection remark here does not make sense. The NAT might = correlate source addresses to user information if it has it available, = but it won=E2=80=99t inspect. The NAT does not store either.=20 2.4.1 In the result table, the dynamic port-range allocation is = dependant of the range size and timing, that should be mentioned. (what = values where used to get to this result?)=20 2.4.2: "The user's behavior normally correlates with system = performance.=E2=80=9D Did you mean s/behavior/experience/ ? Otherwise I can=E2=80=99t grok = this. Even with that change, I=E2=80=99m sure if this sentence is = useful.=20 2.4.2: I=E2=80=99m not sure the reference to RFC6191 makes that much = sense. RFC6191 describes host behavior for incoming connections, while = the goal here is to safely optimize re-use of outgoing NAT ports.=20 As a side note, it might be useful to discuss the merits and problems = relating to TIME-WAIT assassination here.=20 2.4.3: Why not cover port block randomization here as well?=20 3.2 The whole section about block timers is quite hard to follow. A = block may have an additional timer applied after all ports are free. = Having a clear definition here would help more than discussions around = it.=20 3.2 6th paragraph suggests a very dangerous idea, that is to re-use = ports in the latest block as soon as possible. This has the potential of = bringing problems with rapid port re-use in blocks with very few = available ports. This also slows down block re-allocation and reduces = port usage overall, because of the typical port usage patterns (which is = spiky in nature rather than linear).=20 3.3 The recommendations on source port logging are superfluous in this = document. RFC6302 is well enough imo.=20 Things I didn=E2=80=99t see in this document that an implementer may be = looking for:=20 - Port allocation design goals.=20 - Clear definitions of port range allocation terms (including timers) - Address stickiness concept definition - Possible ratios of users per address and tradeoffs.=20 - The idea of a refresh log (in addition to start-end logs, for = long-lived blocks) - Discussion on logging stability, timestamping, reliability. =20 - Discussion on port usage patterns and re-usage algorithms=20 JF --Apple-Mail=_BD406E66-01B7-4205-BEC5-C9DCA50A836D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 21, 2015, at 1:46 PM, George, Wes <wesley.george@twcable.com> wrote:

This will start the two week = adoption call for draft-chen-sunset4-nat64-port-allocation. This is the = draft that previously was known as = draft-chen-sunset4-cng-port-allocation but was renamed once the = IPR-encumbered text was removed. 

http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-a= llocation/

Please send support for adoption to the list, as well as any = comments to improve the draft. This is a current charter milestone for = the WG.

I=E2=80=99ve found the information = presented in this document to be useful for deployers of NAT64s and = support its adoption. 

My general feeling of the document, however, is that many = topics are described very verbosely, sometimes in a confusing manner. It = would be great to use more to-the-point language and descriptions. = Having a clear and focused document on port {block,range} allocations = techniques, sizes and pitfalls would help the reader. Describing the = vocabulary, design goals and tradeoffs would also be = useful. 


I had the following = comments regarding the content: 

2.2.2 "Preassigned port ranges occupy = memory even when there are unused ports."
Really? A = range with two port numbers is negligible quantity compared to a = five-tuple or other data. 

2.4.1 "The storage of log information = may pose a challenge to operators, since it requires additional = resources and data inspection processes to identify users."
The data inspection remark here does not make sense. The NAT = might correlate source addresses to user information if it has it = available, but it won=E2=80=99t inspect. The NAT does not store = either. 

2.4.1 In the result table, the dynamic port-range allocation = is dependant of the range size and timing, that should be mentioned. = (what values where used to get to this result?) 

2.4.2: "The user's = behavior normally correlates with system performance.=E2=80=9D
Did you mean s/behavior/experience/ ? Otherwise I can=E2=80=99t= grok this. Even with that change, I=E2=80=99m sure if this sentence is = useful. 

2.4.2: I=E2=80=99m not sure the reference to RFC6191 makes = that much sense. RFC6191 describes host behavior for incoming = connections, while the goal here is to safely optimize re-use of = outgoing NAT ports. 
As a side note, it might = be useful to discuss the merits and problems relating to TIME-WAIT = assassination here. 

2.4.3: Why not cover port block randomization here as = well? 

3.2 = The whole section about block timers is quite hard to follow. A block = may have an additional timer applied after all ports are free. Having a = clear definition here would help more than discussions around = it. 

3.2 = 6th paragraph suggests a very dangerous idea, that is to re-use ports in = the latest block as soon as possible. This has the potential of bringing = problems with rapid port re-use in blocks with very few available ports. = This also slows down block re-allocation and reduces port usage overall, = because of the typical port usage patterns (which is spiky in nature = rather than linear). 

3.3 The recommendations on source port logging are = superfluous in this document. RFC6302 is well enough = imo. 

Things I didn=E2=80=99t see in this document that an = implementer may be looking for: 
- Port = allocation design goals. 
- Clear definitions = of port range allocation terms (including timers)
- = Address stickiness concept definition
- Possible = ratios of users per address and tradeoffs. 
- = The idea of a refresh log (in addition to start-end logs, for long-lived = blocks)
- Discussion on logging stability, = timestamping, reliability.   
- = Discussion on port usage patterns and re-usage = algorithms 

JF



= --Apple-Mail=_BD406E66-01B7-4205-BEC5-C9DCA50A836D-- From nobody Sun May 3 06:36: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 56CEB1A1A94 for ; Sun, 3 May 2015 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 7SE3QGJBlCfz for ; Sun, 3 May 2015 06:36: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 DAEEB1A1A92 for ; Sun, 3 May 2015 06:36:02 -0700 (PDT) Received: by wief7 with SMTP id f7so60168448wie.0 for ; Sun, 03 May 2015 06:36:01 -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=3F7CVyVss9R5tsTcXlFyHyDdWY9/PwogoLU5xkw3FYE=; b=1GdzgPgTCmRV9pvooXp1dX0AT3pAAYuFWp4FMNPypb/vztdn1zbBaSi0dHUM5x9Hwb lh0sc97BHvfq8/ghkggqG3is/vuCNB9NXm35J5c3+yikZCGvgloohXb3r5MmR/iH2jCh eAG3SW8CuD0z+jVuaWNx7q+lInOG6Jm7jxNZUCdmNtyg/ru1ufIJdQLSYIjhUd5x7Fo4 fMo6T+RrewGtVqcclEgLVoGSpv6NIzMgLay2BNBroGt6WjMJyIPNHDIdPVm0zRsMV1t5 9qRqWnTT9z5IL5poG1mmZ6r8f9L7yVv1vsZNvGoDlrvLcDhHdqU5vRk/PvmuS6eSHgRK sEfA== MIME-Version: 1.0 X-Received: by 10.180.7.169 with SMTP id k9mr11967215wia.70.1430660161637; Sun, 03 May 2015 06:36:01 -0700 (PDT) Received: by 10.28.194.195 with HTTP; Sun, 3 May 2015 06:36:01 -0700 (PDT) In-Reply-To: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> Date: Sun, 3 May 2015 21:36:01 +0800 Message-ID: From: GangChen To: JF Tremblay Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sunset4@ietf.org" Subject: Re: [sunset4] WG Adoption call for draft-chen-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: Sun, 03 May 2015 13:36:05 -0000 Thank you for the comments. I'd seen it's great useful to improve the draft quality. Please see my reply inline. 2015-05-02 4:36 GMT+08:00, JF Tremblay = : >> On Apr 21, 2015, at 1:46 PM, George, Wes >> wrote: >> >> This will start the two week adoption call for >> draft-chen-sunset4-nat64-port-allocation. This is the draft that >> previously was known as draft-chen-sunset4-cng-port-allocation but was >> renamed once the IPR-encumbered text was removed. >> >> http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation= / >> >> >> Please send support for adoption to the list, as well as any comments to >> improve the draft. This is a current charter milestone for the WG. > > > I=E2=80=99ve found the information presented in this document to be usefu= l for > deployers of NAT64s and support its adoption. > > My general feeling of the document, however, is that many topics are > described very verbosely, sometimes in a confusing manner. It would be gr= eat > to use more to-the-point language and descriptions. Having a clear and > focused document on port {block,range} allocations techniques, sizes and > pitfalls would help the reader. Describing the vocabulary, design goals a= nd > tradeoffs would also be useful. Great. You just hit the point. That is also my thinking how to improve the draft description. > > I had the following comments regarding the content: > > 2.2.2 "Preassigned port ranges occupy memory even when there are unused > ports." > Really? A range with two port numbers is negligible quantity compared to = a > five-tuple or other data. I guess it may not only port information matter. One implementation I can see is it will also create mapping table when it reserves a port range. > 2.4.1 "The storage of log information may pose a challenge to operators, > since it requires additional resources and data inspection processes to > identify users." > The data inspection remark here does not make sense. The NAT might correl= ate > source addresses to user information if it has it available, but it won= =E2=80=99t > inspect. The NAT does not store either. the issue is a NAT may don't know what source address should be correlated. Therefore, the NAT have to store entire information preparing the searching= . For your information, the NAT should store at least three-months log in our networks. > 2.4.1 In the result table, the dynamic port-range allocation is dependant= of > the range size and timing, that should be mentioned. (what values where u= sed > to get to this result?) great. I will add in the next version. > 2.4.2: "The user's behavior normally correlates with system performance.= =E2=80=9D > Did you mean s/behavior/experience/ ? Otherwise I can=E2=80=99t grok this= . Even with > that change, I=E2=80=99m sure if this sentence is useful. The sentence is not useful. I like the proposal that just directly going to the point . I will change the description. > 2.4.2: I=E2=80=99m not sure the reference to RFC6191 makes that much sens= e. RFC6191 > describes host behavior for incoming connections, while the goal here is = to > safely optimize re-use of outgoing NAT ports. > As a side note, it might be useful to discuss the merits and problems > relating to TIME-WAIT assassination here. Got your point. It will be clear. > 2.4.3: Why not cover port block randomization here as well? Good to know more if you point me a reference of "port block randomization"= . > 3.2 The whole section about block timers is quite hard to follow. A block > may have an additional timer applied after all ports are free. Having a > clear definition here would help more than discussions around it. > > 3.2 6th paragraph suggests a very dangerous idea, that is to re-use ports= in > the latest block as soon as possible. This has the potential of bringing > problems with rapid port re-use in blocks with very few available ports. > This also slows down block re-allocation and reduces port usage overall, > because of the typical port usage patterns (which is spiky in nature rath= er > than linear). > > 3.3 The recommendations on source port logging are superfluous in this > document. RFC6302 is well enough imo. Those three questions I would leave to my co-authors for more feedback. > > Things I didn=E2=80=99t see in this document that an implementer may be l= ooking for: > > - Port allocation design goals. > - Clear definitions of port range allocation terms (including timers) > - Address stickiness concept definition > - Possible ratios of users per address and tradeoffs. > - The idea of a refresh log (in addition to start-end logs, for long-live= d > blocks) > - Discussion on logging stability, timestamping, reliability. > - Discussion on port usage patterns and re-usage algorithms That is a good suggestion. Those information may implicitly described in the document. Again, I agree you general comments of " to-the-point language and descriptions." It hopefully will be clear when we improve the description. Best Regards Gang > JF > > > > From nobody Mon May 4 07:29:48 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 E01BB1A1A32 for ; Mon, 4 May 2015 07:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 42XtgsjBPdeK for ; Mon, 4 May 2015 07:29:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7E1A1A27 for ; Mon, 4 May 2015 07:29:41 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2353F403B7; Mon, 4 May 2015 10:29:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: JF Tremblay In-Reply-To: Date: Mon, 4 May 2015 10:29:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> To: GangChen X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "sunset4@ietf.org" Subject: Re: [sunset4] WG Adoption call for draft-chen-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: Mon, 04 May 2015 14:29:48 -0000 Inline.=20 > On May 3, 2015, at 9:36 AM, GangChen wrote: >=20 > Thank you for the comments. I'd seen it's great useful to improve the > draft quality. > Please see my reply inline. >=20 > 2015-05-02 4:36 GMT+08:00, JF Tremblay = : >=20 >> 2.4.1 "The storage of log information may pose a challenge to = operators, >> since it requires additional resources and data inspection processes = to >> identify users." >> The data inspection remark here does not make sense. The NAT might = correlate >> source addresses to user information if it has it available, but it = won=E2=80=99t >> inspect. The NAT does not store either. >=20 > the issue is a NAT may don't know what source address should be = correlated. > Therefore, the NAT have to store entire information preparing the = searching. > For your information, the NAT should store at least three-months log > in our networks. In my opinion:=20 - NATs do not / should not store logs. This is done by an external = server (syslog or other). - NATs do not correlate source addresses to users, unless it already has = that information available. This can be done offline by a server with = much more ressources.=20 This could be guidance to put in this document, if not mentioned = elsewhere. (but I thought that was quite obvious) >> 2.4.3: Why not cover port block randomization here as well? >=20 > Good to know more if you point me a reference of "port block = randomization=E2=80=9D. There isn=E2=80=99t a reference. I might have coined the term a couple = of years back, not sure. This is basically the act of randomizing the = assignments of blocks instead or in conjunction with port randomization = within the block. =20 This could be a concept defined and discussed in this document.=20 /JF From nobody Tue May 5 00:11:20 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 46E2B1B2EDA for ; Tue, 5 May 2015 00:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 88b7WJxpSQhB for ; Tue, 5 May 2015 00:11:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9463F1B2ECD for ; Tue, 5 May 2015 00:11:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVR09943; Tue, 05 May 2015 07:11:12 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 May 2015 08:11:11 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.31]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 5 May 2015 15:11:02 +0800 From: "Huangjing (A)" To: JF Tremblay Thread-Topic: [sunset4] WG Adoption call for draft-chen-sunset4-nat64-port-allocation Thread-Index: AQHQhE6PMBpj4xu2SU+ujvNRQXuteZ1pvXaAgAGhUYCAAZy9UA== Date: Tue, 5 May 2015 07:11:03 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6492CBB7@SZXEMA501-MBX.china.huawei.com> References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> In-Reply-To: <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Tom Taylor , "sunset4@ietf.org" , GangChen Subject: Re: [sunset4] WG Adoption call for draft-chen-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, 05 May 2015 07:11:16 -0000 SGksIEpGLA0KDQpTZWUgaW5saW5lDQoNCkphbWVzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogc3Vuc2V0NCBbbWFpbHRvOnN1bnNldDQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpGIFRyZW1ibGF5DQo+IFNlbnQ6IE1vbmRheSwgTWF5IDA0LCAyMDE1IDEw OjMwIFBNDQo+IFRvOiBHYW5nQ2hlbg0KPiBDYzogc3Vuc2V0NEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3N1bnNldDRdIFdHIEFkb3B0aW9uIGNhbGwgZm9yDQo+IGRyYWZ0LWNoZW4tc3Vuc2V0 NC1uYXQ2NC1wb3J0LWFsbG9jYXRpb24NCj4gDQo+IElubGluZS4NCj4gDQo+ID4gT24gTWF5IDMs IDIwMTUsIGF0IDk6MzYgQU0sIEdhbmdDaGVuIDxwaGRnYW5nQGdtYWlsLmNvbT4gd3JvdGU6DQo+ ID4NCj4gPiBUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4gSSdkIHNlZW4gaXQncyBncmVhdCB1 c2VmdWwgdG8gaW1wcm92ZSB0aGUNCj4gPiBkcmFmdCBxdWFsaXR5Lg0KPiA+IFBsZWFzZSBzZWUg bXkgcmVwbHkgaW5saW5lLg0KPiA+DQo+ID4gMjAxNS0wNS0wMiA0OjM2IEdNVCswODowMCwgSkYg VHJlbWJsYXkNCj4gPGplYW4tZnJhbmNvaXMudHJlbWJsYXlAdmlhZ2VuaWUuY2E+Og0KPiA+DQo+ ID4+IDIuNC4xICJUaGUgc3RvcmFnZSBvZiBsb2cgaW5mb3JtYXRpb24gbWF5IHBvc2UgYSBjaGFs bGVuZ2UgdG8NCj4gPj4gb3BlcmF0b3JzLCBzaW5jZSBpdCByZXF1aXJlcyBhZGRpdGlvbmFsIHJl c291cmNlcyBhbmQgZGF0YSBpbnNwZWN0aW9uDQo+ID4+IHByb2Nlc3NlcyB0byBpZGVudGlmeSB1 c2Vycy4iDQo+ID4+IFRoZSBkYXRhIGluc3BlY3Rpb24gcmVtYXJrIGhlcmUgZG9lcyBub3QgbWFr ZSBzZW5zZS4gVGhlIE5BVCBtaWdodA0KPiA+PiBjb3JyZWxhdGUgc291cmNlIGFkZHJlc3NlcyB0 byB1c2VyIGluZm9ybWF0aW9uIGlmIGl0IGhhcyBpdA0KPiA+PiBhdmFpbGFibGUsIGJ1dCBpdCB3 b27igJl0IGluc3BlY3QuIFRoZSBOQVQgZG9lcyBub3Qgc3RvcmUgZWl0aGVyLg0KPiA+DQo+ID4g dGhlIGlzc3VlIGlzIGEgTkFUIG1heSBkb24ndCBrbm93IHdoYXQgc291cmNlIGFkZHJlc3Mgc2hv dWxkIGJlIGNvcnJlbGF0ZWQuDQo+ID4gVGhlcmVmb3JlLCB0aGUgTkFUIGhhdmUgdG8gc3RvcmUg ZW50aXJlIGluZm9ybWF0aW9uIHByZXBhcmluZyB0aGUgc2VhcmNoaW5nLg0KPiA+IEZvciB5b3Vy IGluZm9ybWF0aW9uLCB0aGUgTkFUIHNob3VsZCBzdG9yZSBhdCBsZWFzdCB0aHJlZS1tb250aHMg bG9nDQo+ID4gaW4gb3VyIG5ldHdvcmtzLg0KPiANCj4gSW4gbXkgb3BpbmlvbjoNCj4gLSBOQVRz IGRvIG5vdCAvIHNob3VsZCBub3Qgc3RvcmUgbG9ncy4gVGhpcyBpcyBkb25lIGJ5IGFuIGV4dGVy bmFsIHNlcnZlciAoc3lzbG9nDQo+IG9yIG90aGVyKS4NCj4gLSBOQVRzIGRvIG5vdCBjb3JyZWxh dGUgc291cmNlIGFkZHJlc3NlcyB0byB1c2VycywgdW5sZXNzIGl0IGFscmVhZHkgaGFzIHRoYXQN Cj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlLiBUaGlzIGNhbiBiZSBkb25lIG9mZmxpbmUgYnkgYSBz ZXJ2ZXIgd2l0aCBtdWNoIG1vcmUNCj4gcmVzc291cmNlcy4NCg0KQWdyZWUsIGxvZyBwcm9jZXNz aW5nIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgTkFULg0KDQo+IFRoaXMgY291bGQgYmUgZ3VpZGFu Y2UgdG8gcHV0IGluIHRoaXMgZG9jdW1lbnQsIGlmIG5vdCBtZW50aW9uZWQgZWxzZXdoZXJlLg0K PiAoYnV0IEkgdGhvdWdodCB0aGF0IHdhcyBxdWl0ZSBvYnZpb3VzKQ0KPiANCj4gPj4gMi40LjM6 IFdoeSBub3QgY292ZXIgcG9ydCBibG9jayByYW5kb21pemF0aW9uIGhlcmUgYXMgd2VsbD8NCj4g Pg0KPiA+IEdvb2QgdG8ga25vdyBtb3JlIGlmIHlvdSBwb2ludCBtZSBhIHJlZmVyZW5jZSBvZiAi cG9ydCBibG9jaw0KPiByYW5kb21pemF0aW9u4oCdLg0KPiANCj4gVGhlcmUgaXNu4oCZdCBhIHJl ZmVyZW5jZS4gSSBtaWdodCBoYXZlIGNvaW5lZCB0aGUgdGVybSBhIGNvdXBsZSBvZiB5ZWFycyBi YWNrLA0KPiBub3Qgc3VyZS4gVGhpcyBpcyBiYXNpY2FsbHkgdGhlIGFjdCBvZiByYW5kb21pemlu ZyB0aGUgYXNzaWdubWVudHMgb2YgYmxvY2tzDQo+IGluc3RlYWQgb3IgaW4gY29uanVuY3Rpb24g d2l0aCBwb3J0IHJhbmRvbWl6YXRpb24gd2l0aGluIHRoZSBibG9jay4NCj4gVGhpcyBjb3VsZCBi ZSBhIGNvbmNlcHQgZGVmaW5lZCBhbmQgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQuDQoNCkkg dGhpbmsgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBwb3J0IGJsb2NrIHJhbmRvbWl6YXRpb24g YWxnb3JpdGhtcyBzaW1pbGFyIHRvIHRob3NlIGRlZmluZWQgaW4gUkZDNjQzMS4NCldpbGwgYWRk IHNvbWUgYW5hbHlzaXMgYW5kIHJlZmVyZW5jZQ0KDQo+IA0KPiAvSkYNCj4gDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3Vuc2V0 NCBtYWlsaW5nIGxpc3QNCj4gc3Vuc2V0NEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N1bnNldDQNCg== From nobody Tue May 5 05:11:20 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 74C0C1A9100 for ; Tue, 5 May 2015 05:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 iXpaiGbNJzSa for ; Tue, 5 May 2015 05:11:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 404371A047A for ; Tue, 5 May 2015 05:11:07 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1006] (unknown [IPv6:2620:0:230:2001::1006]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E9AAA403DB; Tue, 5 May 2015 08:11:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: JF Tremblay In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC6492CBB7@SZXEMA501-MBX.china.huawei.com> Date: Tue, 5 May 2015 08:11:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02A44511-C2D6-4DA2-9733-79546259A528@viagenie.ca> References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> <774B240D54DAB844B37EE80C2DD8E8BC6492CBB7@SZXEMA501-MBX.china.huawei.com> To: "Huangjing (A)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Tom Taylor , "sunset4@ietf.org" , GangChen Subject: Re: [sunset4] WG Adoption call for draft-chen-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, 05 May 2015 12:11:19 -0000 > On May 5, 2015, at 3:11 AM, Huangjing (A) = wrote: >=20 >>>=20 >>> Good to know more if you point me a reference of "port block >> randomization=E2=80=9D. >>=20 >> There isn=E2=80=99t a reference. I might have coined the term a = couple of years back, >> not sure. This is basically the act of randomizing the assignments of = blocks >> instead or in conjunction with port randomization within the block. >> This could be a concept defined and discussed in this document. >=20 > I think you are talking about the port block randomization algorithms = similar to those defined in RFC6431. > Will add some analysis and reference Thanks for the reference, James. Interesting. I had in mind a = non-cryptographically random set of port, which doesn=E2=80=99t seem to = be handled in RFC6431. That would basically be a continuous set of ports = where the first port is assigned randomly or semi-randomly (could be on = block boundary for example). This concept could be defined and discussed = in this document, but it=E2=80=99s just a minor point for = discussion/improvement.=20 JF From nobody Sun May 10 11:04:52 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 814B31A8850 for ; Sun, 10 May 2015 11:04:50 -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 3zvYPK717SO7 for ; Sun, 10 May 2015 11:04:48 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 9526C1A884F for ; Sun, 10 May 2015 11:04:48 -0700 (PDT) Received: by oiko83 with SMTP id o83so90155985oik.1 for ; Sun, 10 May 2015 11:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ecAip3QpnbcZqVtYAUuDc/ouNzY3YOdx4zbhdnlPZIc=; b=juXxVRYLLFy1eNZZEuzcxvN2i6CG1Mk25YQAc0dq107bsl4iPTIzEFbQAtKwb6Uiuv A358A20ZrggEpgavNI7q0Gi1+1H377GuoJwCvVc8q/BMU2pZnfiihAs/YSQg5VfbBxCw dUiTfe0+GDJ/7G3WZkgmDx56Pn/GHWlm5yEODtQC1w+mCCTbnZHMYj1akH1bCD/lL/eW IKFZmmJs/EiDn3UX5eaPwmay7kpxM7FR+yL36FJvVOzKQMUyWB5jYHkWsLayhvmkvNNL vtHHJdh/iK20YseyPhJ+xqKxFb9OvN3EQ3ivmrCD+s7yMapwsgVUh2jLgOit2uBIVKoP F/YA== X-Received: by 10.182.196.34 with SMTP id ij2mr5447227obc.71.1431281088097; Sun, 10 May 2015 11:04:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.16.70 with HTTP; Sun, 10 May 2015 11:04:07 -0700 (PDT) In-Reply-To: <02A44511-C2D6-4DA2-9733-79546259A528@viagenie.ca> References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> <774B240D54DAB844B37EE80C2DD8E8BC6492CBB7@SZXEMA501-MBX.china.huawei.com> <02A44511-C2D6-4DA2-9733-79546259A528@viagenie.ca> From: "Mukom Akong T." Date: Sun, 10 May 2015 22:04:07 +0400 Message-ID: To: JF Tremblay Content-Type: multipart/alternative; boundary=089e0153870cd472280515be18c8 Archived-At: Cc: GangChen , "Huangjing \(A\)" , "sunset4@ietf.org" , Tom Taylor Subject: Re: [sunset4] WG Adoption call for draft-chen-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: Sun, 10 May 2015 18:04:50 -0000 --089e0153870cd472280515be18c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've read it and support adoption as well. I also agree with JF's point that the NAT doesn't do logging and inspection. While that is an important consideration deployment, I think section 2.4.1 should explicitly state that such logging and inspection are done on another system, not the NAT64 one. Regards On Tue, May 5, 2015 at 4:11 PM, JF Tremblay < jean-francois.tremblay@viagenie.ca> wrote: > > > On May 5, 2015, at 3:11 AM, Huangjing (A) > wrote: > > > >>> > >>> Good to know more if you point me a reference of "port block > >> randomization=E2=80=9D. > >> > >> There isn=E2=80=99t a reference. I might have coined the term a couple= of years > back, > >> not sure. This is basically the act of randomizing the assignments of > blocks > >> instead or in conjunction with port randomization within the block. > >> This could be a concept defined and discussed in this document. > > > > I think you are talking about the port block randomization algorithms > similar to those defined in RFC6431. > > Will add some analysis and reference > > Thanks for the reference, James. Interesting. I had in mind a > non-cryptographically random set of port, which doesn=E2=80=99t seem to b= e handled > in RFC6431. That would basically be a continuous set of ports where the > first port is assigned randomly or semi-randomly (could be on block > boundary for example). This concept could be defined and discussed in thi= s > document, but it=E2=80=99s just a minor point for discussion/improvement. > > JF > > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > --=20 Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --089e0153870cd472280515be18c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read it and support adoption as well. I also agre= e with JF's point that the NAT doesn't do logging and inspection. W= hile that is an important consideration deployment, I think section 2.4.1 should=C2=A0explicitly state that such logging and inspection are do= ne on another system, not the NAT64 one.
<= br>
Regards

On Tue, M= ay 5, 2015 at 4:11 PM, JF Tremblay <jean-francois.trembla= y@viagenie.ca> wrote:

> On May 5, 2015, at 3:11 AM, Huangjing (A) <james.huang@huawei.com> wrote:
>
>>>
>>> Good to know more if you point me a reference of "port bl= ock
>> randomization=E2=80=9D.
>>
>> There isn=E2=80=99t a reference. I might have coined the term a co= uple of years back,
>> not sure. This is basically the act of randomizing the assignments= of blocks
>> instead or in conjunction with port randomization within the block= .
>> This could be a concept defined and discussed in this document. >
> I think you are talking about the port block randomization algorithms = similar to those defined in RFC6431.
> Will add some analysis and reference

Thanks for the reference, James. Interesting. I had in mind a non-cr= yptographically random set of port, which doesn=E2=80=99t seem to be handle= d in RFC6431. That would basically be a continuous set of ports where the f= irst port is assigned randomly or semi-randomly (could be on block boundary= for example). This concept could be defined and discussed in this document= , but it=E2=80=99s just a minor point for discussion/improvement.

JF



_______________________________________________
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4



--
=

Mukom Akong T.

http://about.me/perfexcellence | =C2=A0twitter: @perfexcellent
-------------------------------= ---------------------------------------------------------------------------= --------------------------------
=E2=80=9CWhen you work, you are the FLU= TE through whose lungs the whispering of the hours turns to MUSIC" - K= ahlil Gibran
-----------------------------------------------------------= ---------------------------------------------------------------------------= -----
--089e0153870cd472280515be18c8-- From nobody Sun May 10 19:57:16 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 56A9B1A01AA for ; Sun, 10 May 2015 19:57: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 HlPOh80r1TlK for ; Sun, 10 May 2015 19:57:13 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 539501A0191 for ; Sun, 10 May 2015 19:57:13 -0700 (PDT) Received: by wgiu9 with SMTP id u9so115604056wgi.3 for ; Sun, 10 May 2015 19:57:12 -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=Pohz+6P2MaSyqHNdRfhMjfphNLdbHTNc4eb0FLHpjC0=; b=AtBARaOrfVQDMs/qukvDGvaK76J9SAuZc6cCsKD+aCOwb640oPHuSGNTfV+dZNJIGI Z5lm5P4FV+o0b43G4sK3pUDCdxO/TkA4skoWNdPKSJ40RgOY2pNaWDt+ugiq2gmOqszM VEJGUoFnUPSQaQ7d15ZCIlBk8Mty/cRB7olgXVYQxl8hIf41ZaIgTPdaEXF+hPwd8tHq ayd0+hzbPwriUy27uw1UtFgXW4j0mY/p+eksnIRoeSDlnaAsiT85qE01on5aFUdVUuZf TtW4uZ0W2WstCG175uiNBmi3mwNwMA2zVlx9IYooGVvtd3kBdog3C0MdE8yIWMpATqJO qLRA== MIME-Version: 1.0 X-Received: by 10.194.190.168 with SMTP id gr8mr15318320wjc.83.1431313032118; Sun, 10 May 2015 19:57:12 -0700 (PDT) Received: by 10.28.194.195 with HTTP; Sun, 10 May 2015 19:57:12 -0700 (PDT) In-Reply-To: References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> <774B240D54DAB844B37EE80C2DD8E8BC6492CBB7@SZXEMA501-MBX.china.huawei.com> <02A44511-C2D6-4DA2-9733-79546259A528@viagenie.ca> Date: Mon, 11 May 2015 10:57:12 +0800 Message-ID: From: GangChen To: "Mukom Akong T." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: JF Tremblay , "Huangjing \(A\)" , "sunset4@ietf.org" , Tom Taylor Subject: Re: [sunset4] WG Adoption call for draft-chen-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: Mon, 11 May 2015 02:57:15 -0000 Hello Mukom and JF, Thank you for the review and support. The point of NAT logging is well understood. We will explicitly state that in the next version. Best Regards Gang 2015-05-11 2:04 GMT+08:00, Mukom Akong T. : > I've read it and support adoption as well. I also agree with JF's point > that the NAT doesn't do logging and inspection. While that is an importan= t > consideration deployment, I think section 2.4.1 should explicitly state > that such logging and inspection are done on another system, not the NAT6= 4 > one. > > Regards > > On Tue, May 5, 2015 at 4:11 PM, JF Tremblay < > jean-francois.tremblay@viagenie.ca> wrote: > >> >> > On May 5, 2015, at 3:11 AM, Huangjing (A) >> wrote: >> > >> >>> >> >>> Good to know more if you point me a reference of "port block >> >> randomization=E2=80=9D. >> >> >> >> There isn=E2=80=99t a reference. I might have coined the term a coupl= e of >> >> years >> back, >> >> not sure. This is basically the act of randomizing the assignments of >> blocks >> >> instead or in conjunction with port randomization within the block. >> >> This could be a concept defined and discussed in this document. >> > >> > I think you are talking about the port block randomization algorithms >> similar to those defined in RFC6431. >> > Will add some analysis and reference >> >> Thanks for the reference, James. Interesting. I had in mind a >> non-cryptographically random set of port, which doesn=E2=80=99t seem to = be >> handled >> in RFC6431. That would basically be a continuous set of ports where the >> first port is assigned randomly or semi-randomly (could be on block >> boundary for example). This concept could be defined and discussed in >> this >> document, but it=E2=80=99s just a minor point for discussion/improvement= . >> >> JF >> >> >> >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >> > > > > -- > > Mukom Akong T. > > http://about.me/perfexcellence | twitter: @perfexcellent > -------------------------------------------------------------------------= ----------------------------------------------------------------- > =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisper= ing of the > hours turns to MUSIC" - Kahlil Gibran > -------------------------------------------------------------------------= ------------------------------------------------------------------ > From nobody Mon May 11 08:07: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 B20AD1A8A1D for ; Mon, 11 May 2015 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 4PQi9FRzSpuc for ; Mon, 11 May 2015 08:06:57 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id D45231A89AC for ; Mon, 11 May 2015 08:06:56 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.13,408,1427774400"; d="scan'208,217";a="249211437" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 May 2015 10:51:04 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 11 May 2015 11:06:54 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Mon, 11 May 2015 11:07:08 -0400 Thread-Topic: WG Adoption call for draft-chen-sunset4-nat64-port-allocation Thread-Index: AdCL/B1+fCEaomdKSKyovumC+O7yQw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1763D8350563wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sunset4] WG Adoption call for draft-chen-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: Mon, 11 May 2015 15:06:58 -0000 --_000_D1763D8350563wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBzZWVuIG5vIG9wcG9zaXRpb24gdG8gYWRvcHRpbmcgdGhpcyBkb2N1bWVudCBhcyBh IFdHIGRvY3VtZW50LiBBdXRob3JzLCB3aGVuIHlvdSBoYXZlIGEgdmVyc2lvbiByZWFkeSB0aGF0 IGluY29ycG9yYXRlcyB0aGUgcmVjZW50IGZlZWRiYWNrLCBwbGVhc2UgcG9zdCBpdCBhcyBhcyBk cmFmdC1pZXRmLXN1bnNldDQtbmF0NjQtcG9ydC1hbGxvY2F0aW9uDQoNClRoYW5rcywNCg0KV2Vz DQoNCg0KRnJvbTogPEdlb3JnZT4sICJHZW9yZ2UsIFdlcyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJs ZS5jb208bWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+Pg0KRGF0ZTogVHVlc2RheSwg QXByaWwgMjEsIDIwMTUgYXQgMTo0NiBQTQ0KVG86ICJzdW5zZXQ0QGlldGYub3JnPG1haWx0bzpz dW5zZXQ0QGlldGYub3JnPiIgPHN1bnNldDRAaWV0Zi5vcmc8bWFpbHRvOnN1bnNldDRAaWV0Zi5v cmc+Pg0KU3ViamVjdDogV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtY2hlbi1zdW5zZXQ0LW5h dDY0LXBvcnQtYWxsb2NhdGlvbg0KDQpUaGlzIHdpbGwgc3RhcnQgdGhlIHR3byB3ZWVrIGFkb3B0 aW9uIGNhbGwgZm9yIGRyYWZ0LWNoZW4tc3Vuc2V0NC1uYXQ2NC1wb3J0LWFsbG9jYXRpb24uIFRo aXMgaXMgdGhlIGRyYWZ0IHRoYXQgcHJldmlvdXNseSB3YXMga25vd24gYXMgZHJhZnQtY2hlbi1z dW5zZXQ0LWNuZy1wb3J0LWFsbG9jYXRpb24gYnV0IHdhcyByZW5hbWVkIG9uY2UgdGhlIElQUi1l bmN1bWJlcmVkIHRleHQgd2FzIHJlbW92ZWQuDQoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtY2hlbi1zdW5zZXQ0LW5hdDY0LXBvcnQtYWxsb2NhdGlvbi8NCg0KUGxlYXNl IHNlbmQgc3VwcG9ydCBmb3IgYWRvcHRpb24gdG8gdGhlIGxpc3QsIGFzIHdlbGwgYXMgYW55IGNv bW1lbnRzIHRvIGltcHJvdmUgdGhlIGRyYWZ0LiBUaGlzIGlzIGEgY3VycmVudCBjaGFydGVyIG1p bGVzdG9uZSBmb3IgdGhlIFdHLg0KDQpUaGFua3MsDQoNCldlcw0KDQpBbnl0aGluZyBiZWxvdyB0 aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkg aGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0 IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8g dGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_D1763D8350563wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PldlIGhhdmUgc2VlbiBubyBvcHBvc2l0aW9uIHRvIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQg YXMgYSBXRyBkb2N1bWVudC4gQXV0aG9ycywgd2hlbiB5b3UgaGF2ZSBhIHZlcnNpb24gcmVhZHkg dGhhdCBpbmNvcnBvcmF0ZXMgdGhlIHJlY2VudCBmZWVkYmFjaywgcGxlYXNlIHBvc3QgaXQgYXMg YXMgZHJhZnQtaWV0Zi1zdW5zZXQ0LW5hdDY0LXBvcnQtYWxsb2NhdGlvbjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5UaGFua3MsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldl czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7Ij48YnI+DQo8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U VE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1U T1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5H LVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+ Jmx0O0dlb3JnZSZndDssICZxdW90O0dlb3JnZSwgV2VzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbSI+d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U dWVzZGF5LCBBcHJpbCAyMSwgMjAxNSBhdCAxOjQ2IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnN1bnNldDRAaWV0 Zi5vcmciPnN1bnNldDRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3Vu c2V0NEBpZXRmLm9yZyI+c3Vuc2V0NEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5XRyBBZG9wdGlvbiBjYWxsIGZvciBk cmFmdC1jaGVuLXN1bnNldDQtbmF0NjQtcG9ydC1hbGxvY2F0aW9uPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PlRoaXMgd2lsbCBzdGFydCB0aGUgdHdvIHdl ZWsgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtY2hlbi1zdW5zZXQ0LW5hdDY0LXBvcnQtYWxsb2Nh dGlvbi4gVGhpcyBpcyB0aGUgZHJhZnQgdGhhdCBwcmV2aW91c2x5IHdhcyBrbm93biBhcyBkcmFm dC1jaGVuLXN1bnNldDQtY25nLXBvcnQtYWxsb2NhdGlvbiBidXQgd2FzIHJlbmFtZWQgb25jZSB0 aGUgSVBSLWVuY3VtYmVyZWQgdGV4dCB3YXMgcmVtb3ZlZC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtY2hlbi1zdW5zZXQ0LW5hdDY0LXBvcnQtYWxsb2NhdGlvbi8iPmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbi1zdW5zZXQ0LW5hdDY0LXBvcnQtYWxsb2NhdGlv bi88L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2Ugc2VuZCBzdXBwb3J0 IGZvciBhZG9wdGlvbiB0byB0aGUgbGlzdCwgYXMgd2VsbCBhcyBhbnkgY29tbWVudHMgdG8gaW1w cm92ZSB0aGUgZHJhZnQuIFRoaXMgaXMgYSBjdXJyZW50IGNoYXJ0ZXIgbWlsZXN0b25lIGZvciB0 aGUgV0cuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi KDEyNywgMTI3LCAxMjcpOyI+QW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVk IGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJjb2xv cjogcmdiKDEyNywgMTI3LCAxMjcpOyI+LS0tLS0tLS0tLS08L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xv cj0iR3JheSIgc2l6ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkNCiBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gg aXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0 byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvDQogdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D1763D8350563wesleygeorgetwcablecom_-- From nobody Mon May 18 19:20:17 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 2E17D1B2D36 for ; Mon, 18 May 2015 19:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 QHxpiJwUFCR5 for ; Mon, 18 May 2015 19:20:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F1C1B2D32 for ; Mon, 18 May 2015 19:20:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSR80818; Tue, 19 May 2015 02:20:11 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 May 2015 03:20:09 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.61]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 19 May 2015 10:20:05 +0800 From: "Huangjing (A)" To: JF Tremblay Thread-Topic: [sunset4] WG Adoption call for draft-chen-sunset4-nat64-port-allocation Thread-Index: AQHQhE6PMBpj4xu2SU+ujvNRQXuteZ1pvXaAgAGhUYCAAZy9UP//zuGAgBXha1A= Date: Tue, 19 May 2015 02:20:04 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC649471E6@SZXEMA501-MBX.china.huawei.com> References: <66189322-D15E-4D84-9844-493C00D8068A@viagenie.ca> <096F8AFE-9A16-4986-8050-85047DD87C17@viagenie.ca> <774B240D54DAB844B37EE80C2DD8E8BC6492CBB7@SZXEMA501-MBX.china.huawei.com> <02A44511-C2D6-4DA2-9733-79546259A528@viagenie.ca> In-Reply-To: <02A44511-C2D6-4DA2-9733-79546259A528@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Tom Taylor , "sunset4@ietf.org" , GangChen Subject: Re: [sunset4] WG Adoption call for draft-chen-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, 19 May 2015 02:20:16 -0000 SGksIEpGLA0KDQpUaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbiENCg0KSmFtZXMNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKRiBUcmVtYmxheSBbbWFpbHRvOmplYW4t ZnJhbmNvaXMudHJlbWJsYXlAdmlhZ2VuaWUuY2FdDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAwNSwg MjAxNSA4OjExIFBNDQo+IFRvOiBIdWFuZ2ppbmcgKEEpDQo+IENjOiBzdW5zZXQ0QGlldGYub3Jn OyBHYW5nQ2hlbjsgVG9tIFRheWxvcg0KPiBTdWJqZWN0OiBSZTogW3N1bnNldDRdIFdHIEFkb3B0 aW9uIGNhbGwgZm9yDQo+IGRyYWZ0LWNoZW4tc3Vuc2V0NC1uYXQ2NC1wb3J0LWFsbG9jYXRpb24N Cj4gDQo+IA0KPiA+IE9uIE1heSA1LCAyMDE1LCBhdCAzOjExIEFNLCBIdWFuZ2ppbmcgKEEpIDxq YW1lcy5odWFuZ0BodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+Pj4NCj4gPj4+IEdvb2Qg dG8ga25vdyBtb3JlIGlmIHlvdSBwb2ludCBtZSBhIHJlZmVyZW5jZSBvZiAicG9ydCBibG9jaw0K PiA+PiByYW5kb21pemF0aW9u4oCdLg0KPiA+Pg0KPiA+PiBUaGVyZSBpc27igJl0IGEgcmVmZXJl bmNlLiBJIG1pZ2h0IGhhdmUgY29pbmVkIHRoZSB0ZXJtIGEgY291cGxlIG9mDQo+ID4+IHllYXJz IGJhY2ssIG5vdCBzdXJlLiBUaGlzIGlzIGJhc2ljYWxseSB0aGUgYWN0IG9mIHJhbmRvbWl6aW5n IHRoZQ0KPiA+PiBhc3NpZ25tZW50cyBvZiBibG9ja3MgaW5zdGVhZCBvciBpbiBjb25qdW5jdGlv biB3aXRoIHBvcnQgcmFuZG9taXphdGlvbg0KPiB3aXRoaW4gdGhlIGJsb2NrLg0KPiA+PiBUaGlz IGNvdWxkIGJlIGEgY29uY2VwdCBkZWZpbmVkIGFuZCBkaXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVu dC4NCj4gPg0KPiA+IEkgdGhpbmsgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBwb3J0IGJsb2Nr IHJhbmRvbWl6YXRpb24gYWxnb3JpdGhtcyBzaW1pbGFyDQo+IHRvIHRob3NlIGRlZmluZWQgaW4g UkZDNjQzMS4NCj4gPiBXaWxsIGFkZCBzb21lIGFuYWx5c2lzIGFuZCByZWZlcmVuY2UNCj4gDQo+ IFRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZSwgSmFtZXMuIEludGVyZXN0aW5nLiBJIGhhZCBpbiBt aW5kIGENCj4gbm9uLWNyeXB0b2dyYXBoaWNhbGx5IHJhbmRvbSBzZXQgb2YgcG9ydCwgd2hpY2gg ZG9lc27igJl0IHNlZW0gdG8gYmUgaGFuZGxlZCBpbg0KPiBSRkM2NDMxLiBUaGF0IHdvdWxkIGJh c2ljYWxseSBiZSBhIGNvbnRpbnVvdXMgc2V0IG9mIHBvcnRzIHdoZXJlIHRoZSBmaXJzdCBwb3J0 DQo+IGlzIGFzc2lnbmVkIHJhbmRvbWx5IG9yIHNlbWktcmFuZG9tbHkgKGNvdWxkIGJlIG9uIGJs b2NrIGJvdW5kYXJ5IGZvcg0KPiBleGFtcGxlKS4gVGhpcyBjb25jZXB0IGNvdWxkIGJlIGRlZmlu ZWQgYW5kIGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50LCBidXQNCj4gaXTigJlzIGp1c3QgYSBt aW5vciBwb2ludCBmb3IgZGlzY3Vzc2lvbi9pbXByb3ZlbWVudC4NCj4gDQo+IEpGDQo+IA0KPiAN Cg0K From nobody Mon May 18 19:55:16 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 46F871B2D92; Mon, 18 May 2015 19:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IdeuEbOfsSOE; Mon, 18 May 2015 19:55:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F331B2D93; Mon, 18 May 2015 19:55:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150519025512.26996.58495.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 19:55:12 -0700 Archived-At: Cc: sunset4@ietf.org Subject: [sunset4] I-D Action: draft-ietf-sunset4-nat64-port-allocation-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 02:55:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sunsetting IPv4 Working Group of the IETF. Title : Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses Authors : Gang Chen Weibo Li Tina Tsou James Huang Tom Taylor Filename : draft-ietf-sunset4-nat64-port-allocation-00.txt Pages : 19 Date : 2015-05-18 Abstract: This document enumerates methods of port assignment in Carrier Grade NATs (CGNs), focused particularly on NAT64 environments. A theoretical framework of different NAT port allocation methods is described. The memo is intended to clarify and focus the port allocation discussion and propose an integrated view of the considerations for selection of the port allocation mechanism in a given deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sunset4-nat64-port-allocation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sunset4-nat64-port-allocation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 18 19:59:34 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 B27701B2DA4 for ; Mon, 18 May 2015 19:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 SN53mhBHn4Kb for ; Mon, 18 May 2015 19:59:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36D1B2DA0 for ; Mon, 18 May 2015 19:59:31 -0700 (PDT) Received: from [192.168.49.231] (unknown [119.145.14.6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 833DE4037C for ; Mon, 18 May 2015 22:59:32 -0400 (EDT) From: "Marc Blanchet" To: sunset4@ietf.org Date: Tue, 19 May 2015 10:57:07 +0800 Message-ID: <9CA124C0-C98E-48C8-9BDC-3CB061D0FFCC@viagenie.ca> In-Reply-To: <20150519025512.26996.58495.idtracker@ietfa.amsl.com> References: <20150519025512.26996.58495.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (1.9.1r5084) Archived-At: Subject: Re: [sunset4] I-D Action: draft-ietf-sunset4-nat64-port-allocation-00.txt 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, 19 May 2015 02:59:32 -0000 Hello, I suggested to the co-authors to post their individual draft as is as draft-ietf-sunset4 so it will be easier for the wg to track down the changes since the call for adoption. So this one is exactly as the individual one. Look for the -01 for changes. Regards, Marc. On 19 May 2015, at 10:55, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Sunsetting IPv4 Working Group of the > IETF. > > Title : Analysis of NAT64 Port Allocation Methods for > Shared IPv4 Addresses > Authors : Gang Chen > Weibo Li > Tina Tsou > James Huang > Tom Taylor > Filename : draft-ietf-sunset4-nat64-port-allocation-00.txt > Pages : 19 > Date : 2015-05-18 > > Abstract: > This document enumerates methods of port assignment in Carrier Grade > NATs (CGNs), focused particularly on NAT64 environments. A > theoretical framework of different NAT port allocation methods is > described. The memo is intended to clarify and focus the port > allocation discussion and propose an integrated view of the > considerations for selection of the port allocation mechanism in a > given deployment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sunset4-nat64-port-allocation/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sunset4-nat64-port-allocation-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4