Not an IPv6 newbie by any stretch, but we still aren’t doing it “at scale” and some of you are, so…
For a very small & dense (on 128-bit scales, anyway) network, is RFC3531 still the last word in IPv6 allocation strategies?
Right now, we’re just approaching it as “pick the next /64 in the range”, as it all gets aggregated at the BGP border anyway, and internally if I really try hard, I might get to 200 subnets someday.
Is there any justification for the labour in doing something more complex like center-allocation in my situation? Worrying about allocation strategies seems appropriate to me if you have 100,000 subnets, not 100.
Opinions wanted, please.
-Adam
Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
Chat with me on Teams
Not an IPv6 newbie by any stretch, but we still aren’t doing it “at scale” and some of you are, so…
For a very small & dense (on 128-bit scales, anyway) network, is RFC3531 still the last word in IPv6 allocation strategies?
Right now, we’re just approaching it as “pick the next /64 in the range”, as it all gets aggregated at the BGP border anyway, and internally if I really try hard, I might get to 200 subnets someday.
Is there any justification for the labour in doing something more complex like center-allocation in my situation? Worrying about allocation strategies seems appropriate to me if you have 100,000 subnets, not 100.
Opinions wanted, please.
-Adam
Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
Chat with me on Teams
I may have mis-read it (I admit I didn’t read it all that carefully) but I think RFC3531 is talking about the strategy for assigning /64s out of a larger pool (a /56, say).
-Adam
Say you have a point of presence (pop) where you serve customers,
allowing each a /56. You assign a /48 to the pop and route the /48 to
the pop rather than routing each /56 individually. Later on you get
more than 256 customers. RFC3531 says you should assign the /48 in
such a way that more often than not you can expand it to /44 without
renumbering instead of assigning another /56 and consuming another
slot in your routing table. The motivation is saving that slot in your
routing table while also avoiding renumbering the subnets already
assigned there.
If you're the customer with the /56, RFC3531 doesn't make much sense.
Your routing table cost is nil and it's desirable to preserve as large
a block in the /56 as possible as long as possible so that you don't
have to ask for more, something the ISP may or may not grant your
class of service.
And of course RFC3531 presumes a hierarchy in your network which is
not necessarily true.
Regards,
Bill Herrin
Hello,
The minimum addressable on a LAN is a /64. So you have to provide the customer with a larger subnet.
Public operators in France generally deliver a /60.
The RFC gives /56, however, as customers are mobile and there is a risk of disaggregating into PAs (or rather allowing the customer to keep his IPs, such as DID portability), we, as operators, supply /48s directly.
Talking about the number of IPs that can be assigned in IPv6 shows a lack of understanding of IPv6. It’s time to get trained!
My 2 cents,
Nicolas VUILLERMET
Network Engineer… and IPv6 ready.
Understood, yes, but I should have been more clear: I’m talking about statically allocating my own internal /64s out of the /56 I’ve reserved for my org’s own use. Is there any point in using a more complex scheme than just “next!” ?
-Adam
Read about EUI-64 that is now legacy, you will understand why.
The minimum (and maximum) subnet mask for a LAN in which -all- of
IPv6's technologies work right is /64. If you don't require stateless
autoconfiguration or automatic link-local addresses, you can pick any
subnet mask you want. In most cases it's desirable to have a size of
/64. In a few cases it's not.
Short version: use /64 as your IPv6 LAN subnet mask unless you clearly
understand the consequences of not doing so and intentionally want
them.
Regards,
Bill Herrin
A /64 is not "enough" period. Each IPv6 /64 should be thought of as
the same as an IPv4 /32.
The RFC is still relevant. You are able to be allocated IPs
justifying 8-bits per customer
(/56) and customers should expect that /56 be the minimum delegated by
their providers.
The prefix delegation for IPv6 is based on number of separate /64
subnets they might have a reason
to use (which can be for many reasons including security and division
of traffic and use cases),
Not number of individual hosts they may have, since subnet divisions
more granular than
/64 are not possible.
Jay,
Each IPv6 /64 should be thought of as the same as an IPv4 /32? That seems a tad wasteful. A single /64 has billions of times more addresses than the entire IPv4 address space. It is enough for any conceivable subnet. There are also billions of /56 prefixes available, so no ISP customer would ever exhaust those either. A customer can get as many /56s as they need.
The RFC seems to be concerned with aggregation efficiency, and while that may be a concern someday, so far computer and memory capacity has far outstripped prefix growth in the default-free zone.
If you can explain why a /64 would ever not be enough for a single subnet, I’m willing to listen.
-mel
The subnet contains a router that gateways to another /64. For
example, there's a home automation controller and the controller
implements its own lan of components on a different media type.
Instead of assigning a pair of /64's, you assign a /63 and then route
a /64 from the /63 to the home automation controller.
Except you don't do that either. IPv6 is plentiful and reverse-DNS
delegates cleanly on 4-bit boundaries so you think in terms of 4-bit
boundaries instead: assign a /60, use a /64 on the immediate LAN and
route a /64 to the home automation controller and retain the balance
for the next device that wants to implement an internal subnet.
Regards,
Bill Herrin
Bill,
I would just make it /64s all the way down. Subnetting a /64 is like taking half-breaths from a snorkel: why bother when the supply is effectively infinite?
-mel