Re: [Softwires] DS-Lite mode enforcement to CPE routers

"Jan Zorz @ go6.si" <jan@go6.si> Wed, 02 March 2011 08:14 UTC

Return-Path: <jan@go6.si>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B1B3A6AD4 for <softwires@core3.amsl.com>; Wed, 2 Mar 2011 00:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+e41FFF4GdW for <softwires@core3.amsl.com>; Wed, 2 Mar 2011 00:14:10 -0800 (PST)
Received: from ipv6.go6.si (go6.si [212.44.108.1]) by core3.amsl.com (Postfix) with ESMTP id 27C103A6AA4 for <softwires@ietf.org>; Wed, 2 Mar 2011 00:14:10 -0800 (PST)
Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:bd40:2cf:211a:f4a8]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 1F8302378040 for <softwires@ietf.org>; Wed, 2 Mar 2011 09:15:11 +0100 (CET)
Message-ID: <4D6DFC92.7000603@go6.si>
Date: Wed, 02 Mar 2011 09:15:14 +0100
From: "Jan Zorz @ go6.si" <jan@go6.si>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: softwires@ietf.org
References: <20110301195841.GA9292@srv03.cluenet.de>
In-Reply-To: <20110301195841.GA9292@srv03.cluenet.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] DS-Lite mode enforcement to CPE routers
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 02 Mar 2011 08:14:12 -0000

On 3/1/11 8:58 PM, Daniel Roesen wrote:
> If the chosen approach is DS-Lite, the ISP needs at some point in time
> start to provision customers in a way to make sure they'll use DS-Lite
> for IPv4 connectivity to conserve IPv4 addresses in a plannable manner.
> "plannable manner" means specifically that the DS-Lite provisioned
> customer cannot opt-out of using DS-Lite by turning off DS-Lite in the
> CPE router and then again get a public IPv4 address via DHCPv4.
>
> Ideally (that's the goal), wether CPE router has to use DS-Lite or just
> go for DHCPv4 (dual stack mode) should be signalled by the ISP to the
> CPE router device. Or more precise: there should be a way for an ISP to
> signal a CPE router that is absolute has to use DS-Lite to obtain IPv4
> connectivity as DHCPv4 will fail. The customer should not have to know
> what "DS-Lite" is or - even worse - explicitly enable it in the CPE
> router GUI in order to get IPv4 connectivity behind a "DS-Lite
> connection".

Hi,

That's what one of benefits of A+P architecture is.

See draft-ymbk-aplusp, section 3.3.4.  "Overall A+P Architecture"

Our idea is incremental deployment. Today ISP can put PRR in his network 
and start shipping out CPEs with A+P semantics deployed (if there would 
be any serious implementation and if we would not be delayed for a year 
with this draft by "they know who they are").

Idea is that you can allocate public IP with full port range to the 
customer and he would not notice the difference. With time you have a 
customer base able to share the IP and when you hit the point in your 
IPv4 stock that you decide you need to share IP addresses you just send 
out a new data-plan possibility (maybe even cheaper) and inform users 
that they can enable it with just a flick of the switch on service pages 
- you only need to change the behaviour of the encapsulation and 
allocate limited set of ports to a customer. This way you still give the 
user public IP address but with limited set of prots. You can go even 
further and offer CGN-like access, but then that wouldn't be worth more 
than 1EUR/month :)

It's there in architecture and it's unique. Current popular transition 
ideas tends to enforce violent mass deployment in a single short period 
of time, when you need to do switchover.

Cheers, Jan Zorz