Cisco CCNA 200-301 – IPv6 Addressing and Routing Part 2
In this lecture, you’ll learn about the format of an IPV Six address. So you already know that it is 128 bits long compared to IPV Four’s 32 bit address. The IPV Six address is written as x colon, x colon x colon. So it’s a great big long address. But when you start working with IPV Six addresses, don’t get freaked out by the length of the address. It’s still just an IP address. So whether you’re working with IPV Four or IPV Six, everything about that address works pretty much exactly the same.
So the routing and the switching is going to work no matter whether you’re using IPV Four or IPV Six in the same way. It’s just a different and longer address that is used in IPV Six. But it’s not like you have to learn a completely new technology or a completely new way of doing things. It’s just a longer address that is on your hosts. With the IPV Six address, each X is a 16 bit hexadecimal field, and hexadecimal means that the values are zero to nine and a through to F. So an example of a valid IPV Six address would be 20010 DB Eight Colon 001001. So you can see that it is a big, long address compared to IPV Four.
So our IPV Four addresses are 32 bits long, and they’re written as X. Each of those segments in between the dots is eight bits long. We’ve got four of them. So four times eight gives us our 32 bit long address. And each part of an IPV Four address is known as an octet. It’s an octet because it’s eight bits long. IPV Six addresses, on the other hand, are 128 bits long, written as that string of X’s with colons in between. Each segment there between the couloons is 16 bits, but there isn’t an official name for them.
Like we have the octets with IPV four. The equivalent of an octet for 16 bits would be hexadecktat. But that’s just too hard to pronounce, so nobody uses that when we’re talking about IPV Six addresses. What the different pieces of IPV Six address are commonly known as is a hex tap or a piece or a quartet. But there’s no official name. When you hear me talking about it during the section, I’ll leave or call it a hex tet or a segment or a piece.
Okay, so you’ve seen already the IP V Six address is very long. It took me about a minute to read out that big long address before. There are, however, thankfully, a couple of ways that we can shorten it to make things more convenient. Address shortening is a standard convention, and it’s supported by all vendors devices. The first way that we can shorten the addresses is that leading zeros in each field can be removed. So if we had that same example address that I was using before that you can see on the screen now, it can be written as 2001. And then the second hextet of zero DB eight, we can write that as just DB eight. We can strip off the leading zero and then call on zero. The next hexet is zero zero zero. So we can strip off three leading zeros and just write it as zero.
The next hex tet of zero zero one, we can write that as one and so on. So whenever you look at an IPV six address and you see a HEXAt, if there’s not four hexadecimal characters in there, for example, if there is two, you know that the first two characters must have both been zero zero because we can strip off the leading zeros. The other thing that we can do to shorten the address is that successive all zero fields can be shortened to the middle bullet point you see here, about the same as what we did just there in the last slide where that big long address can be shortened by removing the leading zeros. But we can take it on a step further as well. So after removing the leading zeros, we had 2001 call on DB eight, call on zero, call on one, call on zero zero, call on one. Well, we can change that to 2001 colon DB eight, colon zero, colon one, double colon one. So those three hexets near the end, which are all zero, we can just write that as a double colon.
So in the example that you see here, there’s three different ways that we could write that same IPV six arrest the big long complete one up at the top, that’s valid. We could type that in on a router and that is acceptable. The second one, where we’ve removed the leading zeros, we could also type that in when we’re configuring an IPV six address and a router and that would be accepted too. Or we can write it the third way where we’ve removed the leading zeros and we’ve also removed successive all zero fields. And again, that is a valid address. So the three IP addresses you see, they’re all exactly the same. They’re just different ways of writing the same thing and they’re all valid. We can use either of the three. The standard way to do it is of course, the shortest way. The last one you see, because that’s the most convenient way to do it now with removing successive all zero fields, that can only be done once in an address to avoid confusion.
So for example, if we had 2001 colon zero, colon zero colon B, that could be shortened to 2001 double colon 1000 B, or it could be shortened to 2001 colon zero, colon zero colon one, double colon B. Because you see in the example, there’s two different parts of the address which have got successive all zero fields, but we can’t shorten it to 2001 double colon one, double colon B because if we did that, you see it in the original address. On the left hand side, we’ve got two zeros, and then to the right of the one, we’ve got three zeros.
Well, if we shortened it to 2001 double colon one double colon B, we wouldn’t know which side of the one had two zeros and which side of the one had three zeros, so we wouldn’t know what the actual address was. So to stop that from happening, you can only put in a double colon once during the entire address. Okay, so that was it for our IPV six address format. I’ll see you back in the next lecture where we’ll talk about the different address types in IPV six, and we’ll actually start configuring this on our routers as well. So you’ll also see how to put this IPV six address on your router. See you there.
In this lecture you’ll learn about why we need to have IPV Six. You already know the main reason from earlier lectures, which is that we’re running out of global IPV Four addresses. But you saw in the last lecture that we can use not network address translation as a workaround. So why can’t we just use Nat permanently? Well, the problem problem is that there are some issues with that. The main one being that it breaks the standard end to end IP model the way that IP normally works, and that can cause issues with security and it can also break some applications. To give you an example, looking at the diagram here, we’ve got Company A and we’ve got Company B, and they’ve both got IP phones internally and they do a lot of business with each other. So they would like to be able to make phone calls to each other over their IP network rather than doing it through the normal phone company because that will save them money. So company A have got their CUCM.
That’s the Cisco Unified Communications manager that controls the phones. I’ll just call it the call manager for short. And Company B have got their call manager as well. And what Company A and Company B can do is they can program their call managers to point to each other so that calls between the two companies can go over the IP network. But when they’re using that, there’s going to be a problem with this. And this is very common with multimedia applications like voice and video. And that is typically going to stop the traffic, it’s going to break it. So let’s walk through what’s going to happen. So you can see the issue here. So I’ve got an IP phone at Company A, it’s extension ten 1001. It’s using a private IP address of ten o ten. And if that IP phone sent traffic out to the internet, let’s say that it would use dynamic Nat. And then for this example, it’s going to get Natted to 2030 113. So the IP phones, they’re not intelligent enough to make their own decisions.
They need to ask the call manager for help with that. So the user at extension ten 1001 at Company A, he wants to call the user at extension Eleven 2001 at Company B. So he picks up his handset and he dials Eleven 2001. That sends a signaling message to the call manager saying, hey, I’d like to call Eleven 2001 please. It comes from the private IP address ten 00:10, and it goes to the call manager’s private IP address of 100 100. So that all works just fine. Everything’s internal in company. A right now. The call manager at Company A then looks in its dial plan, which was configured by the administrator, and it sees that whenever there’s a call for anything, starting with Eleven, and then four additional digits to send that call to the Company B call manager. Which is available with the public IP address of 203 One 1320. So the call manager sends signaling to Company B’s call manager saying hey, there’s a call for eleven 2001 and it’s coming from the phone at ten dot o dot o dot ten that traffic comes from the call manager’s.
IP address of ten dot o dot o dot 100 and it goes to Company B’s call manager at 2030 one 1320 the traffic will reach router A and router A will net the source address of Company A score manager 100 100 to the public. IP address 203 1133. Because on Router A we’ve configured a static Nat rule for that. The traffic will then get to Router B over at Company B and it will net the destination address of 2030 One 1320 to the internal private IP address of ten 00:10 100. Because Company B’s Router B also has a static nat rule for Company B’s call manager. So the signal comes into the call manager at Company B and it knows that extension eleven 2001 is available at IP address ten 00:10. So it sends a signaling message down to the IP phone saying hey, there’s a call coming in for you, please ring. Then the user at extension eleven 2001 hears their phone ringing, so they pick up the handset. The phone will then send a signal back to the company b call manager saying hey, the user has picked up and we’re ready for the call. Now the company b call manager then needs to send a signal back to the company. A call manager saying hey, extension eleven 2001 is ready for the call. And it’s an IP address 1010. That goes from ten 100 at callmanagerb to 203 1133. The public IP address of Call Manager A. Router B sends the traffic out and it will not the source address of ten 100 the Company B Call Manager to 2030 One 1320. It will then gets to Router A and it will not the destination address 203 1133 to ten or 100. So all the traffic is working just fine now, and that is allowing us to have private IP addresses on the inside and those fixed static public addresses on the outside for our call managers. Call Manager A then sends a signaling message to Phone A saying okay, because ready stream your voice directly to ten 00:10 Ten, which is the IP address of the phone at Company B.
And call manager B tells Phone B to stream your voice to Ten o Ten, which is the IP address of the phone at company A. But the problem is that the phones only have connectivity to each other on their netted public IP addresses, not via the internal private addresses. Phone A Ten 00:10 does not have connectivity to 1010 over at Company B. Those are two different private IP addresses that only work internally at Company A and internally at Company B. They don’t work between the two different companies. So for the two phones to be able to communicate with each other, they’d have to be using a public IP address, which would be natted on both sides. But because the information was included in the higher layer traffic within our voice protocols, the phones don’t know to use a public IP address. They’re told to use that private IP address. There’s no connectivity, so the call fails. It doesn’t work. Now, there can be workarounds for this. So devices such as Application Layer Firewalls, which can look up at that higher layer traffic, see what’s going on in there, and make adjustments.
Also, traversal servers and proxy servers can help with these issues, but that does break the way that IP works normally, and it does break applications that use embedded IP addresses or port numbers in the higher OSI layers. So it would be a cleaner solution if IP supported an addressing scheme which was big enough to give all devices in the world a publicly reachable address. That way, the phones inside the two companies would have a publicly reachable address to get to each other, and the call would work. So how can we do that? Well, we’ve got IPV Six. It uses a 128 bit address compared to IPV Four’s 32 bit address, and it provides way more addresses than IPV Four does. The address is four times longer, but it’s much more than four times as many addresses, 7. 9 times ten to the power of 28 times, a very big number. There are other IPV Six enhancements as well.
So in addition to the larger address space, IPV Six was designed to support built in security and also host mobility, where a host can keep the same IP address, but move to different physical locations. Okay, last thing to tell you here is that whether you’re going to use IPV Six and IPV Four, it’s not an either or decision. You don’t have to use IPV Four or IPV Six. You can use IPV four and IPV Six in a Geostack implementation. A network interface on a host or on a router can have both an IPV Four and an IPV Six address at the same time. It can then communicate using either protocol. So if the application sends traffic to an IPV Four destination address, it will use IPV Four. If the application sends traffic to an IPV Six destination address, it will use IPV Six. Joest can be enabled long term if you do need to support both IPV Four and IPV Six applications.
Or it can be used shorter term if you’re using it as an IPV Four to IPV Six transition strategy. Okay, so that’s the limitations of Nap and how IPV Six doesn’t suffer from them. In the next lecture, we’ll start getting into more details about how IPV Six works.
Popular posts
Recent Posts