Introduction to IPv6

Thank you very much Sir,

That’s just that in such case (no implementation of Multicast Listener Discovery for ipv6), i have doubt regarding the real benefit of ipv6 multicast on ipv4 broadcasts;
I trully understand its benefit on other uses of it but here i don’t see the point;
Was just curious after reading the official certification guide that mentions (in short) the “big” benefit of ipv6 use of multicast ; So my conclusion is : Yes it’s a real benefit but not in all cases …

Thanks very much for taking time for testing it / Really appreciate

Hello Pierre

Yes, that is the case for many technologies. The idea is that if you have a fully IPv6 network infrastructure, and you have configured switches to be IPv6 multicast aware using MLD, then the benefits are immense. You can have IPv6 subnets of hundreds or even thousands of hosts without the fear of creating broadcast storms, something that is unheard of for IPv4.

This is especially useful for innovative new applications such as the Internet of Things (IoT), where you may have tens of thousands of devices connected to the same IPv6 subnet without a problem, all because of the fact that you no longer have broadcasts.

Compared to IPv4, you are able to create networks of much greater scale due to the fact that broadcasts have been replaced by multicasts. But for conventional networks, such as a small business LAN for example, there is no essential difference. So it does indeed depend on the case.

I hope this has been helpful!

Laz

Q-1:-you said that mobility device can keep their IP even they will shift to other providers also …But how that public ip can be owned by 2 service provider at the same time ??.

Q-2:- An IPv4 host can’t communicate with a IPv6 host (pingv6 2141::1 source 10.10.10.10 )…right ??.

Q-3:- Can i do nat my pvt IPv4 address users to a IPv6 public IP address ??

Q4–As you said Ipv6 support Ipsec natively, Does that mean IPv6 packets are getting encrypted including payload ??

Hello Narad

As stated in RFC 3775 that defines the IPv6 mobility feature:

Mobile IPv6 allows a mobile node to move from one link to another without changing the mobile node’s “home address”. Packets may be routed to the mobile node using this address regardless of the mobile node’s current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications.

How this is technically achieved can be further examined within the RFC document.

If you don’t configure any mechanisms to allow IPv4 to communicate with IPv6, then you are correct, there can be no direct communication between an IPv4 host and an IPv6 host. However, you can allow IPv4 and IPv6 hosts to communicate using NAT64. An example of this can be seen in this lesson:

Yes, using NAT64.

As far as what is encrypted, IPsec for IPv6 works the same as IPv4. You have both transport and tunnel mode. When configured in transport mode, only the payload is encrypted, while in tunnel mode, the entire IPv6 packet is encrypted and authenticated.

I hope this has been helpful!

Laz

How to find IPv6 Prefix Example

This is in reference to the /53 prexi example. What would have been the difference if the prefix lenth was /52. Wouldn’t that be the same result. Because I notice we put the other bit along/together with the next 4-bit block.

I think it should not be part of the host?

Hello Ibmufa

First of all, remember that network devices view, calculate, and manipulate IPv6 addresses using the binary format. The hexadecimal format is for the benefit of us humans so that we can understand and write out the addresses more easily.

This means that when you see a /53 prefix in this format: 2001:1234:abcd:5678:9877:3322:5541:aabb/53
the network device simply sees it like this:

00100000000000010001001000110100101010111100110101010110011110001001100001110111001100110010001001010101010000011010101010111011

I’ve made the first 53 bits bold to indicate that they are the 53-bit prefix. If we used a 52-bit prefix, it would look like this:

00100000000000010001001000110100101010111100110101010110011110001001100001110111001100110010001001010101010000011010101010111011

So you see, from the point of view of a network device, there are no “4-bit blocks” or 16-bit hextets, so it’s really no problem for a network device to deal with a prefix of any length.

Now having said that, it is difficult for us humans to visualize a /53 simply because of the methodology of representation used. A /53 will cause the prefix to split the IPv6 address within a single hex digit as shown in the lesson.

However, a /52 would be easier to visualize because it actually splits at a particular hex digit. Specifically:

2001:1234:abcd:5678:9877:3322:5541:aabb/52

In the above representation, the bold hex digits belong to the prefix. Remember that each hex digit represents four bits. So that’s 13 hex digits times 4 bits each: 13*4 = 52.

In general, we tend to choose prefixes that are divisible by 16, such as /48 or /64 because they split along one of the “:” indicators in the address. Or, we can choose prefixes that are divisible by 4, so that the split occurs at one of the hex digits, so values of 52, 56, and 60 would also be easily representable in the hex format. But anything not divisible by 4 is typically not used simply because it adds complexity to the hex representation of the addresses.

I hope this has been helpful!

Laz

1 Like

Laz,

Thank you!! Getting to understand IPv6 better and better. You guys are fantastic.

1 Like