Re: [v6ops] Updating RFC 7084 - alternate logic

[Alexandre Petrescu <[e-mail]>]

Le 30/11/2022 à 16:16, Olorunloba Olopade a écrit :
> 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.

Yes, that would be the creation of /62 prefixes for sub-delegation, out 
of a /60 received prefix.

> 
> • 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.

... /63 prefixes out of a /60.

> • 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.

... /59 prefixes out of a /56.

> 
> • 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.

... /60 prefixes out of a /56.

For all these cases, I suggest to specify the value of the bits between 
the position of prefix and the position of IID.  For example, if the 
sub-delegated prefix is /60, then specify the values of the bits 61..64 
to be set to 0 for SLAAC.  Do not let it unspecified.

> • 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.

Sounds reasonable.

But, in such corner cases, such as a prefix /65, rather than indicating 
a complete fault, I would like to suggest a potential use of a VSLAAC 
method ('variable' SLAAC).  A few unix variants support it in a more or 
less mature manner.  And yes, I know many oppose it, but that is my 
suggestion.

Alex

> 
> *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/ 
> <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
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops