Re: [v6ops] I-D Action:draft-ietf-v6ops-incremental-cgn-02.txt

Sheng Jiang <shengjiang@huawei.com> Mon, 11 October 2010 07:58 UTC

Return-Path: <shengjiang@huawei.com>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC933A6783 for <v6ops@core3.amsl.com>; Mon, 11 Oct 2010 00:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.15
X-Spam-Level:
X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 uH88B-vEe6W8 for <v6ops@core3.amsl.com>; Mon, 11 Oct 2010 00:58:41 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CFB493A67A7 for <v6ops@ietf.org>; Mon, 11 Oct 2010 00:58:40 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA4005KN8TF4S@szxga03-in.huawei.com> for v6ops@ietf.org; Mon, 11 Oct 2010 15:58:30 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400AJI8TC5T@szxga03-in.huawei.com> for v6ops@ietf.org; Mon, 11 Oct 2010 15:58:25 +0800 (CST)
Received: from j66104a ([10.110.98.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA400LPN8TB5M@szxml06-in.huawei.com> for v6ops@ietf.org; Mon, 11 Oct 2010 15:58:24 +0800 (CST)
Date: Mon, 11 Oct 2010 15:58:22 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <3B91ECF5-B59D-464B-B5B0-1DAF69303ED4@free.fr>
To: 'Rémi Després' <remi.despres@free.fr>, 'Diang Guo' <guoseu@huawei.com>, 'Brian Carpenter' <brian.e.carpenter@gmail.com>
Message-id: <004401cb691a$13f6d200$2e626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Thread-index: ActpF91oellywieWT42/pXMbekmXSgAAG6cA
Cc: 'v6ops v6ops' <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-incremental-cgn-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2010 07:58:42 -0000

Hi, Remi,

You are right here. You may notice, incremental cgn is an information document, which does not
define any concrete mechanisms. It gives guidelines and discuss time sequence and steps during
transitioning. 6rd with private Ipv4 addresses is one of concrete instance of the certain phase of
incremental cgn. We have already indicated this. Both RFC5569, RFC5969 are quoted in the document.

Best regards,

Sheng

> -----Original Message-----
> From: Rémi Després [mailto:remi.despres@free.fr] 
> Sent: Monday, October 11, 2010 3:42 PM
> To: Sheng Jiang; Diang Guo; Brian Carpenter
> Cc: v6ops v6ops
> Subject: Re: [v6ops] I-D 
> Action:draft-ietf-v6ops-incremental-cgn-02.txt
> 
> Hi Sheng, Diang, Brian,
> 
> The draft says 
> "[ISPs]... currently face two urgent pressures - to 
> compensate for an immediate shortage of IPv4 addresses by 
> deploying some method of address sharing, and to prepare 
> actively for the use of deployment of IPv6 address space and 
> services. ISPs facing only one pressure out of   two could 
> adopt either CGN (for shortage of IPv6 addresses) or 6rd."
> 
> This misses the point that 6rd can also be used by ISPs that, 
> to face the IPv4 address shortage, operate CGN44s and assign 
> private IPv4 addresses to their customers.
> This is illustrated in particular in section 4 of RFC 5569:
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>               ______________________________
>              |                              |
>              | 10.x.x.x/8 private addresses |
>              |  <==                         |
>        <-----|         IPv4 anycast address |----->
>              |            of 6rd relays     |
>     6rd-CPEs |                      ==>     |  6rd-relays
>              |                              |
>        <-----|          0.0.0.0/0           |----->
>              |              :               |
>              |______________V_______________|
>                           __|__
>     ISP-supported NAT(s) |     |
>                          |_____|
>                             |
>                             V
>                  IPv4 public addresses
>           Figure 3: 6rd Applicability to ISPs That Assign
>                     IPv4 Private Addresses
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> If a home gateway supports 6rd with the DHCPv4 option 
> introduced in RFC 5969, the goal of incremental CGN seems to 
> be reached with already specified mechanisms.
> 
> Thoughts?
> 
> Regards,
> RD 
> 
> 
> 
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> > This draft is a work item of the IPv6 Operations Working 
> Group of the IETF.
> > 
> > 
> > 	Title           : An Incremental Carrier-Grade NAT 
> (CGN) for IPv6 Transition
> > 	Author(s)       : S. Jiang, D. Guo
> > 	Filename        : draft-ietf-v6ops-incremental-cgn-02.txt
> > 	Pages           : 13
> > 	Date            : 2010-10-10
> > 
> > Global IPv6 deployment was slower than originally expected. As IPv4 
> > address exhaustion approaches, the IPv4 to IPv6 transition issues 
> > become more critical and less tractable. Host-based transition
> > 
> > 
> > mechanisms used in dual stack environments are not able to meet the 
> > transition requirements. Most end users are not 
> sufficiently expert to 
> > configure or maintain host-based transition mechanisms. 
> Carrier- Grade 
> > NAT (CGN) devices with integrated transition mechanisms can 
> reduce the 
> > operational change required during the IPv4 to IPv6 migration or 
> > coexistence period.
> > 
> > This document proposes an incremental CGN approach for IPv6 
> > transition. It can provide IPv6 access services for 
> IPv6-enabled hosts 
> > and IPv4 access services for IPv4 hosts while leaving much 
> of a legacy 
> > IPv4 ISP network unchanged. It is suitable for the initial stage of 
> > IPv4 to IPv6 migration. Unlike NAT444 based CGN alone, 
> Incremental CGN 
> > also supports and encourages transition towards dual- stack or 
> > IPv6-only ISP networks. A smooth transition to IPv6 
> deployment is also 
> > described in this document.
> > 
> > An integrated configurable CGN device and an adaptive Home Gateway
> > (HG) device are introduced. Both HG and CGN are re-usable devices 
> > during different transition periods. It avoids potential multiple 
> > upgrades. It enables IPv6 migration to be incrementally achieved 
> > according to the real user requirements.
> > 
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-incremental-cgn-0
> > 2.txt
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > <Pièce jointe Mail>_______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
>