Internet Edge Router replacement - IPv6 route tablesizeconsiderations

Fri Mar 11 23:33:42 UTC 2011

On Mar 11, 2011, at 5:53 AM, Jeff Wheeler wrote:

> 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.
> 
Yes, you can bring as much of the pain from IPv4 forward into IPv6
as you like. You can also commit many other acts of masochism.
Personally, I prefer to approach IPv6 as a way to reduce some of
the more painful aspects of IPv4, such as undersized subnets,
having to renumber or add prefixes for growth, limited aggregation,
NAT, and more.

>> 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.
> 
SLAAC is a very useful and convenient way to deal with client
networks. I would agree it's of limited use in a content provider
scenario, but, there is utility to /64s beyond just SLAAC. Yes, they
are a hard requirement for SLAAC.

>> 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.
> 
As someone using SLAAC in a number of environments, I'm confused
by this statement. It seems to be working quite well in many places
and end-user residential networks are certainly not the only places
where it is useful.

Yes, residential end-user CPE is rather limited and somewhat less
than ideal today. I would argue that there are probably at least as
many end-user hosts on non-residential networks that could
take advantage of SLAAC if the administrators wanted to.

> 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.
> 
What do your access routers have to do with your content farm?
Sounds like you've got some pretty darn small access routers as well
if they can't handle 64k NDP entries. Yes, larger tables in switches
would be a good thing, but, I hardly think that's a reason to use
smaller netmasks.

Most of the top-of-rack switches I'm aware of have no problem doing
at least 64k NDP/ARP entries. Many won't do more than that, but,
most will go at least that far.

>> 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.)
> 
How many customers are using smaller-than-/64 subnets to do much
of anything yet?

I find it interesting that you _KNOW_ that /64 LANs will cause you DoS
problems and yet we've been running them for years without incident.

I believe growing the subnet still requires you to touch every machine
unless they're getting all their configuration from DHCP. Again, sounds
like an exercise in unnecessary masochism to me.

> 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.
> 
Yeah, in-between makes little sense. Kind of worst of both worlds.
On that we can at least agree. As to your /96, that's 4.3B, not 4.3M.
(at least last I looked, 2^32 was 4.3B and 4.3M was approximately
a /114).

>> 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.)
> 
There are several things that could eventually be implemented in the
access switch software. Techniques like rapidly timing out unanswered
NDP requests, not storing ND entries for SLAAC MAC-based suffixes
(after all, the information you need is already in the IP address, just
use that). Not storing ND entries for things that don't have an entry
in the MAC forwarding table (pass the first ND packet and if you
get a response, create the ND entry at that time), etc.

Yes, these all involve a certain amount of changing some expected
behaviors, but, those changes could probably be easily accommodated
in most environments.

Finally, the bottom line is that a rogue host behind your firewall
is probably going to cause other forms of damage well before
it runs you out of ND entries and any time you have such a thing,
it's going to be pretty vital to identify and remove it as fast as
possible anyway.

> 
> 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.
> 
They are entirely optional, but, IMHO, avoiding them at all costs
such as you seem to be suggesting is unnecessarily painful in
most environments.

>> 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.

I'd settle for Cisco coming to the point of having RA guard
universally available on all switch products. That, to me,
is a much more pressing issue than this imagined ND
exhaustion attack which, in reality, requires near DDOS
levels of traffic for most networks to actually run the ND
table meaningfully into overflow.

Owen