Hi David, I thought that DHCPv6 Prefix Delegation (PD) could have multiple levels of delegation and that mechanism alone could be used for assignment within a domain? I must admit that it has been a very long time since the home net WG discussions.
Thanks, Acee > On Jul 26, 2023, at 18:08, David 'equinox' Lamparter <[email protected]> > wrote: > > TL;DR: skim the excerpts below, only looking for Yay/Nay. > > > Hi lsr & v6ops WGs, > > > prompted by some presentations and chats in the past days, I've dug up > this old thing that we looked at in some autoconf & multihoming context, > made it presentable and uploaded it. > > On Wed, Jul 26, 2023 at 02:48:34PM -0700, [email protected] wrote: >> Name: draft-lamparter-lsr-v6ops-pd-aargh >> URL: >> https://www.ietf.org/archive/id/draft-lamparter-lsr-v6ops-pd-aargh-00.txt >> Html: >> https://www.ietf.org/archive/id/draft-lamparter-lsr-v6ops-pd-aargh-00.html > > Before any LSR people get a heart attack, this is in its entirely > separate little world of prefix/address management and explicitly > excludes any interaction with routing data/calculation. But first, what > it does - it simply puts your assigned prefix(es) into your link-state > routing protocol. (*Once*, at the network boundary to your uplink. Not > per link/subnet/router/...) From there you can then derive prefixes and > addresses. The idea is extremely simple, though it does need a bunch of > plumbing. (I've entirely handwaved OSPF areas and IS-IS L1/L2.) > > > Here's some excerpts: > > "Between large enterprise networks that can reasonably use their own > IPv6 address space and small home and office networks that do not > utilize a complex routing topology, there is an intermediate space where > a network may need to utilize a nontrivial routed topology but still > connect to the internet in a plain "customer" role, with IPv6 address > space being assigned over e.g. DHCPv6-PD" > > "This document takes a "router-down" perspective without attempting to > take all address management and policy out of the operator's hands. " > > "Only communicating available prefixes and making subnets or host > addresses out of them is considered here. How to apply the results to an > innumerable amount of entities that may need reconfiguring or flushing > of state [...] is a giant of its own." > > "At its most basic, to establish IPv6 reachability given a number of > (working) lower layer links, two things are needed: addresses and > routing information. When the routing domain has come up, the network > should work, and if addresses are assigned statically, it hopefully > will. This mechanism attempts to not worsen this situation - the network > should work after routing has come up." > > "This document does not attempt any kind of automatic prefix or address > assignment in the "second half" of the prefix. It only attempts a > mechanism to convey the "first half" of a prefix, and deal with changing > it - while keeping the second half firmly under operator control" > > > That said, at this point I'm hoping to just get a bunch of "yay" or > "nay"s on whether this might be worth progressing. Even reading it in > its entirety might be wasted effort at this point ;) > > > Cheers, > > > -equi > (David) > > > P.S.: the title originally ended with "... Handling", hence the document > name. > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
