|
ICMPv6 Neighbor Advertisement and Neighbor Solicitation Messages
(Page 2 of 4)
ICMPv6 Neighbor Advertisement Message Format
The format for the Neighbor Advertisement
message is described in Table 111
and Figure 160.
Table 111: ICMPv6 Neighbor Advertisement Message Format
Field
Name
|
Size (bytes)
|
Description
|
Type
|
1
|
Type: Identifies
the ICMPv6 message type; for Neighbor Advertisement messages
the value is 136.
|
Code
|
1
|
Code:
Not used; set to 0.
|
Checksum
|
2
|
Checksum: 16-bit
checksum field for the ICMP header, as described in the
topic on the ICMP common message format.
|
Flags
|
4
|
|
Target
Address
|
16
|
Target Address:
If the Neighbor Advertisement is being sent in response to a
Neighbor Solicitation, this is the same value as in the Target
Address field of the Solicitation. This field will commonly
contain the IPv6 address of the device sending the Neighbor Advertisement,
but not in all cases. For example, if a device responds as a proxy for
the target of the Neighbor Solicitation, the Target Address
field contains the address of the target, not the device sending the
response. See the topic on
address resolution proxying for details.
If the Neighbor Advertisement is being sent unsolicited, then
this is the IPv6 address of the device sending it.
|
Options
|
Variable
|
Options:
When sent in response to a multicast Neighbor Solicitation, a
Neighbor Advertisement message must contain a Target Link-Layer
Address option, which carries the link-layer address of the device
sending the message. This is a good example of an option
that's not really optional. J
When the Neighbor Advertisement is
sent in response to a unicast Neighbor Solicitation, this option
is technically not required (since the sender of the Solicitation
must already have the target's link-layer address to have sent it unicast.)
Despite this, it is still normally included, to ensure that the link-layer
address of the target is refreshed in the cache of the device that sent
the Neighbor Solicitation.
|
|