Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 09 January 2020 20:34 UTC

Return-Path: <prvs=1277e0d723=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7F1202A0 for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2020 12:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FRkD_SqnbQH for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2020 12:34:12 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FC8120047 for <v6ops@ietf.org>; Thu, 9 Jan 2020 12:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1578602049; x=1579206849; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=E047NBOxtVGP8GmAIiIVUyLUbj8YWxyBeL CcgS0dWbI=; b=VUHWLPkMAcjuW0hu8qedgfPgl1HpD3XRQRp8QsELQLg3DQzwsH rnHN+vs2gBMjS9kNzijrXirnT3Y+m590aYeZJsPgyuhI5lYW7y8Jtvmr6WUnPtn/ CjooZtoUGXPAWSkXh1KE54pLgNX0+3Rqco5GUgwMPqwRRtln2UwyxXTyw=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 09 Jan 2020 21:34:09 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 09 Jan 2020 21:34:08 +0100
Received: from [10.192.0.137] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000021910.msg for <v6ops@ietf.org>; Thu, 09 Jan 2020 21:34:06 +0100
X-MDRemoteIP: 10.8.10.6
X-MDHelo: [10.192.0.137]
X-MDArrival-Date: Thu, 09 Jan 2020 21:34:06 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1277e0d723=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.20.0.191208
Date: Thu, 09 Jan 2020 21:33:51 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <24B0BCD2-A8E8-4188-9C74-4518E3ED57B0@consulintel.es>
Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
References: <CAD6AjGRL72mq11sgdCpH5YL5LkRqECuUdk3NXPhcjzULZ_ZssQ@mail.gmail.com> <D54B8E3E-3F17-4B60-9338-F92E0329F3FA@employees.org>
In-Reply-To: <D54B8E3E-3F17-4B60-9338-F92E0329F3FA@employees.org>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3661450439_1707274075"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LmBwg_UFrkA_pX6KMmIEgO5O5Tk>
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 09 Jan 2020 20:34:15 -0000

Hi Ole,

 

Even if I could (partially) agree with your view regarding the single-point-of-failure, at the end the problem is that every network is a different animal.

 

There are CapEx and OpEx impacts that may be different when you need to deliver IPv6-only for both a cellular and a broadband network (in the same operator). And having a single transition is very relevant.

 

We are more often in a world were subscribers have a hybrid/multihomed CE, with (for example) GPON and a backup link via 3/4/5G. Again, because in cellular the only choice is 464XLAT, it becomes much easier (and cheaper) to use also 464XLAT in the main broadband link.

 

Regards,

Jordi

@jordipalet

 

 

 

El 9/1/20 20:22, "v6ops en nombre de Ole Troan" <v6ops-bounces@ietf.org en nombre de otroan@employees.org> escribió:

 

 




On 9 Jan 2020, at 20:04, Ca By <cb.list6@gmail.com> wrote:



 

 

On Thu, Jan 9, 2020 at 9:41 AM <otroan@employees.org> wrote:

>    Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can
>    therefore be much more efficient in terms of port allocation and thus
>    public IP address saving.  The price is the stateful operation in the
>    service provider network, which allegedly does not scale up well.  It
>    should be noticed that in many cases, all those factors may depend on
>    how it is actually implemented.
> 

Not allegedly.
The two mechanism-types do have different scaling properties.
The CGN type are pets (scale with sharding + HA mechanisms), the stateless mechanisms behave like cattle. I.e. you just add more instances.

Cheers,
Ole

 

eh, i don’t believe there is a meaningful scaling function difference.  I don’t know the details of how MAP works, the domains and dhcp dependencies always seemed like a Rube Goldberg machine,  but for 464xlat, if you think of DNS64 being an anycast and / or PREF64 as anycast... you just add more to scale horizontally.  Yes, each NAT64 needs a unique ipv4 pool, but it’s not an artisanal craft. 

 

A stateful NAT44 / NAT64 can also scale beyond 65k sessions / ports per ipv4 using a full 5-tuple... so if we are talking about pushing ipv4 efficiency, this cannot be beat. 

 

All solutions have stateful NATs. It’s just a question if you have one, two or three (in this case one is stateless though).  In a MAP solution the CPE NAT can also operate in endpoint dependent mode. 

 

It will not be able to utilize the IPv4 as efficiently as the CGN solutions. 

 

Where the CGN solutions are hard to scale has to do with robustness. Avoiding a single point of failure requires HA solutions (session synchronization) and sharding of the state space. Whatever you think, that’s a lot harder to do than a stateless solution. I have written code for both. 

 

Cheers 

Ole

 

 



 

 


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.