Re: [v6ops] draft-lmhp-v6ops-transition-comparison-06

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 26 March 2021 14:53 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 ED1BA3A2062 for <v6ops@ietfa.amsl.com>; Fri, 26 Mar 2021 07:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.67
X-Spam-Level:
X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 ghBeDqsdWJFF for <v6ops@ietfa.amsl.com>; Fri, 26 Mar 2021 07:53:50 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE8B3A205F for <v6ops@ietf.org>; Fri, 26 Mar 2021 07:53:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 12QErlQi007740 for <v6ops@ietf.org>; Fri, 26 Mar 2021 15:53:47 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36C9E202496 for <v6ops@ietf.org>; Fri, 26 Mar 2021 15:53:47 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2D4FA201061 for <v6ops@ietf.org>; Fri, 26 Mar 2021 15:53:47 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 12QErlwQ031853 for <v6ops@ietf.org>; Fri, 26 Mar 2021 15:53:47 +0100
To: v6ops@ietf.org
References: <BL0PR05MB5316425C5650B5D2FE43DE4DAE6C9@BL0PR05MB5316.namprd05.prod.outlook.com> <74d6dca7019f44aba09caf47ef703e2f@huawei.com> <CAB75xn7=swhtwqRuV6SoWoMO7jtCcPCc02XiVpAjE=VUx8CyaQ@mail.gmail.com> <6059897e.1c69fb81.ac270.d863SMTPIN_ADDED_BROKEN@mx.google.com> <749643a7-313f-4bd1-8bb8-7dc26d830070@gmail.com> <605aae8f.1c69fb81.8a8ed.04b7SMTPIN_ADDED_BROKEN@mx.google.com> <35c4cf4f-0128-dff6-27a3-4cc868539f7f@gmail.com> <9614BF99-431D-4046-9762-0F111AFBB27D@consulintel.es> <a498117e-4834-41f8-5c90-ad7734d07220@hit.bme.hu> <e770fec1-2189-f683-6c74-36e32541c53d@gmail.com> <abe65114-d9c9-10ee-2c78-449051acbb61@hit.bme.hu> <3c50c72b-b606-a6cf-3095-f08ad48eecf5@gmail.com> <2A0C2B40-2DA4-4941-A09F-5BD31EDA3301@consulintel.es> <2e64b426-3a0a-b5f8-0306-005e9f1023d0@gmail.com> <72754d29-8b57-66fa-2b3a-fc6680c339f2@hit.bme.hu> <bdeec6da-3b2a-8cd4-e2d4-feb62c282c7d@gmail.com> <5E67F1F7-4065-4500-B722-D1E8E9458242@consulintel.es>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <0db72084-5952-d8b0-c3ab-cc30d7325111@gmail.com>
Date: Fri, 26 Mar 2021 15:53:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <5E67F1F7-4065-4500-B722-D1E8E9458242@consulintel.es>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MiXlNXeq3NPl1S-LsRi3Hcs14ZI>
Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison-06
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: Fri, 26 Mar 2021 14:53:55 -0000


Le 26/03/2021 à 15:48, JORDI PALET MARTINEZ a écrit :
> If both end-sites have IPv6 support, the IPv6 addresses will be
> reachable.
> 
> In your example you mention that the PC server is dual-stacked (it
> can be IPv6-only), and the car can be either dual-stacked or
> IPv6-only.

Yes.

> So, the car can always contact the PC server. There is no
> need for any transition mechanism in this scenario.

But how the PC gets an IPv6 address through the Ethernet on the IoT 
Router that connects on 4G?  The 4G only gives it a /64.  The IoT Router 
does not implement clatd etc.

> What it doesn't make any sense in today's world is to do this
> deployment with IPv4-only in any of the sides. That's a negation of
> the reality: IoT with IPv4 (and in general any new deployment with
> IPv4) doesn't make any sense.

I agree.

> One example of this was, a few years ago, the contract awarded to
> Telefónica for 53 millions of gas and electricity meters in UK, worth
> 1.5 billion pounds in 15 years, using cellular and 6LOWPAN. If they
> have done it with IPv4, they will have needed 34 million NATs,
> according to their own calculations.

The IoT devices that I acquire on the market dont do 6lowpan.  There are 
indeed many 6lowpan devices but there are also many other IoT devices 
that connect on 4G, have Bluetooth/WiFi/Ethernet/Galileo and yet dont do 
6lowpan.

> https://www.google.com/search?q=telefonica+awarded+uk+meters
> 
> Now, if you want to make it more complex, and you really need to keep
> IPv4 incoming connections, you can still configure the NAT64 for
> that, either for specific ports or addresses. However, as said, it
> doesn't make sense to use IPv4 for new deployments of "anything".

If I _have_ to do NAT, then NAT44 is largely sufficient.  There is no 
need for v4-v6 transition mechanisms (I mean not in these trials I 
consider).

Alex

> 
> Regards, Jordi @jordipalet
> 
> 
> 
> El 26/3/21 7:04, "v6ops en nombre de Alexandre Petrescu"
> <v6ops-bounces@ietf.org en nombre de alexandre.petrescu@gmail.com>
> escribió:
> 
> 
> 
> Le 24/03/2021 à 16:59, Gabor LENCSE a écrit :
>> Dear Alex,
>> 
>> On 3/24/2021 4:12 PM, Alexandre Petrescu wrote: [...]
>>> Does IPv6 mandate the use of DNS64 and NAT64?
>> 
>> Of course, not. :)
>> 
>> There are several IPv4 as a Services solutions exist. We have
>> covered the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T
>> and lw4o6 in our I-D: 
>> https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-06
>
>> 
> I looked at it.
> 
> There is a need to illustrate also a drawback in 464XLAT/DNS64 in 
> cellular operator networks: they can be used to offer an IPv6 address
> to a smartphone and the smartphone to browse IPv4 sites.
> 
> But they cant be used to offer an IPv6 address to a server behind an
> IoT router and be reachable from another IPv6 client in the
> Internet.
> 
> The result of that impossibility is that IPv4 with port translation
> (but not PCP) is preferred in such a setting, instead of IPv6.  It is
> not a happy situation.
> 
> The use-case is the following: in a street deployment a traffic
> lights controller controls the traffic lights.  This controller is a
> PC with Ethernet interface, linux, IPv6 and IPv4 stacks.  The car
> needs to know the status of the color (red/green, time left, etc.)
> The car tries to http to that PC Server.  The PC needs to connect to
> the Internet via a cellular network operator.  An IoT router (4G and
> Ethernet small router, linux, IPv4, IPv6) is thus plugged on the PC.
> The cellular network operator offers a /64, and also NAT64/DNS64 to
> those who need it.
> 
> In trying to identify where in the draft could this be already 
> explained, I found section "4.3.  Support for Public Server
> Operation". But I think that section does not really explain my
> problem.
> 
> Alex
> 
>> 
>> Your ISP is likely using one of them.
>> 
>> Best regards,
>> 
>> Gábor
>> 
>> _______________________________________________ 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.
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>