In IPv4 we have class A, class B, and class C. In IPv6 we have only global prefix and Interface ID. I know there are plenty of addresses in IPv6 but it gives room for too many host addresses.And when it comes to P2P links only two addresses are used but /64 gives around 18 quintillion possible addresses that's a terrible waste of ip addresses. Is it good or bad practice to subnet the address beyond global prefix ?

  • There are not even any network classes in IPv4 since 1993, over a quarter of a century ago!
    – Ron Maupin
    Commented Mar 20, 2019 at 3:03

4 Answers 4


IPv4 classes A, B and C have been deprecated since the publication of RFC 1519 in 1993.

I agree with you that 64 bits for host addresses is more than anybody will ever need, but that is how it is designed and never having to worry about subnet sizes is wonderful! :)


The classes of networks have not existed since around 1995; they are irrelevant, since they referred to permanent allocations, which have not been available in almost two decades. People use the term "class C" to refer to a /24 network segment out of historical habit, and newer engineers have picked up the habit without really knowing the history. Tell me, do you know what "Class E" networks were reserved for (hint: ask anyone who did DARPA or NSFNet research between mid 1980s and mid 1990s)? Do you know any telecoms operating multicast-backbone devices that refer to the as "Class D"?

In point-to-point segments, use "IP UNNUMBERED", and point your route to segments beyond the point-to-point link (an interface on a router terminating a point-to-point link is rarely interesting; your users probably care abut a resource behind it).

For your allocation, use segments that are a consistent /64. I know it sounds wasteful and sparse, but it will make everything A LOT easier, and you are unlikely to run out of addresses. If you do, get a second allocation, and document your network, as it is probably a GOOGLE-scale or DoD-scale network.

In IPv6, the standard is a /64 for every non-point-to-point segment, and standard allocations of /48 (this means you can break every allocation into 65536 individual segments ; one or two allocations are likely more than you will ever need for all but the largest, most complex networks). RFC 6177 also recommends smaller allocations of /56 for SOHO networks, and possibly flexible allocation sizes for larger networks, although I have trouble imagining a /32 allocation outside of an ISP that is giving addresses from its allocation (the way IPv4 ISPs do) instead of sending their customers directly to ARIN.

  • 2
    "Standard" allocations are a bit more flexible now; see RFC 6177. Commented Nov 1, 2014 at 15:42
  • Interesting. I had never seen that before. Thank you. Is that now an accepted standard? Are small sites (SOHO installations) getting /56 allocations for 256 segments (each a /64), and enterprises getting /48 allocations for 65536 segments (each a /64)? Are allocations now sized by request/need (have to give an annual accounting to ARIN and justification for more)?
    – DTK
    Commented Nov 28, 2014 at 17:50
  • My residential ISP (Comcrap) only gave me a /60, which I've used almost all of already and had to do quite a few bizarre contortions with my (unusually complex) home network to utilize. But yes, from what I've heard /56 and /48 seem to be more normal. From my quick skim of the ARIN policies, it seems that an end site can get a /48 without any justification, it being the minimum size that ARIN will assign. Commented Nov 28, 2014 at 17:56
  • Can you get an allocation from ARIN and ask Comcrap to point a static route and advertise it for you (I presume they would charge you money to peer with you, plus a global AS is expensive for a SOHO, and I haven't seen an ISP share RIP with a customer since around the time people stopped using network classes seriously)?
    – DTK
    Commented Nov 28, 2014 at 18:05
  • Haha. If I wanted to switch to a business account I probably could manage something. But they haven't rolled out IPv6 to business customers at all, as far as I know. I'll eventually convince them to just give me a /56... Commented Nov 28, 2014 at 18:07

In fact, there is not room for too many hosts. The size of the network identifier makes possible mechanisms like SLAAC, opaque interface identifier, or privacy extensions (and several more). Each of these mechanisms need a large space to pick - more or less - randomly an interface identifier with next to negligible probability for a collision. Alas, the proven patterns and paths from Legacy IP make you (and many other admins) think that addresses are wasted and hinder you to unleash the power of IPv6.

N.B. doing away with subnets and subnet masks eliminates a big source of trouble. Subnetting in IPv6 is as simple as it possibly gets.


IPv6 actually does have classful addressing, although not by that name, and there is only one class instead of the three classes A, B and C that we have in IPv4 (there also is an equivalent to class D in IPv6. Not sure about class E).

Update: @RonMaupin points out that IPv6 is technically classless. What I mean here is that the restriction on /64 subnets has the same practical effect as classes did in IPv4, in that it imposes a very ridgid subnetting structure.

IPv6 is actually more restrictive than the IPv4 classes.

In IPv4, the classes are basically just conventions (and, as others have pointed out, classes have been deprecated for a very long time); except for RIP version 1, I know of nothing that has assumptions about classes hard-coded. If you use a class A prefix wih a /29 subnet mask, pretty much nothing breaks.

In IPv6, on the other hand, you simply cannot subnet to anything less than a /64 without breaking a lot, such as SLAAC and Neighbor Discovery.

You can't simply create a /68 or a /120 subnet and expect things to work. You can use a /127 for point-to-point networks, but only because a point-to-point network generally doesn't need anything beyond bare static IP addresses.

  • 1
    IPv6 addressing absolutely does not have classes. It was purposely designed as classless. It can certainly break things if the subnet used is not a /64, but that has nothing to do with classful networking.
    – Ron Maupin
    Commented Sep 25, 2015 at 21:15
  • SLAAC is the only thing "broken" by a prefix length != 64. (and by "broken", I mean "does not apply") My network is not a /64 intentionally to stop android devices from using v6. Nothing has a problem with it. (FWIW, SLAAC was originally /80.)
    – Ricky
    Commented Sep 26, 2015 at 21:03
  • Actually many more things than SLAAC are broken with sizes other than /64. See RFC 5375, "Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes."
    – Ron Maupin
    Commented Sep 27, 2015 at 4:56
  • @RonMaupin In a strictly technical sense, you are of course correct, since "class" in IPv4 refers to the fixed distinction between large, medium and small networks. On the other hand, the restriction on subnets smaller than /64 has the same practical effect as classes. After all, in IPv4, the only reason classes were a problem is that they impose a very ridgid subnetting structure. Commented Sep 27, 2015 at 20:32
  • 1
    Plenty of systems used to make assumptions about classful addressing - it was a lot more than just a "convention". On SunOS in the early 90s it was impossible to merge two "class C" from the official class C blocks into a /23 (but you could if the addresses were picked out of the class B range). Even in the early '00s it was impossible to access Microsoft's sites if you had a (perfectly legal) /32 host address that ended in .0
    – Alnitak
    Commented Nov 6, 2015 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.