Re: [v6ops] Updating RFC 7084 - alternate logic

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 30 November 2022 15:53 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 7D7E0C022C40 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 07:53:07 -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=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 Fz_105HGXA90 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 07:53:03 -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 8D727C152706 for <v6ops@ietf.org>; Wed, 30 Nov 2022 07:53:02 -0800 (PST)
Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NMkHS2TyJz686y1 for <v6ops@ietf.org>; Wed, 30 Nov 2022 23:52:36 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.31; Wed, 30 Nov 2022 16:53:00 +0100
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.31; Wed, 30 Nov 2022 18:52:59 +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.031; Wed, 30 Nov 2022 18:52:59 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Olorunloba Olopade <loba.olopade=40virginmediao2.co.uk@dmarc.ietf.org>, Timothy Winters <tim@qacafe.com>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] Updating RFC 7084 - alternate logic
Thread-Index: AQHZBM6pOh6j9QEUH0aSbXL2LZ6L/a5XnFhg
Date: Wed, 30 Nov 2022 15:52:59 +0000
Message-ID: <49bbf244b8154ddbbdc1e6e5af8c112b@huawei.com>
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <CWXP123MB516352292E412470C7CAB5E5D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP123MB516352292E412470C7CAB5E5D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.195.244.194]
Content-Type: multipart/alternative; boundary="_000_49bbf244b8154ddbbdc1e6e5af8c112bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Ohkb0qL_3kudYbRJhg1eR6Ps-Aw>
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: Wed, 30 Nov 2022 15:53:07 -0000

The router’s tree on site could be big/deep.
The idea (like below) to try to deliver a prefix for every link is right.

I just remind that
if somebody “delegates” then should be a way to “reclaim”,
Or else traffic blackholing is possible (after any uplink to the Carrier would go down).

Ed/
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Olorunloba Olopade
Sent: Wednesday, November 30, 2022 6:16 PM
To: Timothy Winters <tim@qacafe.com>; IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Updating RFC 7084 - alternate logic

Hello,

Wile RFC7084 doesn’t cover the DHCP requirements, there are other spec (e.g. cablelabs) that does. And we have implementation of this.

I agree that we should support DHCP on the CE, but don’t support limiting the sub-delegation to /64, which would make some of the current implementations non-compliant. I will suggest something like the following, which is an amendment of the cablelabs spec

• If the Topology mode is set to “favor config”, then divide the delegated prefix into sizes specified by the CE config.
• If the provisioned MSO assigned IA_PD is smaller than a /56 (e.g., a /60) and the Topology mode is set to "favor depth", the CE MUST divide the delegated prefix on two (2)-bit boundaries into four (4) sub[1]prefixes by default.
• If the provisioned MSO assigned IA_PD is smaller than a /56 (e.g., a /60) and the Topology mode is set to "favor width", the CE MUST divide the delegated prefix on three (3)-bit boundaries into eight (8) sub[1]prefixes by default.
• If the provisioned MSO assigned IA_PD is a /56 or larger and the Topology mode is set to "favor depth", the CE MUST divide the delegated prefix on three (3)-bit boundaries into eight (8) sub-prefixes by default.
• If the provisioned MSO assigned IA_PD is a /56 or larger and the Topology mode is set to "favor width", the CE MUST divide the delegated prefix on four (4)-bit boundaries into sixteen (16) sub-prefixes by default.
• If the provisioned MSO assigned IA_PD is too small to divide in the manner described, the CE MUST divide the delegated prefix into as many /64 sub-prefixes as possible and log an error message indicating the fault


From: v6ops <v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>> On Behalf Of Timothy Winters
Sent: 18 November 2022 14:47
To: IPv6 Operations <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: [v6ops] Updating RFC 7084

Hello,

I've started a draft to update RFC 7084 to support prefix delegation on the LAN interfaces.  The current state of IPv6 in home networks is ISP are assigning prefixes of appropriate sizes but they currently are under utilized due to the lack of prefix delegation on LAN interfaces.

This draft is an attempt to add that support to the draft.

https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/

This is only an update to 7084 at the moment, there has been some discussion on the snac working group about leveraging this work as well.

One item being discussed is this currently doesn't solve multi-homed networks.

I welcome any feedback about the proposal.

~Tim



Save Paper - Do you really need to print this e-mail?

This email contains information from Virgin Media and/or Telefonica UK Limited (O2) and may be confidential and legally privileged. Statements and opinions expressed in this email or any attachment may not represent either those of Virgin Media or Telefonica UK Limited. Any representations or commitments in this email or any attachment are subject to contract.  The information in this email is intended solely for the attention of the addressee(s) and if you are not the intended recipient please delete it (including any attachment) from your system, and be aware that any disclosure, copying distribution or use of any of this information is not permitted.

If you are in receipt of a suspicious email or you have received an email in error from Virgin Media, please report it to www.virginmedia.com/netreport<http://www.virginmedia.com/netreport>, or for Telefonica UK Limited (O2), please report it to www.o2.co.uk/help/safety-and-security<http://www.o2.co.uk/help/safety-and-security>.

 Registered offices:

 Virgin Media Limited, 500 Brook Drive, Reading, RG2 6UU. Registered in England and Wales: 2591237

 Telefonica UK Limited, 260 Bath Road, Slough, Berkshire SL1 4DX. Registered in England and Wales: 1743099

 VMED O2 UK Limited, Griffin House, 161 Hammersmith Road, London, United Kingdom, W6 8BS. Registered in England and Wales: 12580944