Re: [ipwave] New Liaison Statement, "LS on provision of inputs to the online ITS communication standards database"

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 05 October 2021 12:26 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6F33A0B8A for <its@ietfa.amsl.com>; Tue, 5 Oct 2021 05:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.667
X-Spam-Level:
X-Spam-Status: No, score=0.667 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_H2=-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 KAetI8s1LB9Q for <its@ietfa.amsl.com>; Tue, 5 Oct 2021 05:26:09 -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 D371A3A0B87 for <its@ietf.org>; Tue, 5 Oct 2021 05:26:08 -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 195CQ5fr014792 for <its@ietf.org>; Tue, 5 Oct 2021 14:26:06 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E578B206D89 for <its@ietf.org>; Tue, 5 Oct 2021 14:26:05 +0200 (CEST)
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 DC53A203730 for <its@ietf.org>; Tue, 5 Oct 2021 14:26:05 +0200 (CEST)
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 195CQ537011842 for <its@ietf.org>; Tue, 5 Oct 2021 14:26:05 +0200
To: its@ietf.org
References: <163336672480.7831.3929220086915764556@ietfa.amsl.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <70b75931-3c94-4518-f866-85aff611fc82@gmail.com>
Date: Tue, 05 Oct 2021 14:26:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <163336672480.7831.3929220086915764556@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/yHWpXlQydjNscch8WAzRc-_WmI4>
Subject: Re: [ipwave] New Liaison Statement, "LS on provision of inputs to the online ITS communication standards database"
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2021 12:26:14 -0000



Le 04/10/2021 à 18:58, Liaison Statement Management Tool a écrit :
> Title: LS on provision of inputs to the online ITS communication 
> standards database Submission Date: 2021-10-04 URL of the IETF Web 
> page: https://datatracker.ietf.org/liaison/1760/ Please reply by 
> 2021-11-19 From: CITS Itu-t <tsbcits@itu.int> To: Carlos Bernardos 
> <cjbc@it.uc3m.es>,Russ Housley <housley@vigilsec.com> Cc: Russ 
> Housley <housley@vigilsec.com>,Éric Vyncke <evyncke@cisco.com>,Erik 
> Kline <ek.ietf@gmail.com>,Carlos Bernardos <cjbc@it.uc3m.es>,IP 
> Wireless Access in Vehicular Environments Discussion List 
> <its@ietf.org> Response Contacts: trs@roaddb.com Technical Contacts:
>  Purpose: For action
> 
> Body: The Collaboration on ITS communication standards (CITS) serves 
> as an international platform for the coordination of globally 
> acceptable, and harmonized standards on Intelligent Transportation 
> Systems (ITS) in order to enable the rapid deployment of fully 
> interoperable ITS communication-related products and services.
> 
> In keeping with its mandate, in March 2019 CITS agreed to establish 
> an online database for ITS Communication Standards. To furnish this 
> database with key inputs from participating SDOs, these entities
> were invited to review the categorisation of their related-standards
> and to appoint an expert to maintain the relevant communication
> standards in the online database.
> 
> Over the course of two years, the database has been significantly 
> updated with inputs received through liaison statements as well as 
> those presented during the six monthly CITS meetings.
> 
> The current version of the online database is already accessible 
> here.

The word 'here' is supposed to be hypertext - when clicked, or tapped, 
it would redirect to this URL:

https://www.itu.int/net4/ITU-T/landscape#?topic=0.131&workgroup=1&searchValue=&page=1&sort=Revelance

For some reason, the conversion from Zip to Word to copy paste has
dropped that URL somewhere.

But the URL is important.

On one hand, one might try to click it from an IPv6-only computer.
Usually the itu.int addresses do work ok on IPv6, which is a good thing 
for the Internet.  For info, not all URLs work on IPv6: the ietf.org 
URLs do, but many others dont.  Itu.int being on IPv6 is a good thing. 
One could compare that to 3gpp.org and to etsi.org to see whether they 
work on IPv6 too, and if not to deduce something.

Second, going to that URL one will notice a whole set of various SDO
documents that are relevant to ITS.  Among them, one can find the RFC 
8691 and the I-D on vehicular networks that are developped here in IPWAVE.

https://www.itu.int/net4/ITU-T/landscape#?topic=0.131&workgroup=1.1141&searchValue=&page=1&sort=Revelance

Of course, one common value between the two URLs is the word
'Relevance' whose parts are a little bit reversed, but that could be
easily fixed by a willing programmer.

Finally, one might notice the following: several 3GPP documents
specifically about V2X are referred to, such as the "3GPP TR 22.885
Study on LTE support for Vehicle-to-Everything (V2X) services".

However, there is one 3GPP document that is ultra-important for
connecting a vehicle onboard network to the Internet on 5G with IP, and 
that the database does not refer to.  That document is "3GPP TS 23.501". 
  That document is general for all things that connect to 3GPP networks, 
not just cars.  But for cars there is a problem.

The problematic text in TS 23.501 is the following:
> /64 IPv6 prefix allocation shall be supported via IPv6 Stateless
> Auto-configuration according to RFC 4862 [10], if IPv6 is supported.
> The details of Stateless IPv6 Address Autoconfiguration are described
> in clause 5.8.2.2.3. IPv6 parameter configuration via Stateless
> DHCPv6 (according to RFC 3736 [14]) may also be supported.

For an on-board car network to work it is absolutely necessary that more 
than just a /64 prefix be allocated, i.e. there is a need of either 
multiple /64s, or a /63, or shorter.  This is in order for the car to 
form several sub-networks each with a /64 inside the car.

To achieve that, a possible way is to use DHCPv6-PD (Prefix Delegation). 
  However, the text above does not say DHCPv6-PD, neither does it say 
'Stateful'.  The only thing about DHCPv6 that is there is yhe 
'stateless' variant of DHCPv6.  The stateless DHCPv6 RFC3736 does not 
support prefix delegation, so it is impossible to delegate a /63 or 
shorter.   That document also puts the stateless DHCPv6 as a 'may' in 
the above paragraph and not as a must, which is even less encouraging.

The end result is that all 3GPP modems on the market enforce the use of 
this /64 length and prohibit the use of DHCPv6 by means of blocking the 
multicast addressing of DHCPv6 or the UDP port numbers of DHCPv6. 
Basically there are no 3GPP modems that dont block DHCPv6.

That is a big problem for cars on 5G with IP.

Of course, few notice this problem presumably because most address it 
with one of these tools:
- not use the current version of IP (IPv6) but an earlier version like
   IPv4.  In IPv4 one uses NAT to support several subnetworks in the car
   and only one IPv4 address from the mobile network.
- one might use the current version of IP (IPv6) with NAT66 in the car;
   NAT66 is a technology widely deployed; e.g. linux 'masquerade' command
   quickly makes a NAT66, even if it is a technology undesirable in the
   IETF discussions.  Masquerading is undesirable for various reasons, or
   too numerous to mention here.
- use IP (IPv6) with tunnels and ULAs, and still use just one IP address
   from the network.  This has the inconvenient of triangular routing.
- use Mobile IP; also the inconvenient of triangular routing.
- use VPN; again, triangular routing problem.
- use just one subnet in the car, sharing one /64 from the operator;
   that has the inconvenient of sharing the urgent data with
   entertainment data on the same bus (that is CAN bus, or Ethernet).
- use multiple modems each with a /64 and a subnet attached to it; e.g.
   a modem for door lock/unlock, a modem for entertainment, a modem for
   emergency messages, one for cameras, etc.  That has the inconvenient
   of being too expensive because each modem comes with a distinct SIM
   card and hence a distinct data plan.  One might end up with paying
   more for the data to function, than for the gas or electricity to
   move.

If 3GPP solves this problem (modify the above text to include the cars 
on 5G on IP and permit DHCPv6-PD) then the modems will implement that 
recommendations, allow DHCPv6-PD, and cars will happily be connected to 
the Internet.

When that is done, the door will be open for novelty claims of making
the first '5G cars'.  Until then, all such statements are wrong in one
way or another; simply put one is scratching one's left ear with right
hand above the head.  Hopefully, one would not be forced to wait for 6G
do be deployed in year 2030 for cars on Internet on cellular to happen.

Alex

  It includes standards from 3GPP, ETSI, IEEE, IETF, ISO, ITU,
> SAE, TTC, and W3C. In order to keep this database as up to date as 
> possible, CITS would like to encourage you to participate regularly 
> in the CITS e-meetings and provide any relevant inputs either via 
> presentations to the meeting or through formal channels including 
> liaison statements. We are also attaching the current list of
> contact points from various organizations. Please provide any update
> as needed to both the online database and the list of contact points
> in your organization (attachment below).
> 
> The CITS Secretariat (tsbcits@itu.int) remains at your disposal for 
> any additional queries.
> 
> We look forward to continuing our collaboration with your 
> organization. Attachments:
> 
> CITS-LS13-Att1 
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-10-04-itu-t-cits-ipwave-ls-on-provision-of-inputs-to-the-online-its-communication-standards-database-attachment-1.xlsx
>
>
> 
CITS-LS13
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-10-04-itu-t-cits-ipwave-ls-on-provision-of-inputs-to-the-online-its-communication-standards-database-attachment-2.docx
>
>
> 
> 
> _______________________________________________ its mailing list 
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>