Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Mon, 11 June 2012 14:54 UTC

Return-Path: <yiu_lee@cable.comcast.com>
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 6777421F8611 for <softwires@ietfa.amsl.com>; Mon, 11 Jun 2012 07:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.231
X-Spam-Level:
X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 cgfMaFBtmq+U for <softwires@ietfa.amsl.com>; Mon, 11 Jun 2012 07:54:15 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id B043E21F8573 for <softwires@ietf.org>; Mon, 11 Jun 2012 07:54:15 -0700 (PDT)
Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.20724411; Mon, 11 Jun 2012 08:37:45 -0600
Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Mon, 11 Jun 2012 10:54:09 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, liu dapeng <maxpassion@gmail.com>
Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Thread-Index: AQHNR+IN9ZxdlDBC80OY3bEwshPkJA==
Date: Mon, 11 Jun 2012 14:54:08 +0000
Message-ID: <CBFB7C93.21D2B%yiu_lee@cable.comcast.com>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.2.120421
x-originating-ip: [24.40.55.71]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3422256847_485888"
MIME-Version: 1.0
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong Cui <cuiyong@gmail.com>
Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
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: Mon, 11 Jun 2012 14:54:16 -0000

Hi Med and Dapeng,

In order to close the gap, I suggest a slight modification:

"Current standardization effort that is meant to address this IPv4
   service continuity issue focuses mainly on stateful mechanisms that
sharing of global IPv4 addresses between
Customers is based upon the deployment of NAT (Network Address
   Translation) capabilities in the network.  Because of some caveats of
   such stateful approaches the Service Provider community feels that a
   companion effort is required to specify stateless IPv4 over IPv6
   approaches.  Note that the stateless solution elaborated in this
document
focuses on the carrier-side stateless IPv4 over IPv6 solution. States may
still exist in other equipments such as customer-premises equipment."

Thanks,
Yiu


On 6/8/12 8:12 AM, "mohamed.boucadair@orange.com"
<mohamed.boucadair@orange.com> wrote:

>Med: Thanks for the proposal. I shortened your proposal and updated the
>text to:
>
>
>   Current standardization effort that is meant to address this IPv4
>   service continuity issue focuses mainly on stateful mechanisms that
>   assume the sharing of any global IPv4 address that is left between
>   several customers, based upon the deployment of NAT (Network Address
>   Translation) capabilities in the network.  Because of some caveats of
>   such stateful approaches the Service Provider community feels that a
>   companion effort is required to specify stateless IPv4 over IPv6
>   approaches.  Note stateless IPv4 over IPv6 solutions may be enabled
>   in conjunction with a port-restricted NAT44 function located in the
>   customer premises.
>
>   This document provides elaboration on the need for carrier-side
>   stateless IPv4 over IPv6 solution.