IETF Logo Mail Archive

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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 02 February 2023 15:41 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 F05B4C1575B9; Thu, 2 Feb 2023 07:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 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_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 cWplAEy70qsh; Thu, 2 Feb 2023 07:41:12 -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 C736EC14CE33; Thu, 2 Feb 2023 07:41:11 -0800 (PST)
Received: from mscpeml500001.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4P72wP1NYLz688sb; Thu, 2 Feb 2023 23:37:25 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) 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 18:41:09 +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 18:41:09 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, Ted Lemon <mellon@fugue.com>
CC: "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: AQHZNwgtYbssPh2bzkmMlrUONCMSDK67cxCAgABXNhA=
Date: Thu, 02 Feb 2023 15:41:09 +0000
Message-ID: <67cfb26007d9401a858c770bb6de8b53@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>
In-Reply-To: <744C2F4B-DB48-4CB3-983B-C126AAE802D8@employees.org>
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_67cfb26007d9401a858c770bb6de8b53huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/euAKVplufTT95ZktlMcdgFrGlSU>
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 15:41:14 -0000

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] On Behalf Of Ole Troan
Sent: Thursday, February 2, 2023 4:25 PM
To: Ted Lemon <mellon@fugue.com>
Cc: 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"

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