[Ballot comment]
The reference for 1918 should be normative based on the following:

  However, it SHOULD operate its own DHCP(v4) server handing out
  [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.

[Ballot comment]
Consider adding a short discussion or perhaps an example of how services that sit on the Internet side of an AFTR (especially those in the same administrative domain of the AFTR) that need to know which B4 IPv4 traffic came through might get that information from the AFTR (perhaps using the information in the extended binding table described in section 6.6). Showing how a location query in a protocol like HELD (RFC5985) would be answered would be a good example.

[Ballot discuss]
(1) Where's it say that DNSSEC needs to work through
the B4 thing? I don't know if that's problematic or
not but RFC4033 does say the DNS proxies need to be
security aware for DNSSEC to work (section 6 of 4033)
so that may be worth repeating here.

(2) Is the "SHOULD NOT interfere" language in 7.2
sufficient? I don't know but it seems awfully short.
Is there anything similar that needs to be said
about TLS or DTLS?

(3)  8.1 - ought that say "the address ranges in the
pools"? (Instead of the "the address range in the
pools")

(4) How would the AFTR impact on anti-spam solutions
such as DNSRBLs? I think that may warrant a mention.

[Ballot comment]
In section 5.2, the final paragraph should be slightly more
clear that it's saying to fragment the IPv6 tunnel packet
into multiple IPv6 fragments, and not the inner IPv4 packet
into multiple tunnelled IPv6 packets.  It may be worth
mentioning here also that fragmenting the IPv4 packet instead
is not a good idea or alternative.


Typos:
- in Section 6.4, "a B4 elements" -> "a B4 element"

[Ballot discuss]
Section 5.6 is a little strange, since it says that the topic
is out of scope, but doesn't give any hint as to where this
information might be found, why it's deemed out of scope, or
who it would be in-scope for.  I would think this should be
easy to clarify.

[Ballot comment]
There are a few places where I feel the document could be improved, if the document is revised.

section 4.1 what is horizontal scaling?
4.2 last sentence duplicates section 1
diagrams would help
6.3 discusses clients, but clients are not defined.
6.4 the English is a little weak;
8.5 carrier-grade nat is not defined
B.1 s/DCHP/DHCP/
figure 1 uses 10.0 addresses, while the text talks about 192.168 addresses.
are the addresses used consistent with reserved example addresses?
s/concentrartor/concentrator/
B.1.2 SE not defined on first use.
B.2.1 why a.b.c.d rather than 192.0.0.2?

[Ballot discuss]
There are a few question I would like to discuss before approving this document.

1) 6.3 makes assumptions, but doesn't prescribe behavior if the assumption is false.
what should happen if an AFTR runs out of resources due to reassembly?
2) 6.5 why MAY, and not SHOULD or MUST?
3) 7.1 why SHOULD and not MUST? what are the acceptable exceptions to SHOULD?
4) 7.2 why SHOULD NOT rather than MUST NOT? what are the acceptable exceptions, what types of interference are expected/allowed, and how should implementations handle the interference?
5) 7.3 why is this out of scope?
6) 8.1 s/must not/MUST NOT/
7) 8.2 why SHOULD rather than MUST? acceptable exceptions? how should implementations respond to the exceptional case for interoperability?

[Ballot comment]
Thanks for a fine and readble document.

Herewith, a few minor points you might like to look at to improve the document.

---

I was surprised that the following statements use a weak "MAY"

  The B4 element MAY use any other addresses within
  the 192.0.0.0/29 range.

  The AFTR MAY use the well-known IPv4 address 192.0.0.1

"MAY" is usually used when there is some other more normal behavior, but
you don't say what that is.

---

7.2.  VPN

  Dual-stack lite implementations SHOULD NOT interfere with the
  functioning of IPv4 or IPv6 VPNs.

Seems a bit of an odd use of "SHOULD NOT". I'm not clear whether you
are commentng that "in your view the DS-Lite technology should not
cause anything to break" or observing that it would be a broken
implementation that *chose* to interfere with VPN function.

---

8.4.  Sharing global IPv4 addresses

  AFTR shares a single IP to multiple users.

s/to/address with/

---

8.5.  Port forwarding / keep alive

  Work on a control plane to the carrier-grade NAT is done in the PCP
  working group at IETF.  The PCP protocol enables

What does the second 'P' in "PCP" stand for?

IANA has a question about the IANA Actions in this document.

IANA understands that, upon approval of this document, the authors have
requested a single IANA Action as follows:

"Allocate a well know IPv4 192.0.0.0/29 network prefix." "Reserving a
/29 allows for 6 possible interfaces on a multi-home node. The IPv4
address 192.0.0.1 is reserved as the IPv4 address of the default router
for such dual- stack lite hosts."

IANA Question --> IANA needs to clarify the routing scope of the
assignment requested by the authors, so that IANA can record it in the
registry:
http://www.iana.org/assignments/iana-ipv4-special-registry

As an example of what the IANA is looking for, please examine:

http://www.iana.org/assignments/iana-ipv6-special-registry

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <softwires@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-softwire-dual-stack-lite-07.txt> (Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion'
  <draft-ietf-softwire-dual-stack-lite-07.txt> as a Proposed Standard

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 2011-04-12. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-dual-stack-lite/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-dual-stack-lite/

I have now completed my review of the draft. Here are the remaining comments:

Overall:

The draft is in relatively good shape. I saw a number of cases where you should have been more precise in the specification, but those cases can definitely be corrected. There are a few missing things, but again something that can be taken care of.

I am expecting a new revision.

Technical:

Shouldn't the draft talk about how a service provider AFTR makes it less likely that the user can exert control with protocols like UPnP-IGD? You should bring up this issue up early in the document, and then you can point to Appendix C for possible future work around that limitation.

What happens if two B4s are chained together, both using the reserved address range?

> However, moving the NAT functionality from the home gateway to the
> core of the service provider network and sharing IPv4 addresses among
> customers create additional requirements when logging data for abuse
> usage.  With any architecture where an IPv4 address does not uniquely
> represent an end host, IPv4 addresses and a timestamps are no longer
> sufficient to identify a particular broadband customer.  Additional
> information such as transport protocol information will be required
> for that purpose.  For example, we suggest to log the transport port
> number for TCP and UDP connections.

What needs to be logged depends on the element that you are in. A peer would log the other side's transport port number, an AFTR would log the line/tunnel ID and the transport port number.

> The AFTR performs translation functions for interior IPv4 hosts at
> RFC 1918 addresses or at the IANA reserved address range (TBA by
> IANA).

How do we know which address range is being used?

> If the interior host is properly using the authorized IPv4
> address with the authorized transport protocol port range such as A+P
> semantic for the tunnel, the AFTR can simply forward without
> translation to permit the authorized address and port range to
> function properly.  All packets with unauthorized interior IPv4
> addresses or with authorized interior IPv4 address but unauthorized
> port range MUST NOT be forwarded by the AFTR.  This prevents rogue
> devices from launching denial of service attacks using unauthorized
> public IPv4 addresses in the IPv4 source header field or unauthorized
> transport port range in the IPv4 transport header field.  For
> example, rogue devices could bombard a public web server by launching
> TCP SYN ACK attack.  The victim will receive TCP SYN from random IPv4
> source addresses at a rapid rate and deny TCP services to legitimate
> users.

What is a properly authorized IPv4 address? What about an authorized transport protocol?

> If IPv6 address spoofing prevention is not in place, the AFTR should
> perform further sanity checks on the IPv6 address of incoming IPv6
> packets.  For example, it should check if the address has really been
> allocated to an authorized customer.

How? Isn't address checking of this kind really just another form of spoofing prevention?

Editorial:

> The source IPv4 is the RFC1918 addressed
> assigned by the Dual-Stack home router which is unique to each host
> behind the home gateway.

... address assigned ...

> or
> example, rogue devices could bombard a public web server by launching
> TCP SYN ACK attack.  The victim will receive TCP SYN from random IPv4
> source addresses at a rapid rate and deny TCP services to legitimate
> users.

Should this be ... launching *a* TCP SYN ACK attack? And maybe add a reference hree. Also, ... receive a TCP SYN packet from random ...

Part 2 of my review.

Technical:

I wonder if the draft should say something more about MTU handling. In particular, should it attempt to inform clients on its inner interface of the real MTU so that fragmentation is not needed. Here's what RFC 5844 said in a very similar situation.

  o  The DHCPOFFER message [RFC2131] sent to the mobile node MUST
      include the Interface MTU option [RFC2132].  The DHCP servers in
      the Proxy Mobile IPv6 domain MUST be configured to include the
      Interface MTU option.  The MTU value SHOULD reflect the tunnel MTU
      for the bidirectional tunnel between the mobile access gateway and
      the local mobility anchor.

(Though I wonder if this text is right either, as presumably you have to ask for options before handing them out...)

> 8.1. NAT pool
>
>
> AFTRs MAY operate distinct, non overlapping NAT pools.  Those NAT
> pools do not have to be continuous.

This text is unclear. Are you talking about different AFTRs operating with different sets of public address pools? Or one AFTR running for some set of clients, using a number of different address pools? Or assigning a public address for one client from different pools for different connections? These are all different, and I think you mean the second alternative but I'm not sure.

Please specify.

> The AFTR should only perform a minimum number of ALG for the classic
> applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through
> and enable the users to use their own ALG on statically or
> dynamically reserved ports instead.

First off, shouldn't this be written as "... should only implement a minimum ..."

The more substantial comment is that the recommendation is very weak. I do not know if the application list above is complete or if I am expected to implement additional ALGs. Secondly, are there RFCs that we can point to for these ALGs? Finally, I do not know how to provide the use-own-alg functionality. But I'm reading on, maybe its described later in the document.

> There is an important operational difference if those N ports are
> pre-allocated in a cookie-cutter fashion versus allocated on demand
> by incoming connections.  This is a difference between an average of
> N ports and a maximum of N ports.  Several service providers have
> reported an average number of connections per customer in the single
> digits.  At the opposite end, thousands or tens of thousands of ports
> could be use in a peak by any single customer browsing a number of
> AJAX/Web 2.0 sites.

Is your argument assuming a traditional web browsing usage model, i.e.., that users actively use an application and that the computer sits idle at other times? I am not sure this the model we have going forward. Many popular applications are starting to update content and perform various actions even when the browser sits idle, for instance. I think there will still be a difference between average and maximum, though it is perhaps not as pronounced over the time dimension but could still be very visible between users.

> In order to achieve higher address space reduction ratios, it is
> recommended that service provider do not use this cookie-cutter
> approach, and, on the contrary, allocate ports as dynamically as
> possible, just like on a regular NAT.

Given the above, perhaps the text should warn that in order for this trick to work at all, there really has to be a difference either in the between-users or the time dimension, and that trends in networking may easily reduce either one.

> When dynamic port assignment is used to maximize the number of
> subscribers sharing the AFTR global IPv4 addresses, the AFTR should
> implement checks to avoid DOS attack through exhaustion of available
> ports. 

How?

Editorial:


>    In broadband home networks, sometime devices are directly connected

Sometimes? Some devices?

> Under this scenario, the customer device is a dual-stack capable host
>    that is only provisioned by the service provider only with IPv6.

Would this be better: "... is provisioned by the service provider only with IPv6"?

I am reviewing this draft. Please find the first batch of my comments below:

Technical:

> The common thinking for more than 10 years has been that the
> transition to IPv6 will be based on the dual stack model and that
> most things would be converted this way before we ran out of IPv4.
>
> However, this has not happened.  The IANA free pool of IPv4 addresses
> will be depleted soon, well before any significant IPv6 deployment
> will have occurred.
>
> This document revisits the dual-stack model and introduces the dual-
> stack lite technology aimed at better aligning the costs and benefits
> of deploying IPv6.  Dual-stack lite will provide the necessary bridge
> between the two protocols, offering an evolution path of the Internet
> post IANA IPv4 depletion.

I would partially rewrite this. The claims are strong, but at least from my point of view, while dual stack lite solves specific problems it is not a general replacement for dual stack. Here's my suggested new text:

  The common thinking for more than 10 years has been that the
  transition to IPv6 will be based solely on the dual stack model and that
  most things would be converted this way before we ran out of IPv4.
  However, this has not happened. The IANA free pool of IPv4 addresses
  will be depleted soon, well before sufficient IPv6 deployment will
  exist. As a result, many IPv4 services have to continue to be provided
  even under severely limited address space.

  This document specifies the dual-stack lite technology which is aimed at
  better aligning the costs and benefits in service provider networks.
  Dual-stack lite will enable both continued support for IPv4 services
  and incentives for the deployment of IPv6. It also de-couples IPv6
  deployment in the service provider network from the rest of the Internet,
  making incremental deployment easier.

At the same I would also rewrite parts of the abstract:

OLD:
  This document revisits the dual-stack model and introduces the dual-
  stack lite technology aimed at better aligning the costs and benefits
  of deploying IPv6.
NEW:
  This document revisits the dual-stack model and introduces the dual-
  stack lite technology aimed at better aligning the costs and benefits
  of deploying IPv6 in service provider networks.

> A DS-Lite home gateway SHOULD NOT operate a NAT function on a B4
> interface, as the NAT function will be performed by the AFTR in the
> service provider's network.

I am not sure what it means to operate a NAT function on an interface. Presumably it would be operated between two interfaces. Perhaps you wanted to say that "the GW SHOULD NOT operate a NAT function".

> It SHOULD also advertise itself as a DNS server in the DHCP
> Option 6 (DNS Server).  Additionally, it SHOULD operate a DNS proxy
> to accept DNS IPv4 requests from home hosts and send them using IPv6
> to the service provider DNS servers, as described in Section 5.5.

It is unclear to me why you need to make these recommendations (but I'm reading on). This material in general  seems more suited to a homegateway RFC than DS-Lite RFC. Also, I do not understand why the usual passing of service provider DNS server addresses is unsuitable in this configuration. I see the comment later that says a large number of DNS requests might create a lot of unnecessary state. But there seems to be complexity that the text glosses over. Operating a real DNS server might be more than what simple gateways want to implement or configure. Its not clear that proxied requests from the gateway are in any way less taxing for the NAT (at least my Linux box uses a different source port on every request, so I might as well have all hosts send their own requests). And I'm not sure if you wanted to say "in addition" or "alternatively" for the DNS proxy.

> 3. Terminology

I am pretty sure there should be other terms as well, starting from dual stack (RFC 4213), NAT, CPE/home gateway, etc.

Editorial:

>  == Outdated reference: A later version (-04) exists of
>      draft-cheshire-nat-pmp-03
>
>  == Outdated reference: A later version (-02) exists of
>      draft-droms-softwires-snat-01
>
>  == Outdated reference: A later version (-01) exists of
>      draft-durand-dual-stack-lite-00
>
>  == Outdated reference: A later version (-05) exists of
>      draft-nishitani-cgn-04
>
>  == Outdated reference: draft-templin-seal has been published as RFC 5320
Idnits reports that some of the references are outdated. Please correct these.

Section 1 would benefit from an overview of what the remaining sections will cover.

The document talks about home gateways and CPEs. Is there a difference, or should you be using the same term?

(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?

Dave Ward is the Shepherd. He has
reviewed the documents and believes they ready for publication.

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

We saw evidence of extensive review on the mailing list. The documents
has been presented in softwires, v6ops, and dhc working groups.

(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?

No concerns.

(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 WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

This is strictly a protocol specification. We believe that an
operational document discussing some of the various tradeoffs and
choices when deploying DS-Lite would be valuable.

We know of no IPR disclosures related to this document.

(1.e) 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?

Some individuals have expressed concern that the document doesn't go
into enough depth on certain subjects, such as MTU handling, but in the chair's opinion most
of those subject are general issues, not specific to DS-lite. Aside of this,
the document has strong support in the WG.

(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 theInternet-Drafts Checklist <http://www.ietf.org/id-info/checklist.html>
andhttp://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?

Passes nits, no need for doctor reviews.

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

Clean.

(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 suggest a
reasonable name for the new registry? See [RFC5226]. 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?

There is a request for one dhcp option code point in the IANA
considerations section of the DHCP option document and a request for a
well known IPv4 prefix in the DS-Lite document.

(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?

There is no formal language in the document.

(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

DHCP option


This document specifies two DHCPv6 options which are meant to be used
by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to
discover its Address Family Transition Router (AFTR) address.

DS-Lite

This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6. Dual-stack lite enables a broadband service
provider to share IPv4 addresses among customers by combining two
well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address
Translation (NAT).


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. There is some
disagreement over small details, but overall 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?

There are multiple, independent, interoperable implementations of this
protocol today. Several service providers have announced plans to deploy
or interest in deploying.