IETF Logo Mail Archive

Re: [v6ops] Our IPv6-only home network and future experiments

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 15 April 2024 08:01 UTC

Return-Path: <vasilenko.eduard@huawei.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 D74C1C14F711 for <v6ops@ietfa.amsl.com>; Mon, 15 Apr 2024 01:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LPMr9ZO99cC for <v6ops@ietfa.amsl.com>; Mon, 15 Apr 2024 01:01:50 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641DFC14F70F for <v6ops@ietf.org>; Mon, 15 Apr 2024 01:01:50 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VJ02M4hkSz6K69h; Mon, 15 Apr 2024 15:59:55 +0800 (CST)
Received: from mscpeml100003.china.huawei.com (unknown [10.199.174.67]) by mail.maildlp.com (Postfix) with ESMTPS id 991221404F4; Mon, 15 Apr 2024 16:01:48 +0800 (CST)
Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml100003.china.huawei.com (10.199.174.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 15 Apr 2024 11:01:48 +0300
Received: from mscpeml500004.china.huawei.com ([7.188.26.250]) by mscpeml500004.china.huawei.com ([7.188.26.250]) with mapi id 15.02.1258.028; Mon, 15 Apr 2024 11:01:48 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Gert Doering <gert@space.net>
CC: "Soni \"They/Them\" L." <fakedme+ipv6@gmail.com>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] Our IPv6-only home network and future experiments
Thread-Index: AQHajOKQainvZ81VEUSU3NSRL3/g/bFo6ouQ///QZICAADoc8P//0pOAgAAzj+A=
Date: Mon, 15 Apr 2024 08:01:47 +0000
Message-ID: <a1dea94cb05548328e0de9f1b7c3aa16@huawei.com>
References: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com> <7b89e8bd81674a61b364e1fec4176006@huawei.com> <ZhzSD0g_xmVfeiM1@Space.Net> <0685641f158c4c9885a4b53964548abd@huawei.com> <Zhzcs9PU3HbYtwYp@Space.Net>
In-Reply-To: <Zhzcs9PU3HbYtwYp@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/scUTmANiXRzfpjYSkTjApSlD1qc>
Subject: Re: [v6ops] Our IPv6-only home network and future experiments
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 15 Apr 2024 08:01:54 -0000

OK. The majority of applications is compiled without any special keys, hence, libc is linked dynamically.
And we do not care about unlucky loosers who compiled libc into the code - their application would break. Right?

> nothing new needs to be added, API-wise
I doubt that it would be possible to persuade the community to radically modify the behavior of basic functions.

Ed/
-----Original Message-----
From: Gert Doering <gert@space.net> 
Sent: Monday, April 15, 2024 10:52
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Gert Doering <gert@space.net>; Soni "They/Them" L. <fakedme+ipv6@gmail.com>; IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Our IPv6-only home network and future experiments

Hi,

On Mon, Apr 15, 2024 at 07:37:41AM +0000, Vasilenko Eduard wrote:
> 1. libc is for "C". Hence, the compilation is mandatory.
> 2. I assume that it would be a new function in the library. Hence, code change and compilation are mandatory.

Neither.  libc is the basic building block on all modern unix-like systems, which is shared (= new functionality can be added without recompiling
anything) and which provides run-time to basically all languages - try running "ldd somebinary", whether C or Go or Java, and verify for yourself.

To add the described functionality, functions like socket() or connect() need to be modified, but (for pure "applications can use this") nothing new needs to be added, API-wise.  Of course they could add some control functions for "CLAT aware applications", but that would be missing the point.

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard,
                                           Ingo Lalla, Karin Schuler
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

v2.23.0 | Report a Bug | By Email