I’m yet to learn about the other by features leveraged by icmpv6 but your explanation makes sense. It would be interesting to listen to the discussions that take place when the architects make decisions on how new protocols are to operate.
How many more years do you think it will be until native ipv6 networks are the norm? It seems like the clock has been ticking for some time now.
It’s great to hear that you enjoy answering these queries Laz as each one new piece of knowledge seems to spawn two more questions!
I think it’s going to be a long time before IPv6 becomes the norm. My opinion is at least a decade or more. Although the Internet is well on its way to becoming fully IPv6, adoption is still very slow at less than 35% worldwide, keeping in mind that this level was at 5% at the beginning of 2015, and the increase seems to be linear so far. Fewer than 5 countries have achieved more than 50% of adoption.
But these are statistics that have to do with the use of IPv6 on the Internet. I believe that internal enterprise networks are going to be even slower in adoption. This is because all of the measures taken to increase the longevity of IPv4 have been too successful, making it easy to keep your IPv4 networks in an ever-increasingly IPv6 world.
I live in a country that is among the top ten in the adoption of IPv6 on the Internet, but I have yet to see any large scale private or government network adopt IPv6, except for an experimental network maintained by several universities. It’s just too easy to keep using IPv4, at least for the time being. The investment time and effort to upgrade is not worth the benefit that IPv6 provides over IPv4 on steroids.
Just my thoughts.
That’s one of the things that makes networking so interesting! You rarely get bored!
Thank you Laz. It was very nice to be here and see all your reply. One more help, Is there any link explaining difference dhcp messages, like dhcp rebind, dhcp infrom, and renew messages. Also where i can find information on ipv6 subnetting.
For complete information about all the details of DHCP and how it works, you can take a look at the RFC that describes it. This is the official definition of the protocol. The current valid RFC for DHCP is RFC2131:
There you will find the definitions of the various messages, as well as the fields found within each one and the flags that define if a message is for renewal, rebinding, or other processes.
IPv6 doesn’t approach subnetting in the same way as IPv4. For this reason, in order to understand how IPv6 operates in this respect, I suggest you go over the following lessons:
If you have any further questions about this, let us know!
Inverse Neighbor Discovery (IND) allows nodes to determine and advertise an IPv6 address corresponding to a given MAC address. This is similar to Reverse ARP for IPv4. This is an extention to the IPv6 NDP and is defined in RFC 3122.
Secure Neighbor Discovery Protocol (SEND) is also an extension of NDP delivering security features to such communication. This in defined in RFC 3971 and has been updated by RFC 6494.
Both of these extensions, extensively use ICMPv6 and generate RS, RA, NS, and NA mechanisms and operations.
That was very helpful, but it does lead to another question for me.
I know that typically host will drop frames if the frame is not to the host’s mac address, if the frame is not FF-FF-FF-FF-FF-FF for a broadcast and if the frame is not a multicast address that the host is listening for.
Question: then: Dose this mean the hosts also adds the 3333:FFXX:XXXX address to its listening mac addresses? I would think so since, otherwise, it would drop the frame since its not its own mac address or a broadcast (FF-FF-FF-FF-FF-FF)
Yes, this is the case. Whenever an IPv6 host listens to a particular IPv6 multicast address such as FF02::1:FFXX:XXXX in order to allow the Neighbor Discovery Protocol to function, it will also listen to the corresponding multicast MAC addresses at Layer 2.
I’m a bit stuck with the IPv6 Neighbor Solicitation process. Can I please ask for help?
I understand that NS is the IPv6 version of IPv4’s ARP, which means that if the sender has the recipient’s IP but not its MAC address, it uses either NS or ARP, depending on which version of IP is used. I also understand that the benefit of NS is that it doesn’t use the all Fs MAC address, which means that the hosts that aren’t the intended recipients of the frame don’t process it. This results in the usage of less resources, such as processing power by the hosts (i.e. less CPU cycles).
To avoid using the all Fs MAC address, the sender must have a way to create a MAC address that’s specific to the intended recipient. To do this, the MAC address 33:33:xx:xx:xx:xx is used by the sender. The sender uses the unicast IPv6 address of the recipient to create the solicited node multicast address. The xs of the MAC address are filled in by the sender according to the solicited node multicast address of the recipient. This takes care of both L2 and L3.
What I don’t understand is why the sender can’t just use the unicast IPv6 address of the recipient in the packet? The sender already knows the unicast IPv6 address of the recipient. Creating the solicited node multicast address is an extra step for the receiver, with no benefit. Why does the sender have to use the solicited node multicast address of the recipient, instead of the recipient’s unicast address?
In other words, why is it necessary for the sender in IPv6 Neighbor Solicitation (NS) to create a solicited node multicast address based on the recipient’s unicast IPv6 address, instead of directly using the recipient’s unicast address in the packet? Considering that the sender already knows the recipient’s unicast IPv6 address, creating the solicited node multicast address seems like an additional step for the sender without any apparent benefit.
The goal here is to determine the L2 address from the L3 address. We have the IPv6 unicast address of the destination, but we don’t have the L2 address of the destination. There is no mechanism in place that can directly determine the appropriate L2 address from the known IPv6 address. Therefore, by definition, we cannot use the IPv6 unicast address.
However, we want to inform the destination that we need its MAC address. The NDP gives us this ability through the solicited node multicast address. This process does have a mechanism in place that can be used to directly determine the multicast L2 address that corresponds with the intended destination. By using this multicast IPv6 address, through which an appropriate L2 address can be derived directly to contact the intended destination, the MAC address of the destination is requested and obtained.
So you see, it is a matter of what mechanisms are in place to enable the direct derivation of the L2 address. The IPv6 unicast address by definition (and by design) cannot be used for this purpose, but the solicited node multicast address can be used. Does that make sense?
Then the answer is that the people who designed the NS process decided that devices need the solicited-node multicast address.
But I don’t see how this addresses my main point: there’s no reason to use the solicited-node multicast address, because the MAC address 33:33:xx:xx:xx:xx is built using the solicited-node multicast address, and the solicited-node multicast address is built using the unicast address. Which means that the MAC address 33:33:xx:xx:xx:xx could be built using the unicast address. The solicited-node multicast address doesn’t provide any additional information that the sender doesn’t already have at the beginning of the process.
So now the question is: why was this process designed this way? Doesn’t the creation of a solicited-node multicast address just use up resources while achieving the same goal that could be achieved with the unicast address?
Multicast in IPv6 is a well-established mechanism used for multiple purposes, including NDP, SLAAC, DAD, RAs, RSs, and others. Among the various types of multicast addresses (all routers, all nodes etc), we have the solicited-node multicast address. The solicited-node multicast address is the unique multicast address to which each IPv6 interface belongs. It is a multicast group consisting of only one host. This is automatically computed by every IPv6 host and maintained.
The use of this address has made many IPv6 functions much more efficient because of the fact that you no longer need to send broadcasts out for things like ARP, but you can send multicasts that actually act as unicast because of the fact that there is only one host in the multicast group.
Now it is true that from the unicast address you can derive the multicast address, and from the multicast address you can derive the multicast MAC address, so you can theoretically determine the multicast MAC address from the unicast address. But isn’t that what’s happening already? You’re still ultimately deriving the multicast MAC address from the original unicast address, but you’re simply using the solicited-node address to achieve it.
I understand what you are saying because it does sound counterintuitive to do all of this if you can derive it directly. However, remember that the multicast mechanism is a well-established extant mechanism that achieves what we want. It would be cumbersome to introduce a new mechanism simply to derive the multicast MAC for the unicast IPv6 address. How would you then leverage the multicast MAC? You couldn’t use it with the unicast IPv6 address, so such an endeavor would not work out. Does that make sense?
The FILTER-IPv6 access list that you have created permits the NDP messages, that is NAs and NSes, however, it will block any RAs and RSes that are sent. However, you have to keep the following principle in mind:
An access list applied in an outward direction on an interface will not filter outgoing traffic that is generated by the local router. Take a look at this NetworkLessons note on the topic.
I assume that you have applied the ACL in an outbound direction on Gi/0 on H1. This means that RSes sent from H1 are not filtered. Similarly, since it is applied in an outbound direction, any RAs sent from the router will freely enter the Gi0/0 interface.
Just to be sure, I labbed this up and confirmed this. I tried denying all traffic and applied the access list in both inbound and outbound directions, and the SLAAC process failed. I removed the inbound ACL and all worked perfectly.
Just a note here, if you want to permit RAs and RSes through an access list you are creating, you can use the following ACL statements:
permit icmp any any router-advertisement
permit icmp any any router-solicitation
