| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
A link-local unicast address assigned to the interface from
which this message is sent. Note that routers may use multiple
addresses, and therefore this address is not sufficient for the
unique identification of routers.
Destination Address
Either the Solicited-Node multicast address of the receiver or
the link-scoped All-Nodes multicast address.
Hop Limit
255
ICMP Fields:
Type
149
Code
0
Checksum
The ICMP checksum [6].
Identifier
A 16-bit unsigned integer field, acting as an identifier to
help match advertisements to solicitations. The Identifier
field MUST be zero for advertisements sent to the All-Nodes
multicast address and MUST NOT be zero for others.
All Components
A 16-bit unsigned integer field, used to inform the receiver of
the number of certificates in the entire path.
A single advertisement SHOULD be broken into separately sent
components if there is more than one certificate in the path,
in order to avoid excessive fragmentation at the IP layer.
Individual certificates in a path MAY be stored and used as
received before all the certificates have arrived; this makes
the protocol slightly more reliable and less prone to Denial-
of-Service attacks.
Examples of packet lengths of Certification Path Advertisement
messages for typical certification paths are listed in Appendix
C.
Component
A 16-bit unsigned integer field, used to inform the receiver
which certificate is being sent.
The first message in an N-component advertisement has the
Component field set to N-1, the second set to N-2, and so on.
A zero indicates that there are no more components coming in
this advertisement.
The sending of path components SHOULD be ordered so that the
certificate after the trust anchor is sent first. Each
certificate sent after the first can be verified with the
previously sent certificates. The certificate of the sender
comes last. The trust anchor certificate SHOULD NOT be sent.
Reserved
An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Valid Options:
Certificate
One certificate is provided in each Certificate option to
establish part of a certification path to a trust anchor.
The certificate of the trust anchor itself SHOULD NOT be sent.
Trust Anchor
Zero or more Trust Anchor options may be included to help
receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a
multi-component advertisement.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST
have a length that is greater than zero.
The ICMP length (derived from the IP length) MUST be 8 or more
octets.
6.4.3. Trust Anchor Option
The format of the Trust Anchor option is described in the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
15
Length
The length of the option (including the Type, Length, Name Type,
Pad Length, and Name fields), in units of 8 octets.
Name Type
The type of the name included in the Name field. This
specification defines two legal values for this field:
1 DER Encoded X.501 Name
2 FQDN
Pad Length
The number of padding octets beyond the end of the Name field but
within the length specified by the Length field. Padding octets
MUST be set to zero by senders and ignored by receivers.
Name
When the Name Type field is set to 1, the Name field contains a
DER encoded X.501 Name identifying the trust anchor. The value is
encoded as defined in [12] and [7].
When the Name Type field is set to 2, the Name field contains a
Fully Qualified Domain Name of the trust anchor; for example,
"trustanchor.example.com". The name is stored as a string, in the
DNS wire format, as specified in RFC 1034 [1]. Additionally, the
restrictions discussed in RFC 3280 [7], Section 4.2.1.7 apply.
In the FQDN case, the Name field is an "IDN-unaware domain name
slot", as defined in [9]. That is, it can contain only ASCII
characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [9] for more
information.
All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type.
Padding
A variable-length field making the option length a multiple of 8,
beginning after the previous field ends and continuing to the end
of the option, as specified by the Length field.
6.4.4. Certificate Option
The format of the certificate option is described in the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
16
Length
The length of the option (including the Type, Length, Cert Type,
Pad Length, and Certificate fields), in units of 8 octets.
Cert Type
The type of the certificate included in the Certificate field.
This specification defines only one legal value for this field:
1 X.509v3 Certificate, as specified below
Reserved
An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
Certificate
When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [7], as described in Section
6.3.1.
Padding
A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field [7, 15]
ends and continuing to the end of the option, as specified by the
Length field.
6.4.5. Processing Rules for Routers
A router MUST silently discard any received Certification Path
Solicitation messages that do not conform to the message format
defined in Section 6.4.1. The contents of the Reserved field and of
any unrecognized options MUST be ignored. Future, backward-
compatible changes to the protocol may specify the contents of the
Reserved field or add new options; backward-incompatible changes may
use different Code values. The contents of any defined options that
are not specified to be used with Router Solicitation messages MUST
be ignored, and the packet processed in the normal manner. The only
defined option that may appear is the Trust Anchor option. A
solicitation that passes the validity checks is called a "valid
solicitation".
Routers SHOULD send advertisements in response to valid solicitations
received on an advertising interface. If the source address in the
solicitation was the unspecified address, the router MUST send the
response to the link-scoped All-Nodes multicast address. If the
source address was a unicast address, the router MUST send the
response to the Solicited-Node multicast address corresponding to the
source address, except when under load, as specified below. Routers
SHOULD NOT send Certification Path Advertisements more than
MAX_CPA_RATE times within a second. When there are more
solicitations, the router SHOULD send the response to the All-Nodes
multicast address regardless of the source address that appeared in
the solicitation.
In an advertisement, the router SHOULD include suitable Certificate
options so that a certification path can be established to the
solicited trust anchor (or a part of it, if the Component field in
the solicitation is not equal to 65,535). Note also that a single
advertisement is broken into separately sent components and ordered
in a particular way (see Section 6.4.2) when there is more than one
certificate in the path.
The anchor is identified by the Trust Anchor option. If the Trust
Anchor option is represented as a DER Encoded X.501 Name, then the
Name must be equal to the Subject field in the anchor’s certificate.
If the Trust Anchor option is represented as an FQDN, the FQDN must
be equal to an FQDN in the subjectAltName field of the anchor’s
certificate. The router SHOULD include the Trust Anchor option(s) in
the advertisement for which the certification path was found.
If the router is unable to find a path to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case,
the router SHOULD include the Trust Anchor options that were
solicited.
6.4.6. Processing Rules for Hosts
A host MUST silently discard any received Certification Path
Advertisement messages that do not conform to the message format
defined in Section 6.4.2. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future, backward-
compatible changes to the protocol MAY specify the contents of the
Reserved field or add new options; backward-incompatible changes MUST
use different Code values. The contents of any defined options not
specified to be used with Certification Path Advertisement messages
MUST be ignored, and the packet processed in the normal manner. The
only defined options that may appear are the Certificate and Trust
Anchor options. An advertisement that passes the validity checks is
called a "valid advertisement".
Hosts SHOULD store certification paths retrieved in Certification
Path Discovery messages if they start from an anchor trusted by the
host. The certification paths MUST be verified, as defined in
Section 6.3, before storing them. Routers send the certificates one
by one, starting from the trust anchor end of the path.
Note: Except to allow for message loss and reordering for temporary
purposes, hosts might not store certificates received in a
Certification Path Advertisement unless they contain a certificate
that can be immediately verified either to the trust anchor or to a
certificate that has been verified earlier. This measure is intended
to prevent Denial-of-Service attacks, whereby an attacker floods a
host with certificates that the host cannot validate and overwhelms
memory for certificate storage.
Note that caching this information, and the implied verification
results between network attachments for use over multiple attachments
to the network, can help improve performance. But periodic
certificate revocation checks are still needed, even with cached
results, to make sure that the certificates are still valid.
The host SHOULD retrieve a certification path when a Router
Advertisement has been received with a public key that is not
available from a certificate in the hosts’ cache, or when there is no
certification path to one of the host’s trust anchors. In these
situations, the host MAY send a Certification Path Solicitation
message to retrieve the path. If there is no response within
CPS_RETRY seconds, the message should be retried. The wait interval
for each subsequent retransmission MUST exponentially increase,
doubling each time. If there is no response after CPS_RETRY_MAX
seconds, the host abandons the certification path retrieval process.
If the host receives only a part of a certification path within
CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in
addition transmit a Certification Path Solicitation message with the
Component field set to a value not equal to 65,535. This message can
be retransmitted by using the same process as for the initial
message. If there are multiple missing certificates, additional CPS
messages can be sent after getting a response to first one. However,
the complete retrieval process may last at most CPS_RETRY_MAX
seconds.
Certification Path Solicitations SHOULD NOT be sent if the host has a
currently valid certification path from a reachable router to a trust
anchor.
When soliciting certificates for a router, a host MUST send
Certification Path Solicitations either to the All-Routers multicast
address, if it has not selected a default router yet, or to the
default router’s IP address, if a default router has already been
selected.
If two hosts want to establish trust with the CPS and CPA messages,
the CPS message SHOULD be sent to the Solicited-Node multicast
address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are outside
the scope of this specification.
When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process those advertisements
with the same Identifier field value as that of the solicitation
first. This makes Denial-of-Service attacks against the mechanism
harder (see Section 9.3).
6.5. Configuration
End hosts are configured with a set of trust anchors in order to
protect Router Discovery. A trust anchor configuration consists of
the following items:
o A public key signature algorithm and associated public key, which
may optionally include parameters.
o A name as described in Section 6.4.3.
o An optional public key identifier.
o An optional list of address ranges for which the trust anchor is
authorized.
If the host has been configured to use SEND, it SHOULD possess the
above information for at least one trust anchor.
Routers are configured with a collection of certification paths and a
collection of certificates containing certified keys, down to the key
and certificate for the router itself. Certified keys are required
for routers so that a certification path can be established between
the router’s certificate and the public key of a trust anchor.
If the router has been configured to use SEND, it should be
configured with its own key pair and certificate, and with at least
one certification path.
7. Addressing
7.1. CGAs
By default, a SEND-enabled node SHOULD use only CGAs for its own
addresses. Other types of addresses MAY be used in testing, in
diagnostics, or for other purposes. However, this document does not
describe how to choose between different types of addresses for
different communications. A dynamic selection can be provided by an
API, such as the one defined in [21].
7.2. Redirect Addresses
If the Target Address and Destination Address fields in the ICMP
Redirect message are equal, then this message is used to inform hosts
that a destination is, in fact, a neighbor. In this case, the
receiver MUST verify that the given address falls within the range
defined by the router’s certificate. Redirect messages failing this
check MUST be treated as unsecured, as described in Section 7.3.
Note that base NDP rules prevent a host from accepting a Redirect
message from a router that the host is not using to reach the
destination mentioned in the redirect. This prevents an attacker
from tricking a node into redirecting traffic when the attacker is
not the default router.
7.3. Advertised Subnet Prefixes
The router’s certificate defines the address range(s) that it is
allowed to advertise securely. A router MAY, however, advertise a
combination of certified and uncertified subnet prefixes.
Uncertified subnet prefixes are treated as unsecured (i.e., processed
in the same way as unsecured router advertisements sent by non-SEND
routers). The processing of unsecured messages is specified in
Section 8. Note that SEND nodes that do not attempt to interoperate
with non-SEND nodes MAY simply discard the unsecured information.
Certified subnet prefixes fall into the following two categories:
Constrained
If the network operator wants to constrain which routers are
allowed to route particular subnet prefixes, routers should be
configured with certificates having subnet prefixes listed in the
prefix extension. These routers SHOULD advertise the subnet
prefixes that they are certified to route, or a subset thereof.
Unconstrained
Network operators that do not want to constrain routers this way
should configure routers with certificates containing either the
null prefix or no prefix extension at all.
Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check
are treated as containing uncertified subnet prefixes.
Nodes SHOULD use one of the certified subnet prefixes for stateless
autoconfiguration. If none of the advertised subnet prefixes match,
the host SHOULD use a different advertising router as its default
router, if one is available. If the node is performing stateful
autoconfiguration, it SHOULD check the address provided by the DHCP
server against the certified subnet prefixes and SHOULD NOT use the
address if the prefix is not certified.
7.4. Limitations
This specification does not address the protection of NDP packets for
nodes configured with a static address (e.g., PREFIX::1). Future
certification path-based authorization specifications are needed for
these nodes. This specification also does not apply to addresses
generated by the IPv6 stateless address autoconfiguration from a
fixed interface identifiers (such as EUI-64).
It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing
addresses. These addresses may be the result of stateful or
stateless address autoconfiguration, or may have resulted from the
use of RFC 3041 [17] addresses. If the CGA method is not used, nodes
are required to exchange certification paths that terminate in a
certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify
the format of these certificates, as there are currently only a few
cases where they are provided by the link layer, and it is up to the
link layer to provide certification for the interface identifier.
This may be the subject of a future specification. It is also
outside the scope of this specification to describe how stateful
address autoconfiguration works with the CGA method.
The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in proxy Neighbor
Discovery, which is not supported by this specification.
8. Transition Issues
During the transition to secured links, or as a policy consideration,
network operators may want to run a particular link with a mixture of
nodes accepting secured and unsecured messages. Nodes that support
SEND SHOULD support the use of secured and unsecured NDP messages at
the same time.
In a mixed environment, SEND nodes receive both secured and unsecured
messages but give priority to secured ones. Here, the "secured"
messages are those that contain a valid signature option, as
specified above, and "unsecured" messages are those that contain no
signature option.
A SEND node SHOULD have a configuration option that causes it to
ignore all unsecured Neighbor Solicitation and Advertisement, Router
Solicitation and Advertisement, and Redirect messages. This can be
used to enforce SEND-only networks. The default for this
configuration option SHOULD be that both secured and unsecured
messages are allowed.
A SEND node MAY also have a configuration option whereby it disables
the use of SEND completely, even for the messages it sends itself.
This configuration option SHOULD be switched off by default; that is,
SEND is used. Plain (non-SEND) NDP nodes will obviously send only
unsecured messages. Per RFC 2461 [4], such nodes will ignore the
unknown options and will treat secured messages in the same way that
they treat unsecured ones. Secured and unsecured nodes share the
same network resources, such as subnet prefixes and address spaces.
SEND nodes configured to use SEND at least in their own messages
behave in a mixed environment as explained below.
SEND adheres to the rules defined for the base NDP protocol, with the
following exceptions:
o All solicitations sent by a SEND node MUST be secured.
o Unsolicited advertisements sent by a SEND node MUST be secured.
o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements sent in response to an
unsecured solicitation MUST be secured as well, but MUST NOT
contain the Nonce option.
o A SEND node that uses the CGA authorization method to protect
Neighbor Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates that the
tentative address is already in use, the node generates a new
tentative CGA. If after three consecutive attempts no non-unique
address is generated, it logs a system error and gives up