Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


IPv4 CIDR
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

IPv4 CIDR

VPNVPN Member
edited December 2013 in General

LET'ers, I want your opinion on something.

I was under the impression that the low end of the CIDR for IPv4 looked like this;

  • /32 - 1 IP
  • /31 - 2 IP
  • /30 - 4 IP
  • /29 - 8 IP

This then obviously carries on doubling the IP count for every /. But recently I am seeing a lot of people offering multiple IP addresses and referring to /29 as 4 IPs and sometimes even 5.

So what I'm asking, am I right in my understanding with the above. The maths gets me to /0 being 4,294,967,296 which is right as that is every IPv4 address.

Comments

  • We're talking about how many usable IPs. That's the difference. You've got gateway and other things. Generally you need to subtract 3 IPs, so /30 is 1 Usable and /29 has 5 Usable.

  • From wikipedia -
    "For routed subnets bigger than /31 or /32, two reserved addresses need to be subtracted from the number of available host addresses: the largest address, which is used as the broadcast address, and the smallest address, which is used to identify the network itself.[8][9] In addition, any border router of a subnet typically uses a dedicated address."

  • Ah I see. I hadn't thought about broadcast and gateway addresses.
    So in practice nobody would ever be given a /31 or a /31 for a dedicated box because then they'd have no IPs lol.

  • MaouniqueMaounique Host Rep, Veteran

    small allocations are wasting IPs :(

  • @Maounique said:
    small allocations are wasting IPs :(

    That's what I'm thinking too now.

  • Maounique said: small allocations are wasting IPs :(

    True, I completely agree with you.

    However, in practice, it just happens. I had a /28 from Cloud Shards and I wanted more IPs. They couldn't expand the first /28 so I had to get a new one, which resulted in the loss of more IPs. It's not their fault, I mean, they had to allocate another subnet after I got my server from them. But it just happens to turn out like this.

  • You can ask them to cancel the first /28 and give you a /27, but in practical it's not good.

  • I still haven't figured out the technical reason for this wasting of IPs with micro-allocations and their respective reserved IPs other than some misguided effort to justify larger blocks from ARIN (snooping/broadcast related concerns? do they really matter?) :( I could understand breaking up large blocks for multiple locations, but multiple micro-allocations for a single server? Could someone please enlighten a layman such as myself what justifies wasting so many IPs? Routing over different segments of a network? Ok, but what about when that isn't a concern? :) Thanks! Sean

  • @netdude said:

    Depending on who your upstream provider is, you may have to pay them to re-announce the new block. It is not feasible to renumber accounts, as it is simple enough to add an existing allocated micro-block to their server. Most clients also only ever want to purchase one or two additional IP addresses, resulting in more of these micro-blocks being created.

    @OkieDoke said:

    You could ask your provider to give you a /27 , and allow you some time to "renumber" out of your existing range. You would have to give up your current /28 after some time, and would have to live in a completely new IP range, but you would effectively reclaim those 3 IP addresses lost by having two /28s instead of one single /27.

  • @HardCloud said:
    You could ask your provider to give you a /27 , and allow you some time to "renumber" out of your existing range. You would have to give up your current /28 after some time, and would have to live in a completely new IP range, but you would effectively reclaim those 3 IP addresses lost by having two /28s instead of one single /27.

    That makes sense. Luckily at the moment I don't need 32 IPs but I will do fairly soon I think.

  • @netdude said:
    I still haven't figured out the technical reason for this wasting of IPs with micro-allocations and their respective reserved IP

    Often, layer 2 separation.

  • VPNVPN Member
    edited December 2013

    So another thing I'm not sure about and that I think is being used incorrectly is the CIDR references for IPv6.

    I see people using /64 for one IPv6 address but this is technically incorrect.

    With /0 being 340,282,366,920,938,463,463,374,607,431,768,211,456 available IPv6 addresses (2^128), one address would be /128 (2^0). /64 is actually 18,446,744,073,709,551,616 addresses (2^64).

    Thoughts?

  • /64 is used for IPv6 to describe the end-user allocation size. It means 1 subnet, so the smallest size that should be allocated.

  • @ska said:

    Depletion of the internet address space, version 2. I'm not happy with IPv6 subnets being so large, especially when that's what most companies are giving per EACH VPS.

  • @HardCloud said:
    Depletion of the internet address space, version 2. I'm not happy with IPv6 subnets being so large, especially when that's what most companies are giving per EACH VPS.

    Thinking in single IPs and a possible depletion when speaking of IPv6 shows the misunderstanding of the concept of IPv6.

  • MicrolinuxMicrolinux Member
    edited December 2013

    @HardCloud said:
    Depletion of the internet address space, version 2. I'm not happy with IPv6 subnets being so large, especially when that's what most companies are giving per EACH VPS.

    The amount of IPv6 space is many, many magnitudes larger that IPv4. It was designed to allow for enormous subnets per-device. See RFC 5375.

    In terms of smallest practical subnet assignments, using IPv4's 1 billion /30s is conceivable. IPv6's 18 quintillion /64s less-so . . .

    Owen Delong from HE wrote an excellent article dispelling the misconceptions about IPv6 run-out.

Sign In or Register to comment.