03-27-2018 03:41 AM - edited 03-08-2019 02:24 PM
Hello everyone,
I was wondering, lets say for example that there are 2 hosts in a subnet that are doing the DAD process at the same time with source address :: (all zeros address). How are the other hosts in the subnet able to send their NA message to the correct host, so for which the NA message is ment?
I am also curious from a more general point of view, how can the NA messages in general be received from the correct host doing the DAD process, what i mean is how can other hosts know which host is using the unpsecifed address? (withouth the other hosts getting confused and mistakenly sending the NA message to another host doing the DAD process for example)
Thanks in advance for your time.
Solved! Go to Solution.
03-27-2018 07:38 AM
Hello Alan,
You have some very nice questions at hand!
How are the other hosts in the subnet able to send their NA message to the correct host, so for which the NA message is ment?
If the source of the Neighbor Solicitation is an unspecified address (the all-zeros, or the :: address), then the Neighbor Advertisement would be sent to the all-nodes multicast IPv6 address FF02::1. This is described in RFC 4861 Section 7.2.4:
If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to the all-nodes address. Otherwise, the node MUST set the Solicited flag to one and unicast the advertisement to the Source Address of the solicitation.
I am also curious from a more general point of view, how can the NA messages in general be received from the correct host doing the DAD process, what i mean is how can other hosts know which host is using the unpsecifed address?
Let's break it down.
A host performing DAD for a particular address would send out a Neighbor Solicitation, not a Neighbor Advertisement. Two hosts having the same tentative IPv6 address would therefore either hear each other's Neighbor Solicitation (and both would know that the address is in conflict - this would happen if both hosts sent out the Neighbor Solicitation around the same time), or one of the hosts would hear the other host's Neighbor Solicitation before it managed to send out its own (so at least the "slower" host would know its address is in conflict). RFC 4862 does not specify if, in the second case, the "slower" host should still send out its own Neighbor Solicitation so that the "faster" host knows that a conflict exists; in fact, it is not technically required because the "slower" host would still know that the address is already in use, and won't use it himself, preventing the conflict.
A Neighbor Advertisement would be sent out only for an address that is not tentative anymore - an address that has passed the DAD already, meaning that there is already a rightful owner of this IP address on the link. In this case, the rule quoted earlier would apply - the owner would multicast the Neighbor Advertisement to all-nodes.
Feel welcome to ask further!
Best regards,
Peter
03-27-2018 12:55 PM
Hello Alan,
No apologies needed :) In fact, you made me learn something new myself! :)
If the other ''slower'' host sees an Neighbor Solicitation message coming by, he already knows by the looks of the NS message that he should not try to use this IPv6 address anymore because a ''faster host'' was able to send a NS message before him for that same specific IPv6 address.
Exactly correct. In fact, it is not just the "looks" of the NS message - it is its "guts" since the complete IPv6 address that is being tested for uniqueness is carried in the body of the NS message.
So does a host stop his initial thought of sending an NS message for a specific IPv6 address, if another host was able to sent his NS message for that same specific IPv6 address before him?
I have quickly tested it on a 15.5 IOS - and from what I saw, it looks like it. I had obviously difficulties in assigning the same IPv6 address to two devices at exactly the same time, but this what I saw:
And if both hosts hear the Neighbor Solicitation around the same time, will both of them not use this specific IPv6 address anymore?
Definitely so. To each one of them, this is an indication of an address conflict, and each of them has to act on it; they cannot assume that it's the other host's job to back off.
Feel welcome to ask further!
Best regards,
Peter
03-27-2018 07:38 AM
Hello Alan,
You have some very nice questions at hand!
How are the other hosts in the subnet able to send their NA message to the correct host, so for which the NA message is ment?
If the source of the Neighbor Solicitation is an unspecified address (the all-zeros, or the :: address), then the Neighbor Advertisement would be sent to the all-nodes multicast IPv6 address FF02::1. This is described in RFC 4861 Section 7.2.4:
If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to the all-nodes address. Otherwise, the node MUST set the Solicited flag to one and unicast the advertisement to the Source Address of the solicitation.
I am also curious from a more general point of view, how can the NA messages in general be received from the correct host doing the DAD process, what i mean is how can other hosts know which host is using the unpsecifed address?
Let's break it down.
A host performing DAD for a particular address would send out a Neighbor Solicitation, not a Neighbor Advertisement. Two hosts having the same tentative IPv6 address would therefore either hear each other's Neighbor Solicitation (and both would know that the address is in conflict - this would happen if both hosts sent out the Neighbor Solicitation around the same time), or one of the hosts would hear the other host's Neighbor Solicitation before it managed to send out its own (so at least the "slower" host would know its address is in conflict). RFC 4862 does not specify if, in the second case, the "slower" host should still send out its own Neighbor Solicitation so that the "faster" host knows that a conflict exists; in fact, it is not technically required because the "slower" host would still know that the address is already in use, and won't use it himself, preventing the conflict.
A Neighbor Advertisement would be sent out only for an address that is not tentative anymore - an address that has passed the DAD already, meaning that there is already a rightful owner of this IP address on the link. In this case, the rule quoted earlier would apply - the owner would multicast the Neighbor Advertisement to all-nodes.
Feel welcome to ask further!
Best regards,
Peter
03-27-2018 11:35 AM - edited 03-27-2018 11:47 AM
Hello Peter,
Thanks alot for your time and for writing this helpful answer.
I have 2 small questions that I would like to add.
A host performing DAD for a particular address would send out a Neighbor Solicitation, not a Neighbor Advertisement. Two hosts having the same tentative IPv6 address would therefore either hear each other's Neighbor Solicitation (and both would know that the address is in conflict - this would happen if both hosts sent out the Neighbor Solicitation around the same time), or one of the hosts would hear the other host's Neighbor Solicitation before it managed to send out its own (so at least the "slower" host would know its address is in conflict). RFC 4862 does not specify if, in the second case, the "slower" host should still send out its own Neighbor Solicitation so that the "faster" host knows that a conflict exists; in fact, it is not technically required because the "slower" host would still know that the address is already in use, and won't use it himself, preventing the conflict.
So if i understood correctly
If the other ''slower'' host sees an Neighbor Solicitation message coming by, he already knows by the looks of the NS message that he should not try to use this IPv6 address anymore because a ''faster host'' was able to send a NS message before him for that same specific IPv6 address.
So does a host stop his initial thought of sending an NS message for a specific IPv6 address, if another host was able to sent his NS message for that same specific IPv6 address before him?
Two hosts having the same tentative IPv6 address would therefore either hear each other's Neighbor Solicitation (and both would know that the address is in conflict - this would happen if both hosts sent out the Neighbor Solicitation around the same time),
And if both hosts hear the Neighbor Solicitation around the same time, will both of them not use this specific IPv6 address anymore?
Sorry if I made the questions very detailed for you. I am very curious to a host his behavior in such specific cases.
Kind regards,
Alan
03-27-2018 12:55 PM
Hello Alan,
No apologies needed :) In fact, you made me learn something new myself! :)
If the other ''slower'' host sees an Neighbor Solicitation message coming by, he already knows by the looks of the NS message that he should not try to use this IPv6 address anymore because a ''faster host'' was able to send a NS message before him for that same specific IPv6 address.
Exactly correct. In fact, it is not just the "looks" of the NS message - it is its "guts" since the complete IPv6 address that is being tested for uniqueness is carried in the body of the NS message.
So does a host stop his initial thought of sending an NS message for a specific IPv6 address, if another host was able to sent his NS message for that same specific IPv6 address before him?
I have quickly tested it on a 15.5 IOS - and from what I saw, it looks like it. I had obviously difficulties in assigning the same IPv6 address to two devices at exactly the same time, but this what I saw:
And if both hosts hear the Neighbor Solicitation around the same time, will both of them not use this specific IPv6 address anymore?
Definitely so. To each one of them, this is an indication of an address conflict, and each of them has to act on it; they cannot assume that it's the other host's job to back off.
Feel welcome to ask further!
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide