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 <[email protected]<mailto:[email protected]>> Date: Thursday, July 24, 2014 at 4:02 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
