[sunset4] review of draft-chen-sunset4-cgn-port-allocation

[Lee Howard]

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

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

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#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.
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

[George, Wes]

Additional comments:

Chair:
As noted during the meeting, if the deterministic CGN section is to stay in this document (we'll call consensus on that separately as a part of WG adoption call), the IPR statement from
https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-donley-behave-deterministic-cgn will need to be updated to point to this document instead.

Individual:
2.4.1 - worth noting that log size may be governed by legal and company policy regarding the length of time a given set of logs must be retained, months vs years, and that while a fairly large log with a short storage duration might be manageable, a large log coupled with a long duration retention requirement may become prohibitively expensive, even with compression and archiving to cheaper long-term storage media.
Table 1 - need to specify that this is RAW (uncompressed) log size

Failover considerations shouldn't be specific to deterministic port alloc, maybe promote to a main section and expand, or duplicate for section 3, add to section 3.4, etc. Basically, with each port allocation method you discuss, you need to cover failover considerations. This is especially important if state is maintained and must be synced between a primary and backup, or if it operates in active/active mode with load balancing, etc.

Need to update section 4.4 with more up-to-date info on IPv6 penetration on Alexa top 1M (a lot has changed since 2012), probably including a reference to the source for that information so that the reader can follow it to get more up-to-date information.

Thanks,

Wes


From: Lee Howard <***@asgard.org<mailto:***@asgard.org>>
Date: Thursday, July 24, 2014 at 4:02 PM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [sunset4] review of draft-chen-sunset4-cgn-port-allocation

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#section-3> and Section 4<http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#section-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


________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

[Tom Taylor]

Lee, thank you for the time you put into this. I won't be able to deal
with a lot of it personally because it requires my co-authors'
knowledge. However, based on the IPR discussion at the meeting, I think
we will split out deterministic CGN and let it go on its way as an
individual draft. I can do that step and respond to as much of your
review as I can. My co-authors can take the next step or advise me on
the remaining issues.

Tom Taylor

Post by Lee Howard
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
provide transparent routing to end hosts
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.
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

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

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.
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
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#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
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
https://www.ietf.org/mailman/listinfo/sunset4

[George, Wes]

Authors, you have a draft that will expire in a few weeks, as well as one
or more substantive reviews to address. Please push a revision, and then
we will do an adoption call so that we can discuss it further as a WG
draft during the meeting in honolulu.


Thanks,

Wes

Post by Tom Taylor
Lee, thank you for the time you put into this. I won't be able to deal
with a lot of it personally because it requires my co-authors'
knowledge. However, based on the IPR discussion at the meeting, I think
we will split out deterministic CGN and let it go on its way as an
individual draft. I can do that step and respond to as much of your
review as I can. My co-authors can take the next step or advise me on
the remaining issues.
Tom Taylor

Post by Lee Howard
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
provide transparent routing to end hosts
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.
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

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

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.
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
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
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
https://www.ietf.org/mailman/listinfo/sunset4

_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of

[Tom Taylor]

Excellent timing. I've freed myself more or less from some other stuff
and can get on this today. I get a new version out, then let my
co-authors address those of Lee's comments that I cannot.

Tom

Post by George, Wes
Authors, you have a draft that will expire in a few weeks, as well as one
or more substantive reviews to address. Please push a revision, and then
we will do an adoption call so that we can discuss it further as a WG
draft during the meeting in honolulu.
Thanks,
Wes

Post by Tom Taylor
Lee, thank you for the time you put into this. I won't be able to deal
with a lot of it personally because it requires my co-authors'
knowledge. However, based on the IPR discussion at the meeting, I think
we will split out deterministic CGN and let it go on its way as an
individual draft. I can do that step and respond to as much of your
review as I can. My co-authors can take the next step or advise me on
the remaining issues.
Tom Taylor

Post by Lee Howard
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
provide transparent routing to end hosts
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.
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

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

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.
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
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
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
https://www.ietf.org/mailman/listinfo/sunset4

_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

[Tom Taylor]

Responses marked with [PTT].

Thanks again for doing this review.

Tom Taylor

Post by Lee Howard
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
provide transparent routing to end hosts
provide connectivity to end hosts

[PTT] Done.

Post by Lee Howard
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.
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

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.

Post by Lee Howard
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".

Post by Lee Howard
Section 2.1 Port Consumption on NAT64

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.

Post by Lee Howard
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.

Post by Lee Howard
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.

Post by Lee Howard
[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.

Post by Lee Howard
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
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.

Post by Lee Howard
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"/>).

Post by Lee Howard
A+P style [citation needed]

[PTT] RFC 6346.

Post by Lee Howard
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".

Post by Lee Howard
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.

Post by Lee Howard
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
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.

Post by Lee Howard
Sections 2.4.1 and 2.4.2 are excellent.
2.4.3 s/alllocation/allocation

[PTT] Ok

Post by Lee Howard
3.1 US means U.S.? Americans have higher traffic profiles?

[PTT] Apparently so, subject to the way CableLabs derived their numbers.

Post by Lee Howard
3.2 Remove sentence "Here is how dynamic allocation of port-ranges would
work in greater detail. "

[PTT] OK

Post by Lee Howard
3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12.

[PTT] Fixed
Is

Post by Lee Howard
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..

Post by Lee Howard
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.

Post by Lee Howard
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.

Post by Lee Howard
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.

Post by Lee Howard
That's all I have on this round.
Lee

Thanks again.
Tom