Responses marked with [PTT].
Thanks again for doing this review.
Tom Taylor
On 24/07/2014 4:02 PM, Lee Howard wrote:
Doing my homework before the WG meeting this afternoon (and re-sending from
the correct email address). . .
This document needs significant work and reorganization.
1. Introduction
You say:
provide transparent routing to end hosts
I think it should say:
provide connectivity to end hosts
[PTT] Done.
Is it worth adding a sentence that these methods are only useful for address
sharing methods, not NPT, and not encapsulation mechanisms? It may not be
necessary.
But, for instance, this sentence:
The CGN may not do Network Address Port Translation (NAPT), but only
Network Address Translation (NAT) [RFC3022
<http://tools.ietf.org/html/rfc3022> ].
THat's not an rfc2119 "may not," it's a description of one scenario. I had
to read it four times to figure that out; maybe it would be clearer as:
The CGN might do Network Address Port Translation
(NAPT) without Network Address Translation (NAT) [RFC3022
<http://tools.ietf.org/html/rfc3022> ]. In
this scenario, there is no concern about port assignment. When NAPT is
involved, Š
Then you can enumerate the "does" and "does not" cases.
[PTT] Rewrote and moved text to new paragraph at end of section:
NEW PARA
The considerations in this document do not apply where the CGN does only
Network Address Translation (NAT) <xref target="RFC3022"/>. In this
scenario, there is no concern about port assignment. Similarly, this
document does not apply where encapsulation rather than translation is
used as the IPv6 transition method.
independently of the particular flavour should be independent of the
particular flavour
[PTT] I'll leave that to the RFC Editor. According to the grammar I was
taught, "independently" is an adverb modifying the adjective "applicable".
Section 2.1 Port Consumption on NAT64
This editorializing is unnecessary:
Thanks to its simplicity and efficiency, NAT64 will likely be
deployed widely.
Also,
That is, a NAT44 will be deployed in an
IPv4-only environment.
NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so this
is untrue. But this whole paragraph reads like a sales pitch for NAT64: cut
it out.
[PTT] Done.
Second paragraph:
One of the authors did a test comparison of port consumption on NAT64
and NAT44.
Can you just cite the study? Can you say, "A study of port consumption
[portstudy]. . ." Though again, this whole study is only true to a point in
time (though what version of the Alexa100 includes 43 sites with AAAA I
don't know).
[PTT] Changed to "China Mobile". If Gang has a published study he can
give a reference.
NAT64 "provides everyone with incentives to use IPv6,"
What incentives? Does it buy ice cream for everyone who uses IPv6? Either
explain, or, since defending the use of NAT64 is out of place in this
document, remove.
[PTT] Done.
[as v6 transition progresses,] it will be possible to relax the
multiplexing ratio of IPv4 address sharing.
This is a good point.
change of IPv4 address will cause
renumbering of IPv6 addresses.
I don't see how. But again, I don't think this is intended as a NAT
discussion document, I thought it was just evaluating port allocation
methods. Clean up that paragraph.
[PTT] This is stateless allocation with embedded IPv4 addresses, so yes,
when the IPv4 address changes, so does the IPv6 address.
It has been learned from subscribers'
behaviors that the average number of sessions consumed by one
user's device is around 200 to 300 ports. Several devices may
appear behind a CPE. Administrators may configure a range
with 1000 ports to each CPE in fixed networks.
Avoid the passive voice. Can you cite the 200-300 number? Is that true in
2014, or for as long as this document is intended to be useful? Yes,
administators may configure 1000 ports. Or 1001. Or 999. Maybe what you
mean is:
1000 ports per subscriber household will provide enough room for multiple
active users. Administrators should monitor usage to adjust this number if
users are being limited by this number, or if usage is so low that fewer
ports would be sufficient.
[PTT] This comes from the China Mobile study. Here is the new text,
replacing the existing paragraph from "It has been learned ..." onwards.
NEW
The China Mobile study mentioned earlier observed that the average
number of sessions consumed by one user's device was around 200 to 300
ports. Several devices may appear behind a CPE. Based on this
observation, 1000 ports per subscriber household will provide enough
room for multiple active users. Administrators should monitor usage to
adjust this number if users are being limited by this number, or if
usage is so low that fewer ports would be sufficient.
non-contiguous port range for the
sake of attack defense.
I think you explain this later in the document, but a reference to what you
mean here would help.
[PTT] Modified text: The assigned ports can be in either a contiguous
port range or a non-contiguous port range for the sake of defence
against port-guessing attacks (see <xref target="bulkAlloc_2"/>).
A+P style [citation needed]
[PTT] RFC 6346.
2.3.1 Use of the word "older" sounds perjorative. Do you mean to imply
that NAT64 is obsolete? Both in the title and text.
[PTT] Changed to "other".
Stepping outside
the boundaries of NAT64 for the moment, DS-Lite [RFC6333
<http://tools.ietf.org/html/rfc6333> ] refers to
the cautions in [RFC6269 <http://tools.ietf.org/html/rfc6269> ] but does
not specify any port allocation
method.
First, that's pretty informal language. Second, why point to DS-Lite
pointing to RFC6269; why not just point to RFC6269?
[PTT] OK, changed "Stepping outside the boundaries" to "Looking beyond".
The reason to point to DS-Lite is that it does not specify a port
allocation method. That's the main point.
2.3.2 Current Work on Stateless Transition Technologies
The proposals made in Section 3
<http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sectio
n-3> and Section 4
<http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sectio
n-4> do not apply
to the current work in progress because that work has gone in another
direction. That work includes:
Do we need to enumerate protocols that this work doesn't apply to? If so,
then I think this document is making normative references to those protocols
(since their port allocation methods could, potentially, change until they
are published), which will delay publication until lw4over6, MAP-T, MAP-E,
4rd have all been published. Having said that, this may be a useful
comparison of possible methods, but I would try to limit it to that.
[PTT] Left the summary in, though I don't feel strongly about it.
Sections 2.4.1 and 2.4.2 are excellent.
2.4.3 s/alllocation/allocation
[PTT] Ok
3.1 US means U.S.? Americans have higher traffic profiles?
[PTT] Apparently so, subject to the way CableLabs derived their numbers.
3.2 Remove sentence "Here is how dynamic allocation of port-ranges would
work in greater detail. "
[PTT] OK
3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12.
[PTT] Fixed
Is
this section supposed to be a privacy considerations section?
[PTT] Definitely not what we originally had in mind. A separate Privacy
Considerations section as you suggest may be the way to go, but RFC 6269
really says it all already..
Discoverability? I think in the era of Pervasive Surveillance, reference to
other IETF work is needed. Also, please refer to RFC6302.
[PTT] Thanks for the 6302 reference.
I'm not sure, though, that the discussion of server port logging is
appropriate in a document about how to allocate ports in CGN. A mention of
it makes sense, but evaluating the capability of different web servers, with
a config guide, seems out of place.
[PTT] Removed summary and appendix.
These "traceability" issues apply equally to all port allocation methods,
right? Maybe a Privacy Considerations section at the end.
I didn't review section 4, because I've reviewed it before. And I ran out
of time.
5. Security Considerations needs a rewrite‹it completely ignores Section 4.
[PTT] Section 4 is gone now, based on feedback from Toronto.
That's all I have on this round.
Lee
Thanks again.
Tom
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
