WEBVTT

0:00:08.480000 --> 0:00:14.220000
 Okay, our last topic here under transition
 mechanisms is going to just

0:00:14.220000 --> 0:00:16.640000
 be talking about running
 dual stack.

0:00:16.640000 --> 0:00:22.700000
 So obviously with the tunnels, it was
 about connecting islands of IPv6

0:00:22.700000 --> 0:00:27.360000
 over an IPv4 infrastructure
 in the middle.

0:00:27.360000 --> 0:00:34.240000
 Dual stack is simply the idea and I think,
 again, a little bit of my personal

0:00:34.240000 --> 0:00:38.500000
 opinion here, this is where we're
 going to be for a long time.

0:00:38.500000 --> 0:00:44.300000
 We're not going to be turning off IPv4
 anytime real soon, I don't think.

0:00:44.300000 --> 0:00:49.360000
 And there's been some discussion of
 NAT and some platform support, you

0:00:49.360000 --> 0:00:53.820000
 know, six to four NAT, and there's been
 NAT PT, and there's been a couple

0:00:53.820000 --> 0:00:56.320000
 ways of doing NAT.

0:00:56.320000 --> 0:00:59.200000
 And honestly, they really just
 don't want you doing that.

0:00:59.200000 --> 0:01:02.860000
 Most of them have been deprecated
 and they have issues.

0:01:02.860000 --> 0:01:06.340000
 And, you know, at the end of the day,
 what you've got to remember is this,

0:01:06.340000 --> 0:01:09.340000
 it's what I said way back
 in the introduction topic.

0:01:09.340000 --> 0:01:12.000000
 Okay, NAT was a crutch.

0:01:12.000000 --> 0:01:15.600000
 We're not supposed to
 use it with IPv6.

0:01:15.600000 --> 0:01:19.160000
 Some people are having a hard time letting
 it go because of some illusion

0:01:19.160000 --> 0:01:23.540000
 that it's a security mechanism.

0:01:23.540000 --> 0:01:29.200000
 My statement to that is whether it
 is or is not a thin, small, little

0:01:29.200000 --> 0:01:34.540000
 sheet of security, your firewall needs
 to be able to protect you with

0:01:34.540000 --> 0:01:37.740000
 or without NAT. It's that simple.

0:01:37.740000 --> 0:01:41.340000
 And if it doesn't, then maybe
 it's time for a new firewall.

0:01:41.340000 --> 0:01:46.780000
 So, you know, NAT technically should
 be in a transition mechanism.

0:01:46.780000 --> 0:01:50.920000
 I'm not even going to go over it because
 you really just shouldn't be

0:01:50.920000 --> 0:01:54.860000
 doing it. There is documentation
 out there to do it.

0:01:54.860000 --> 0:01:59.020000
 And I have a couple sample configs of
 six to four NAT and such like that.

0:01:59.020000 --> 0:02:04.320000
 A lot of the platforms don't
 even support NAT 64 yet.

0:02:04.320000 --> 0:02:06.220000
 They just support NAT PT.

0:02:06.220000 --> 0:02:11.280000
 NAT PT has major security issues, which
 is, I think, ironic since people

0:02:11.280000 --> 0:02:13.880000
 want it to help with security,
 so to speak.

0:02:13.880000 --> 0:02:16.900000
 And then it has security
 issues, sort of funny.

0:02:16.900000 --> 0:02:23.300000
 But in any case, I think the choice we're
 going to be at for 99% of implementations

0:02:23.300000 --> 0:02:26.620000
 out there is we're just going
 to be running them both.

0:02:26.620000 --> 0:02:31.580000
 You're going to be supporting IPv4 and
 IPv6 at the same time on all the

0:02:31.580000 --> 0:02:37.100000
 devices. And honestly, we've been doing
 that this entire bootcamp, this

0:02:37.100000 --> 0:02:43.860000
 entire class. Because every single lab
 that we've gone into, every time

0:02:43.860000 --> 0:02:47.580000
 I've gone into the config, IPv4 has
 been running underneath all of this.

0:02:47.580000 --> 0:02:50.400000
 We've used it for a couple things in
 fact, so you've seen some of it,

0:02:50.400000 --> 0:02:54.140000
 maybe not all of it, but you saw some
 of it as we went through the different

0:02:54.140000 --> 0:02:59.360000
 lessons. So, you know, they're basically
 what I like the term, you know,

0:02:59.360000 --> 0:03:01.640000
 people refer to them as
 ships in the night.

0:03:01.640000 --> 0:03:04.720000
 The two protocols really have
 nothing to do with each other.

0:03:04.720000 --> 0:03:07.900000
 We were doing all sorts of
 crazy stuff with IPv6.

0:03:07.900000 --> 0:03:15.200000
 Meanwhile, IPv4 was sitting underneath,
 all running OSPF, area zero, everywhere,

0:03:15.200000 --> 0:03:16.740000
 and that was the end of it.

0:03:16.740000 --> 0:03:23.340000
 Meanwhile, in IPv6, we're running RipNG
 and BGP and EIGRP and OSPF and

0:03:23.340000 --> 0:03:26.120000
 redistributing and
 all this nonsense.

0:03:26.120000 --> 0:03:31.000000
 And IPv4 was sitting under there going,
 what is all that nonsense up there?

0:03:31.000000 --> 0:03:32.140000
 No, of course it wasn't.

0:03:32.140000 --> 0:03:33.860000
 It has nothing to do with it.

0:03:33.860000 --> 0:03:40.200000
 Okay. Now, and again, that's another
 reason why not just, oh, it just

0:03:40.200000 --> 0:03:41.360000
 becomes a problem.

0:03:41.360000 --> 0:03:44.120000
 Now you're intertwining the
 two protocols and stuff.

0:03:44.120000 --> 0:03:46.360000
 It's just, it's really
 does not good.

0:03:46.360000 --> 0:03:52.600000
 Separate protocols run them
 both during the interim.

0:03:52.600000 --> 0:03:56.760000
 For areas where you can't run IPv6,
 well, we just came through, all the

0:03:56.760000 --> 0:04:02.580000
 tunneling mechanisms, all the ways
 that we can get IPv6 over that IPv4

0:04:02.580000 --> 0:04:04.700000
 infrastructure. Okay.

0:04:04.700000 --> 0:04:06.080000
 So this is what we were
 just saying, right?

0:04:06.080000 --> 0:04:09.020000
 Both infrastructures
 completely isolated.

0:04:09.020000 --> 0:04:12.760000
 That way, if you completely break your
 IPv6 or it blows up, you're not

0:04:12.760000 --> 0:04:15.880000
 going to hurt your exist, I mean, unless
 you really do something bad,

0:04:15.880000 --> 0:04:18.980000
 I guess, crash or router
 or something doing it.

0:04:18.980000 --> 0:04:24.900000
 But it won't, you know, directly
 affect anything you do in IPv4.

0:04:24.900000 --> 0:04:27.560000
 Okay. That's the plus.

0:04:27.560000 --> 0:04:30.200000
 Here's the downside.

0:04:30.200000 --> 0:04:36.000000
 At the end of the day, you're basically
 now supporting two networks.

0:04:36.000000 --> 0:04:40.500000
 One running IPv4 and
 one running IPv6.

0:04:40.500000 --> 0:04:45.820000
 Okay. And one more thing about transition
 and dual stack and all of this,

0:04:45.820000 --> 0:04:47.480000
 because I hear this a lot.

0:04:47.480000 --> 0:04:52.280000
 Well, how am I going to design
 my IPv6 network and all this?

0:04:52.280000 --> 0:04:56.320000
 And a lot of times I'll look at people
 and I just love to ask this question

0:04:56.320000 --> 0:05:01.300000
 because I'm just like, well, oh, what
 I'll look at and I'll say, well,

0:05:01.300000 --> 0:05:03.600000
 what's wrong with
 your IPv4 network?

0:05:03.600000 --> 0:05:06.620000
 Well, well, nothing.

0:05:06.620000 --> 0:05:10.580000
 But, you know, but we're supposed
 to be moving towards IPv6.

0:05:10.580000 --> 0:05:15.720000
 Okay. But you were saying that your
 IPv4 network is well designed and

0:05:15.720000 --> 0:05:18.560000
 it works well. Well, yeah.

0:05:18.560000 --> 0:05:21.900000
 Then why are you looking
 to redesign it?

0:05:21.900000 --> 0:05:26.760000
 Why can't you build IPv6 exactly the
 same way as your IPv4 network is

0:05:26.760000 --> 0:05:29.380000
 today? Same subnets.

0:05:29.380000 --> 0:05:34.020000
 Yes, you probably want to do it in hex
 instead of decimal, you know, whatever.

0:05:34.020000 --> 0:05:36.540000
 Okay. But you can still
 subnet it the same way.

0:05:36.540000 --> 0:05:38.900000
 You're not going to have to
 redesign your whole network.

0:05:38.900000 --> 0:05:44.260000
 Now, every once in a while, and I have
 a couple of friends of mine who

0:05:44.260000 --> 0:05:47.160000
 gave me this answer, and I'm like,
 yeah, by the way, don't call me.

0:05:47.160000 --> 0:05:52.280000
 No, but seriously, you know, sometimes
 you get the flip side of that,

0:05:52.280000 --> 0:05:56.740000
 which is the, oh my goodness, our network
 looks like it was designed by

0:05:56.740000 --> 0:05:58.300000
 chip monks or something.

0:05:58.300000 --> 0:05:59.740000
 I don't know. I don't know.

0:05:59.740000 --> 0:06:01.180000
 Maybe chip monks would do better.

0:06:01.180000 --> 0:06:03.460000
 That probably wasn't fair to chip monks
 because I've seen some really

0:06:03.460000 --> 0:06:05.240000
 bad networks out there.

0:06:05.240000 --> 0:06:09.020000
 Some of the points that you're sitting
 there going, how does this even

0:06:09.020000 --> 0:06:15.800000
 work, you know, networks where, you
 know, discontinuous subnets just all

0:06:15.800000 --> 0:06:20.080000
 over the place? And I mean, truth be
 told, it's not usually anybody's

0:06:20.080000 --> 0:06:25.100000
 fault. It's usually the network
 grew out, grew over time.

0:06:25.100000 --> 0:06:28.940000
 And when it started out, nobody sat
 around and said, okay, so if this

0:06:28.940000 --> 0:06:34.040000
 was going to become, you know, a 4
,000 site global network, how should

0:06:34.040000 --> 0:06:37.260000
 we design this? Let's
 start with that.

0:06:37.260000 --> 0:06:38.660000
 Nobody built it.

0:06:38.660000 --> 0:06:40.060000
 They said, oh, yeah,
 we got this network.

0:06:40.060000 --> 0:06:41.340000
 Okay, we got it running.

0:06:41.340000 --> 0:06:43.280000
 Oh, wait, now we bought
 this little company.

0:06:43.280000 --> 0:06:46.220000
 Well, now we got to bring them in and,
 oh, now we brought this over here

0:06:46.220000 --> 0:06:49.340000
 and look, it happens gradually
 over the time.

0:06:49.340000 --> 0:06:55.880000
 So I guess what I'm getting at is if your
 IPV for network is a train wreck,

0:06:55.880000 --> 0:07:01.720000
 then maybe you look at this as a darn
 good time to redesign it as you

0:07:01.720000 --> 0:07:03.520000
 move to IPV six.

0:07:03.520000 --> 0:07:09.780000
 Okay. So the good news is they are isolated,
 perfect chance to redesign,

0:07:09.780000 --> 0:07:14.160000
 start over, get a fresh start, do things
 the way they should have been

0:07:14.160000 --> 0:07:19.860000
 the first way, which I'm sure all happened
 before you took over the network.

0:07:19.860000 --> 0:07:21.120000
 That's how it always is.

0:07:21.120000 --> 0:07:22.260000
 It was like that when
 you got there.

0:07:22.260000 --> 0:07:25.540000
 I know either that or all
 this happened over time.

0:07:25.540000 --> 0:07:28.980000
 Now seriously, that is usually
 how it plays out, right?

0:07:28.980000 --> 0:07:34.880000
 But in any case, the point is, if you're
 on the flip side of that, your

0:07:34.880000 --> 0:07:37.140000
 network was designed well
 from the beginning.

0:07:37.140000 --> 0:07:40.600000
 It's been well maintained
 and everything's good.

0:07:40.600000 --> 0:07:45.840000
 Don't redesign. Build your IPV six exactly
 the same way, right alongside

0:07:45.840000 --> 0:07:48.720000
 your IPV four. Okay.

0:07:48.720000 --> 0:07:52.360000
 That would actually make it simpler for
 you in the long run because again,

0:07:52.360000 --> 0:07:55.060000
 at the end, you are going to
 be running two networks now.

0:07:55.060000 --> 0:08:05.140000
 And if you're running two networks,
 you need to make all the changes on

0:08:05.140000 --> 0:08:07.840000
 both sides. I'll cover
 that again in a second.

0:08:07.840000 --> 0:08:14.960000
 But if you do redesign for IPV six,
 now you're maintaining two, well,

0:08:14.960000 --> 0:08:17.380000
 fundamentally different networks.

0:08:17.380000 --> 0:08:19.760000
 And again, ultimately, that
 may be a good thing.

0:08:19.760000 --> 0:08:21.840000
 It's just more work.

0:08:21.840000 --> 0:08:31.240000
 Okay. And all of that, you know, I'm going
 to switch over, you know, transitioning

0:08:31.240000 --> 0:08:38.160000
 and all that. Don't forget that whatever
 security mechanisms your company

0:08:38.160000 --> 0:08:44.380000
 has implemented on the IPV four side,
 you need to copy that over and bring

0:08:44.380000 --> 0:08:47.100000
 that over to IPV six.

0:08:47.100000 --> 0:08:59.400000
 So all your firewall rules need
 to be duplicated in IPV six.

0:08:59.400000 --> 0:09:02.400000
 You know, I've been in so many companies
 where their firewall rule list

0:09:02.400000 --> 0:09:06.880000
 is so long. And you're like, do
 you really need all these rules?

0:09:06.880000 --> 0:09:07.980000
 Oh, I don't know.

0:09:07.980000 --> 0:09:09.660000
 They were all there
 when I started.

0:09:09.660000 --> 0:09:10.680000
 Oh, I don't know.

0:09:10.680000 --> 0:09:12.260000
 They came in every time.

0:09:12.260000 --> 0:09:14.920000
 I don't know if anybody, if anything,
 actually still uses that rule or

0:09:14.920000 --> 0:09:17.460000
 not. Well, here's an idea.

0:09:17.460000 --> 0:09:19.860000
 Let's, let's look at
 a hit counter on it.

0:09:19.860000 --> 0:09:21.480000
 See if any traffic's hitting it.

0:09:21.480000 --> 0:09:24.200000
 And if no traffic hits it
 for a month, I don't know.

0:09:24.200000 --> 0:09:26.220000
 Let's pull it out, you know.

0:09:26.220000 --> 0:09:30.860000
 But in any case, in any case,
 route filtering you're doing.

0:09:30.860000 --> 0:09:33.800000
 Don't forget, we still have
 IPV six prefix lists.

0:09:33.800000 --> 0:09:36.780000
 You have IPV six access lists.

0:09:36.780000 --> 0:09:44.360000
 If your company does things like dynamic
 ARP inspection DHCP snooping,

0:09:44.360000 --> 0:09:56.440000
 things like this, don't forget that
 we have the equivalent of this.

0:09:56.440000 --> 0:09:58.200000
 This is not a security class.

0:09:58.200000 --> 0:10:01.240000
 So I'm not going to go into a
 whole bunch of this right now.

0:10:01.240000 --> 0:10:05.100000
 But we have something called
 IPV six first hop security.

0:10:05.100000 --> 0:10:08.040000
 Some of your new switches
 support it.

0:10:08.040000 --> 0:10:10.240000
 A lot of them do not yet.

0:10:10.240000 --> 0:10:15.660000
 But this is things like secure neighbor
 discovery, router advertisement

0:10:15.660000 --> 0:10:21.620000
 protection. You know, I mean, with IPV
 six, remember we said, you don't

0:10:21.620000 --> 0:10:25.800000
 get your address of your default
 gateway from DHCP anymore.

0:10:25.800000 --> 0:10:29.220000
 You have to get it from
 a router advertisement.

0:10:29.220000 --> 0:10:32.200000
 Well, what would keep me from just
 firing up a router on your network

0:10:32.200000 --> 0:10:35.140000
 and saying, Yep, I'm the router.

0:10:35.140000 --> 0:10:37.060000
 Everybody come to me.

0:10:37.060000 --> 0:10:39.100000
 And I start sending out
 router advertisements.

0:10:39.100000 --> 0:10:40.360000
 You all believe it.

0:10:40.360000 --> 0:10:42.460000
 Send all your traffic to me.

0:10:42.460000 --> 0:10:45.400000
 Okay. So these are some good
 features to look into.

0:10:45.400000 --> 0:10:50.900000
 If you are looking for the security
 side of this, of course, I mean, we

0:10:50.900000 --> 0:10:53.900000
 have lots of security classes
 and stuff out there as well.

0:10:53.900000 --> 0:10:58.100000
 But just look into IPV six first hop
 security and the features that it

0:10:58.100000 --> 0:11:05.440000
 offers to protect some of these things
 in IPV six that yes, they're a

0:11:05.440000 --> 0:11:10.020000
 little different than IPV four, you
 know, we don't have to do dynamic

0:11:10.020000 --> 0:11:13.020000
 ARP inspection because we
 do neighbor discovery now.

0:11:13.020000 --> 0:11:15.480000
 And that's where secure neighbor
 discovery comes in.

0:11:15.480000 --> 0:11:20.500000
 So they're, you know, different names,
 different implementations to support

0:11:20.500000 --> 0:11:22.560000
 a different technology.

0:11:22.560000 --> 0:11:26.620000
 But at the end of the day, they're protecting
 from the same sort of thing.

0:11:26.620000 --> 0:11:32.040000
 The main point in all of this is as you're
 running two completely different

0:11:32.040000 --> 0:11:37.260000
 networks, don't forget to protect
 both of them equally.