Re: [Softwires] Stateless implementation plan

Cameron Byrne <cb.list6@gmail.com> Wed, 08 February 2012 19:49 UTC

Return-Path: <cb.list6@gmail.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 0834C11E809B for <softwires@ietfa.amsl.com>; Wed, 8 Feb 2012 11:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.283
X-Spam-Level:
X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 yEwdmQY40JVR for <softwires@ietfa.amsl.com>; Wed, 8 Feb 2012 11:49:36 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02C11E8080 for <softwires@ietf.org>; Wed, 8 Feb 2012 11:49:36 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so911269pbc.31 for <softwires@ietf.org>; Wed, 08 Feb 2012 11:49:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LAWNukw6FPhA3ugHkPJbJZDS5FpiFvlk8vjDqxxAboY=; b=g8MzQMdR6skky1JEHRqGZ8oOlikqATmYhMP6mAeR3pA0VlPHMhcn7s72OV4+ZjYEKA MRHHeju347+fv37SFCISU/fs9atbhuIxPR6W9GvPUS0+XKgL7icdE/l+GzPPu+lxbLZI jGtn2MzvZEv/hz0bVnftmrGWmasjibyeqlWgE=
MIME-Version: 1.0
Received: by 10.68.209.6 with SMTP id mi6mr71075810pbc.87.1328730575982; Wed, 08 Feb 2012 11:49:35 -0800 (PST)
Received: by 10.143.164.16 with HTTP; Wed, 8 Feb 2012 11:49:35 -0800 (PST)
In-Reply-To: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net>
References: <CAD6AjGTfQ4akndGG3C9k7SZU=4BpuA4qrorg1FeV5u8wEJRdaA@mail.gmail.com> <CAD6AjGS7TBhUVJjwjqMibXJRo1Y=F4UKcDmYXfh-9OUDe=Me0w@mail.gmail.com> <CAC8QAccCa_6g-LQRvfx2MSNDFH09Vb_kjBHSVk6-5uiTUTYX_A@mail.gmail.com> <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net>
Date: Wed, 08 Feb 2012 11:49:35 -0800
Message-ID: <CAD6AjGStQykwzBYjHxEGXUY=hhtLYgvBbB37ogq9ntXXf+-C8Q@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: softwires@ietf.org
Subject: Re: [Softwires] Stateless implementation plan
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: Wed, 08 Feb 2012 19:49:37 -0000

On Wed, Feb 8, 2012 at 1:23 AM, Rémi Després <despres.remi@laposte.net> wrote:
> Hi Behcet,
>
> Le 2012-02-08 à 09:46, Behcet Sarikaya a écrit :
>
>> Hi Cameron,
>> 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is
>> not appropriate to be hosted in a UE.
>>
>> I think your solution 464XLAT's mobile part is way better for your
>> purposes. There you can put all your IPv4 resources on the PLAT box so
>> that CLAT box is kept simpler.
>>
>> In 4rd, CPEs have A+P and BR is kept "stateless" these are not so
>> useful for your purposes, I think.
>
> Note however that:
> - 464XLAT doesn't support shared IPv4 addresses (while 4rd does)

Hmm... we may be getting off topic.

464XLAT definitely shares IPv4 addresses on the PLAT -- That is RFC
6146 -- statefule NAT64.

Perhaps what you mean to say is that 464XLAT uses stateful sharing of
IPv4 addresses as defined in RFC6146.  The public IPv4 address
resources are decoupled from the IPv4 service deployment at the edge.
This is more flexible, IPv4 efficient, and allows for geographic
redundancy of the translation exit points.

So, to summarize.  Both 4RD and 464XLAT support address sharing. One
is stateless and the other is stateful.

> - 4rd over 6rd can work, and therefore offer both IPv6 and shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot AFAIK).
>

4RD over 6RD?

That is a lot of RD :)

I believe the implementation report here shows that 464XLAT provides a
good users experience on 3G networks

http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html

CB

> Regards,
> RD
>
>>
>> Regards,
>>
>> Behcet
>>
>>
>> On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
>>> Are the map and 4rd solutions deployable for existing networks that do not
>>> have reserves  of ipv4 ?  My assumption is that these solutions target
>>> existing networks that have meaningful growth and they need a v6 solution.
>>>
>>> If yes, how? Any pointers within the reams of drafts I should look for?
>>>
>>> In my brief and simple skimming, it appears to me that setting up one of
>>> these solutions would require me to collapse my existing network to harvest
>>> back the addresses so that they may be redeployed in map.
>>>
>>> What would the deployment process be for an address exhausted network of 10
>>> million subs with 10% annual growth be?
>>>
>>> Cb
>>>
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires