IETF Logo Mail Archive

Re: [Snac] [v6ops] "router cascade with DHCPv6-PD"

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 02 February 2023 18:23 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: snac@ietfa.amsl.com
Delivered-To: snac@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE50DC1522C4; Thu, 2 Feb 2023 10:23:03 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 soMOOqJda8_d; Thu, 2 Feb 2023 10:22:59 -0800 (PST)
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 2FCCEC151522; Thu, 2 Feb 2023 10:22:59 -0800 (PST)
Received: from mscpeml100002.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4P76W30s24z6J69c; Fri, 3 Feb 2023 02:19:11 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Thu, 2 Feb 2023 21:22:55 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.034; Thu, 2 Feb 2023 21:22:55 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ted Lemon <mellon@fugue.com>
CC: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, "snac@ietf.org" <snac@ietf.org>, V6 Ops List <v6ops@ietf.org>, Juliusz Chroboczek <jch@irif.fr>, Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [v6ops] [Snac] "router cascade with DHCPv6-PD"
Thread-Index: AQHZNyGfmxYPo0Z2BU2KFgMdwSaid66798Vg
Date: Thu, 02 Feb 2023 18:22:55 +0000
Message-ID: <02a80ca79e8745488c77a526a5602115@huawei.com>
References: <Y813Mzn7ucC/YODu@Space.Net> <7EA5E930-4E81-4B79-BBD0-07FACDC5E4B5@employees.org> <Y82U2Sv39Gk9qesd@Space.Net> <729e9054-abcd-5c41-8db8-9b295f36cd05@posteo.de> <CAPt1N1k6zeZBFN1a7zOXrC6g9_5kCSY9t_LKqhES2B6n5c2v9A@mail.gmail.com> <744C2F4B-DB48-4CB3-983B-C126AAE802D8@employees.org> <67cfb26007d9401a858c770bb6de8b53@huawei.com> <CAPt1N1=uuHwShPUdhUrRF1aogB8OHmdQ2DXYdbqdvdW_9CGm8g@mail.gmail.com>
In-Reply-To: <CAPt1N1=uuHwShPUdhUrRF1aogB8OHmdQ2DXYdbqdvdW_9CGm8g@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.209.140]
Content-Type: multipart/alternative; boundary="_000_02a80ca79e8745488c77a526a5602115huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/WVQX4JbLUCrlO3M1E4MXGEA-YgE>
Subject: Re: [Snac] [v6ops] "router cascade with DHCPv6-PD"
X-BeenThere: snac@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for discussing problems relating to the automatic connection of stub networks to existing infrastructure networks. " <snac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/snac>, <mailto:snac-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/snac/>
List-Post: <mailto:snac@ietf.org>
List-Help: <mailto:snac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/snac>, <mailto:snac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2023 18:23:04 -0000

Is it really possible to assume that we could use it for PA blocks?
For a massive production.
Or for some reason “DHCP Reconfirm Request” would not happen?
Ed/
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Thursday, February 2, 2023 7:01 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Ole Troan <otroan=40employees.org@dmarc.ietf.org>; snac@ietf.org; V6 Ops List <v6ops@ietf.org>; Juliusz Chroboczek <jch@irif.fr>; Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [v6ops] [Snac] "router cascade with DHCPv6-PD"

DHCP Reconfirm Request works for withdrawal.

On Thu, Feb 2, 2023 at 7:41 AM Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
It looks like we are talking about address appointment. ND is for this task by definition. DHCP too.

ND is capable of announcements and withdrawal.
DHCP is only for an announcement.
Big difference.

Ed/
From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of Ole Troan
Sent: Thursday, February 2, 2023 4:25 PM
To: Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>>
Cc: snac@ietf.org<mailto:snac@ietf.org>; V6 Ops List <v6ops@ietf.org<mailto:v6ops@ietf.org>>; Juliusz Chroboczek <jch@irif.fr<mailto:jch@irif.fr>>; Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>
Subject: Re: [v6ops] [Snac] "router cascade with DHCPv6-PD"

Ted,

Exactly!

I don't know how you do stable prefix assignment to subnets with NDP/ICMP. I'm sure you could, but how much different than PD would it be at that point?

The original prefix delegation proposal did exactly that:
https://datatracker.ietf.org/doc/html/draft-haberman-ipngwg-auto-prefix-02

And the observation was then “this looks just like DHCP, why not use that?”

O.



On Thu, Feb 2, 2023 at 12:22 AM Klaus Frank <klaus.frank@posteo.de<mailto:klaus.frank@posteo.de>> wrote:
I agree, with that. And tbh, I personally think introducing DHCPv6-PD at
all was a conceptional mistake. It's duties should have been carried out
by ICMPv6 and NDP...

Also there is no real alternative for environments with dynamically
assigned prefixes or where clients are roaming between networks and need
a delegated prefix locally for e.g. Docker or VMs... Except for "use
DHCPv6-PD to get the prefix, run a DIY script to update configuration
files and restart radvd and/or bird..."

On 22.01.2023 20:56, Gert Doering wrote:
> DHCPv6-PD seems to be a half-finished routing protocol already, and trying to
> wiggle around admitting it.
>
> Gert Doering
>          -- NetMaster
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops
--
Snac mailing list
Snac@ietf.org<mailto:Snac@ietf.org>
https://www.ietf.org/mailman/listinfo/snac

v2.23.0 | Report a Bug | By Email