Re: [v6ops] Updating RFC 7084 - alternate logic

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 05 December 2022 14:48 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 C2D86C1524B4 for <v6ops@ietfa.amsl.com>; Mon, 5 Dec 2022 06:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.329
X-Spam-Level:
X-Spam-Status: No, score=-4.329 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 iL6v5oMrWT0g for <v6ops@ietfa.amsl.com>; Mon, 5 Dec 2022 06:48:03 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B153BC1524B0 for <v6ops@ietf.org>; Mon, 5 Dec 2022 06:48:02 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2B5Em1Y9042343 for <v6ops@ietf.org>; Mon, 5 Dec 2022 15:48:01 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5E896206821 for <v6ops@ietf.org>; Mon, 5 Dec 2022 15:48:00 +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 550DC206699 for <v6ops@ietf.org>; Mon, 5 Dec 2022 15:48:00 +0100 (CET)
Received: from [10.11.242.28] ([10.11.242.28]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2B5Em0rf057102 for <v6ops@ietf.org>; Mon, 5 Dec 2022 15:48:00 +0100
Message-ID: <848ec271-2183-bf3e-3004-4aa9a6bf9453@gmail.com>
Date: Mon, 05 Dec 2022 15:48:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
Content-Language: fr
To: v6ops@ietf.org
References: <CAJgLMKs=CTBAdW=-GaFT+j+rjnd=sdDe6ytoqpZhYE1KW29jUQ@mail.gmail.com> <CWXP123MB51634A6A6D20796AE43A6207D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <db23f437-7dd8-ad24-0c72-e3164dd43f4a@gmail.com> <CWXP123MB516311D9A5E90628BC8E8FD2D3149@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <DU0P190MB1978713EFCC2841F4B762F05FD149@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <5782557e-e2d8-48c0-b75c-d67d7e6cb228@gmail.com> <DU0P190MB19782F86F06A030BD9AC4836FD189@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <9169a670-1141-d688-fd7c-68f06c221378@gmail.com> <Y4313SQDIpYMfclu@Space.Net> <ee4c1b38-d25a-62e2-f815-71aa0e368b9e@gmail.com> <Y439HZAYY540zT2O@Space.Net> <868d2e96-0faf-7ba6-2432-7c31f3c44ba0@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <868d2e96-0faf-7ba6-2432-7c31f3c44ba0@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_5xifBQs82w9g-DhgRa-3Q03yvw>
Subject: Re: [v6ops] Updating RFC 7084 - alternate logic
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, 05 Dec 2022 14:48:07 -0000



Le 05/12/2022 à 15:39, Alexandre Petrescu a écrit :
> 
> 
> Le 05/12/2022 à 15:15, Gert Doering a écrit :
>> Hi,
>>
>> On Mon, Dec 05, 2022 at 02:57:28PM +0100, Alexandre Petrescu wrote:
>>> But it is not that straightforward.
>>
>> It is :-)
>>
>>> For that to work, one possibility would be a for the AP in router mode
>>> to run a DHCPv6 Relay.  But as far as I know there are no WiFi access
>>> points that run DHCPv6 Relay software.
>>
>> If the "AP in router mode" wants to do routing, and IPv6, it needs
>> to understand prefixes left *and right*.  So for the "right side prefix",
>> it needs to speak DHCPv6-PD anyway, to get a prefix assigned from the
>> ISP router.
>>
>> In IPv4 land, all these "things in router mode" will just do hierarchical
>> NAT44, but that's not how you do IPv6.
> 
> I agree.
> 
>>
>>> Another possibility would be that the snac router is precofigured with
>>> the address of the DHCPv6 server (ISP's inhome router), so it does not
>>> need to discover it across IP hops, because multicast discovery across
>>> IP hops does not work.
>>
>> You cannot do DHCPv6-PD across a non-participating intermediate router,
>> because that router needs to add forwarding entries. 
> 
> Fair enough.

I correct myself: it _is_ possible to run DHCPv6-PD (and
DHCPv6-Addresses) across a non-DHCPv6 set of intermediary routers,
without a need to update the routing table entries of these intermediary
routers upon prefix allocation.   The secret lies in pre-configuring the
routing properlY.

Alex

> 
> Still, the configuration I described is common in many places: WiFi APs 
> in router mode (as opposed to bridge mode) are used extensively in home 
> settings.
> 
> So I am not sure how good is it to assume that they dont exist.
> 
>> And no, "having
>> a routing protocol on the right side" is not *less* complicated than
>> just having DHCPv6-PD support.
> 
> Fair enough.
> 
> But there is already a hard time in finding DHCPv6 Clients and Servers 
> in these home devices (APs) that looking for a routing protocol presence 
> in APs will only further daunt the task.  HNCP was designed for that but 
> I dont see it.
> 
> Alex
> 
>>
>> Gert Doering
>>          -- NetMaster
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops