Internet Edge Router replacement - IPv6 route tablesizeconsiderations

Jeff Wheeler jsw at inconcepts.biz
Fri Mar 11 13:53:51 UTC 2011


On Thu, Mar 10, 2011 at 10:51 PM, George Bonser <gbonser at seven.com> wrote:
> And I say making them /127s may not really make any difference.  Say you
> make all of those /127s, at some point you *are* going to have a network
> someplace that is a /64 that has hosts on it and that one is just as
> subject to such an attack.  If you are a content provider, it doesn't
> make any difference if they take down the links between your routers or
> if they take down the link that your content farm is on.  The end result
> is the same.  You have managed to re-arrange the deck chairs.  Have
> another squeeze at that water balloon.

Again, this is the argument put forth by the "RFC wavers," that you
can't solve the problem because you must want to configure /64s for
... what, exactly?  Oh, right, SLAAC.  More on that below.

If I'm a content provider, I don't have to configure a /64 for my
content farm.  I can configure a /120 or whatever subnet size is
practical for my environment.  I can also use link-local addressing on
my content farm LANs and route subnets to my content boxes, if that is
somehow more practical than using a smaller subnet.

> If you are a service provider where practically all of your links are
> point to points, sure.

No, you can avoid configuring /64s if you don't need SLAAC.  Who needs
SLAAC?  I don't.  It has absolutely no place in any of my
environments.  It seems to me that DHCPv6 will do everything which
SLAAC does, and everything SLAAC forgot about.  The "complexity"
argument is pretty much indefensible when the trade-off is configuring
DHCPv6 vs turning a bunch of router knobs and hoping no one ever
targets your LANs with an NDP DoS.

> We didn't need much more host addressing, we needed more subnet
> addressing.  I would have settled for 16 bits of host addressing and 112
> bits of subnet addressing and I suppose nothing prevents me from doing
> that except none of the standard IPv6 automatic stuff would work
> anymore.

None of that "standard IPv6 automatic stuff" works today, anyway.  The
state of IPv6 support on end-user CPE generally ranges from
non-existent to untested to verified-to-be-broken.  This is the only
place in your network where /64 can offer any value, and currently,
CPE is just not there.  Even the latest Cisco/Linksys CPE does not
support IPv6.  Sure, that'll change; but what won't change is the
total lack of any basis for configuring /64 LANs for "content farms"
or any similar non-end-user, non-dynamic segments.

I don't want 16 bits of host addressing.  I want to choose an
appropriate size for each subnet.  Why?  Because exactly zero of my
access routers can handle 2**16 NDP entries, let alone 2**16 entries
on multiple interfaces/VLANs.  I would like to see much larger ARP/NDP
tables in layer-3 switches, and I think vendors will deliver on that,
but I doubt we'll soon see even a 10x increase from typical table
sizes of today.  VPS farms are already pushing the envelope with IPv4,
where customers are already used to conserving addresses.  Guess what,
customers may still have to conserve addresses with IPv6, not because
the numbers themselves are precious, but because the number of ARP/NDP
entries in the top-of-rack or distribution switch is finite.

> And again, are you talking about all the way down to the host subnet
> level?  I suppose I could configure server farms in /112 or even /96
> (/96 has some appeal for other reasons mostly having to do with
> multicast) but then I would wonder how many bugs that would flush out of
> OS v6 stacks.

I'm not getting reports of problems with smaller-than-/64 subnets from
customers yet.  Am I confident that I never will?  No, absolutely not!
 Like almost everyone else, I have some customers who have configured
IPv6, but the amount of production traffic on it remains trivial.
That is why I allocate a /64 but provision a /120 (or similar
practical size.)  I can grow the subnet if I have to.  I do know that
/64 LANs will cause me DoS problems, so I choose to work around that
problem now.  If /120 LANs cause me OS headaches in the future, I have
the option to revise my choice with minimal effort (no services get
renumbered, only the subnet must grow.)

Why would you suggest /96 as being more practical than /64 from the
perspective of NDP DoS?  Again, this is an example of the "in-between"
folks in these arguments, who seem not to fully understand the
problem.  Your routers do not have room for 2**(128-96) NDP entries.
Typical access switches today have room for a few thousand to perhaps
16k, and typical "bigger" switches are specifying figures below 100k.
This doesn't approach the 4.3M addresses in a /96.  In short,
suggesting /96 is flat out stupid -- you get "the worst of both
worlds," potential for OS compatibility issues, AND guaranteed NDP DoS
vulnerability.

> passing traffic. That doesn't protect against rogue hosts but there
> might be ways around that, too, or at least limiting the damage a rogue
> host can cause.

How do you suggest we limit the damage a rogue host can cause?  A lot
of people would like to hear your idea.  Again, in nearly ten years of
discussing this with colleagues, I have not seen any idea which is
more practical than configuring a /120 instead of a /64.  I have not
seen any idea, period, which doesn't involve configuring the IPs which
are allowed to be used on the LAN, either on the access switch port
(NDP inspection), the access router, or in a database (like RADIUS.)

This kind of configuration complexity is exactly what SLAAC hoped to
avoid.  Unfortunately, the folks who thought that up did so at a time
when most access routers were still routing in CPU and main memory,
not ASIC.  It's important to understand how the underlying technology
has changed in the past 15+ years -- if you don't, you must think,
"man, those IPv6 standards guys were idiots."  They weren't idiots,
but they didn't know how routing and switching hardware would evolve,
certainly they did not know how long it would take IPv6 to be deployed
(it still isn't, effectively), and they probably didn't consider the
potential future where DDoS is rampant and virtually unchecked to be a
good reason not to craft SLAAC into the standards.  They were also
coming out of an era where CIDR/VLSM was still kinda new, and I
believe there were *zero* boxes at that time which could "route" at
wire speed, vs many boxes that would switch at wire speed, thus there
were perceived advantages to having fewer, bigger subnets with no
requirement for VLSM.

Remember when there was no such thing as a layer-3 switch, and
installing an RSM in your Cat5500 to get a little bit of routing
capability was the greatest thing since sliced bread?  This is where
IPv6 came from, and it is why we have these design problems today --
the standards people are ideologically married to ideas that made
perfect sense in the mid-90s, but they forgot why those ideas made
sense back then and don't understand why this is not practical today.

I'm glad SLAAC is an option, but that's all it is, an option.  /64
LANs must also be considered optional, and should be considered useful
only when SLAAC is desired.

> Something will have to be done at some point ... soon.

I'm glad more people are coming around to this point of view.  Cisco
certainly is there.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts




More information about the NANOG mailing list