Re: [v6ops] Updating RFC 7084 - alternate logic

[Ted Lemon <[e-mail]>]

Okay, but this isn't a good configuration. You have a router where there
shouldn't be one, and it's acquiring the /56 when it shouldn't. Of course
this is a fairly common case, but maybe we should actually figure out a way
to signal to the router in this case that the customer-owned device should
get the entire /56, rather than that the ISP router should get it. In
general this situation works really poorly for IPv4, because you have a
double NAT, so fixing the configuration is a win both for IPv6 and IPv4.

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
>