ietf
[Top] [All Lists]

Re: [sunset4] Last Call: <draft-ietf-behave-lsn-requirements-07.txt> (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice

2012-07-11 10:10:51
There are few things that in my opinion should be added.

First, the port numbers to be allocated to CPE. Excluding Well known port 
numbers should be mentioned. Moreover if port numbers are allocated to each 
CPE, what is the criteria for allocation. As mentioned in the document : “ 
There should be no limit on the size of the address pool”, does this address 
pool imply the one that would be allocated to the CPE? According to the 
requirement of the CPE, the pool should be allocated or a fixed number of 
addresses in the address pool should be allocated to each CPE? Some amount of 
clarity in this respect would be helpful.

Moreover, the document advocates the use of Endpoint independent filtering. If 
AID is used, there would be a delay of 120 seconds for each port reallocation. 
So should EIF be used only with those applications that can’t function without 
it, instead of applying it for all.

The need to maintain a record or database of the allocated ports and their 
lifetime would be helpful. If this is maintained, the ports that are near to 
expiring their lifetime would be considered first and allocated before and in a 
order. In such cases there will be less chances of the traffic being dropped 
due to ports not being available. There should be a definite lifetime defined, 
before connection is refused due to unavailability of ports. If there is a 
threshold of say,180 seconds, during which allocated ports database can be 
scanned and if any ports is recently available, can be allocated. This would 
lead to efficient use of ports.

Tina

On Jul 9, 2012, at 8:08 AM, "Simon Perreault" 
<simon(_dot_)perreault(_at_)viagenie(_dot_)ca<mailto:simon(_dot_)perreault(_at_)viagenie(_dot_)ca>>
 wrote:

On 2012-07-09 11:03, George, Wes wrote:
While the NAT specified by this
document itself may only act on IPv4 traffic, as you note above it's
not limited to just NAT444 or even an IPv4-only *network*. The
recommendations in this doc will work for an IPv4 NAT associated with
DSLite just as easily as a more traditional IPv4 transport. This is
an important distinction, IMO.

Right, I understand now. It's the logical NAT function that is IPv4-only, not 
the global use case. I'll add some text to make this clear, and I'll 
specifically point out the DS-Lite example.

How about "Common Requirements for IPv4 Carrier Grade NATs
(CGNs)"?
[WEG] This helps, but only in conjunction with additional
clarification about the application - that is, just because the NAT
is IPv4-only doesn't mean that the network must also be IPv4-only.

Understood.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
sunset4 mailing list
sunset4(_at_)ietf(_dot_)org<mailto:sunset4(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/sunset4