Re: [v6ops] Updating RFC 7084 - alternate logic

Timothy Winters <tim@qacafe.com> Wed, 30 November 2022 15:55 UTC

Return-Path: <tim@qacafe.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 1C184C14CE59 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 07:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com
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 c7VlaTC8Aorl for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 07:55:53 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6EEC14F613 for <v6ops@ietf.org>; Wed, 30 Nov 2022 07:55:52 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id a13-20020a9d6e8d000000b00668d65fc44fso11466323otr.9 for <v6ops@ietf.org>; Wed, 30 Nov 2022 07:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RA1IkoUIThH4/7xw26Z6emSYN2piNAqtcGhHjvvjnFs=; b=MF3nSgkTUHo4AyBtAYDYoHs479hoiPzy/DKLCD7d8LjfHAGA+b7HCwCHWWRcObe2BO yd4MoOe/mOYiHzXL61npmR0VYGMTiJyniDmXvGhLMcu+0X8tbt+sQWiy1s5rvGwbRlj6 qTliEvpM7bWF/ggtHy0Rzt/Y/FCImiaewOBTU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RA1IkoUIThH4/7xw26Z6emSYN2piNAqtcGhHjvvjnFs=; b=3yRqGMtZ3ShHXnvoeM7ktVPQ3Dq7yJwxFVo1BXBsSLKTXrXor6T0niDUH5KpZzyHF0 O4Ng5oIVRfbTiVGCR8+2tm5xdfIRxHTGEfd27hh7jOMCD/SGi1syKgq/rnoCuWkyfXwb JIDnJk4vr+p30A8+zdUabXEW77sPA08FaeV+a3rWkw/0/uzKgJoKTjvouiP1rXDg6Cc2 0HG4CgDrbFepLM3YJLpYV5ewLRQXQ+Q+fmmtkKP5j4XmR8KFMxTdNXDgAQhfb6Dc3tYR ztdl67tSW+NiXpKKzNDtEc1ned/4K6+1QvhpFjxqsoE0r+4mG992t8yORwwfbOldSLPC OGKA==
X-Gm-Message-State: ANoB5pmLgpw9wwE3K4QenvZn7wabI++hn+74zfDihaGlGk7Lq7YTuRMV UsuI2V4PJuBqYKS0Zkwkdr4P4WvXmRKxwsgRqO/ARD8aLkg=
X-Google-Smtp-Source: AA0mqf63WBYa0pfSCoyYBX1g8jSiuF45Azp39+RCG1JDo/BFZlR+Bsal4rN0XqkndRP8ZCtffDGYqIjBQ/d58QN+H8E=
X-Received: by 2002:a9d:6a45:0:b0:66c:2d7f:420f with SMTP id h5-20020a9d6a45000000b0066c2d7f420fmr20491263otn.212.1669823751664; Wed, 30 Nov 2022 07:55:51 -0800 (PST)
MIME-Version: 1.0
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <CWXP123MB516352292E412470C7CAB5E5D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP123MB516352292E412470C7CAB5E5D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
From: Timothy Winters <tim@qacafe.com>
Date: Wed, 30 Nov 2022 10:55:40 -0500
Message-ID: <CAJgLMKt8uvW77QL5emk5fUq+k2osyn5AHka7ye2+vSZS5A5PFQ@mail.gmail.com>
To: Olorunloba Olopade <loba.olopade@virginmediao2.co.uk>
Cc: IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008e60af05eeb2236b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/K8PUzhQEHqvFINVS_fws-gG2Yas>
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:55:57 -0000

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> 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> *On Behalf Of *Timothy Winters
> *Sent:* 18 November 2022 14:47
> *To:* IPv6 Operations <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, 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
>