Received changes through RFC Editor sync (changed abstract to 'When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.

This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot discuss]
This is a discuss-discuss (nothing for the authors for the authors to do)

From the secdir review:

It would be nice if either this draft or the one referenced [wing-nat-pt-replacement-comparison] would prescribe techniques to mitigate [DoS and spoofing] attacks.

I understand this draft just documents what the thinking was back then, but is there a reason it shouldn't document techniques to mitigate DoS and spoofing attacks?

[Ballot comment]
I like this document and find it useful *now*. However, the Abstract and the start of Section 1 make a strong statement about this being a historical record of the thinking over two years ago. I find that detracts from the value of the document. Maybe this is just a statement that I would have prefered the I-D to have been published sooner.

---

I don't find the Security section very strong or helpful. I think that
rather than pointing to an example (non-normative) I-D, you should actually
set out generic the security issues for the solutions to consider. In other
words, a little general security guidance in line with the other guidance
about the solutions in the document. After all, you don't say in Section 2
"Description of solutions can be found elsewhere, for instance in
[I-D.durand-dual-stack-lite]."



And a couple of nits I found along the way...

---

Section 1 page 5
s/public addresses and on the IPv4/public addresses, and on the IPv4/

---

Section 2.1

more hosts behind the gateway (GW) as there are IPv4
s/as/than/

[Ballot comment]
I don't find the Security section very strong or helpful. I think that
rather than pointing to an example (non-normative)



And a couple of nits I found along the way...

---

Section 1 page 5
s/public addresses and on the IPv4/public addresses, and on the IPv4/

---

Section 2.1

more hosts behind the gateway (GW) as there are IPv4
s/as/than/

[Ballot discuss]
It's a tiny, pettifogging Discuss, but...

I like this document and find it useful *now*. That suggests that its classification as Informational is correct.

However, the Abstract and the start of Section 1 make a strong statement about this being a historical record of the thinking over two years ago. That would make this a Historic RFC.

I would prefer to remove the text about history, and keep the document Informational

[Ballot comment]
A well written document.

nit:

old
The tunnel could created in any number of
new
The tunnel could be created in any number of

[Ballot comment]
From the Security Directorate review:

  The security considerations section does exist and defers to
  wing-nat-pt-replacement-comparison for some of the solutions.
  wing-nat-pt-replacement-comparison discusses possible DoS and
  spoofing attacks when sharing an IPv4 amongst multiple subscribers.
  Though it would be nice if either this draft or the one referenced
  would prescribe techniques to mitigate such attacks.

  General comments:

  None.

  Editorial comments:

  s/reader to be consider/reader to consider/

  This sentence should be restructured for readability purposes:

  For deployments where the GW is owned and operated by the customer,
  this becomes operational overhead for the Internet Service Provider
  (ISP) that it will no longer be able to rely on the customer and the
  seller of the GW device for.


  s/of NAT444 need/of NAT444 needs/

  s/tunnel could created/tunnel could be created/

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for
forwarding to the IESG for publication?

There is no shepherd. Jari Arkko has reviewed the draft in its entirety
in July 2009 and made small updates where necessary. The authors believe
the draft is ready to be published as a historical record of the
thinking in late 2008 when various new work items for IPv6 - IPv4
coexistence were taken on by the IETF.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that have been
performed?

There has been discussion of both the document itself, and its
recommendations for new work. To a large extent those recommendations
have already been adopted.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA,
internationalization or XML?

It is obvious that the community interested in the co-existence issue
needs to review this in Last Call before we publish this. But other than
that, there are no specific concerns or specific review needs.

(1.d) Does the Document Shepherd have any specific concerns or issues
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 interested community has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

No concerns.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

We believe that the community in general agrees with the position that
the document takes. It is possible that the port based routing parts are
controversial. However, the document does not that those parts have not
yet been adopted by the IETF. So in this sense the document seems to
reflect the real state of affairs.

(1.f) 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 entered into the ID
Tracker.)

No

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?

Yes, no concerns.

(1.h) Has the document split its references into normative and
informative? 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 strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to
support the Area Director in the Last Call procedure for them
[RFC3967].

Yes, no downref concerns.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document describes
an Expert Review process has Shepherd conferred with the Responsible
Area Director so that the IESG can appoint the needed Expert during
the IESG Evaluation?

Yes, no problems.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

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

Technical Summary

When IPv6 was designed, it was expected that the transition from
IPv4 to IPv6 would occur more smoothly and expeditiously than
experience has revealed. The growth of the IPv4 Internet and predicted
depletion of the free pool of IPv4 address blocks on a foreseeable horizon
has highlighted an urgent need to revisit IPv6 deployment models. This
document provides an overview of deployment scenarios with the goal of
helping to understand what types of additional tools the industry
needs to assist in IPv4 and IPv6 co-existence and transition.

Working Group Summary

This document was originally created as input to the Montreal
co-existence interim meeting in October 2008, which led to the
rechartering of the Behave and Softwire working groups to take on new
IPv4 and IPv6 coexistence work. This document is published as
a historical record of the thinking at the time.

Document Quality

At least some of the recommendations from the document have been adopted
through rechartering of the Behave and Softwire working groups.