Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite

Rémi Després <despres.remi@laposte.net> Tue, 08 November 2011 18:01 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEE421F844E; Tue, 8 Nov 2011 10:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI4oYbacxJmB; Tue, 8 Nov 2011 10:01:21 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7511E80B3; Tue, 8 Nov 2011 10:01:20 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 8B9C57000182; Tue, 8 Nov 2011 19:01:19 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id BAE957000188; Tue, 8 Nov 2011 19:01:14 +0100 (CET)
X-SFR-UUID: 20111108180114765.BAE957000188@msfrf2214.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAD5CAEA.570A2%rpenno@juniper.net>
Date: Tue, 08 Nov 2011 19:01:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBDE2C1E-1D09-4B51-8AD4-7DA89A5B6FC3@laposte.net>
References: <CAD5CAEA.570A2%rpenno@juniper.net>
To: Reinaldo Penno <rpenno@juniper.net>, Alain Durand <adurand@juniper.net>
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" <softwires@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2011 18:01:21 -0000

Reinaldo, Alain, Lionel,

Nicely written document.
Here are a few points:

1. Other stateless solutions and DS-lite
The introduction suggests that other stateless solutions resulted from "efforts to evolve the DS-lite model", this isn't really how they were designed: 
- The DS-lite model is AFAIK based on
  . RFC-1918 addresses being the only IPv4 addresses that traverse the ISP network
  . NATs within the ISP infrastructure
  . Hub-and-spoke topologies (mesh topologies excluded)  
- Works on 4rd and A+P excluded since the origin these three features. They are based on:
  . Public IPv4 addresses across ISP networks 
  . IP-payload transparency (no NAT)
  . Support of mesh topologies (with hub and spoke possible as a limit case)


2. IPv4 address-pool modifications
The draft asserts that SDNAT is necessarily better than stateless solutions to "add and remove addresses from the NAT pool", but doesn't explain.
This isn't clear to me, in particular because sec. 2.1 says "the SD-CPE can learn the external address it is mapped to using the PCP protocol". 
Changing the IPv4 address pool seems therefore to have consequences similar to those of solutions that provide addresses and port sets in DHCP.

On the other hand, with a lifetime applicable to mapping rules, it is possible with other stateless solutions to plan a replacement of obsolete mapping rules by new ones. The time during which IPv4 is unavailable needs not to be long. 


3. Number of ports in IPv6 addresses 
The draft asserts that, with other stateless solutions, "the number of IPv4 port allocated per subscriber is encoded in the IPv6 address". 
There were such proposals, but also proposals that didn't have it.
This isn't AFAIK a requirement of the MAP design team.


4. IPv4-only ISP access networks (6rd + 4rd also works!)
A claimed advantage is that SD-CPEs "can remain IPv4-only devices" (IMHO a strange idea since they have to be upgraded to support SDNAT), and that "the ISP access network can also remain IPv4-only".

On the latter point, note that 6rd can be combined with 4rd (or some other mesh-compatible stateless solution) for the same result: this brings, across IPv4-only  access networks, both IPv6 service AND IPv4 residual service. 


5. Differentiated sharing ratios? 
To support differentiated CPE sharing ratios several sets of mapping-function parameters are presumably needed. 
Their impact on routing plans, and on CGN operation, aren't evaluated.


6. Operational experience
A claimed advantage of SD-NAT over double translation solutions is that there is more operational experience with encapsulation, a consideration that has limited but real value.
But the need of SDNAT to support PCP for incoming connectivity leads to a world where past experience is very limited. 
The fact that others stateless solutions don't need PCP should therefore be noted in the comparison section sec. 7.2.


In view of the above, the need for one more standard is unclear to me. 
(A Mesh-capable solution also works for hub-and-spoke topologies, and can easily be added to CGNs). 


Regards,
RD
 


Le 2 nov. 2011 à 00:12, Reinaldo Penno a écrit :

> Hello,
> 
> we submitted a new draft detailing our implementation of
> Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT)
> 
> http://tools.ietf.org/html/draft-penno-softwire-sdnat-01
> 
> This is a based on our experience with port bucket/chunk allocation and
> deterministic NAPT44. In the draft we provide a comparison with other
> stateless/stateful methods floating around.
> 
> Thanks,
> 
> Reinaldo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave