draft-durand-dual-stack-lite-00 general comments

[Pekka Savola <pekkas@netcore.fi>]

This architecture is essentially DSTM (base version) with permanent 
addressing coupled with a v4 NAT functionality.  A more generic 
solution could also be possible which decouples tunnel+NAT 
functionality because the NAT is not necessarily needed in all 
deployments.

The description of the proposal seems somewhat on the lengthy side. 
Essentially, it seems that the proposal essentially requires the 
following:

 1) modifications to decapsulating NAT to look into inner v4 header for
    multiplexing purposes (and not just v6 header).  Requires colocating
    the decapsulator with NAT.

 2) a mechanism to distribute tunnel endpoint information to the customer
    edge devices (not specified in this document).

 3) either (unspecified in this document):
    a) a method to figure out which customers support this approach (a
       significant issue?) and turn off v4 DHCP on those customer links;
    b) a change in the client code to first obtain v6 address and tunnel
       endpoint information, and if that is obtained, not get a DHCPv4
       lease; or
    c) change from providing public v4 addresses to private v4
       addresses (i.e. worsening existing service to make a new
       offering more lucrative)

 4) TCP MSS rewriting on edge devices and NAT box to better cope with lowered
    effective maximum packet size OR a way to use a higher MTU on the path
    between the edge device and the tunnel box.

Of these, 1) is a minor modification.  2) requires standardization. 3) 
is mostly a (significant) deployment problem -- you can't control all 
the edge device implementations users may have so the ISP would 
probably need to do 3.a) and/or 3.c).  4) is commonly used already 
although probably not specified in any IETF standard.

Given the difficulty of 3), it seems that the approach is basically 
only suitable in deployments where the users can only connect to the 
ISP using a CPE device provided by the ISP.  Users' own CPE boxes or 
cable/DSL cards attached to a host operating system (e.g. USB sticks) 
would be a challenge. From my perspective, "you must use our CPE 
device (and pay dearly for it!)" service provisioning is rather rare 
and not necessarily a desirable approach from the user POV.  As such 
if 3) can't be solved in a generic fashion, the solution has only 
limited applicability.

Nit: It's not clear why Section 4.1 suggests using 0.0.0.1 as source 
address.  The CPE box is going to have some address on the LAN 
interface and it could just as well use that.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings