1/base.txt 2/issue13.txt
Secure Neighbor Discovery Working J. Arkko Secure Neighbor Discovery Working J. Arkko
Group Ericsson Group Ericsson
Internet-Draft J. Kempf Internet-Draft J. Kempf
Expires: June 8, 2004 DoCoMo Communications Labs USA Expires: June 9, 2004 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
December 9, 2003 December 10, 2003
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-pre01 draft-ietf-send-ndopt-pre01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
  Skipping to change at page 1, line 39:
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 8, 2004. This Internet-Draft will expire on June 9, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine each the link-layer addresses other nodes on the link, to determine each the link-layer addresses
of the nodes on the link, to find routers, and to maintain of the nodes on the link, to find routers, and to maintain
  Skipping to change at page 2, line 14:
secured, NDP is vulnerable to various attacks. This document secured, NDP is vulnerable to various attacks. This document
specifies security mechanisms for NDP. Unlike to the original NDP specifies security mechanisms for NDP. Unlike to the original NDP
specifications, these mechanisms do not make use of IPsec. specifications, these mechanisms do not make use of IPsec.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . 7 3. Neighbor and Router Discovery Overview . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 11 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 10
5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 12 5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 11
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . 12 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . 11
5.1.1 Processing Rules for Senders . . . . . . . . .14 5.1.1 Processing Rules for Senders . . . . . . . . .13
5.1.2 Processing Rules for Receivers . . . . . . . .14 5.1.2 Processing Rules for Receivers . . . . . . . .13
5.1.3 Configuration . . . . . . . . . . . . . . . .15 5.1.3 Configuration . . . . . . . . . . . . . . . .14
5.2 Signature Option . . . . . . . . . . . . . . . . . . 15 5.2 Signature Option . . . . . . . . . . . . . . . . . . 14
5.2.1 Processing Rules for Senders . . . . . . . . .18 5.2.1 Processing Rules for Senders . . . . . . . . .17
5.2.2 Processing Rules for Receivers . . . . . . . .18 5.2.2 Processing Rules for Receivers . . . . . . . .17
5.2.3 Configuration . . . . . . . . . . . . . . . .19 5.2.3 Configuration . . . . . . . . . . . . . . . .18
5.3 Timestamp and Nonce options . . . . . . . . . . . . 20 5.3 Timestamp and Nonce options . . . . . . . . . . . . 19
5.3.1 Timestamp Option . . . . . . . . . . . . . . .20 5.3.1 Timestamp Option . . . . . . . . . . . . . . .19
5.3.2 Nonce Option . . . . . . . . . . . . . . . . .21 5.3.2 Nonce Option . . . . . . . . . . . . . . . . .20
5.3.3 Processing rules for senders . . . . . . . . .22 5.3.3 Processing rules for senders . . . . . . . . .21
5.3.4 Processing rules for receivers . . . . . . . .22 5.3.4 Processing rules for receivers . . . . . . . .21
5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 24 5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 23
6. Authorization Delegation Discovery . . . . . . . . . . . . 25 6. Authorization Delegation Discovery . . . . . . . . . . . . 24
6.1 Delegation Chain Solicitation Message Format . . . . 25 6.1 Certificate Format . . . . . . . . . . . . . . . . . 24
6.2 Delegation Chain Advertisement Message Format . . . 27 6.1.1 Router Authorization Certificate Profile . . .24
6.3 Trust Anchor Option . . . . . . . . . . . . . . . . 29 6.2 Certificate Transport . . . . . . . . . . . . . . . 25
6.4 Certificate Option . . . . . . . . . . . . . . . . . 30 6.2.1 Delegation Chain Solicitation Message Format .26
6.5 Router Authorization Certificate Format . . . . . . 31 6.2.2 Delegation Chain Advertisement Message Format 27
6.5.1 Router Authorization Certificate Profile . . .32 6.2.3 Trust Anchor Option . . . . . . . . . . . . .30
6.6 Processing Rules for Routers . . . . . . . . . . . . 33 6.2.4 Certificate Option . . . . . . . . . . . . . .31
6.7 Processing Rules for Hosts . . . . . . . . . . . . . 34 6.2.5 Processing Rules for Routers . . . . . . . . .32
7. Securing Neighbor Discovery with SEND . . . . . . . . . . 37 6.2.6 Processing Rules for Hosts . . . . . . . . . .33
7.1 Neighbor Solicitation Messages . . . . . . . . . . . 37 7. Securing Neighbor Discovery with SEND . . . . . . . . . . 36
7.1.1 Sending Secure Neighbor Solicitations . . . .37 7.1 Neighbor Solicitation Messages . . . . . . . . . . . 36
7.1.2 Receiving Secure Neighbor Solicitations . . .37 7.1.1 Sending Secure Neighbor Solicitations . . . .36
7.2 Neighbor Advertisement Messages . . . . . . . . . . 37 7.1.2 Receiving Secure Neighbor Solicitations . . .36
7.2.1 Sending Secure Neighbor Advertisements . . . .37 7.2 Neighbor Advertisement Messages . . . . . . . . . . 36
7.2.2 Receiving Secure Neighbor Advertisements . . .38 7.2.1 Sending Secure Neighbor Advertisements . . . .36
7.3 Other Requirements . . . . . . . . . . . . . . . . . 38 7.2.2 Receiving Secure Neighbor Advertisements . . .37
8. Securing Router Discovery with SEND . . . . . . . . . . . 40 7.3 Other Requirements . . . . . . . . . . . . . . . . . 37
8.1 Router Solicitation Messages . . . . . . . . . . . . 40 8. Securing Router Discovery with SEND . . . . . . . . . . . 39
8.1.1 Sending Secure Router Solicitations . . . . .40 8.1 Router Solicitation Messages . . . . . . . . . . . . 39
8.1.2 Receiving Secure Router Solicitations . . . .40 8.1.1 Sending Secure Router Solicitations . . . . .39
8.2 Router Advertisement Messages . . . . . . . . . . . 40 8.1.2 Receiving Secure Router Solicitations . . . .39
8.2.1 Sending Secure Router Advertisements . . . . .41 8.2 Router Advertisement Messages . . . . . . . . . . . 39
8.2.2 Receiving Secure Router Advertisements . . . .41 8.2.1 Sending Secure Router Advertisements . . . . .40
8.3 Redirect Messages . . . . . . . . . . . . . . . . . 41 8.2.2 Receiving Secure Router Advertisements . . . .40
8.3.1 Sending Redirects . . . . . . . . . . . . . .41 8.3 Redirect Messages . . . . . . . . . . . . . . . . . 40
8.3.2 Receiving Redirects . . . . . . . . . . . . .42 8.3.1 Sending Redirects . . . . . . . . . . . . . .40
8.4 Other Requirements . . . . . . . . . . . . . . . . . 42 8.3.2 Receiving Redirects . . . . . . . . . . . . .41
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 43 8.4 Other Requirements . . . . . . . . . . . . . . . . . 41
10. Performance Considerations . . . . . . . . . . . . . . . . 45 9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . 46 10. Performance Considerations . . . . . . . . . . . . . . . . 44
11.1 Threats to the Local Link Not Covered by SEND . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . 45
11.2 How SEND Counters Threats to Neighbor Discovery . . 47 11.1 Threats to the Local Link Not Covered by SEND . . . 45
11.2.1 Neighbor Solicitation/Advertisement Spoofing .47 11.2 How SEND Counters Threats to Neighbor Discovery . . 46
11.2.2 Neighbor Unreachability Detection Failure . .48 11.2.1 Neighbor Solicitation/Advertisement Spoofing .46
11.2.3 Duplicate Address Detection DoS Attack . . . .48 11.2.2 Neighbor Unreachability Detection Failure . .47
11.2.4 Router Solicitation and Advertisement Attacks 49 11.2.3 Duplicate Address Detection DoS Attack . . . .47
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49 11.2.4 Router Solicitation and Advertisement Attacks 48
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49 11.2.5 Replay Attacks . . . . . . . . . . . . . . . .48
11.3 Attacks against SEND Itself . . . . . . . . . . . . 50 11.2.6 Neighbor Discovery DoS Attack . . . . . . . .48
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 51 11.3 Attacks against SEND Itself . . . . . . . . . . . . 49
13. IANA Considerations . . . . . . . . . . . . . . . . . . . 52 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 50
Normative References . . . . . . . . . . . . . . . . . . . 53 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . 54 Normative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55 Informative References . . . . . . . . . . . . . . . . . . 53
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 58 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 59 C. Cache Management . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . 62 D. Comparison to AH-Based Approach . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . 61
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [7]. IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [7].
Nodes on the same link use NDP to discover each other's presence, to Nodes on the same link use NDP to discover each other's presence, to
determine each other's link-layer addresses, to find routers, and to determine each other's link-layer addresses, to find routers, and to
maintain reachability information about the paths to active maintain reachability information about the paths to active
neighbors. NDP is used both by hosts and routers. Its functions neighbors. NDP is used both by hosts and routers. Its functions
include Neighbor Discovery (ND), Router Discovery (RD), Address include Neighbor Discovery (ND), Router Discovery (RD), Address
Autoconfiguration, Address Resolution, Neighbor Unreachability Autoconfiguration, Address Resolution, Neighbor Unreachability
  Skipping to change at page 5, line 51:
Nonce Nonce
A random number generated by a node and used exactly once, and A random number generated by a node and used exactly once, and
never again. In SEND, nonces are used to ensure that a particular never again. In SEND, nonces are used to ensure that a particular
advertisement is linked to the solicitation that triggered it. advertisement is linked to the solicitation that triggered it.
Router Authorization Certificate Router Authorization Certificate
An X.509v3 [10] PKC certificate using the profile specified in An X.509v3 [10] PKC certificate using the profile specified in
Section 6.5.1. Section 6.1.1.
SEND node SEND node
An IPv6 node that implements this specification. An IPv6 node that implements this specification.
non-SEND node non-SEND node
An IPv6 node that does not implement this specification but uses An IPv6 node that does not implement this specification but uses
the legacy RFC 2461 and RFC 2462 mechanisms. the legacy RFC 2461 and RFC 2462 mechanisms.
  Skipping to change at page 7, line 24:
In IPv6, many of the tasks traditionally performed at lower the In IPv6, many of the tasks traditionally performed at lower the
layers, such as ARP, have been moved to the IP layer. As a layers, such as ARP, have been moved to the IP layer. As a
consequence, a set of unified mechanisms can be applied across link consequence, a set of unified mechanisms can be applied across link
layers, any introduced security mechanisms or other extensions can be layers, any introduced security mechanisms or other extensions can be
adopted more easily, and a clear separation of the roles between the adopted more easily, and a clear separation of the roles between the
IP and link layer has been achieved. IP and link layer has been achieved.
The main functions of IPv6 Neighbor Discovery are the following. The main functions of IPv6 Neighbor Discovery are the following.
o Neighbor Unreachability Detection (NUD) is used for tracking the o The Router Discovery function allows IPv6 hosts to discover the
reachability of neighboring nodes, both hosts and routers. NUD is local routers on an attached link. Router Discovery is described
defined in Section 7.3 of RFC 2461 [7]. NUD is in Section 6 of RFC 2461 [7]. The main purpose of Router
security-sensitive, because an attacker could falsely claim that Discovery is to find neighboring routers that are willing to
reachability exists when it in fact does not. forward packets on behalf of hosts. Prefix discovery involves
determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should
be sent to a router or to the destination node directly.
o The Redirect function is used for automatically redirecting hosts
to an alternate router. Redirect is specified in Section 8 of RFC
2461 [7]. It is similar to the ICMPv4 Redirect function [15].
o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The Address
Autoconfiguration mechanism defined in [8] is stateless. To
create IP addresses, the hosts use any prefix information
delivered to them during Router Discovery, and then test the newly
formed addresses for uniqueness. A stateful mechanism, DHCPv6
[24], provides additional Autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address o Duplicate Address Detection (DAD) is used for preventing address
collisions [8]. A node that intends to assign a new address to collisions [8], for instance during Address Autoconfiguration. A
one of its interfaces first runs the DAD procedure to verify that node that intends to assign a new address to one of its interfaces
there is no other node using the same address. Since the rules first runs the DAD procedure to verify that there is no other node
forbid the use of an address until it has been found unique, no using the same address. Since the rules forbid the use of an
higher layer traffic is possible until this procedure has been address until it has been found unique, no higher layer traffic is
completed. Thus, preventing attacks against DAD can help ensure possible until this procedure has been completed. Thus,
the availability of communications for the node in question. preventing attacks against DAD can help ensure the availability of
communications for the node in question.
o Address Resolution is similar to IPv4 ARP [16]. The Address o Address Resolution is similar to IPv4 ARP [16]. The Address
Resolution function resolves a node's IPv6 address to the Resolution function resolves a node's IPv6 address to the
corresponding link-layer address for nodes on the link. Address corresponding link-layer address for nodes on the link. Address
Resolution is defined in Section 7.2 of RFC 2461 [7], and it is Resolution is defined in Section 7.2 of RFC 2461 [7], and it is
used for hosts and routers alike. Again, no higher level traffic used for hosts and routers alike. Again, no higher level traffic
can proceed until the sender knows the hardware address of the can proceed until the sender knows the hardware address of the
destination node or the next hop router. Note that like its destination node or the next hop router. Note that like its
predecessor in ARP, IPv6 Neighbor Discovery does not check the predecessor in ARP, IPv6 Neighbor Discovery does not check the
source link layer address against the information learned through source link layer address against the information learned through
Address Resolution. This allows for an easier addition of network Address Resolution. This allows for an easier addition of network
elements such as bridges and proxies, and eases the stack elements such as bridges and proxies, and eases the stack
implementation requirements as less information needs to be passed implementation requirements as less information needs to be passed
from layer to layer. from layer to layer.
o Address Autoconfiguration is used for automatically assigning o Neighbor Unreachability Detection (NUD) is used for tracking the
addresses to a host [8]. This allows hosts to operate without reachability of neighboring nodes, both hosts and routers. NUD is
explicit configuration related to IP connectivity. The Address defined in Section 7.3 of RFC 2461 [7]. NUD is
Autoconfiguration mechanism defined in [8] is stateless. To security-sensitive, because an attacker could falsely claim that
create IP addresses, the hosts use any prefix information reachability exists when it in fact does not.
delivered to them during Router Discovery, and then test the newly
formed addresses for uniqueness using the DAD procedure. A
stateful mechanism, DHCPv6 [24], provides additional
Autoconfiguration features. Router and Prefix Discovery and
Duplicate Address Detection have an effect on the Address
Autoconfiguration tasks.
o The Redirect function is used for automatically redirecting hosts
to an alternate router. Redirect is specified in Section 8 of RFC
2461 [7]. It is similar to the ICMPv4 Redirect function [15].
o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [7]. The main purpose of Router
Discovery is to find neighboring routers that are willing to
forward packets on behalf of hosts. Prefix discovery involves
determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should
be sent to a router or to the destination node directly.
Typically, address autoconfiguration and other tasks can not
proceed until suitable routers and prefixes have been found.
The Neighbor Discovery messages follow the ICMPv6 message format. The Neighbor Discovery messages follow the ICMPv6 message format.
They have ICMPv6 types from 133 to 137. The IPv6 Next Header value The actual Neighbor Discovery message includes an NDP message header,
for ICMPv6 is 58. The actual Neighbor Discovery message includes an consisting of an ICMPv6 header and ND message-specific data, and zero
NDP message header, consisting of an ICMPv6 header and ND or more NDP options.
message-specific data, and zero or more NDP options.
<------------NDP Message----------------> <------------NDP Message---------------->
*-------------------------------------------------------------* *-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND message- | ND Message | | IPv6 Header | ICMPv6 | ND message- | ND Message |
| Next Header = 58 | Header | specific | Options | | Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | | | (ICMPv6) | | data | |
*-------------------------------------------------------------* *-------------------------------------------------------------*
<--NDP Message header--> <--NDP Message header-->
The NDP message options are formatted in the Type-Length-Value The NDP message options are formatted in the Type-Length-Value
  Skipping to change at page 9, line 27:
o Duplicate Address Detection uses the NS and NA messages. o Duplicate Address Detection uses the NS and NA messages.
o Address Autoconfiguration uses the NS, NA, RS, and RA messages. o Address Autoconfiguration uses the NS, NA, RS, and RA messages.
o Address Resolution uses the NS and NA messages. o Address Resolution uses the NS and NA messages.
o Neighbor Unreachability Detection uses the NS and NA messages. o Neighbor Unreachability Detection uses the NS and NA messages.
o Redirect uses the Redirect message. o Redirect uses the Redirect message.
The NDP messages are always meant to be used within a link, and never
intended to leak outside of it. The destination and source addresses
used in these messages are as follows:
o Neighbor Solicitation: The destination address is either the
Solicited-Node multicast address, a unicast address, or an anycast
address. The source address is either the unspecified address (in
DAD) or a unicast address assigned to the sending interface. In a
typical case, the source address is equal to the source address of
the outgoing packet, locally triggering the need to send the
solicitation.
o Neighbor Advertisement: The destination address is either a
unicast address or the link-scoped All-Nodes multicast address
[21]. The source address is a unicast address assigned to the
sending interface.
o Router Solicitation: The destination address is typically the
All-Routers multicast address [21]. The source address is either
the unspecified address or a unicast address assigned to the
sending interface. An unspecified source address does not have
any special semantics; it is just an optimization for startup.
o Router Advertisement: The destination address can be either a
unicast or the link-scoped All-Nodes multicast address [21]. The
source address is a link-local address assigned to the sending
interface.
o Redirect: This message is always sent to the source address of the
packet that triggered the Redirect. Hosts verify that the IP
source address of the Redirect is the same as the current
first-hop router for the specified ICMP Destination Address.
Rules in [21] dictate that anycast, or multicast addresses may not
be used as source addresses. If the source address is an
unspecified address, it is impossible to send a Redirect, since
the unspecified address is forbidden as the destination address.
Therefore, the destination address must always be a unicast
address.
The source address is a link-local address assigned to the sending
interface.
4. Secure Neighbor Discovery Overview 4. Secure Neighbor Discovery Overview
To secure the various functions, a set of new Neighbor Discovery To secure the various functions, a set of new Neighbor Discovery
options is introduced. They are used in to protect Neighbor and options is introduced. They are used in to protect Neighbor and
Router Discovery messages. This specification introduces these Router Discovery messages. This specification introduces these
options, an authorization delegation discovery process, an address options, an authorization delegation discovery process, an address
ownership proof mechanism, and requirements for the use of these ownership proof mechanism, and requirements for the use of these
components for Neighbor Discovery. components for Neighbor Discovery.
The components of the solution specified in this document are as The components of the solution specified in this document are as
  Skipping to change at page 19, line 24:
Neighbor Discovery Protocol message type: Neighbor Discovery Protocol message type:
authorization method authorization method
This parameter determines the method through which the authority This parameter determines the method through which the authority
of the sender is determined. It can have four values: of the sender is determined. It can have four values:
trust anchor trust anchor
The authority of the sender is verified as described in Section The authority of the sender is verified as described in Section
6.5. The sender may claim additional authorization through the 6.1. The sender may claim additional authorization through the
use of CGAs, but that is neither required nor verified. use of CGAs, but that is neither required nor verified.
CGA CGA
The CGA property of the sender's address is verified as The CGA property of the sender's address is verified as
described in [12]. The sender may claim additional authority described in [12]. The sender may claim additional authority
through a trust anchor, but that is neither required nor through a trust anchor, but that is neither required nor
verified. verified.
trust anchor and CGA trust anchor and CGA
  Skipping to change at page 25, line 24:
Since the newly-connected node cannot communicate off-link, it can Since the newly-connected node cannot communicate off-link, it can
not be responsible for searching information to help validating the not be responsible for searching information to help validating the
router(s); however, given a chain of appropriately signed router(s); however, given a chain of appropriately signed
certificates, it can check someone else's search results and conclude certificates, it can check someone else's search results and conclude
that a particular message comes from an authorized source. In the that a particular message comes from an authorized source. In the
typical case, a router, which is already connected to beyond the typical case, a router, which is already connected to beyond the
link, can (if necessary) communicate with off-link nodes and link, can (if necessary) communicate with off-link nodes and
construct such a certificate chain. construct such a certificate chain.
The Secure Neighbor Discovery Protocol introduces two new ICMPv6 The Secure Neighbor Discovery Protocol mandates a certificate format
messages that are used between hosts and routers to allow the host to and introduces two new ICMPv6 messages that are used between hosts
learn a certificate chain with the assistance of the router. Where and routers to allow the host to learn a certificate chain with the
hosts themselves are certified by a trust anchor, these messages MAY assistance of the router.
also optionally be used between hosts to acquire the peer's
certificate chain. However, the details of such usage are left for 6.1 Certificate Format
future specification.
The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization chains are not a common practice
in the Internet at the time this specification is being written, the
chain MUST consist of standard Public Key Certificates (PKC, in the
sense of [20]). The certificates chain MUST start from the identity
of a trust anchor that is shared by the host and the router. This
allows the host to anchor trust for the router's public key in the
trust anchor. Note that there MAY be multiple certificates issued by
a single trust anchor.
6.1.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined
in RFC 3280 [10], and MUST contain at least one instance of the X.509
extension for IP addresses, as defined in [11]. The parent
certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to a trusted party (such as the user's
ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The
certificates for intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one
addressesOrRanges element that contains an addressPrefix element with
an IPv6 address prefix for a prefix the router or the intermediate
entity is authorized to advertise. If the entity is allowed to route
any prefix, the used IPv6 address prefix is the null prefix, 0/0.
The addressFamily element of the containing IPAddrBlocks sequence
element MUST contain the IPv6 Address Family Identifier (0002), as
specified in [11] for IPv6 prefixes. Instead of an addressPrefix
element, the addressesOrRange element MAY contain an addressRange
element for a range of prefixes, if more than one prefix is
authorized. The X.509 IP address extension MAY contain additional
IPv6 prefixes, expressed either as an addressPrefix or an
addressRange.
A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attept to
take an intersection of the ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate.
The above check SHOULD be done for all certificates in the chain
received through DCA messages. If any of the checks fail, the client
MUST NOT accept the certificate.
Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default
configuration that requires rigorious prefix and range checks.
6.2 Certificate Transport
The Delegation Chain Solicitation (DCS) message is sent by a host The Delegation Chain Solicitation (DCS) message is sent by a host
when it wishes to request a certificate chain between a router and when it wishes to request a certificate chain between a router and
the one of the host's trust anchors. The Delegation Chain the one of the host's trust anchors. The Delegation Chain
Advertisement (DCA) message is sent as an answer to the DCS message. Advertisement (DCA) message is sent as an answer to the DCS message.
These messages are separate from the rest of Neighbor and Router These messages are separate from the rest of Neighbor and Router
Discovery, in order to reduce the effect of the potentially Discovery, in order to reduce the effect of the potentially
voluminous certificate chain information on other messages. voluminous certificate chain information on other messages.
The Authorization Delegation Discovery (ADD) process does not exclude The Authorization Delegation Discovery (ADD) process does not exclude
other forms of discovering certificate chains. For instance, during other forms of discovering certificate chains. For instance, during
fast movements mobile nodes may learn information - including the fast movements mobile nodes may learn information - including the
certificate chains - of the next router from a previous router. certificate chains - of the next router from a previous router.
6.1 Delegation Chain Solicitation Message Format Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the
peer's certificate chain. However, the details of such usage are
left for future specification.
6.2.1 Delegation Chain Solicitation Message Format
Hosts send Delegation Chain Solicitations in order to prompt routers Hosts send Delegation Chain Solicitations in order to prompt routers
to generate Delegation Chain Advertisements. to generate Delegation Chain Advertisements.
0 1 2 3 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 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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Reserved |
  Skipping to change at page 27, line 17:
An unused field. It MUST be initialized to zero by the sender An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Valid Options: Valid Options:
Trust Anchor Trust Anchor
One or more trust anchors that the client is willing to accept. One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.3. If there are more than Encoded X.501 Name; see Section 6.2.3. If there are more than
one Trust Anchor options, the options past the first one may one Trust Anchor options, the options past the first one may
contain any types of Trust Anchors. contain any types of Trust Anchors.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message.
6.2 Delegation Chain Advertisement Message Format 6.2.2 Delegation Chain Advertisement Message Format
Routers send out Delegation Chain Advertisement messages in response Routers send out Delegation Chain Advertisement messages in response
to a Delegation Chain Solicitation. to a Delegation Chain Solicitation.
0 1 2 3 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 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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component | | Identifier | Component |
  Skipping to change at page 29, line 37:
Zero or more Trust Anchor options may be included to help Zero or more Trust Anchor options may be included to help
receivers decide which advertisements are useful for them. If receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a present, these options MUST appear in the first component of a
multi-component advertisement. multi-component advertisement.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message.
6.3 Trust Anchor Option 6.2.3 Trust Anchor Option
The format of the Trust Anchor option is as described in the The format of the Trust Anchor option is as described in the
following: following:
0 1 2 3 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 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 | | Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... | Name ...
  Skipping to change at page 30, line 44:
When the Name Type field is set to 2, the Name field contains a When the Name Type field is set to 2, the Name field contains a
Fully Qualified Domain Name of the trust anchor, for example, Fully Qualified Domain Name of the trust anchor, for example,
"trustanchor.example.com". The name is stored as a string, in the "trustanchor.example.com". The name is stored as a string, in the
"preferred name syntax" DNS format, as specified in RFC 1034 [1] "preferred name syntax" DNS format, as specified in RFC 1034 [1]
Section 3.5. Additionally, the restrictions discussed in RFC 3280 Section 3.5. Additionally, the restrictions discussed in RFC 3280
[10] Section 4.2.1.7 apply. [10] Section 4.2.1.7 apply.
All systems MUST implement support the DER Encoded X.501 Name. All systems MUST implement support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type. Implementations MAY support the FQDN name type.
6.4 Certificate Option 6.2.4 Certificate Option
The format of the certificate option is as described in the The format of the certificate option is as described in the
following: following:
0 1 2 3 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 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 | Pad Length | | Type | Length | Cert Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ... | Certificate ...
  Skipping to change at page 31, line 42:
The number of padding octets beyond the end of the Certificate The number of padding octets beyond the end of the Certificate
field but within the length specified by the Length field. field but within the length specified by the Length field.
Padding octets MUST be set to zero by senders and ignored by Padding octets MUST be set to zero by senders and ignored by
receivers. receivers.
Certificate Certificate
When the Cert Type field is set to 1, the Certificate field When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [10], as described in Section contains an X.509v3 certificate [10], as described in Section
6.5.1. 6.1.1.
6.5 Router Authorization Certificate Format
The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization chains are not a common practice
in the Internet at the time this specification is being written, the
chain MUST consist of standard Public Key Certificates (PKC, in the
sense of [20]). The certificates chain MUST start from the identity
of a trust anchor that is shared by the host and the router. This
allows the host to anchor trust for the router's public key in the
trust anchor. Note that there MAY be multiple certificates issued by
a single trust anchor.
6.5.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined
in RFC 3280 [10], and MUST contain at least one instance of the X.509
extension for IP addresses, as defined in [11]. The parent
certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to a trusted party (such as the user's
ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The
certificates for intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one
addressesOrRanges element that contains an addressPrefix element with
an IPv6 address prefix for a prefix the router or the intermediate
entity is authorized to advertise. If the entity is allowed to route
any prefix, the used IPv6 address prefix is the null prefix, 0/0.
The addressFamily element of the containing IPAddrBlocks sequence
element MUST contain the IPv6 Address Family Identifier (0002), as
specified in [11] for IPv6 prefixes. Instead of an addressPrefix
element, the addressesOrRange element MAY contain an addressRange
element for a range of prefixes, if more than one prefix is
authorized. The X.509 IP address extension MAY contain additional
IPv6 prefixes, expressed either as an addressPrefix or an
addressRange.
A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attept to
take an intersection of the ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate.
The above check SHOULD be done for all certificates in the chain
received through DCA messages. If any of the checks fail, the client
MUST NOT accept the certificate.
Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default
configuration that requires rigorious prefix and range checks.
6.6 Processing Rules for Routers 6.2.5 Processing Rules for Routers
Routers SHOULD possess a key pair and a certificate from at least one Routers SHOULD possess a key pair and a certificate from at least one
certificate authority. certificate authority.
A router MUST silently discard any received Delegation Chain A router MUST silently discard any received Delegation Chain
Solicitation messages that do not satisfy all of the following Solicitation messages that do not satisfy all of the following
validity checks: validity checks:
o The IP Hop Limit field MUST have a value of 255, i.e., the packet o The IP Hop Limit field MUST have a value of 255, i.e., the packet
could not possibly have been forwarded by a router. could not possibly have been forwarded by a router.
  Skipping to change at page 34, line 30:
an FQDN, the FQDN must be equal to an FQDN in the subjectAltName an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
field of the anchor's certificate. The router SHOULD include the field of the anchor's certificate. The router SHOULD include the
Trust Anchor option(s) in the advertisement for which the delegation Trust Anchor option(s) in the advertisement for which the delegation
chain was found. chain was found.
If the router is unable to find a chain to the requested anchor, it If the router is unable to find a chain to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trust Anchor options which were the router SHOULD include the Trust Anchor options which were
solicited. solicited.
6.7 Processing Rules for Hosts 6.2.6 Processing Rules for Hosts
Hosts SHOULD possess the public key and trust anchor name of at least Hosts SHOULD possess the public key and trust anchor name of at least
one certificate authority, they SHOULD possess their own key pair, one certificate authority, they SHOULD possess their own key pair,
and they MAY posses a certificate from the above mentioned and they MAY posses a certificate from the above mentioned
certificate authority. certificate authority.
A host MUST silently discard any received Delegation Chain A host MUST silently discard any received Delegation Chain
Advertisement messages that do not satisfy all of the following Advertisement messages that do not satisfy all of the following
validity checks: validity checks:
  Skipping to change at page 35, line 30:
contents of any defined options that are not specified to be used contents of any defined options that are not specified to be used
with Delegation Chain Advertisement messages MUST be ignored and the with Delegation Chain Advertisement messages MUST be ignored and the
packet processed in the normal manner. The only defined options that packet processed in the normal manner. The only defined options that
may appear are the Certificate and Trust Anchor options. An may appear are the Certificate and Trust Anchor options. An
advertisement that passes the validity checks is called a "valid advertisement that passes the validity checks is called a "valid
advertisement". advertisement".
Hosts SHOULD store certificate chains retrieved in Delegation Chain Hosts SHOULD store certificate chains retrieved in Delegation Chain
Discovery messages if they start from an anchor trusted by the host. Discovery messages if they start from an anchor trusted by the host.
The certificates chains SHOULD be verified, as defined in Section The certificates chains SHOULD be verified, as defined in Section
6.5, before storing them. Routers are required to send the 6.1, before storing them. Routers are required to send the
certificates one by one, starting from the trust anchor end of the certificates one by one, starting from the trust anchor end of the
chain. Except for temporary purposes to allow for message loss and chain. Except for temporary purposes to allow for message loss and
reordering, hosts SHOULD NOT store certificates received in a reordering, hosts SHOULD NOT store certificates received in a
Delegation Chain Advertisement unless they contain a certificate Delegation Chain Advertisement unless they contain a certificate
which can be immediately verified either to the trust anchor or to a which can be immediately verified either to the trust anchor or to a
certificate which has been verified earlier. certificate which has been verified earlier.
Note that it may be useful to cache this information and implied Note that it may be useful to cache this information and implied
verification results for use over multiple attachments to the verification results for use over multiple attachments to the
network. network.
  Skipping to change at page 42, line 26:
The Signature option MUST be constructed with the configured The Signature option MUST be constructed with the configured
authorization method(s), the used key being within the configured authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value. an acceptable trust anchor and/or minSec value.
The configured authorization methods MUST include the trust anchor The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to authorization method, and MAY be additionally configured to
require CGA authorization. require CGA authorization.
The receiver MUST verify that the Redirect message comes from an Note that RFC 2461 rules already prevent a bogus router from
IP address to which the host may have earlier sent the packet that sending a Redirect message when the host is not using the bogus
the Redirect message now partially returns. That is, the source router as a default router.
address of the Redirect message must be the default router or the
on-link destination host for traffic sent to the destination of
the returned packet. If this is not the case, the message MUST be
silently discarded.
This step prevents a bogus router from sending a Redirect message
when the host is not using the bogus router as a default router.
8.4 Other Requirements 8.4 Other Requirements
Hosts SHOULD use Authorization Delegation Discovery to learn the Hosts SHOULD use Authorization Delegation Discovery to learn the
certificate chain of their default router (or peer host), as certificate chain of their default router (or peer host), as
explained in Section 6. The receipt of a protected Router explained in Section 6. The receipt of a protected Router
Advertisement message for which no router Authorization Certificate Advertisement message for which no router Authorization Certificate
and certificate chain is available triggers Authorization Delegation and certificate chain is available triggers Authorization Delegation
Discovery. Discovery.
  Skipping to change at page 45, line 23:
Routers are required to perform a larger number of operations, Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen ones per second, some of operations is on the order of a few dozen ones per second, some of
which can be precomputed as discussed below. A large number of which can be precomputed as discussed below. A large number of
router solicitations may cause higher demand for performing router solicitations may cause higher demand for performing
asymmetric operations, although RFC 2461 limits the rate at which asymmetric operations, although RFC 2461 limits the rate at which
responses to solicitations can be sent. responses to solicitations can be sent.
Signatures related to the use of the Signature option be precomputed Signatures can be precomputed for unsolicited (multicast) Neighbor
for Multicast Neighbor and Router Advertisements. Typically, and Router Advertisements. Typically, solicited advertisements are
solicited advertisements are sent to the unicast address from which sent to the unicast address from which the solicitation was sent.
the solicitation was sent. Given that the IPv6 header is covered by Given that the IPv6 header is covered by the signature, it is not
the signature, it is typically not possible to precompute possible to precompute solicited-for advertisements.
solicited-for advertisements.
11. Security Considerations 11. Security Considerations
11.1 Threats to the Local Link Not Covered by SEND 11.1 Threats to the Local Link Not Covered by SEND
SEND does not compensate for an insecure link layer. In particular, SEND does not compensate for an insecure link layer. In particular,
there is no cryptographic binding in SEND between the link layer there is no cryptographic binding in SEND between the link layer
frame address and the IPv6 address. On an insecure link layer that frame address and the IPv6 address. On an insecure link layer that
allows nodes to spoof the link layer address of other nodes, an allows nodes to spoof the link layer address of other nodes, an
attacker could disrupt IP service by sending out a Neighbor attacker could disrupt IP service by sending out a Neighbor
  Skipping to change at page 52, line 12:
MAX_DCA_RATE 10 times per second MAX_DCA_RATE 10 times per second
13. IANA Considerations 13. IANA Considerations
This document defines two new ICMP message types, used in This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range: ICMPv6 type numbers from the informational message range:
o The Delegation Chain Solicitation message, described in Section o The Delegation Chain Solicitation message, described in Section
6.1. 6.2.1.
o The Delegation Chain Advertisement message, described in Section o The Delegation Chain Advertisement message, described in Section
6.2. 6.2.2.
This document defines six new Neighbor Discovery Protocol [7] This document defines six new Neighbor Discovery Protocol [7]
options, which must be assigned Option Type values within the option options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages: numbering space for Neighbor Discovery Protocol messages:
o The Trust Anchor option, described in Section 6.3. o The Trust Anchor option, described in Section 6.2.3.
o The Certificate option, described in Section 6.4. o The Certificate option, described in Section 6.2.4.
o The CGA option, described in Section 5.1. o The CGA option, described in Section 5.1.
o The Signature option, described in Section 5.2. o The Signature option, described in Section 5.2.
o The Timestamp option, described in Section 5.3.1. o The Timestamp option, described in Section 5.3.1.
o The Nonce option, described in Section 5.3.2. o The Nonce option, described in Section 5.3.2.
This document defines a new 128-bit CGA Message Type [12] value, This document defines a new 128-bit CGA Message Type [12] value,

Diff produced by rfcdiff v0.34, from http://www.levkowetz.com/ietf/tools/rfcdiff/