> On Apr 18, 2020, at 15:20 , William Herrin <b...@herrin.us> wrote: > > On Sat, Apr 18, 2020 at 2:44 PM Owen DeLong <o...@delong.com> wrote: >> Handing out a /48 to each end site is a core engineering design that was put >> into IPv6 for many valid reasons. > > Hi Owen, > > If I understand correctly, the /32, /48 and /64 size recommendations > were originally discussed on public, now-archived IETF mailing lists. > At the time, dynamic dialups were the equivalent of what we today > consider residential customers (as opposed to business and hobbyist > end sites). Have you found some citations among those discussions > which clarify that /48 was intended to apply to all ISP customers > explicitly including individual end users of the ISP, not just network > clients of the ISP.
While I don’t have citations, I can say that you aren’t entirely correct. While not as ubiquitous as they are today, both CMTS and DSL systems were known residential ISP technologies at the time those boundaries were established and the idea of automatic hierarchical topologies through layered DHCP-PD was very much something that was considered as applicable to a potential future residential context. It would take some time to find any citations for this, but I personally recall participating in some of those discussions. By the time we were establishing those boundaries, it was already assumed that an always-on broadband connection via DSL, CMTS, or other future technology with similar or even greater capabilities would become the norm for residential internet services. Not that all of the assumptions came true. It was assumed that IPv6 would be an enabling technology helping to drive deployment of that infrastructure, rather than the other way around. There are others on this list who were there. I’m sure someone will correct any misstatements I may have made or any incorrect details. Owen _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
