Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions
draft-ietf-softwire-stateless-4v6-motivation-05

The security considerations section reduces to "this might be better than some other approach". It would be much more useful to talk about the security properties if this kind of solution were deployed. The document seems to avoid highlighting some of the tradeoffs a stateless approach entails. For instance, if an element ended up inappropriately in a blacklist, some avenues for recourse available in a stateful solution would not be available here. Adding discussion of that kind of tradeoff would make a more useful document for motivating and guiding additional work.

1) This document is in the softwire charter so I can see publishing it, but I tend to agree with Adrian that I expected s3 to better motivate the need.  I for sure thought you'd correlate the sections in s3.* with the numbers in s3.

2) s1: The word smithing that follows is non-blocking (obviously) ... but maybe:

OLD:

   When the global IPv4 address space is exhausted, Service Providers
   will be left with an address pool that cannot be increased anymore.
   Many services and network scenarios will be impacted by the lack of
   IPv4 public addresses.  Providing access to the (still limited) IPv6
   Internet only won't be sufficient to address the needs of customers,
   as most of them will continue to access legacy IPv4-only services.
   Service Providers must guarantee their customers that they can still
   access IPv4 contents although they will not be provisioned with a
   global IPv4 address anymore.  Means to share IPv4 public addresses
   are unavoidable [RFC6269].

NEW:

 When the global IPv4 address space is exhausted, Service Providers
 will be unable to obtain addition IPv4 addresses for their customers.
 Service Providers can't simply provide their customers with IPv6
 addresses because many services will likely be IPv4-only services for
 the foreseeable future.  Service Providers need to guarantee continued
 access to the IPv4-only services for the customers.

3) s1: I think this is redundant:

 There is nothing like a
 "One size fits all" solution or one target architecture that would
  work for all situations.

maybe just:
 
 There is no one size fits all solution.

4) s1: word smithing alert:

OLD:

 Current standardization effort that is meant to address this IPv4
 service continuity issue focuses mainly on stateful mechanisms that
 sharing of global IPv4 addresses between Customers is based upon the
 deployment of NAT (Network Address Translation) capabilities in the
 network.

NEW:

 Current standardization efforts to address the IPv4 service continuity
 issue focuses on stateful mechanisms that share global IPv4 addresses
 between customers with NAT (Network Address Translation) capabilities
 in the network.

5) s1: when you say "Because of some caveats of such" what do you mean?  I thought it's more that they're unhappy they're going to have buy/deploy/manage another box (i.e., CGN) that they're (hopefully) not going to keep for very long - in other words it's a low ROI.  If I'm right can we say that?

OLD:

 Because of some caveats of such stateful approaches the
 Service Provider community feels that a companion effort is required
 to specify stateless IPv4 over IPv6 approaches. 

NEW:

 Because the stateful approaches requires the deployment of additional
 hardware that will be unnecessary once IPv6 is fully deployed, Service
 Providers see a low return on their investment in a Carrier Grade NAT
 (CGN) and are seeking to specify stateless IPv4 over IPv6 approaches.

6) s1: I don't think the solution is elaborated in this document:

OLD:

 Note that the
 stateless solution elaborated in this document focuses on the
  carrier-side stateless IPv4 over IPv6 solution.

NEW:

 This document focuses on carrier-side stateless IPv4 over IPv6.

7) s1: delete penultimate paragraph it's redundant if you accept #6.

8) s2 stateful 4/6 solution: Maybe more simply

 Stateful 4/6 solution  (or stateful solution in short): denotes a
      solution where a NAT in the Service Provider's network
      maintains user-session states [I-D.ietf-behave-lsn-requirements].
      The NAT function is
      responsible for sharing the same IPv4 address among several
      subscribers and for maintaining user-session state.

9) s2 stateless: Maybe more simply:

 denotes a
 solution that does not require any per-user state (see Section
 2.3 of [RFC1958]) be maintained in the Service Provider's network.
 A dependency between an IPv6 prefix and IPv4 address is assumed.
 In an IPv4 address sharing context, dedicated
 functions are enabled in the CPE router to
 restrict the source IPv4 port numbers.  Within this document,
 "port set" and "port range" terms are used interchangeably.

11) s3: If you're going to keep s3.4 should cost be in the s3 list? Maybe even at the top?

12) s3.2.1: I think you could delete the 1st paragraph - of course they want to preserve their practices because it's cheaper to do so.

13) s3.2.1: Maybe some common practices are preserved I can't believe all will be preserved.

14) Please: expand CAPEX, OPEX, and CGN.

15) s3.2.4: I had a lot of trouble parsing this:

 Deploying stateful techniques, especially when used in the Service
 Providers networks, constrains severely deploying multi-vendor
 redundancy since very often proprietary vendor-specific protocols are
 used to synchronize state.

Maybe:

 Deploying stateful techniques is problematic because often proprietary
 protocols are used to synchronize state and with multiple vendors in
 a Service Provider's network multiple protocols are needed.

and I had trouble parsing this:

OLD:

 This criterion is very important for Service Providers having a
 sourcing policy to avoid mono-vendor deployments and to operate
 highly-available networks composed on multi-vendors equipment.

NEW:

 This criterion is very important for Service Providers because they
 want to avoid being locked into one vendor for their entire network
 and they want to operate multi-vendor-supplied networks.

15) s3.4: Not sure the following is entirely true because I'm not sure you can speak for all service providers:

 From a
 Service Provider perspective, stateless solutions are more attractive
 because they do less impact the current network operations and
 maintenance model that is widely based on stateless approaches.

Maybe:

 From a Service Provider perspective, stateless solutions may be
 more attractive because it impacts the current network operations
 and maintenance model less than stateful solutions.

16) s5: Unsure s5 is needed - especially the last paragraph.  It's already in the charter to do this work so I don't see the point.

17) I also agree with Robert that discussing the security properties if this kind of solution were deployed would be better than just saying we're just as good but maybe a little better.

- I agree with other comments that the list at the start of
section 3 needs work. Adrian's breakdown of that looks
reasonable to me. 

- Some acronyms are used but not defined, e.g. OSS, ASBR

- 3.1.3 says that abuse reporting requires traceability, and
refers to rfc 6269, but the section there on traceability
refers only (I think) to legal obligations that exist "in many
jurisdictions." Given rfc 2804 I think the argument here either
needs to be fixed or else better, the section removed.  Note:
I'm not saying here that operators don't have to meet legal
requirements, but that the IETF have consensus not to
standardise the wiretapping aspects of that, so its not that
clear whether this argument works given that context. 

- 3.1.4 says that UPnP can be used. I don't know the security
properties of such a solution, but I'd not be surprised if they
were problematic. Are they? [1] would appear to imply there are
ongoing issues at least. If so, then saying/admitting that
would be better. 

   [1] http://www.upnp-hacks.org/

- 3.3.1 - it seems odd to me that identifying a subscriber via
IP addressing alone is really a good approach for offering many
value added services so I'm not so sure this is a very good
argument. 

- The above 3 points might or might not result in security
related issues with some resulting stateless approach but I
don't think any ought be DISCUSS level issues here.