On 07/10/2012 10:43 PM, Tina TSOU wrote:
First, the port numbers to be allocated to CPE. Excluding Well known
port numbers should be mentioned.
As draft editor, I would ask for a justification. I can't add a
requirement without a justification.
Moreover if port numbers are allocated
to each CPE, what is the criteria for allocation.
I don't know, I'm just an editor. What specific text in the draft do you
think needs to be changed?
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?
No. It refers to the external address pool used by the CGN.
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?
Sorry, I don't understand this question.
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 draft proposes a more conservative approach: use EIF for everything
with ADF exceptions. I understand you propose the reverse: ADF for
everything with EIF exceptions. And I understand that the justification
would be scalability. However, it seems to me that ADF exceptions can be
made for heavy use protocols such as HTTP and DNS to address that
scalability concern. Why isn't that enough?
The need to maintain a record or database of the allocated ports and
their lifetime would be helpful.
How could any NAT work without such a database? I probably misunderstand
what you're suggesting...
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.
This seems to go against REQ-11 D.
REQ-11: When a CGN is unable to create a mapping due to resource
constraints or administrative restrictions (i.e., quotas):
D. and it MUST NOT delete existing mappings in order to
"make room" for the new one. (This only applies to
normal CGN behavior, not to manual operator
intervention.)
Are you suggesting that this requirement be dropped? If so, it would be
necessary to demonstrate why the justification for this requirement,
quoted below, is invalid.
Applications generally handle connection establishment failure
better than established connection failure. This is why dropping
the packet initiating the new connection is preferred over
deleting existing mappings. See also the rationale in [RFC5508]
section 6.
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.
I'm sorry, I don't understand this proposal. Maybe an example would help?
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
