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

From: Pekka Savola <[email-masked]>
Date: Sun, 27 Jul 2008 20:25:15 +0300 (EEST)

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 27 Jul 2008 21:43:24 +0300

> interface and it could just as well use that.

By the way, my Ubuntu PC refuses to accept 0.0.0.1 as a valid address. I 
reckon the same operating system is found in certain CPEs.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: Alain Durand <[email-masked]>
Date: Sun, 27 Jul 2008 17:19:49 -0400

> reckon the same operating system is found in certain CPEs.

This address is mainly used in the case a device -that-is-not-behind-a-CPE-
wants to initiate the tunnel. In this mode of operation, dual-stack lite is
a very simple alternative to NAT-PT.

Now, I suggested 0.0.0.1, but this may not be the best choice. I will
probably end up asking IANA to reserve an address for this.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Sun, 27 Jul 2008 17:25:48 -0400

On 7/27/08 1:25 PM, "Pekka Savola" <[email-masked]> wrote:

> [...]
> [...]

I do not expect that this technology will be turned on automatically by any
ISP on its customers without their knowledge, but rather be part of a
different service offering.

The DHCP server already has some logic to decide how to handle different
customers. The same logic can be extended to decide which customer get an
IPv4 address and which one don't but benefit from this tunneled
connectivity.

This can be done with ISP provided home gateway as well as with retail ones.

  - Alain.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jul 2008 18:46:04 +0100

>    the decapsulator with NAT.

Right. Note that this is pretty much the same functionality as a NAT64  
provides.

>    between the edge device and the tunnel box.

IPv6 routers could advertise a reduced MTU. On the other hand, that  
has the downside that end-to-end IPv6 traffic now also has to use the  
smaller MTU.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jul 2008 18:48:48 +0100

> probably end up asking IANA to reserve an address for this.

The right choice would be something in the RFC 1918 space so  
applications that inspect their source address know they're behind NAT  
and change their behavior accordingly.

In the MNAT-PT draft from seven months ago there's text about creating  
a source address in the 172.31/16 range where the lower 16 bits are  
chosen such that they compensate for the checksum difference between  
IPv4 and IPv6 so there's no need to recalculate the checksums.