Tina TSOU | 1 Sep 06:00 2010

Re: Port Management To Reduce Logging In Large-Scale NATs


B. R.
Tina
http://tinatsou.weebly.com/index.html

----- Original Message ----- 
From: "Dan Wing" <dwing <at> cisco.com>
To: "'Tina TSOU'" <tena <at> huawei.com>; <behave <at> ietf.org>
Sent: Tuesday, August 31, 2010 11:46 PM
Subject: RE: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

>> -----Original Message-----
>> From: Tina TSOU [mailto:tena <at> huawei.com]
>> Sent: Tuesday, August 31, 2010 2:25 AM
>> To: behave <at> ietf.org; Dan Wing
>> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
>> NATs
>> 
>> 
>> B. R.
>> Tina
>> http://tinatsou.weebly.com/index.html
>> ----- Original Message -----
>> From: "Dan Wing" <dwing <at> cisco.com>
>> To: "'Tina TSOU'" <tena <at> huawei.com>; <behave <at> ietf.org>
>> Sent: Monday, August 30, 2010 12:30 PM
>> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
>> NATs
>> 
>> 
(Continue reading)

Tina TSOU | 1 Sep 09:05 2010

Re: Port Management To Reduce Logging In Large-Scale NATs


B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message ----- 
From: "Reinaldo Penno" <rpenno <at> juniper.net>
To: "Tina TSOU" <tena <at> huawei.com>; <behave <at> ietf.org>
Sent: Tuesday, August 31, 2010 11:49 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

> Hello Tina,
>
> We have experience with this method and would like to suggest the 
> following
> be explained in the draft.
[Tina:] Reinaldo, thank you for your kind sharing and suggestion. Will 
explain them in -02 version.

>
> 1 - What is a user? A private source IP address?

[Tina] It depends, it could be a private source IP address, or tunnel ID, 
etc.

If the users could be distinguished by private source IP address, I could 
say a private source IP address stands for a user.

But in some case, i.e. DS-Lite, all the users may have a same private IP 
address, and then users should be distinguished by tunnel ID.

(Continue reading)

Tina TSOU | 1 Sep 09:11 2010

Re: Port Management To Reduce Logging In Large-Scale NATs


B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message ----- 
From: "Joel M. Halpern" <jmh <at> joelhalpern.com>
To: "Dan Wing" <dwing <at> cisco.com>
Cc: "'Tina TSOU'" <tena <at> huawei.com>; <behave <at> ietf.org>
Sent: Wednesday, September 01, 2010 12:08 AM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

>I may be missing something, but given the variations, it seems a heck of a 
>lot more reliable, and more compliant with rules, for operator NATs to log 
>what information they can, and for server logging to be a separate matter.
> The quesiton of how the NAT writes its logs, and what it writes, depends 
> upon the style of NAT and other implementation details.
> (For full cone NAT, it seems that logs which show source port allocation, 
> with timestamps, are sufficient to meet most regulatory regimes.)
[Tina: Joel, thanks a lot for your comments. What's your specific suggestion 
for this work?]
>
> Yours,
> Joel
>
> Dan Wing wrote:
>>> -----Original Message-----
>>> From: Tina TSOU [mailto:tena <at> huawei.com]
>>> Sent: Tuesday, August 31, 2010 2:25 AM
>>> To: behave <at> ietf.org; Dan Wing
>>> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
(Continue reading)

Reinaldo Penno | 1 Sep 09:12 2010
Picon

Re: Port Management To Reduce Logging In Large-Scale NATs

Hummm....let me put another way.

Subscriber A is allocated ports 1000-1200. After 5 minutes ports 1050, 1051,
1060, 1070, 1077 have not been used and therefore you return them to the
pool. 

Another subscriber comes in and is allocated ports 1201-1398, 1060 and 1070.

Now multiply this by million users. The port range gets fragmented.

Therefore after a short period all allocation of ports will be non
continuous. 

On 9/1/10 12:05 AM, "Tina TSOU" <tena <at> huawei.com> wrote:

>> 2.1  - If you return the ports individually to the pool you will not have
>> contiguous ports after some time (even if you want to). If you do not not,
>> your basically statically carving out resources and making poor use of the
>> port space.
> 
> [Tina] Conceptually there is a port pool for each user, and there are port
> blocks in the pool.
> If no ports in a block is in user for a period of time, e.g. 5minutes (TBD),
> this port block should be released and could be assigned to another user.
> There should be no "not-continuous" problem.

Picon

Re: Port Management To Reduce Logging In Large-Scale NATs


-----Original Message-----
From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf
Of Reinaldo Penno
Sent: Wednesday, September 01, 2010 3:13 AM
To: Tina TSOU; behave <at> ietf.org
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale
NATs

Hummm....let me put another way.

Subscriber A is allocated ports 1000-1200. After 5 minutes ports 1050,
1051, 1060, 1070, 1077 have not been used and therefore you return them
to the pool. 

[Senthil] I would think the port ranges are allocated/deallocated in
blocks to avoid fragmentation. Otherwise, 
it would prove difficult to manage the ports within a short span of
time. The question now may be how is oversubscription handled. For
instance, subscriber A is idle and not using his ports for the past n
minutes and subscriber Z wants more ports because he is actively
opening/closing connections but doesn't have any ports, what do we do. I
guess that is a network administration issue to solve. 

Another subscriber comes in and is allocated ports 1201-1398, 1060 and
1070.

Now multiply this by million users. The port range gets fragmented.

Therefore after a short period all allocation of ports will be non
(Continue reading)

Reinaldo Penno | 1 Sep 09:40 2010
Picon

Re: Port Management To Reduce Logging In Large-Scale NATs

Agreed. I mentioned on the first email that there are basically two choices:

* Individual port release which in the long run leads to fragmentation but
better resource use.

* Or allocating/releasing in blocks of well-known size which in a sense is
almost a static division given a number N of subscribers.

On 9/1/10 12:35 AM, "Senthil Sivakumar (ssenthil)" <ssenthil <at> cisco.com>
wrote:

> [Senthil] I would think the port ranges are allocated/deallocated in
> blocks to avoid fragmentation. Otherwise,
> it would prove difficult to manage the ports within a short span of
> time. The question now may be how is oversubscription handled. For
> instance, subscriber A is idle and not using his ports for the past n
> minutes and subscriber Z wants more ports because he is actively
> opening/closing connections but doesn't have any ports, what do we do. I
> guess that is a network administration issue to solve. 

Tina TSOU | 1 Sep 12:28 2010

Re: Port Management To Reduce Logging In Large-Scale NATs

Big pool and small pool are containing relationship. Release the port first 
to the small pool. After finishing releasing all the ports in the small 
pool, release the port to the big port. Here we go, there is no 
fragmentation.

B. R.
Tina
http://tinatsou.weebly.com/index.html

----- Original Message ----- 
From: "Reinaldo Penno" <rpenno <at> juniper.net>
To: "Senthil Sivakumar (ssenthil)" <ssenthil <at> cisco.com>; "Tina TSOU" 
<tena <at> huawei.com>; <behave <at> ietf.org>
Sent: Wednesday, September 01, 2010 3:40 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Agreed. I mentioned on the first email that there are basically two choices:

* Individual port release which in the long run leads to fragmentation but
better resource use.

* Or allocating/releasing in blocks of well-known size which in a sense is
almost a static division given a number N of subscribers.

On 9/1/10 12:35 AM, "Senthil Sivakumar (ssenthil)" <ssenthil <at> cisco.com>
wrote:

> [Senthil] I would think the port ranges are allocated/deallocated in
> blocks to avoid fragmentation. Otherwise,
> it would prove difficult to manage the ports within a short span of
(Continue reading)

Iljitsch van Beijnum | 1 Sep 17:11 2010

draft-ietf-behave-ftp64-05

I submitted a new version of the FTP64 draft.

I removed the client and server recommendations as per the input from the FTPEXT2 BoF and also made some
small other tweaks.

Iljitsch

> A new version of I-D, draft-ietf-behave-ftp64-05.txt has been successfully submitted by Iljitsch van
Beijnum and posted to the IETF repository.

> Filename:	 draft-ietf-behave-ftp64
> Revision:	 05
> Title:		 An FTP ALG for IPv6-to-IPv4 translation
> Creation_date:	 2010-09-01
> WG ID:		 behave
> Number_of_pages: 15

Internet-Drafts | 1 Sep 17:15 2010
Picon

I-D Action:draft-ietf-behave-ftp64-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : An FTP ALG for IPv6-to-IPv4 translation
	Author(s)       : I. van Beijnum
	Filename        : draft-ietf-behave-ftp64-05.txt
	Pages           : 15
	Date            : 2010-09-01

The File Transfer Protocol (FTP) has a very long history, and despite
the fact that today, other options exist to perform file transfers,
FTP is still in common use.  As such, it is important that in the
situation where some client computers are IPv6-only while many
servers are still IPv4-only and IPv6-to-IPv4 translators are used to
bridge that gap, FTP is made to work through these translators as
best it can.

FTP has an active and a passive mode, both as original commands that
are IPv4-specific, and as extended, IP version agnostic commands.
The only FTP mode that works without changes through an IPv6-to-IPv4
translator is extended passive.  However, many existing FTP servers
do not support this mode, and some clients do not ask for it.  This
document describes specifies a middlebox that may solve this
mismatch.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-ftp64-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Reinaldo Penno | 1 Sep 17:23 2010
Picon

Re: Port Management To Reduce Logging In Large-Scale NATs

Sure, but then your port available space is divided by the size of your
small pool and it will impact how many subscribers you can handle.

On 9/1/10 3:28 AM, "Tina TSOU" <tena <at> huawei.com> wrote:

> Big pool and small pool are containing relationship. Release the port first
> to the small pool. After finishing releasing all the ports in the small
> pool, release the port to the big port. Here we go, there is no
> fragmentation.
> 
> B. R.
> Tina
> http://tinatsou.weebly.com/index.html
> 
> ----- Original Message -----
> From: "Reinaldo Penno" <rpenno <at> juniper.net>
> To: "Senthil Sivakumar (ssenthil)" <ssenthil <at> cisco.com>; "Tina TSOU"
> <tena <at> huawei.com>; <behave <at> ietf.org>
> Sent: Wednesday, September 01, 2010 3:40 PM
> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs
> 
> 
> Agreed. I mentioned on the first email that there are basically two choices:
> 
> * Individual port release which in the long run leads to fragmentation but
> better resource use.
> 
> * Or allocating/releasing in blocks of well-known size which in a sense is
> almost a static division given a number N of subscribers.
> 
(Continue reading)


Gmane