And /48 was chosen as the site size so that we didn’t have to think about that either. It’s large enough to cover almost all sites with additional /48s to be provided if you run out of /64s.
Nothing in the last 20+ years has lead me to believe that these decisions were wrong. In fact NOT following these rules has consequences for everybody else as you can’t policy filter at the /48 boundary without collateral damage. I would recommend that all ISP’s using longer prefixes for customer assignment shorten them to /48s. Mark > On 29 Dec 2017, at 8:35 am, Owen DeLong <[email protected]> wrote: > > Sigh… Let’s stop with the IPv4-think. > > Wasting 2^64 addresses was intentional because the original plan was for a > 64-bit total > address and the additional 64 bits was added to make universal 64-bit subnets > a no-brainer. > > Owen > >> On Dec 28, 2017, at 09:55 , Michael Crapse <[email protected]> wrote: >> >> Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. >> If that was ipv4 you could recreate the entire internet with that many >> addresses. >> >> On 28 December 2017 at 10:39, Owen DeLong <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Dec 28, 2017, at 09:23 , Octavio Alvarez <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 12/20/2017 12:23 PM, Mike wrote: >>>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>>> due to ping-pong and just so many technical manuals and other advices, >>>> you are told to "just use a /64' for your point to points. >>> >>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >>> exception would be if a router does not support it. >>> >>> Best regards, >>> Octavio. >> >> Best practice used most places is to assign a /64 and put a /127 on the >> interfaces. >> >> Owen >> >> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected]
