I’m running IPv4 ( /16 legacy + /20) and have enough space to last me for a while, multi-homed, BGP4 full tables + peering, ect.
I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.
I want to start building my IPv6 infrastructure.
I have a /32 assigned from ARIN (2001:4918::/32)
I’m looking for some direction/reading list of how to properly configure IPv6. I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 instead. Assign all loopbacks from the same /64, use a different /64 for each loopback. Ect, ect.
I’m trying not to light a religious war but what is the current best practice for IPv6 deployment in a service provider network?
PS. I’ll be at NANOG69 in DC next month, 1st NANOG for me after 22 years.
I’m looking for some direction/reading list of how to properly
configure IPv6. I’ve read to use a /64 for PtP interfaces and I’ve
read use a /128 instead. Assign all loopbacks from the same /64,
use a different /64 for each loopback. Ect, ect.
I’m trying not to light a religious war but what is the current best
practice for IPv6 deployment in a service provider network?
PS. I’ll be at NANOG69 in DC next month, 1st NANOG for me after 22 years.
At the start, the advice was to configure individual /64 for loopbacks, however latterly its assign a /64 for loopbacks and configure /128 instead.
Why do not you feel compelled to ask this question?
Did you ask this question when you deployed ipv4?
AFAIK, everyone deploys ipv4 in a unique way. Same for ipv6. IPv6 is not
exotic or filled with unique pitfalls. A lot of networks have deployed
production networks with ipv6, each one unique, so you don't need to watch
out for that one weird bug ( at least any more than ipv4). So, just like
ipv4, read about the standards, read about vendor implementation that are
close to you, make informed decisions.
My only nugget of advice is to deploy ipv6 in such a way it is not forever
coupled with ipv4. There will be a day when you deploy ipv6 without ipv4,
this day already came for Facebook, Comast, T-mobile and others.
I have not read this, but you may find the discussion helpful
Suggest /128's for loopbacks and /124's for point to points, all from
the same /64. This way you don't burn space needlessly, don't open
yourself to neighbor discovery issues on point to points and can
filter inbound Internet packets to that /64 in one fell swoop so that
it's harder to hit your routers directly. Just make sure not to filter
the outbound packets.
Reminder: No matter what size you pick, use nibble boundaries for
visual and DNS convenience. So /124, not /126.
Suggest /128's for loopbacks and /124's for point to points, all from
the same /64. This way you don't burn space needlessly, don't open
yourself to neighbor discovery issues on point to points
I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point connection and configure a /127 using ::a on one side and ::b on the other. All of these from a block reserved for infrastructure for filtering:
and can
filter inbound Internet packets to that /64 in one fell swoop so that
it's harder to hit your routers directly. Just make sure not to filter
the outbound packets.
Having a single block for infrastructure makes this very easy. In most cases I don't need to worry about "burning space needlessly" so I reserve /64s per point-to-point. Worrying about "wasting" address space is more often an IPv4-ism than good practice with IPv6 IMHO But it all depends on the complexity of your network. There are cases where it makes sense to think about this.
Reminder: No matter what size you pick, use nibble boundaries for
visual and DNS convenience. So /124, not /126.
That's overall good advice. I quibble with a couple of points:
1. If you plan to use a /126 on a point to point and can't imagine how
you would use a /64 on that point to point, don't allocate a /64. Odds
are that by the time you can imagine some way to use a /64 there, the
details will require you to assign a new block anyway.
Why be concerned about resource consumption? Because it's a good
habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
is, but shrewd use of available resources is a good habit even when
resources are plentiful.
2. Make all your point to points /124. That will work for all your
point to points. Serial or ethernet. Even the ethernets which have two
high-availability routers on both ends along with the failover address
needing a total of 6 IPs plus 1 for your troubleshooting laptop.
Configuring /124 every time allows you to standardize your
configuration, the same way /64 standardizes the netmask on a LAN
deployment.
One additional point not brought up:
Minimum assignment to a customer: /60. Never ever /64 or /128. How
much more than a /60 you choose as your minimum is up to you. Common
choices are /56 and /48. But never, ever less than a /60. Your
customer will want to deploy a /64 to each LAN. And there are so many
cases where he'll want to deploy more than one LAN.
I've noticed a lot of hosting providers getting this wrong. Some of
your customers do create VPNs on their VPC you know.
The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors. Just do it. The numbers in IPv6 are staggering. The generally accepted best practice is to allocate a /64 and use a /128 within that /64 for point to point links.
The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors.
Hi Matthew,
I'm always interested in learning something new. Please explain the
DOS vectors you're referring to and how they're mitigated by
allocating a /64 to the point to point link.
Just do it.
No. But if you offer a good reason, I'll factor your reason in to my
considerations.
The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors.
if you mean allocating a /127, then... sure.
Neighbor discovery on point to point links could be a problem as is the
poential for looping behavior . There are of course ways other than
allocating a longer prefix to a point to point link to achieve that,
e.g. disabling it. among other things You have to disable DAD anyway if
you ever plan to loop them up for testing.
Please check the nanog archives. There were some arguments that I and I assume others felt compelling why allocating a /64 per point to point link was a good idea. Your network, your rules. I was just responding to the argument that a /64 is wasteful and serves little purpose.
IIRC, the problem was that some routers could only fit the first 64
bits in the TCAM so routes longer than /64 fell out of the fast path.
That was about half a decade ago. No idea if anything modern still
suffers from this.
That would impact every route in Matthew's proposed solution: the
loopbacks from the infrastructure /64 and the /127's from otherwise
unpopulated /64's. Because programmatically those /64's don't have one
prefix, they have two: the /127 for the link and the implicit null
route for everything else. The router has to honor the implicit null
route so it can't aggregate the /127 to /64 and keep it in the fast
path.
