I have a question regarding the following statement. I’m not quite understand about the remote host.
The result will be that only the remote host will receive the neighbor solicitation. That’s far more efficient than a broadcast that is received by everyone…
Since all the devices with ipv6 enabled will automatically generated a solicited node multicast address, how does it different from the broadcast since all the devices will receive the packets.
Hello Po
Even though multicast is being used for this mechanism, a Neighbor Solicitation will not be broadcasted or multicasted to multiple hosts. The NS will go only to the single host that requested it. This is because the solicited note multicast address defines a multicast group which contains a single host. The multicast address is computed by taking the multicast group address of FF02::1:FF /104 and adding the last 6 hex characters from the IPv6 address of the specific host. This creates a unique multicast address that corresponds to a single device, making an NS much more efficient than the counterpart IPv4 process which uses broadcast.
I hope this has been helpful!
Laz
Hi Lagapides,
Why both router perform NS, NA to each other. let’s say R1 router send NS to R2 then R2 router send NA to R1 . In this communication both Router should know their L2 address right ?? So why R2 will send NS to R1 and R1 will send NA to R2 ??Thx
BR//ZAMAN
Hello Zaman
You are absolutely correct in that a single NS sent with an NA reply will allow both sender and target to obtain each other’s MAC addresses and to resolve them to IPv6 addresses. RFC 4861 which describes Neighbor Discovery in IPv6 states the following:
A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other’s link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation.
However, because NS and NA messages are used for more than just resolving the MAC address to the IPv6 address, this process is performed in both directions. Specifically, NS is used to verify that a neighbor is still reachable, and this is achieved by periodically sending out NS and expecting back NAs. This is performed in both directions. NS and NAs are also used to perform Duplicate Address Detection (DAD) which requires the exchange in both directions.
I hope this has been helpful!
Laz
Hi Rene and staff,
may we dive deeper with IPV6 redirect messages ?
I want to interpret the fields Target address and Destination Address in the capture below
We know that the host fe80:260:x send a ping to the host 3000::1 via the option which contains the IPV6 initial packet
So, the router fe80:2b0:y send a reply to the host fe80:260:x, that is a redirect message with target address and Destination address
I read this (not in a RFC)
This is a bit confusing…(for me)
In the example, Target address has not the same value as Dest address
Target address is the router link-local and Dest address is 2001:db8::1
Could you help me to interpret these fields and the redirect message ?
Regards
Hi Rene and staff,
still studying ipv6 and testing ND cache, ipv6 states, NUD, etc …
and relative cisco commands
So i do a basic lab with 2 CiscoIOSv15.6(1)T-1
I set a static entry in the ND cache and i cannot delete it. Please look the above pic
Hello Dominique
Looking at the packet capture, I believe that the source fe80::2b0:Y is actually not a router, but an end device. You can see this from the MAC address indicated in the Ethernet II frame: Computer_23:47:33. In addition, the fe80::260:X is not an end device, but a 3COM router, once again visible from the MAC address: 3com_52:59:d8. This is information that we obtain via the first 24 bits of the MAC address, or the OUI.
Unless I am interpreting this incorrectly, keeping this in mind, we see that it is the computer (host) that sends the redirect to the router. (strange situation, but that’s what it looks like. 
)
Here we have a target address of fe80::2b0:Y. This is the node that solicited the response. This is the router. The RFC says that “when the target address is the endpoint of a communication, it must contain the same value as destination address field.” But the target address is not the endpoint of the communication. So you shouldn’t see the same address, which is what we see in the output of the packet analyzer.
What the RFC is stating is that the target address and the destination address will be the same if the destination of the original intended echo request is a neighbor of the sender of the redirect message. Does that make sense?
I hope this has been helpful!
Laz
Hello Dominique
The clear ipv6 neighbors command will delete all IPv6 neighbor discovery cache entries except for static entries. You can find out more about this command here:
In order to remove the static entries, you must use the “no” option of the command like so: no ipv6 neighbor. More about this command can be found here:
I hope this has been helpful!
Laz
Thanks Laz,
i lab the finite state machine below,
and i understand exactly what is reachability (and consequently what is unreachability). I tought it was “you answer a question from your neighbor”, this is reachability…not exactly. Let’s have a look with this basic lab !
Debug ipv6 nd is on on each router
R1 send a ping to R2. So R1 gets a reply to its own probe => it has ULP confirm because it is a reply to its own probe
R2 replies to the ping: you may think this is reachability, but this is not because it is not its own probe; it is just a reply to R1 probe. So R2 says “R1 is alive, but this not really reachability” , and R2 has to send its own NS to get NA from R1 and to say “now this is reachability”
So R2, in contrary to R1, has to go to probe state
From the perspective of R2
It is just to help others
Regards
Hello Dominique
This is great information, thanks for sharing! It’s important to remember that NDP is used for multiple purposes. As mentioned in a previous post, for the purpose of resolving link layer addresses, the RFC states that:
a single request-response pair of packets is sufficient for both the initiator and the target to resolve each other’s link-layer addresses
But as you say, this is not enough to ensure reachability in both directions. This is confirmed by RFC4861 in that it states that:
Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer.
This positive confirmation as described requires reachability to be established in both directions as you state.
Thanks again for the info!
Laz
Hi Rene and staff,
i have an issue to understand precisely ND redirect message. I think it was easier with IPV4 redirect ? was not it ?
With IPV6 you have 4 addresses:
Would it be possible to clarify how it works giving some examples ?
or at minima just a real basic one
something like: in this example, this addr <the_addr> is in that field, this other <the_other_addr> is in that other field, etc …
(as far as it is possible in this forum)
Regards
Hello Dominique
I found the following document useful in understanding ICMP for IPv6 redirects, but I’m sure you’ve already looked at it:
Let’s use their diagram to help us out:
Now imagine that Host H sent a packet to some global unicast address. The next hop for this is Device A. But Device A knows of a better default gateway for this destination, and sends back an ICMP IPv6 redirect message to Host H. This redirect message contains various IPv6 addresses.
Now we see the following addresses:
I hope this has been helpful!
Laz
Hi LAZ,
thanks for the help,
sure i have already find this configuration guide, thanks to think that about me…but you say it: “this is not very clear”
Thanks to network lessons as it reduces the time i have to spend on researches to clarify my understanding…but even doing your best, it is not possible to clarify anything for any student. So for redirect, i had to think at it more and more
But may i try another question to clarify
The option “prefix” in RA message has a flag L (on-link determination flag). L=1 is OK
The question is about L=0
I read “flag L=0 <=> prefix off-link enforce PVLAN-like traffic flow”
My understanding is: prefix with flag L=0 is like a private vlan which type is community
So the traffic host-to-host in L2 domain flows through the interface of the router. OK, but in private vlan you cannot have traffic between hosts in distinct communities
What L=0 is really use for ?
Is that mean that we cannot have traffic between different prefix with L=0 in the L2 domain ? (it will be like a default policy)
If yes, can i configure manual routing to get around this forbidding ?
Could you clarify ?
Thanks for your work
Regards
Hello Dominique
It’s great to see how in depth you get into these subjects to fully understand what is going on, that’s great!
I went into RFC4861 which describes these features of NDP to examine your question further. I also did some more digging in RFC5942 which was very enlightening as well.
The fundamental principle behind this has to do with the fact that in IPv4, if you have an IP address and a subnet mask, this is enough information to determine if that address is on the same segment, or “on link” as another address. This is not the case with IPv6. As stated in the latter RFC,
“The on-link determination is separate from the address assignment.”
The RFC goes on to say:
The reception of a Prefix Information Option (PIO) with the L-bit set [RFC4861] and a non-zero valid lifetime creates (or updates) an entry in the Prefix List. All prefixes on a host’s Prefix List (i.e., those prefixes that have not yet timed out) are considered to be on-link by that host.
So when L = 1 (as you already stated), the prefix in question is considered unequivocally to be on-link, and thus it is added to a host’s Prefix List.
Now according to RFC4861, if L = 0, this does not mean that the prefix is off-link. In other words, if an address is derived from the prefix in question, it simply states that “I don’t know if it is off-link or on-link”. This means that if L = 0 for a particular prefix, such an RA must not update a previous indication that this particular prefix is on-link. So if you have, in a host’s prefix list IPv6 address A, and an RA arrives with the same prefix as address A and L = 0 in that RA, you must not update your prefix list. Take a look at the Host Behavior section of RFC 5942 as it is indeed informative.
Now what does this mean? Well, if L = 1, then the prefix enters the prefix list, and any communication with IPv6 addresses of that prefix will be sent directly. That is, no default router is involved. If L = 0, no change in the prefix list takes place. If the prefix expires (times out), then any future communication with that prefix must take place via the default router. I think this is the behaviour that you were were describing as a PVLAN-like behaviour.
I hope this has been helpful!
Laz
Hi Rene and staff,
since my last post i do create many personal labs with gns3 to test as many things as i can for ipv6 ND. I notice that “autoconfig default” dont work as i expected: it seems to give the same result as just “autoconfig”. I wonder why ?
This is the basic lab
R4 has a slot NM-16ESW to act like a SW
Only R1 and R2 are needed to ask my question (R1 acts as the client, R2 will act as the router)
First i configure R2
Second i configure R1 e0/0 (no default added)
And here are output of the show commands
A default route has been inserted in R1’s RIB pointing to R2
Since R2 is a router (unicast-routing), it sends RA, so by default, it has to appear in R1’s list of routers (?), and act like a possible default route (?), and this is the case in this topology
But what if you dont want R1 to have a default route via its interface e0/0 (for some reasons)
So, what “default” is used for ?
Does it take meaning in other topologies ?
Regards
Hello Dominique
I also labbed this up using VIRL, and I found that if I don’t use the default keyword, a default route will not appear in the routing table. When using the default keyword, it does indeed appear.
It may be that your platform puts in the default route in the routing table by default. Even so, the default keyword does still have meaning. When autoconfig is configured on your router, one of the things that this procedure provides for the router as you know very well, is a default router, via the RA on the local network segment. So, the router, as a good and obedient “host”, seems to place that default router into the routing table as the default route of the router.
But the default keyword is essentially useful if you have multiple IPv6 enabled interfaces using autoconfig.
In this case, only one IPv6 interface can have the default keyword enabled, because only one interface can be a default route for the router. So even if the default route is installed without the keyword, keep in mind that this keyword becomes more important when there are multiple IPv6 interfaces using autoconfig.
I suggest you try to enable multiple IPv6 interfaces on a router, configure them with autoconfig (without the default keyword), have routers exist on the other ends of those links, and see if a default route (and which one) is installed in the routing table.
I hope this has been helpful!
Laz
Good day.
I don’t understand what the real difference is between ARP and Neighbor Discovery Protocol, I understand that they are both different protocols and work differently, but why is Neighbor Discovery Protocol better than ARP?
Both flood their local segment with messages and all receive them and to whom they are destined to reply.
Hello Armando
One of the fundamental differences between the ND protocol and ARP is that a Neighbor Solicitation (NS) message (IPv6’s counterpart to an ARP request) is not broadcast to the whole network segment, while an ARP request is.
ND takes advantage of multicast as opposed to broadcast. Now this may sound like it’s quite similar to ARP, but it is not. NS’es are sent to the Solicited Node Multicast address of the remote host. Even though this is multicast, the NS is sent to only a single device, the device for which an IPv6 address is being requested. You see, this multicast address has only a single member: the remote host in question, so the request goes only to that remote host.
This is more thoroughly described in the IPv6 Neighbor Discovery Protocol
lesson.
Now beyond ARP, the ND protocol has other responsibilities including, as described in RFC4861:
IPv6 nodes on the same link use Neighbor Discovery to
discover each other’s presence, to determine each other’s link-layer
addresses, to find routers, and to maintain reachability information
about the paths to active neighbors.
Additional functions including router, prefix, and parameter discovery, address autoconfiguration and resolution, next-hop determination, neighbor unreachability detection, duplicate address detection, and redirect.
I hope this has been helpful!
Laz
Hi Guys - any ideas why ICMPv6 was chosen for Neighbor Discovery? Could this function not have been designed using the IPv6 header and/or Extension Headers? Thanks - Gareth.
Hello Gareth
Such a question is not easy to answer, because there are a lot of factors involved in why engineers decided to use one particular architecture over another. Could it have been employed using IPv6 headers? Probably. Although I can’t definitively answer why they chose this implementation, I can offer some thoughts on why I believe this architecture was chosen over others, but this is just my own opinion…
To understand the various components of IPv6 it’s often useful to take a look at the IPv4 counterparts that were replaced or improved upon. For the NDP, the corresponding features in IPv4 include ARP, ICMP Router Discovery, and ICMP Router redirect. These were separate operations for IPv4, taken care of by distinct protocols from IPv4. Carrying on in the same way for IPv6, a separate protocol from IPv6, ICMPv6 was chosen to take care of these.
Now one can say that IPSec for example, was incorporated into the header(s) of IPv6, why not NDP? Well, NDP includes enough mechanisms and operations to be defined as a self-contained set of features. There are many extensions and other features including Secure Neighbor Discovery (SEND), Multicast Listener Discovery (MLD) which both leverage ICMPv6, giving more credence to the use of ICMPv6 separately rather than as an inherent part of IPv6.
A more in-depth explanation of how NDP compares with IPv4 can be found in the “Comparison with IPv4” section of RFC4861, which also gives insight into why it was designed this way:
I hope this has been helpful!
Laz
PS, Gareth, your questions are interesting and inquisitive, and it is a pleasure to answer them! It shows that you are deeply interested in the subject, and that’s great to experience. I always look forward to your questions! 
