Subject: Re: [sunset4] review of draft-chen-sunset4-cgn-port-allocation

From: Tom Taylor <[email-masked]>
Date: Wed, 13 Aug 2014 07:38:22 -0400

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

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
>
> 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#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
>
>
>
>
>
>
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4
>