Re: [Softwires] AD review of draft-ietf-softwire-dual-stack-lite (part 1)

[Alain Durand <[e-mail]>]

I have posted draft-ietf-softwire-dual-stack-lite-06 to answer all the points raised bellow except for the ID nits.
Note: Randy Bush and Brian Haberman have asked to be removed from the author list, so I did.

  - Alain.





On Aug 9, 2010, at 11:35 AM, Jari Arkko wrote:

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<http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-05#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?

Jari