mailing list archives
Re: IPV6 in enterprise best practices/white papaers
From: Jay Ashworth <jra () baylink com>
Date: Tue, 29 Jan 2013 14:09:59 -0500 (EST)
----- Original Message -----
From: "Doug Barton" <dougb () dougbarton us>
IPv4 is mature enough that for small to medium sized networks, the
answer is "you plug everything in".
My appraisal of v6 is that it's an order of magnitude (or two) more
complex than that, both in 'attack' surface and interoperability issues.
But, I suppose, it took me a couple years to really learn IPv4 well.
That said, *having* learned IPv4 relatively well, I remain surprised
that there's as much additional (perceived) complexity in v6.
You have perfectly illustrated one of the largest barriers to IPv6
adoption. You of course know that if you were to go into a greenfield
IPv4 deployment the answer would not be "just plug everything in."
Depends on how big your "deployment" is. For a small office -- say, 100
PCs or less; something that will fit in what I will catch schidt for
referring to as a "Class C" :-) -- with a single current generation
consumer market edge NAT router, then yes, in fact, you Just Plug It All
Yes, I realize, that approach does not apply to "being Road Runner". :-)
have to figure out how to split your allocated space (and/or 1918
into reasonable networks, decided which networks get DHCP, assign IP
helpers, carve out p-t-p links, etc. etc. But because you've done that
million times, and all the terminology and factors to consider are
known to you, in effect it amounts to, "just plug everything in."
Well, no, not really. As you note, of course, most of those things
are reflexes for most network engineering types, but certainly they
took a while to get there.
Whereas, with IPv6 you have most, if not all of the same factors to
consider, but there is some marginal added complexity around things like
SLAAC/RA, some different terminology, binary math in hex instead of
octal, network sizes are many orders of magnitude larger, etc. So the
net effect is that even though "under the hood" it's not all that
different, it all feels new and strange. And we all know how humans
react to things that are new and strange. :)
I think "marginal added complexity" is probably a polite understatement;
my apprehension of IPv6 is that they decided they had to fix *lots* of
problems which almost nobody actually had, *in addition* to fixing
the one which actually was a problem: address length.
In consequence of that, IPv6 feels to me like it has a bad case of what
Fred Brooks would call Second System Syndrome.
My point in asking you to provide the equivalent link for IPv4 is to
show that there isn't one, nor could there be. You can't give someone
a cookie-cutter IPv4 network layout because the unique factors that they
have to consider will prevent that. The same is true for IPv6. What you
_can_ do, for both protocols, is to teach people best practices around
the key issues, and help and guidance along the way. There are lots of
lists that exist to do this with v6. One of the best is
ipv6-ops () lists cluenet de If people are interested in learning more
about v6 by osmosis that's a good list to lurk on. It's medium traffic,
but high signal::noise, and any discussions you are not interested in
you can just delete.
You seem to be suggesting, though, to drag the conversation back where
I started it, that there is *so much new stuff* with IPv6 that it's
difficult *even for old hats with IPv4* to learn it by analogy.
If that's what you mean, then I agree with you. :-)
(Yes, yes, I am coming late to this argument; the networks I'm responsible
are historically relatively small. IPv6 connectivity has been troublesome
to acquire except at the last couple.)
Jay R. Ashworth Baylink jra () baylink com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
Re: IPV6 in enterprise best practices/white papaers Jay Ashworth (Jan 28)
Re: IPV6 in enterprise best practices/white papaers Eugeniu Patrascu (Jan 28)
- Re: IPV6 in enterprise best practices/white papaers, (continued)