Re: [v6ops] Updating RFC 7084 - alternate logic

[Ted Lemon <[e-mail]>]

It's worth pointing out that "flat" here means simply that each non-edge
router gets a /64, not that the network topology is necessarily flat.

On Wed, Nov 30, 2022 at 12:44 PM Timothy Winters <[e-mail]> wrote:

> 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 <
> [e-mail]> 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 <[e-mail]>
>> *Sent:* 30 November 2022 16:44
>> *To:* Olorunloba Olopade <[e-mail]>
>> *Cc:* IPv6 Operations <[e-mail]>; Timothy Winters <[e-mail]>
>> *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=
>> [e-mail]>
>>
>> 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 <[e-mail]>
>> *Sent:* 30 November 2022 15:56
>> *To:* Olorunloba Olopade <[e-mail]>
>> *Cc:* IPv6 Operations <[e-mail]>
>> *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 <
>> [e-mail]> 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 <[e-mail]> *On Behalf Of *Timothy Winters
>> *Sent:* 18 November 2022 14:47
>> *To:* IPv6 Operations <[e-mail]>
>> *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
>> <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, 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
>> <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
>> [e-mail]
>> 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
>>
>