cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1083
Views
15
Helpful
3
Replies

Unknown unspecified IPv6 DAD processes question

Alan_4
Level 1
Level 1

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.

2 Accepted Solutions

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

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

View solution in original post

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:

  1. R1 was configured with fe80::1 link-local address, and immediately sent out a NS for it
  2. R2 was configured with fe80::2 link-local address about 0.4 seconds later; since it did not have an IPv6 address before, it ignored R1's NS, and sent its own NS
  3. R1 immediately claimed that the address is duplicate, and fell completely silent; R1 did not send out another NS to also tell R2 that this address is mutually conflicting
  4. As a result, R2 kept fe80::1 as a usable address while R1 refrained from using it

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

View solution in original post

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

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

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

 

 

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:

  1. R1 was configured with fe80::1 link-local address, and immediately sent out a NS for it
  2. R2 was configured with fe80::2 link-local address about 0.4 seconds later; since it did not have an IPv6 address before, it ignored R1's NS, and sent its own NS
  3. R1 immediately claimed that the address is duplicate, and fell completely silent; R1 did not send out another NS to also tell R2 that this address is mutually conflicting
  4. As a result, R2 kept fe80::1 as a usable address while R1 refrained from using it

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

Review Cisco Networking for a $25 gift card