You are here: Home / Blog / IPv6 – /48 allocation in /64 chunks – that’s a lot of addresses

IPv6 – /48 Allocation in /64 Chunks – That’s a Lot of Addresses

21st January 2011 by 15 Comments

I posted yesterday about changes to RFC3177 for IPv6 allocation. I wonder how many have done the maths on this and realised just how many addresses this works out to be.

Lets hold hands and work through the maths:

  • Lets say you are allocated a /48 by your favourite RIR.
  • Lets also say you allocate this in /64 chunks (as is custom and recommendation for IPv6 at this time).
  • that means you have 2^16 networks.
  • that 65536 subnets.

Just for reference that’s as many subnets as there are individual IP Addresses are in B-Class IPv4 address.

If you are allocated a /48 from the RIR then this is quite a lot of subnets – even when allocating a /64 per point to point connection. I don’t understand why people are saying that this isn’t enough address space or complaining that using a /64 is wasteful.

I can accept that a carrier or a very corporate might need a bigger space, but if you ask they will allocate it to you (providing you can make a case for it).

Am I missing the point here ?

Other posts in the series

  1. Why Allocating a /64 is Not Wasteful and Necessary
  2. IPv6 - /48 allocation in /64 chunks - that's a lot of addresses (This post)
  3. IPocalypse: What's next for the 'End of the Internet' ?
  4. The IPocalyse is Nigh - Forced Allocation of IPv4 to RIRs next week ?
  5. IETF IPv6 address allocation policy being updated.
  6. Scheduling the IPocalypse
Filed Under: Blog Tagged With: ,
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • Ben Jencks

    Nope. You’re getting the point perfectly. It’s the people who are worried about scarcity that aren’t getting it.

    (It still might be advisable to *number* point-to-point connections with a /127, due to the ping-ping attack and to mitigate NDP flooding attacks, but that’s no reason not to *allocate* a full /64 for the link, just to simplify things)

    • http://etherealmind.com Greg Ferro

      I disagree with the security topics, they aren’t very much different from the issues in IPv4 and we never did anything about them. Why bother ?

      • Ben Jencks

        The ping-pong thing isn’t much different from IPv4, but the scale of the NDP flooding is massively different from ARP flooding. If you were to use v4 /24s for PtP links (not likely these days, but the best equivalent to a /64), an attacker could use at most 254 entries of your ARP table. That’s a big difference from the essentially infinite number of entries they could generate with in a /64.

        These issues really only apply to carriers, though, since enterprises will generally have everything behind a firewall. Carriers can also prevent them with ACLs blocking all traffic to their interfaces.

        • Dejan Protich

          Okay, not worried about the scarcity how about the router resources, if you had allocated a /64 per rack and you had twenty 10 racks in a 24 port switch, and the the uplink each had a /64 and you had 4 uplinks that would be 14 x 65k the router would crap out if you had scanned those subnets no????

  • http://globalconfig.net Brandon Carroll

    I’ve been talking about this all week. I am so ready for IPv6. Out with the old, in with the new!

    • Joe Astorino

      Yes I remember thinking through this and discussing with some students of mine and coming to the realization that a /48 is 65536 /64s. Whoah.

  • http://packetlife.net/ stretch

    Along a similar vein, I think a lot of people are also still coming to grips with the concept of a /64 as being able to support an effectively infinite number of end hosts (practical restrictions notwithstanding).

  • http://blog.ipexpert.com/ Marko Milivojevic

    “640K of memory should be enough for anybody.”

    I’m pretty certain there is similar quote from the meeting on which IP classes were decided. We are repeating the same mistake.

    Yeah, numbers are bigger, but what tomorrow brings… we do not know. I am sure we may live to regret being wasteful.

    –
    Marko Milivojevic – CCIE #18427 (SP R&S)
    Senior Technical Instructor – IPexpert

    • http://blog.quux.de Jens Link

      > Yeah, numbers are bigger, but what tomorrow bringsÖ we do not know. I am sure we may live to
      > regret being wasteful.

      So what? Let’s say in about 20 years we figure out we were to wasteful with 2000::/3 we can still decided to use another addressing scheme for 4000::/3 and another for 6000::/3 and another, ….

      • http://blog.ipexpert.com/ Marko Milivojevic

        You may be right, yes. We’ll see in 10-15 years . All I’m saying is that even IPv6 pool is not an indefinite resource. We don’t know how many /64 per nano-bot will be required in 20 years, but all I’m saying is that we may be in for the same old problem in the future, only because we have no idea what’s coming.

        –
        Marko Milivojevic – CCIE #18427 (SP R&S)
        Senior Technical Instructor – IPexpert

    • Micah

      I think the easy answer to this one is what I’ve done and seen most do in the Carrier space which is allocate a /64 but number interfaces as /126 (easier bit boundary). This addresses security concerns and leaves flexibility to go back and simply change the prefix length should that ever be required.

  • Ben Johnson

    Hmmm. Maybe I’m showing my age here, but I’ve always taken on board the lesson that resources should never be wasted, no matter the ‘perceived’ inexhaustibility of said resource. I agree that, at the moment, it seems almost inconceivable that the v6 address space could even come close to exhaustion, but that doesn’t stop the ‘idea’ of using ~2^64 host addresses to achieve a single point-to-point connection seeming extraordinarily wasteful. Obviously trying to manage a /48 address space in /127 chunks could be likened to an acute form of masochism, but the point – at least to me – is still this: If I need two buckets of sand to build my sand-castle, why would you tell me to use 18446744073709552000, even if I DO own the whole beach?

  • Pingback: Why Allocating a /64 is Not Wasteful and Necessary ñ My Etherealmind

  • Rob

    So is the recommendation still to only have ~512 to 1000 clients per subnet?

  • Dave

    I actually do agree that /64s is too large, but not necessarily because of the waste.  Most companies will get a /48 (including mine).  The problem comes when you try to allocate subnets cleanly.  Yes, it is extremely unlikely that we will ever even come remotely close to using the 65535 subnets we have allocated to us.  However, some of the cool things you can do with v6 to make it easier on you to remember IP addresses (and yes engineers will ALWAYS have to know addresses…at least for short periods of time) like do 1:1:1:DC01::/64, and then all subnets below “DC01″ are actually in your datacenter go completely out the window if you keep the /64 allotment scheme.