> On Apr 21, 2015, at 1:46 PM, George, Wes <[email protected]> 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/
> <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’ve 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’t
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.”
Did you mean s/behavior/experience/ ? Otherwise I can’t grok this. Even with
that change, I’m sure if this sentence is useful.
2.4.2: I’m 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’t 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
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
