Eugeniu Patrascu wrote:
As being personally involved deploying IPv6 on an enterprise network,
here's how I did it (keeping in mind the fact that we have our own
ASN):
I suggest this be step 0
- get a /48 PI from the local LIR
And this be step 1
Hopefully that did not included filtering ICMPv6? 
Can you show me the equivalent link for "I want to implement IPv4 on my network"?
Eugeniu Patrascu wrote:
As being personally involved deploying IPv6 on an enterprise network,
here's how I did it (keeping in mind the fact that we have our own
ASN):I suggest this be step 0
Yes.
- get a /48 PI from the local LIR
And this be step 1
No, this is step 2 and /48 is not necessarily the right answer.
Step 1 is to evaluate your network and figure out your addressing needs.
If you have a single corporate office and are not an ISP, then /48 is fine.
If you have multiple locations, then a /48 per location is more appropriate.
If you are an ISP, then you need to look at a more involved address planning exercise.
Owen
> I thought about running pure IPv6 inside and do 6to4, but it's too
> much of a headache,
Does an L2 switch really care about IPv6? (except for stuff like DHCPv6
snooping, etc?)
For management it does care. NO ipv4 is NO ipv4. As in not even
management addresses.
Also, if a switch does not do MLD snooping, it will flood multicast to
all ports. You lose one of the major benefits of IPv6 multicast - less
admin traffic.
You need to spec new switches with IPv6 capability.
Regards, K.
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.
Cheers,
-- jra
Jay,
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." You'd
have to figure out how to split your allocated space (and/or 1918 space)
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 a
million times, and all the terminology and factors to consider are well
known to you, in effect it amounts to, "just plug everything in."
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.
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.
hth,
Doug
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
In.
Yes, I realize, that approach does not apply to "being Road Runner".
You'd
have to figure out how to split your allocated space (and/or 1918
space)
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
a
million times, and all the terminology and factors to consider are
well
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.)
Cheers,
-- jra
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"
generation consumer market edge NAT router, then yes, in fact, you
Just Plug It All In.
Well sure, but the same would be true for the equivalent IPv6 deployment.
Yes, I realize, that approach does not apply to "being Road Runner".
You'd have to figure out how to split your allocated space (and/or
1918 space) 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 a million times, and all the terminology
and factors to consider are well 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.
Yes, that's precisely my point. No one learned IPv4 networking
overnight. But people who already know IPv4 are complaining that they
can't magically come to the same degree of competence with IPv6 without
spending any time to learn it. The irony is that people who already know
"networking" will have a much easier time learning IPv6, with a minimal
amount of extra work, but minimal != zero.
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;
No, it really isn't. I realize that the IPv6 zealots hate it when I say
this, but in many ways you can treat IPv6 just like IPv4 with bigger
addresses.
1. Don't filter ICMPv6.
2. Treat a /64 roughly the way you'd treat a /24 in IPv4.
3. Put SLAAC on the networks you have DHCPv4 on.
4. Statically assign addresses and networks for v6 on the systems you
statically assign them on v4 (servers, etc.)
5. Neighbor Discovery (ND) replaces arp, but mostly you don't every need
to worry about it (just like you hardly ever need to worry about arp).
Voila! You've just learned 80% of what you need to know to be successful
with IPv6.
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.
Your assessment is correct, but the good news is that you can ignore
almost all of it. The "SLAAC vs. full-featured DHCPv6" thing is still
kind of a PITA, but it's working itself out. Beyond that, if there is a
feature of IPv6 that you're not interested in, don't use it.
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.
No, quite the opposite. What I'm saying is that if you already
understand how to run a network with v4 that learning the v6 terminology
and equivalent concepts, plus the few extra things that you actually do
need to manage for v6, is not that difficult. It just *seems* hard
because before you tackle it, it's all new and strange.
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.)
Roger that. Not that I'm trying to toot my own horn, but most of my
experience has been with large enterprise networks, often spanning
multiple continents, so I tend to think in those terms. The good news
for smaller shops is that if you can get it, IPv6 is pretty much "just
plug it in," very similar to how you described IPv4 for a smaller shop
above.
Doug
From: "Doug Barton" <dougb@dougbarton.us>
> 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"
> generation consumer market edge NAT router, then yes, in fact, you
> Just Plug It All In.Well sure, but the same would be true for the equivalent IPv6
deployment.
Is that in fact true? My takeaway from watching NANOG the last 8 years
is that it doesn't always work like that.
> 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.Yes, that's precisely my point.
overnight. But people who already know IPv4 are complaining that they
can't magically come to the same degree of competence with IPv6 without
spending any time to learn it. The irony is that people who already
know "networking" will have a much easier time learning IPv6, with a
minimal amount of extra work, but minimal != zero.
Well, this it my point. My integration of the questions I see, and
the problems I had trying to even get a first tier grasp of it myself
is that I *expect* leverage from understanding v4 which I did not
in fact *get*; enough stuff has changed at a fundamental level that
my v4 knowledge isn't all that helpful.
> I think "marginal added complexity" is probably a polite
> understatement;No, it really isn't. I realize that the IPv6 zealots hate it when I say
this, but in many ways you can treat IPv6 just like IPv4 with bigger
addresses.1. Don't filter ICMPv6.
2. Treat a /64 roughly the way you'd treat a /24 in IPv4.
3. Put SLAAC on the networks you have DHCPv4 on.
4. Statically assign addresses and networks for v6 on the systems you
statically assign them on v4 (servers, etc.)
5. Neighbor Discovery (ND) replaces arp, but mostly you don't every need
to worry about it (just like you hardly ever need to worry about arp).Voila! You've just learned 80% of what you need to know to be
successful with IPv6.
Great, and now you've answered the OPs question.
So where, in fact, *is* the IPv6 primer that says that stuff, with
enough backfill that you can do the further research about how and
why?
> In consequence of that, IPv6 feels to me like it has a bad case of
> what Fred Brooks would call Second System Syndrome.Your assessment is correct, but the good news is that you can ignore
almost all of it. The "SLAAC vs. full-featured DHCPv6" thing is still
kind of a PITA, but it's working itself out. Beyond that, if there is
a feature of IPv6 that you're not interested in, don't use it.
Hmmm...
> 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.No, quite the opposite. What I'm saying is that if you already
understand how to run a network with v4 that learning the v6 terminology
and equivalent concepts, plus the few extra things that you actually
do need to manage for v6, is not that difficult. It just *seems* hard
because before you tackle it, it's all new and strange.
Hmmm ^ 2.
> (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.)Roger that. Not that I'm trying to toot my own horn, but most of my
experience has been with large enterprise networks, often spanning
multiple continents, so I tend to think in those terms. The good news
for smaller shops is that if you can get it, IPv6 is pretty much "just
plug it in," very similar to how you described IPv4 for a smaller shop
above.
You haven't tried to *buy* IPv6 edge transit, have you?
Has that gotten any easier than "months later, nobody has the first
clue what I'm talking about"?
Cheers,
-- jra
*cough*Implementation detail*cough*
Also, if a switch does not do MLD snooping, it will flood multicast to
all ports. You lose one of the major benefits of IPv6 multicast - less
admin traffic.
Agreed; but just to be fair: there is still a difference between
multicast being flodded everywhere and boradcast being flooded
everywhere ... L2 interrupt vs. L2+L3 interrupt; bigger difference
than it sounds ;).
/TJ
Not sure if anyone mentioned Aaron's presentation on this topic
from way back... Here's the link:
John Kemp (kemp@routeviews.org)
I hadn't, but now that I have, my opinion is "it's like most presentation
decks: if you don't already understand what they're talking about, then
you need the actual presentation to go with it".
It's also biased a bit higher in the stack than I live, but that's not
the presentation's fault, given it's target audience.
Cheers,
-- jra
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;No, it really isn't. I realize that the IPv6 zealots hate it when I say
this, but in many ways you can treat IPv6 just like IPv4 with bigger
addresses.
I'm a pretty well known IPv6 zealot and I completely agree with you.
1. Don't filter ICMPv6.
2. Treat a /64 roughly the way you'd treat a /24 in IPv4.
Actually, I'd say treat a /64 roughly the way you'd treat any sized subnet
in IPv4, whether it's a /24, a /31, or something in between or even a really
large IPv4 single network such as a /22.
If it's an IPv4 /32, then think IPv6 /128.
3. Put SLAAC on the networks you have DHCPv4 on.
4. Statically assign addresses and networks for v6 on the systems you
statically assign them on v4 (servers, etc.)
5. Neighbor Discovery (ND) replaces arp, but mostly you don't every need
to worry about it (just like you hardly ever need to worry about arp).Voila! You've just learned 80% of what you need to know to be successful
with IPv6.
Agreed. The remainder has to do with:
1. Understanding and configuring RDNSS support if you're going to use SLAAC.
2. Understanding and configuring DHCPv6 if you want to use that.
3. Managing AAAA records and dealing with ip6.arpa (nearly identical to A and in-addr.arpa)
4. IPv6 routing protocols (if you are in a larger environment)
5. Security policies that are more complex than simply default-deny-all-inbound/permit-outbound.
There's really not a whole lot else one needs to learn for most environments.
No, quite the opposite. What I'm saying is that if you already
understand how to run a network with v4 that learning the v6 terminology
and equivalent concepts, plus the few extra things that you actually do
need to manage for v6, is not that difficult. It just *seems* hard
because before you tackle it, it's all new and strange.
I 100% agree with this summary.
Owen
It doesn't, I was talking about management IP addresses (for example
HP2510 only uses IPv4 management addresses).
Eugeniu
No, of course not
I did a bit (actually very little) of reading about IPv6 before doing
all that, but nothing compares to the actual implementation when you
discover the quirks each vendor has in that regard :))
Eugeniu
Yes, I know this is the rule, but right now we only have one location,
so I got only a /48.
One thing that I missed in my first e-mail, was to say that for each
subnet I allocated a /64 as it works with most equipment and no funky
netmasks.
One of my ISPs is running /126 netmask on the border links and the
other runs /64 - probably a matter of preference by their network
admins.
Eugeniu