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
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.
independently of the particular flavour should be independent of the
particular flavour
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.
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).
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.
[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.
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.
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.
A+P style [citation needed]
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.
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?
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#sec
tio
n-3> and Section 4
<http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sec
tio
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.
Sections 2.4.1 and 2.4.2 are excellent.
2.4.3 s/alllocation/allocation
3.1 US means U.S.? Americans have higher traffic profiles?
3.2 Remove sentence "Here is how dynamic allocation of port-ranges would
work in greater detail. "
3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12.
Is
this section supposed to be a privacy considerations section?
Discoverability? I think in the era of Pervasive Surveillance,
reference to
other IETF work is needed. Also, please refer to RFC6302.
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.
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.
That's all I have on this round.
Lee
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
