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

Unfortunately the amount of work required to address the outstanding comments on this document has proven too much.  I think the right thing to do with it is to send it to the ISE.

[Ballot comment]
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.

[Ballot comment]
I second Adrian's points.
Section 3 is not motivating a stateless solution, as many claims are not proven in reality.
This draft is good to have for the group's discussion, but I do not see why it must become an RFC. 

An editorial point:
Section 2., paragraph 3:

>    Session state:  refers to an information state as defined in Section
>        2.3 of [RFC2663].  In particular, it refers to the state
>        maintained by the NAT so that datagrams pertaining to a session
>        are routed to the right node.  Note, TCP/UDP sessions are
>        uniquely identified by the tuple of (source IP address, source
>        TCP/UDP port, target IP address, target TCP/UDP port) while ICMP
>        query sessions are identified by the tuple of (source IP
>        address, ICMP query ID, target IP address).

The tuple for TCP and UDP, and also ICMP, is incomplete, as the protocol identifier is missing. It is sort of implicit that the text says TCP/UDP port, but a device would use the protocol fields listed and also the protocol identifier.  Even though the text is written in RFC 2663, it is not correct as it is now.

[Ballot comment]
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.

[Ballot comment]

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

[Ballot discuss]

  The Gen-ART Review by Joel Halpern on 5-Oct-2012 raised several
  issues.  Based on the discussion that followed, I was expecting an
  updated I-D to pe posted to resolve those issues.  So far, that has
  not happened.

[Ballot comment]
I really appreciate the willingness of Service Providers to become
involved in this debate. But I havesome real problems with this
document.

I find that several of the list of 15 "motivations which justify the
need for a stateless solution", while being good and desirable things
in a network, don't motivate the stateless solution unless you are able
to show more clearly that a stateful solution prevents these features.

I hoped that the subsections of section 3 would discuss these features
one by one, but the subsections are organised differently and so bring
the list into question.

Furthermore, the discussions in Section 3 seem to treat statelessness
as some kind of magic panacea.

I am not sure that there is any real actionable solution to my concerns.
Perhaps an entire re-write from a different perspective might resolve
this, but it seems unreasonable to ask you to do this, so I have decided
to Abstain so as to not block the progress of this work.

IANA has reviewed draft-ietf-softwire-stateless-4v6-motivation-04,
which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions) to Informational RFC


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Motivations for Carrier-side Stateless IPv4 over IPv6 Migration
  Solutions'
  as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  IPv4 service continuity is one of the most pressing problems that
  must be resolved by Service Providers during the IPv6 transition
  period - especially after the exhaustion of the public IPv4 address
  space.  Current standardization effort that addresses IPv4 service
  continuity focuses on stateful mechanisms.  This document elaborates
  on the motivations for the need to undertake a companion effort to
  specify stateless IPv4 over IPv6 approaches.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivation/ballot/


No IPR declarations have been submitted directly on this I-D.

Please advance in the process and publish the draft from the
Softwires WG. Here is the proto writeup for the draft:
draft-ietf-softwire-stateless-4v6-motivation-04.txt


>(1) What type of RFC is being requested (BCP, Proposed Standard,
>Internet Standard, Informational, Experimental, or Historic)? Why
>is this the proper type of RFC? Is this type of RFC indicated in the
>title page header?

Intended status: Informational
This document discusses the motivation for Carrier-side Stateless
IPv4 over IPv6, rather than defines a protocol.

>
>(2) The IESG approval announcement includes a Document Announcement
>Write-Up. Please provide such a Document Announcement Write-Up. Recent
>examples can be found in the "Action" announcements for approved
>documents. The approval announcement contains the following sections:
>
>Technical Summary

IPv4 service continuity is a desired function even for IPv6 access
networks. Current standardization effort that addresses IPv4 service
continuity focuses on stateful mechanisms. This document elaborates
on the motivations for the need to undertake a companion effort to
specify stateless IPv4 over IPv6 approaches.


>Working Group Summary
>
> Was there anything in WG process that is worth noting? For
> example, was there controversy about particular points or
> were there decisions where the consensus was particularly
> rough?

This document was discussed in depth and well-reviewed.
WG consensus is strong to publish this document.


>
>Document Quality
>
> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to
> implement the specification? Are there any reviewers that
> merit special mention as having done a thorough review,
> e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If
> there was a MIB Doctor, Media Type or other expert review,
> what was its course (briefly)? In the case of a Media Type
> review, on what date was the request posted?

N/A.
This is motivation document rather than a protocol definition.

>
>Personnel
>
> Who is the Document Shepherd? Who is the Responsible Area
> Director?

Softwire co-chair, Yong Cui, is the Document Shepherd.
Ralph Droms is the Responsible AD.


>
>(3) Briefly describe the review of this document that was performed by
>the Document Shepherd. If this version of the document is not ready
>for publication, please explain why the document is being forwarded to
>the IESG.

The document is well writen and ready for publication.

>
>(4) Does the document Shepherd have any concerns about the depth or
>breadth of the reviews that have been performed?

No.
>
>
>(5) Do portions of the document need review from a particular or from
>broader perspective, e.g., security, operational complexity, AAA, DNS,
>DHCP, XML, or internationalization? If so, describe the review that
>took place.

No.
>
>(6) Describe any specific concerns or issues that the Document Shepherd
>has with this document that the Responsible Area Director and/or the
>IESG should be aware of? For example, perhaps he or she is uncomfortable
>with certain parts of the document, or has concerns whether there really
>is a need for it. In any event, if the WG has discussed those issues and
>has indicated that it still wishes to advance the document, detail those
>concerns here.

N/A.
>
>(7) Has each author confirmed that any and all appropriate IPR
>disclosures required for full conformance with the provisions of BCP 78
>and BCP 79 have already been filed. If not, explain why.

N/A.
This document does not define any architecture/protocol nor any solution
to a technical problem.

>
>(8) Has an IPR disclosure been filed that references this document?
>If so, summarize any WG discussion and conclusion regarding the IPR
>disclosures.

No IPR issue.
>
>(9) How solid is the WG consensus behind this document? Does it
>represent the strong concurrence of a few individuals, with others
>being silent, or does the WG as a whole understand and agree with it?

This document was revised based on the discussion in wg meetings
and mailinglist.
The WG consensus is strong and most of the active participants
strongly agree on the advancement of this document.

>
>(10) Has anyone threatened an appeal or otherwise indicated extreme
>discontent? If so, please summarise the areas of conflict in separate
>email messages to the Responsible Area Director. (It should be in a
>separate email because this questionnaire is publicly available.)

No.

>
>(11) Identify any ID nits the Document Shepherd has found in this
>document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
>Checklist). Boilerplate checks are not enough; this check needs to be
>thorough.

No nits issues.
>
>
>(12) Describe how the document meets any required formal review
>criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.
>
>(13) Have all references within this document been identified as
>either normative or informative?

As a motivation document, there are only informative references
in the document.

>
>(14) Are there normative references to documents that are not ready for
>advancement or are otherwise in an unclear state? If such normative
>references exist, what is the plan for their completion?

No.
>
>(15) Are there downward normative references references (see RFC 3967)?
>If so, list these downward references to support the Area Director in
>the Last Call procedure.
>
No.

>
>(16) Will publication of this document change the status of any
>existing RFCs? Are those RFCs listed on the title page header, listed
>in the abstract, and discussed in the introduction? If the RFCs are not
>listed in the Abstract and Introduction, explain why, and point to the
>part of the document where the relationship of this document to the
>other RFCs is discussed. If this information is not in the document,
>explain why the WG considers it unnecessary.

No.
>
>(17) Describe the Document Shepherd's review of the IANA considerations
>section, especially with regard to its consistency with the body of the
>document. Confirm that all protocol extensions that the document makes
>are associated with the appropriate reservations in IANA registries.
>Confirm that any referenced IANA registries have been clearly
>identified. Confirm that newly created IANA registries include a
>detailed specification of the initial contents for the registry, that
>allocations procedures for future registrations are defined, and a
>reasonable name for the new registry has been suggested (see RFC 5226).

N/A.
>
>
>(18) List any new IANA registries that require Expert Review for future
>allocations. Provide any public guidance that the IESG would find
>useful in selecting the IANA Experts for these new registries.

N/A.
>
>(19) Describe reviews and automated checks performed by the Document
>Shepherd to validate sections of the document written in a formal
>language, such as XML code, BNF rules, MIB definitions, etc.

N/A.