Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 24 March 2021 22:31 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 0F88D3A0EA0 for <v6ops@ietfa.amsl.com>; Wed, 24 Mar 2021 15:31:08 -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, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 I6U9QVbdQuNk for <v6ops@ietfa.amsl.com>; Wed, 24 Mar 2021 15:31:05 -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 84EF43A0E9F for <v6ops@ietf.org>; Wed, 24 Mar 2021 15:31:05 -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 12OMV1nB001220; Wed, 24 Mar 2021 23:31:01 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BC38F207F06; Wed, 24 Mar 2021 23:31:01 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AF16C207EF9; Wed, 24 Mar 2021 23:31:01 +0100 (CET)
Received: from [10.14.0.25] ([10.14.0.25]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 12OMV1WQ001657; Wed, 24 Mar 2021 23:31:01 +0100
To: Martin Hunek <martin.hunek@tul.cz>, v6ops@ietf.org
References: <BL0PR05MB5316425C5650B5D2FE43DE4DAE6C9@BL0PR05MB5316.namprd05.prod.outlook.com> <72754d29-8b57-66fa-2b3a-fc6680c339f2@hit.bme.hu> <69744eb4-2f2e-6876-eba7-c439c5c4db9d@gmail.com> <2076432.Icojqenx9y@rumburak.ite.tul.cz>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b526d48d-f013-7451-4f25-78bfa1ed9d9b@gmail.com>
Date: Wed, 24 Mar 2021 23:31:01 +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: <2076432.Icojqenx9y@rumburak.ite.tul.cz>
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/s3vMHPgV1snV2XD-10cdFtjeUgU>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
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: Wed, 24 Mar 2021 22:31:08 -0000


Le 24/03/2021 à 19:08, Martin Hunek a écrit :
[...]
> It is possible to turn it off,

The best possibility to turn IPv4 off in linux is to make the IPv4 stack
a module.  That means to add some hooks, and other tweaks.  In that way
one will be able to 'rmmod ipv4' just like one is able to 'rmmod ipv6'
today.

Then remove 127.0.0.1 from /etc/hosts and the IPv4 resolver from
/etc/resolve.conf and one is good to go.

I agree it is very much programming effort and nobody did it since
years.  One needs to struggle through hundreds of thousands of lines of
code to see who calls whom, and then interfere.   But it is a good goal,
I think.

Maybe in OpenBSD or FreeBSD the situation is different?  Maybe there one
_is_ able to remove the IPv4 stack from the kernel...

Alex