> On Apr 18, 2020, at 01:41 , Fernando Frediani <[email protected]> wrote: > > On 18/04/2020 05:26, Owen DeLong wrote: >> ... >> >> Admittedly, /48s for everyone still isn’t gaining as much traction as we’d >> like due to a combination of IPv4-think at some ISPs and other reasons I >> have trouble understanding. > Thankfully it is not !
How so? What’s the advantage to not doing so? >> >> E.G. I once had a discussion with the IPv6 project manager for a major >> $CABLECO about why they were sticking it to their residential customers with >> a maximum /60 instead of a /48. His answer perplexed me… He said that the >> problem was that if they gave out /48s to all their customers the way their >> network is structured, they’d need a /12. Now I realize that policy only >> allows ARIN to give out a /16 at a time, but I’m quite certain this >> particular organization could easily qualify for 16 /16s without any issue >> whatsoever. When I pointed this out, he just walked away shaking his head. > And he is right. I still fail to understand from where this idea of giving > residential customers a /48 came from. And this is not thinking with IPv4's > mind really. Really? What is the benefit to NOT giving residential customers /48s? Please explain it to me because so far, I haven’t heard an explanation for this limitation that makes any sense. >> >> Now I realize a /12 sounds like a ridiculous amount of space, but if you >> think about it, this is an organization that has several /8s worth of IPv4, >> so it’s not actually all that far fetched. Also, I seriously doubt that >> there are anywhere near 100 organizations with the number of customers this >> $CABLECO has. There are 512 /12s in 2000::/3 which is just the first 1/8th >> of IPv6 address space designated as GUA (Global Unicast Addresses). The math >> works. We have the address space to do this and give everyone /48s without >> any issue of running out. > Well, I hear this every time I talk against this "/48 for all" idea. And I > don't think because of this justification 'we have plenty so let's give them' > should be broadly and always applied. Give people whatever is reasonable for > their usage, but not a tremendous exaggeration. And a /48 for a residential > customer is an exaggeration that will hardly ever be used. If one day this > changes we can adapt to the new scenario. > That’s not the justification. That’s the rebuttal to the IPv4-Think mentality of let’s pretend there’s scarcity and put unnecessary limitations in place as a result. The reason we want /48s everywhere is so that future applications involving automatic topologies with multiple layers of DHCP-PD can be brought to fruition. So that in-home network segmentation without user intervention can eventually become a reality. So that we can actually develop plug-and-play secure networking with proper segmentation working in an automated fashion. You simply cannot do that with a /60. It’s marginal with a /56 and you run into a number of walls. >> >> So… we have a circumstance of competing tradeoffs in policy: >> >> 1. We don’t want policy to create perverse incentives to not give >> /48s to customers. That’s one of the reasons >> for the particular wording of the PAU text in the IPv6 ISP >> policy (which staff doesn’t do a particularly good >> job of following in my observation). >> >> 2. We don’t want to create economic disincentives to IPv6 >> deployment. > I can see the intents of this proposal specially for point 2 and perhaps > there are adjustments to be done, but certainly not with the idea of giving > /48 everywhere in mind. > Well… I think policy and engineering wise, you’re in the minority (fortunately). Policy as written definitely favors /48s for everyone. Owen
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
