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

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.perreault@viagenie.ca<mailto:simon.perreault@viagenie.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@ietf.org<mailto:sunset4@ietf.org>
https://www.ietf.org/mailman/listinfo/sunset4