Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device

[Lorenzo Colitti <[e-mail]>]

Let's not fall into another debate about the /64 boundary :-) The draft
does not have /64 hard coded anywhere in it, so if and when we change the
subnet size supported by SLAAC to something else, the document will not
need to be modified.

The draft does say that the server must hand out a prefix of sufficient
size to support SLAAC. There's a good reason for this: SLAAC is the only
address assignment mechanism that is mandatory to implement, and in large
numbers of hosts, it's the only one that is implemented.

Yes, this does mean that this draft is not applicable on all networks. But
to be realistically, I see no way that we could get consensus on *any*
method that would support end-to-end connectivity and permissionless
network extension on all networks. If anyone can think of one, please do
share and we'll go off and do that instead :-)

In the meantime, this draft is what comes closest to that goal. It
meaningfully increases the capabilities of large networks by allowing
unlimited end-to-end extension, and that's a huge improvement. Let's not be
the perfect be the enemy of the good.

Cheers,
Lorenzo

On Fri, 4 Aug 2023, 05:30 Brian E Carpenter, <[e-mail]>
wrote:

> On 04-Aug-23 05:25, Owen DeLong wrote:
> > /64 also provides a sufficiently large space that the odds of a
> collision among randomly generated addresses are sufficiently small as to
> allow address autoconf to have a high success rate on the first attempt.
>
> There's that, and a similar argument about privacy/guessability of IIDs.
> When we looked at this for RFC7421, we concluded that 40 bits was enough,
> so /80 or even /88 subnets would be reasonable.
> (https://www.rfc-editor.org/rfc/rfc7421.html#page-16)
>
> >
> > Walking further right to work around stingy provider’s bad allocation
> policies is a step in the wrong direction, IMHO.
> >
> > That said, I do agree that /64 shouldn’t be hard coded anywhere and that
> prefix size should be an operator choice. I think it is useful for /64 to
> remain a strong recommendation.
>
> So perhaps 6man should adopt draft-bourbaki-6man-classless-ipv6?
>
>     Brian
>
> >
> > Owen
> >
> >
> >> On Aug 3, 2023, at 08:52, Pascal Thubert (pthubert) <pthubert=
> [e-mail]> wrote:
> >>
> >> +295147905179352825856
> >>
> >> I believe that neither any new spec nor any new implementation should
> have 64 hardcoded in it anymore. There should be a MUST in a BCP for that.
> >>
> >> There are some chains of inheritance that should be broken before they
> hurt too much, e.g.,
> https://garethdennis.medium.com/the-not-so-glamourous-origins-of-standard-track-gauge-2b5f1ae7e3bc
> .
> >>
> >> Though the horse tall tale might be overrated, I still believe in the
> one that says that the 64 value was not defined for the best of admins, but
> to allow SLAAC using the MAC address as IID even in L2 networks using the
> MAC-of-the-future, of 64 bits. Firewire is dead, and 15.4 is the only major
> L2 left with 8 bytes MACs. The IETF now discourages MAC for IID anyway.
> >>
> >> 64 is thus only useful because of some existing SLAAC implementations
> and should be considered as a special value only in that context, to be
> provisioned accordingly by the admin that really wants SLAAC and those
> devices (admittedly, my home gateway is like that).
> >>
> >> NetOps who are not in that context should be able to build the network
> they want with minimum constraints. There should not be constraints that
> are there only to fit the taste or the limitations of the protocol
> designers. A touch of humility and a good dose of separation of power &
> responsibility would serve us well here.
> >>
> >> All the best,
> >>
> >> Pascal
> >>
> >>
> >>> -----Original Message-----
> >>> From: v6ops <[e-mail]> On Behalf Of Brian E Carpenter
> >>> Sent: Wednesday, August 2, 2023 11:38 PM
> >>> To: Ole Trøan <[e-mail]>
> >>> Cc: [e-mail] list <[e-mail]>
> >>> Subject: Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device
> >>>
> >>>> On 03-Aug-23 09:20, Ole Trøan wrote:
> >>>> Brian,
> >>>>
> >>>>> On 2 Aug 2023, at 23:10, Brian E Carpenter <
> [e-mail]>
> >>> wrote:
> >>>>>
> >>>>> On 02-Aug-23 18:55, Ole Trøan wrote:
> >>>>>>> With all due respect, etc. etc., very few people on this list have
> a
> >>> typical home network. If we are talking about customers of an ISP that
> only
> >>> offers a /60, it's a different world to ours. I am *not* defending
> such ISPs,
> >>> far from it, but the CEs that they provide are highly unlikely to
> enable
> >>> dhcp-pd-per-device.
> >>>>>> If this proposal results in an address assignment approach that
> cannot
> >>> even number a home network that has been assigned 295147905179352825856
> >>> addresses, at least an outsider would start wondering what we were
> smoking.
> >>>>>
> >>>>> Well yes, but aren't you agreeing with me? A CE that only has a /60
> >>> probably shouldn't support a delegation method that assigns a whole
> /64 to a
> >>> single device. (Unless the CE also knows that the device is capable of
> >>> assigning longer prefixes to subsidiary devices, which is essentially
> what
> >>> Pascal was saying.)
> >>>>>
> >>>>> Or in other words, the dhcp-pd-per-device mechanism is only useful
> for
> >>> networks that know how to use it.
> >>>>
> >>>> Yes, that we agree on.
> >>>> DHCP PD as a delegation method supports any prefix length.
> >>>
> >>> So does RFC 8992, as it happens. I had fun in my toy implementation
> >>> supporting any prefix length.
> >>>
> >>>> The size of the assigned prefix should be an operational choice. I am
> not
> >>> sure this document needs to say more than if the prefix is longer than
> 64
> >>> then further sub-assignment to other hosts will not support SLAAC. If
> even
> >>> that.
> >>>
> >>> Yes.
> >>>     Brian
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>