Re: [v6ops] Updating RFC 7084 - alternate logic

Olorunloba Olopade <loba.olopade@virginmediao2.co.uk> Thu, 01 December 2022 07:48 UTC

Return-Path: <loba.olopade@virginmediao2.co.uk>
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 00DAAC14CF0F for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 23:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virginmediao2.co.uk header.b=wNT468Wj; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=virginmediauk.onmicrosoft.com header.b=W+4vwAbS
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 ysi4aiSxVVLb for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 23:48:01 -0800 (PST)
Received: from mx.emea.email-out.fireeyecloud.com (mta-89810c.eu.email-out.fireeyecloud.com [52.215.218.162]) (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 84CC9C14CF0B for <v6ops@ietf.org>; Wed, 30 Nov 2022 23:48:00 -0800 (PST)
Received: from [127.0.0.1] ([127.0.0.1:37004] helo=smtp-injection-worker) by prd07-euw1-09 (envelope-from <loba.olopade@virginmediao2.co.uk>) (ecelerity 4.3.1.999 r(:)) with ESMTPS (cipher=AES128-GCM-SHA256) id FF/9B-06433-E2C58836; Thu, 01 Dec 2022 07:47:58 +0000
X-FE-ETP-SENDER-IP: 193.38.82.66
X-FE-ETP-CONNECTING-IP: 193.38.82.66
Received: from mailrelay02.ntl.com (mailrelay02.ntl.com [193.38.82.66]) by prd07-euw1-03 (envelope-from <loba.olopade@virginmediao2.co.uk>) FireEye ETP with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 4A2B04572B2C58836170ef189; batch_id 4A/2B-04572-B2C58836; Thu, 1 Dec 2022 07:47:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=virginmediao2.co.uk; i=@virginmediao2.co.uk; q=dns/txt; s=202105corpsmtpuk; t=1669880875; x=1701416875; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding:from; bh=N2Iw1aEUdx3K57sb269sUIBwxBQCNibgg7+XcevFWDA=; b=wNT468WjcRzFfN9QaZTzXWa8LZPmtF/k87GZWDYNtCoNXjMF7jnfG7/X m6jc/FyNusjbE3acjpzoSu8zm2CkQjdc6FYm9dAi26v25UWK6oHHzx6U4 GcKBGZPb4AzDjXo8r5qrHdE+ZrlvI/gcAO5Z8+kgq8LSDRfgD4lqpIQSW XcJV3/aso34Ow5SB1lx2rooG5qhzQOXz8dO1ByTznLD/Y36iB3ExOYhDB 4R6W3VZ5lbHI5hoUi0+LyuVOs74x9mwqwATtI1aZywxE2OWvSQiW62De6 CF0PIeqdk8Chemd2Ls0CuBaG6npflG5rh34nL0s/JQMDdFpDXfk6ceTlq Q==;
From: Olorunloba Olopade <loba.olopade@virginmediao2.co.uk>
X-AddDisclaimer: Media
X-SMTP-INT: N
X-NonCorpAttach-CLI: false
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XkPvETPVErU70TOVUs3+kXw1Smwy4dsyh9H4d2wOTpnbHqy/sN+aXvjr6ANaq8Y92iLqVvPjfKuon+LTv6g9o2hRrOz9kJCb+J5CRG1wYUcRXdvL3VwIpybGJWchwd+rKYQ6l4gSmnngxuUnnwNU/vUtL7fwtxTVfcZoa/9x0MdE3mtZWtLTUW4nayYc57R1q5dj8OexTWjK+lv1BqljvQ2s8Bovu5JnugrJ/+y6/ACUg5vw+TutzpsqAjioVaioPwwOW33mzyyJl1QZfPZ2nNgETFu4Srr575s5e9wW+2k0DUKro/ZIPOs0ePv4W47bziC/UDUA4IaP8O42wZaLxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QsT/fOaBu2XUHGZLHWOFPR4CTy2eU4gy/UZVX91wSrg=; b=YtjMIU77Ug4A26Aw7RhnlMyt7PWZ9OLT4Sz4LhTaWX0f28gPX2G+v0rUVpIfZSP3HHcA5ULBcZj7WNSQjoNcJ5+JsxjgWrUodkOx0HBLpjeA6NGKnfz3n+db3NMUdiq6/Ky1Kv/2RytibrJZ9EmtxVgJhPnOFWaw6u4byMLzLdqAX0Cr1voOnqfsh6y/7gQiqNgupe+bVRrNhlI8naMXClCpPZGxtY+kN1Ubss6c1IPvaEsuREWe7humw+vW8KEW4LXU2gaZ9UlJZqHo0CXHX0qix6O/R4GUSPyk9wBzWHYEdYTH8us62d7UVVbS6ihXDfp+BVUFZMjJMe59GoexdA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virginmedia.co.uk; dmarc=pass action=none header.from=virginmedia.co.uk; dkim=pass header.d=virginmedia.co.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virginmediauk.onmicrosoft.com; s=selector1-virginmediauk-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QsT/fOaBu2XUHGZLHWOFPR4CTy2eU4gy/UZVX91wSrg=; b=W+4vwAbSMrbHE5JV/EYi8r5FgMR9LomcSo2lU1KLKjkojoM+b4+pKuToTUo2gTGuLDw7Q32ZedewIRTWc/u143E0d8MDQNojompZEcdk1EYN4xT4xhqAbHMPmPzjrmF8uYG3pmzaWy5UE1sS9PL8d55vD3E+qti389mTvwIY+9eZnviuMsLKC/Ub4JGpXaiVwgKZBX0HASQdNk+HpKQVOFgweVG2nQTmhKu15pqeIiol/xvskJ7v1eMcmfPz9AMljeLfn6GSTx794X6PmFxDdhTr8QMNTe5vaRGK3vUqQS0Xvab6AN6trHhNm3fzrJWdmT/p0T+IsdPw+l96RnwZNg==
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Timothy Winters <tim@qacafe.com>
CC: IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] Updating RFC 7084 - alternate logic
Thread-Index: AQHZBM6pOh6j9QEUH0aSbXL2LZ6L/a5XnsYAgAABcNCAAAwHAIAAA49QgAANbgCAAADAkIAAIKCAgADGWQA=
Date: Thu, 01 Dec 2022 07:47:54 +0000
Message-ID: <CWXP123MB516311D9A5E90628BC8E8FD2D3149@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <CWXP123MB516352292E412470C7CAB5E5D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <CAJgLMKt8uvW77QL5emk5fUq+k2osyn5AHka7ye2+vSZS5A5PFQ@mail.gmail.com> <CWXP123MB51634E2B32B3643F0FC0274CD3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <CAPt1N1nqjZyMdGcagHeqOwwZZay=gCdaP_iq-M=JGOZ92=t+aQ@mail.gmail.com> <CWXP123MB516372E5FF9C699BB8180FABD3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <CAJgLMKs=CTBAdW=-GaFT+j+rjnd=sdDe6ytoqpZhYE1KW29jUQ@mail.gmail.com> <CWXP123MB51634A6A6D20796AE43A6207D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <db23f437-7dd8-ad24-0c72-e3164dd43f4a@gmail.com>
In-Reply-To: <db23f437-7dd8-ad24-0c72-e3164dd43f4a@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virginmedia.co.uk;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CWXP123MB5163:EE_|CWLP123MB6730:EE_
x-ms-office365-filtering-correlation-id: f9f87a61-72c6-4197-9a46-08dad3705ae2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0A02zUHq8nK+cHUYB2hxKb+ST+/fAMc9U1/bWwuTn+FkGJn+vH+HDibv76oBsZmag5Vk5PCAo3XG7UPBQ+TIhn1Y7A73fO6szCn7fB247J5vlBQNpAF8x4pkOmF75jlhobTX1UKsqm7BDij69FTBj7rCCnz1FBTeJN3VUY4X5pLHhAGD0B7DEl+8npK77RFKDX2bAbkG28/mwH9fvyUY0J6HNb+3ej2yESCr0uI/w9YngyPCY3qSN/rBE72o5p2q/N5UVeLn8mLp7fTEXX5bujsDZr+dZuvoLVgIGah9Vg+tASxJZwMJzlhLkxB8Nu6aCZDQBiss4/Er3wRfK5KqA6BppfbKN6Peb26QW/aXcGGByT4oc1FHoN3JVUTxSac3EkKaAKaNqXfcoTISvaiY73O2igP/EMobWPVJzeKfcMjxZoXXGUUF+j95qsyVwHspMD3ffiwpfb4OlOEPSA+lXA/EohSi+TXuP9raOLw3BF48kaUp35Wk0hDalBdhZFP8gKAc5Qo3VorwrV5E9wsbfARrStcx0G5sdI5+Hqkb5MzTFtQSAB9qblmocyD5etWjtH2zKZ++j2rZRXDuTOGH8L3SlaZw7iDvpkBKzdTsoMy2cPSK8QjPyrTVohZ17ad9P8SuPdzBbrm8QpP51O9vxhcORIIFkZ1N+PawYY3XbjEzhkOWVKYPPX0VXv48PLbo8xVzkveIVBiniv35tffgsVQWmnlPf/OecUg+LeRfmkcJuTmVauyIdkiUXAdC7IdJPjKeiiPo4ww9hnBwTLgnOA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(136003)(39860400002)(346002)(396003)(366004)(451199015)(316002)(83380400001)(110136005)(30864003)(5660300002)(55016003)(2906002)(38070700005)(33656002)(8936002)(122000001)(76116006)(66946007)(4326008)(41300700001)(66556008)(66476007)(66446008)(64756008)(15974865002)(8676002)(52536014)(38100700002)(66899015)(478600001)(966005)(71200400001)(86362001)(9686003)(186003)(53546011)(6506007)(7696005)(26005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 3BdhpwZJ0j3x55b6ovLPU21G2D98okkc0718QxDPJ67g++Wx71zG1TWKT5vv6vy09hgdbZKdb6YmGHDDLxGJMlhENB1tPTMCZPLL4hg5yC7eLGp5dNsfHO2/RbfnT2TxEkrT3xN9ph/+bidsYAMwH0J1f9oAENEYkCF8UPh0EUx5lG3P8u3z1IeihTfOBBXLqthi0z63hPjsiiXN1Zu4Pn2mYOp4AB9m0tYPIf9hWevH0eWX75OyAsau/p4zOIHIC4E4kIoTKsb8ZdVa6tBP0n44zfE5a+gsLMjK8BRkRBzh+Jqb2+jaVPIhUj8o0h6NgPnLzoBFyhhC7QDhy3TESo9mFjlYIPyYCD50o4l/kgNGwXjWgiiMPrI7XsPbhvv8CCyHIcuQujWDNjnkB+xYK23RcdpxdMdPjfJSAhUhRt/+HfwDpR8oasyYaJo1Aqmh5jKk/AcQeDBVT65kg9ibZe5OuYHfbRkDEclWuy9g8vKNVl7VuUg5ucpAvHrA4zfx9GdIi0KPC3uffiBsSz6XlrbGCuZZcYi+HVI/XOUFQapQG4ecBmfEVcYtlvdqsYFqaAzhA6oeGxLuAAUsG05NIPyVbBdP753Ujq2CzaijQV+tcefM1tsvY9s5B9yiD+OEAROkx5gaOR7K+al/4OqRb38itF183x2+CjugF9ojvittbVUbpuRJKZ6ZjBbVujdHW8Yk7WMTaMEKGwWSUAyC4xYXS7Dg+Q5bmbabDhPH4liTT5ZZx2Mpe0F1lAgTi7cxq70Yu0EblqbaSjTrPfyoeKYo0breX2pv/4h4DHp2xYe/aEYGi/2fRV5flUiJGuIOvU76g/6Riau9Ptt9jomoy09EpQ31hjgWQHQhrxj9ubQb0vaHCflUAHTkbG5GJEqdrEOCxNGHIMDxmFUZLqCzdwa0NuasDPfRxFkACBJHvrnHb1Wx7srq0v9FcDvZtDlvWRQBvODNXqqWZt/G7jApIdr5Qan90w0FAqnn9S0uMp6AoKvAIRZlUc/ap/TOx91ezE0MAszJuZPAXcMJMQeefiZy9Nuh2JfuJgtM6PqX7QK/yjAkXIzy0wc9iOLdaZNiXnnrqePb09jAl2vLQ8V1a+Omsa1KiRqU5lMnISgaIvk/UFiKxOOAelVDlCNbqa9fEmaXUNnhl711w6kp5PBvGZ1jEHnJOt2mSa5O1U6NFwCiC0Q3/n8MBPLibtPUf4rEmLr7Xt5SqCC2kCxF3cOl6kGe5+5RiWHiTo1B6VJ56JUv21BErgoepK9eO6ifC22VcDzqGgxMM3vIbYMXjxzhY6vMLTZL3KJHOXaapAMjWEL/ob6HH7iTt6fK2XKsLjWU+h37lvfZEehFXCrxUIielG/0mEFh5+ZNyBZHNxfVHwYzd7gLI9rxKUOu3TYcXoW5+VMS3g1MVe5Yc7BbjhnE9HJPcxOUJtCcVsmJOl4PII7iYf/QL7ZBB0puM0cdmCqwOTIQn/Ou60E51t+Scr4guS4DRcJBuO03h2zN58hlEFIrB+rQLAm/elAgp49qMynuRfbYlhjpMTIA1ANSwtmK5DP6ViPJj6Va2dy71B8LujsR5bhvgrW/yOk/gsvi4u1J04b1XnNfNTd4/xVVkORbGA==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f9f87a61-72c6-4197-9a46-08dad3705ae2
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2022 07:47:54.0632 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3632a834-7ef3-430e-a7a1-8f8554088224
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: q5pgZq7lamoAiuezzHI4fHSKo2uVu71M/0CpBNB0ZvoRWmiv8JGDdwW6d76jHIZfHwP5TYusiE/SHxLB/xCKe35qSDrrpCEqZFLpMLUwFWM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP123MB6730
X-OriginatorOrg: virginmedia.co.uk
Content-Transfer-Encoding: base64
X-FE-ETP-METADATA: eyAidGlkIjogIjRBMkIwNDU3MkIyQzU4ODM2MTcwZWYxODkiLCAiYWNjZXB0ZWRfdGltZXN0YW1w IjogIjIwMjIxMjAxMDc0NzU1IiwgImFjY2VwdGVkX3RpbWVzdGFtcF9lcG9jaCI6ICIxNjY5ODgw ODc1IiwgImRvbWFpbl9uYW1lIjogInZpcmdpbm1lZGlhbzIuY28udWsiLCAiYXR0X2NvdW50Ijog LTIsICJzcmNfaXAiOiAiMTkzLjM4LjgyLjY2IiB9
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/howQPc9Mnc4sjqoNFX_LjCJtCi0>
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: Thu, 01 Dec 2022 07:48:07 -0000

I will rather take a /61 (as an example) than multiple /64s.

The debate is about flat vs tree. SLAAC works with both. I'm not bringing variable length SLAAC into the debate.

Loba

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 
Sent: 30 November 2022 19:44
To: Olorunloba Olopade <loba.olopade@virginmediao2.co.uk>; Timothy Winters <tim@qacafe.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Updating RFC 7084 - alternate logic

On 01-Dec-22 06:50, Olorunloba Olopade wrote:
> I agree that both can be made to work. I disagree that the flat model is easier or better. Maybe some concise points on why you think the flat model is better/easier?

What Ole said: In the flat mode a PD client can ask for multiple /64s.

That keeps everything simple and aligned with the fact that all hosts support SLAAC, even if they don't support DHCPv6, and that all SLAAC implementations rely on /64 today.

This would change (and become more complicated) if we standardised variable length SLAAC as Alexandre is suggesting.

    Brian

> 
> *From:*Timothy Winters <tim@qacafe.com>
> *Sent:* 30 November 2022 17:45
> *To:* Olorunloba Olopade <loba.olopade@virginmediao2.co.uk>
> *Cc:* Ted Lemon <mellon@fugue.com>; IPv6 Operations <v6ops@ietf.org>
> *Subject:* Re: [v6ops] Updating RFC 7084 - alternate logic
> 
> Hi Olorunloba,
> 
> I'm suggesting that when users have there own gateways, that will still work with this update.  As Ole mentioned, I think a flat model is easier than a tree model.
> 
> ~Tim
> 
> On Wed, Nov 30, 2022 at 12:42 PM Olorunloba Olopade <loba.olopade@virginmediao2.co.uk <mailto:loba.olopade@virginmediao2.co.uk>> wrote:
> 
>     I agree with your general thoughts here – we should fix the spec where it is wrong. However, I disagree with the specific here that the spec is clearly wrong.
> 
>     And I’ve tried to argue from both angles – existing implementation and right approach.
> 
>     To re-state my points on right approach
> 
>       * Resulting tree mirrors topology
>       * Removes limitation on a specific prefix size
>       * More flexible design
> 
>     And as per use case, I’ve seen scenarios where our customer doesn’t want to use the ISP CPE (which is allocated the /56). They want to use their own gateway, and might also want to have a separate DMZ for some internal servers. In this scenario, the /64 isn’t adequate.
> 
>     *From:*Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>>
>     *Sent:* 30 November 2022 16:44
>     *To:* Olorunloba Olopade <loba.olopade@virginmediao2.co.uk <mailto:loba.olopade@virginmediao2.co.uk>>
>     *Cc:* IPv6 Operations <v6ops@ietf.org <mailto:v6ops@ietf.org>>; Timothy Winters <tim@qacafe.com <mailto:tim@qacafe.com>>
>     *Subject:* Re: [v6ops] Updating RFC 7084 - alternate logic
> 
>     I think it’s important to be clear on the distinction between what some spec may require and what will actually work best.  When the spec is wrong, we should update it. This doesn’t mean every implementation has to be updated, but if we realize that the spec is wrong, we should definitely fix it, not live with it forever.
> 
>     In this case, the spec is clearly wrong: it’s requiring an allocation strategy that will never in practice be correct. This is why we didn’t adopt this work in the IETF. This was a known issue at the time.
> 
>     If you have some use case where you think this is the right thing, then you should argue from that position. Arguing from the position that we can’t fix a past mistake just doesn’t make sense.
> 
>     Op wo 30 nov. 2022 om 11:24 schreef Olorunloba Olopade <loba.olopade=40virginmediao2.co.uk@dmarc.ietf.org <mailto:40virginmediao2.co.uk@dmarc.ietf.org>>
> 
>         Yes, it is a MUST in the requirements.
> 
>         I don’t have a large enough pool to conclude how widely it is implemented. But it is implemented (somewhat) in ALL the CPEs I’ve come across.
> 
>         If the issue is the tree, this is a by product of the physical topology. By avoiding a complex physical topology, we can avoid a complex tree. Personally, I still prefer the tree as it mirrors the topology and would make troubleshooting easier. I expect that it would be more difficult to troubleshoot with relays.
> 
>         I also don’t see a problem with under utilised prefixes (something we generally don’t have a problem with, when it comes to v6). I see more of a problem where I want something later than a /64, and I cannot get it. Yes, my scenario for wanting something larger than a /64 is possibly not SNAC related, but this comes under general CE requirements.
> 
>         *From:*Timothy Winters <tim@qacafe.com <mailto:tim@qacafe.com>>
>         *Sent:* 30 November 2022 15:56
>         *To:* Olorunloba Olopade <loba.olopade@virginmediao2.co.uk <mailto:loba.olopade@virginmediao2.co.uk>>
>         *Cc:* IPv6 Operations <v6ops@ietf.org <mailto:v6ops@ietf.org>>
>         *Subject:* Re: [v6ops] Updating RFC 7084 - alternate logic
> 
>         Hi Olorunloba,
> 
>         I was aware of the requirements, there were a couple of things I was trying to avoid.   This model creates a tree that can lead to under utilized prefixes which was somehting I wanted to avoid.  Additionally, I'm aware that it's not widely implemented due to the complexity.   Do you know if all eRouters are required to support this?
> 
>         ~Tim
> 
>         On Wed, Nov 30, 2022 at 10:16 AM Olorunloba Olopade <loba.olopade@virginmediao2.co.uk <mailto:loba.olopade@virginmediao2.co.uk>> wrote:
> 
>             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/ <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 <https://www.google.com/maps/search/500+Brook+Drive,+Reading,+RG2+6UU?entry=gmail&source=g>. Registered in England and Wales: 2591237
> 
>             *Telefonica UK Limited*, 260 Bath Road, Slough, Berkshire SL1 4DX <https://www.google.com/maps/search/260+Bath+Road,+Slough,+Berkshire+SL1+4DX?entry=gmail&source=g>. Registered in England and Wales: 1743099
> 
>             *VMED O2 UK Limited*, Griffin House, 161 Hammersmith Road, London, United Kingdom, W6 8BS <https://www.google.com/maps/search/161+Hammersmith+Road,+London,+United+Kingdom,+W6+8BS?entry=gmail&source=g>. Registered in England and Wales: 12580944
> 
> 
> 
>         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 <https://www.google.com/maps/search/500+Brook+Drive,+Reading,+RG2+6UU?entry=gmail&source=g>. Registered in England and Wales: 2591237
> 
>         *Telefonica UK Limited*, 260 Bath Road, Slough, Berkshire SL1 4DX <https://www.google.com/maps/search/260+Bath+Road,+Slough,+Berkshire+SL1+4DX?entry=gmail&source=g>. Registered in England and Wales: 1743099
> 
>         *VMED O2 UK Limited*, Griffin House, 161 Hammersmith Road, London, United Kingdom, W6 8BS <https://www.google.com/maps/search/161+Hammersmith+Road,+London,+United+Kingdom,%0D%0AW6+8BS?entry=gmail&source=g>. Registered in England and Wales: 12580944
> 
>         _______________________________________________
>         v6ops mailing list
>         v6ops@ietf.org <mailto:v6ops@ietf.org>
>         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> 
>     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
> 
> 
> 
> 
> 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
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
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, or for Telefonica UK Limited (O2), please report it to 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