Internet Edge Router replacement - IPv6 route tablesizeconsiderations

Fri Mar 11 19:22:51 UTC 2011

On Fri, Mar 11, 2011 at 1:07 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> Feel free to explain how SLAAC should work on a /96 with 32 bits of host address
> (or any amount smaller than the 48 bits most MAC addresses provide).  Remember
> in your answer to deal with collisions.

Why should SLAAC dictate the size of *every subnet* on the IPv6
Internet?  This is what people who I label "IPv6 Fundamentalists" wish
to do.  They refuse to admit that their ideas were conceived in the
mid-90s, that technology has advanced a great deal since that time,
and ARP/NDP is a real limit now, while VLSM is no longer a tough
challenge (vendors have had a couple decades to make it work really
well!)

I think there are a lot of people who throw around the SLAAC argument
like it's actually good for something.  Do these people know what
SLAAC does?  For core networks, it doesn't do anything.  For
hosting/datacenter networks and cluster/VPS environments, again, it
doesn't do anything.  Zero benefit.  You probably don't configure
these things using DHCP today.  Wait, you do?  Oh, it's a good thing
we've got DHCPv6, which clearly can run alongside your DHCP for IPv4.

Is SLAAC for end-user access networks?  Not so much.  See recent
discussions on this list about things which are not included in SLAAC
that DHCPv6 does do today.  SLAAC can provide an advantage if you can
live without those things, but that advantage is limited to one thing:
the subnet doesn't need a DHCPv6 server (or proxy/forwarding of
packets to same.)  IPv4 has gotten along just fine for a long time
with both full-featured and light-weight DHCP servers, and statically
configured subnets.  Is SLAAC solving any problem?  Sure, for some
situations, like SOHO networks, it's a nice option, but it's just
that, an option.  It isn't needed.

Is SLAAC for fully peer-to-peer networks, with no central gateway?
No.  To function, SLAAC requires an RA message from something that
decides it is a router.  It isn't going to facilitate a headless,
ad-hoc network to support the next revolution with peer-to-peer cell
phones.

So what we know is that the sole arguments from "IPv6 Fundamentalists"
in favor of /64 LANs are
* VLSM is hard (it isn't; vendors are really good at it now, otherwise
IPv4 wouldn't work)
* SLAAC needs it to work (not all LANs need SLAAC)
* it's the standard (more on this below)

I believe everything except the "it's the standard" argument is fully
and completely debunked.  If anyone disagrees with me, feel free to
correct me, or argue your point until you are blue in the face.  I
have often been reminded that I should have been more vocal about this
matter 10+ years ago, but frankly, I thought vendors, large ISPs,
veterans with more public credibility than myself, or the standards
folks themselves, would have straightened this out a long time ago.

If you can decide for yourself that VLSM is easy and you trust your
vendor to do it right (if you don't, summarize to /64 towards your
core, or do one great thing IPv6 allows us to do, and summarize to
*even shorter* prefixes towards your core, and carry fewer routes in
core) then you are half-way there.

If you realize SLAAC isn't a tool for your VPS farm or on your
backbone link-nets, you're all the way there.

At this point, you can deploy your IPv6 without it being broken by
design.  The only thing broken here is the "Fundamentalists," who are
stuck in a mid-1990s mindset.  These guys need to get out of the way,
because they are impeding deployment (for those smart enough to
recognize this problem) and they are creating an almost certain need
for a future re-design (for those who aren't smart.)  This "future"
doesn't depend on anything except v6 actually getting deployed enough
to where DDoS happens over it at any appreciable scale.

In the current state of the Internet, it is certain that this problem
will happen.  No visible progress has been made on solving it, except
by guys like myself who are happy to cry "the sky is falling,"
configure our networks in a "non-standard" way, and tell the standards
folks they are wrong.  The Cisco knob is "progress" only in that Cisco
recognizes customers are concerned about this problem and allow them
to steer their failure mode.  If the DDoS happens before vendors
provide a real solution, or before standards are revised or thrown
out, you can thank those of us on the "sky is falling" side of this
argument for testing the work-around (by never having exposed
ourselves to the problem in the first place.)

> It's one thing to say "it should be redesigned". It's another matter entirely to actually
> come up with a scheme that doesn't suck even harder than "screw it, it's a /64".

This is true.  I think the price of energy is continuing to rise and
our future is very uncertain as a result.  I don't know how to fix it.
 Does that mean I should keep my opinion to myself?  Of course not.
Recognizing a problem is the first step on the path to a solution.

I imagine the same arguments taking place before VLSM and again before
CIDR, which pre-dates my entry into this field by a few years.  I
don't think most people in our field today understand why the IPv6
standard ended up the way it did.  They haven't been around long
enough to understand the context of IPv6 being developed in what was
truly a different era.

I don't have a better idea for SLAAC, in large part because I do not
care about SLAAC.  I don't think SLAAC should dictate the size of
*every subnet.*  I do think SLAAC should be an *option* available to
those who want it on a given LAN.

I've got three feasible "fixes" to the NDP flooding problem.  One is
dead simple: don't configure /64 LANs.  How hard is that?  It's a lot
easier than the alternatives.

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