IETF Logo Mail Archive

[v6ops] Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 07 August 2024 07:13 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 27421C151091 for <v6ops@ietfa.amsl.com>; Wed, 7 Aug 2024 00:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 eiPWKHOSbHXe for <v6ops@ietfa.amsl.com>; Wed, 7 Aug 2024 00:13:42 -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 AA8FAC15108F for <v6ops@ietf.org>; Wed, 7 Aug 2024 00:13:42 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Wf1YC331tz6K993; Wed, 7 Aug 2024 15:10:55 +0800 (CST)
Received: from mscpeml500003.china.huawei.com (unknown [7.188.49.51]) by mail.maildlp.com (Postfix) with ESMTPS id C045F1402C6; Wed, 7 Aug 2024 15:13:39 +0800 (CST)
Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml500003.china.huawei.com (7.188.49.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.34; Wed, 7 Aug 2024 10:13:39 +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.034; Wed, 7 Aug 2024 10:13:39 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Nick Buraglio <buraglio@forwardingplane.net>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] Working group Last call: draft-ietf-v6ops-cpe-lan-pd
Thread-Index: AQHa6BP7PlYlDHCLZEefiEKZCH8BqbIbW02g
Date: Wed, 07 Aug 2024 07:13:39 +0000
Message-ID: <dd798136c6db44e5819dd8a98c5d95e6@huawei.com>
References: <CACMsEX_x0ORZZ+nYeUQ5Lf83W9GZPwZOfcWpfq5gDtuY7oqk9w@mail.gmail.com>
In-Reply-To: <CACMsEX_x0ORZZ+nYeUQ5Lf83W9GZPwZOfcWpfq5gDtuY7oqk9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.59.222]
Content-Type: multipart/alternative; boundary="_000_dd798136c6db44e5819dd8a98c5d95e6huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: G4LECJTWYWZTK37BS2ISFJUPDN3QCD3I
X-Message-ID-Hash: G4LECJTWYWZTK37BS2ISFJUPDN3QCD3I
X-MailFrom: vasilenko.eduard@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mmIRRxGktpe3d-TUXGzwR7Q7SS0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

  *   After LAN link prefix assignment the IPv6 CE Router MUST make the remaining IPv6 prefixes available to other routers via Prefix Delegation.¶<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-lan-pd-02#section-5.1-1.4.1>
Why “other routers”? Maybe “other nodes”.


  *   The IPv6 CE Router MUST set the O flag to 1 in its transmit Router Advertisments messages [RFC4861<https://www.rfc-editor.org/info/rfc4861>].¶<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-lan-pd-02#section-5.1-1.5.1>
Will the host try DHCP IA_NA in this case? (that is probably not available) For how long it would delay address acquisition?
I remember that 6man was trying hard to optimize this time (RFC 9131).
By the way, it is an excellent example of why a separate flag is needed for IA_NA and IA_PD.
Unfortunately, the P flag (planned) has a different meaning “only /64 IA_PD is available”. Hence, the P flag is not a resolution for the problem.
If you believe that the P flag is the solution to this problem – you should mention it.

I have not found what should happen after the CPE reload. If the same prefix would be delegated to the CPE then would the same prefixes would be sub-delegated?

I have not found out what would happen after the uplink flapping (very probable on mobile links). As we know, in 37% of cases the CPE would get a different prefix.
There is no way to inform hosts and routers downstream, they would blackhole the traffic up to the lease time.
This initiative looks to me as “mine the field”.
It is easy to predict a lot of screams (people would step on this mine) and pressure on 6man/v6ops to fix this disaster.

IMHO: it is better not to open this “Pandora box”.

Ed/
From: Nick Buraglio <buraglio@forwardingplane.net>
Sent: Tuesday, August 6, 2024 18:18
To: IPv6 Operations <v6ops@ietf.org>
Subject: [v6ops] Working group Last call: draft-ietf-v6ops-cpe-lan-pd

All,

This message begins the working group last call for draft-ietf-v6ops-cpe-lan-pd. Please read the draft and send your comments in response to this email.

The draft can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/

nb

v2.27.8 | Report a Bug | By Email | System Status