1/base.txt		2/issue35.txt
Skipping to change at page 2, line 11:
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
reachability information about the paths to active neighbors. If not		reachability information about the paths to active neighbors. If not
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
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 . . . . . . . . . . . . 11
5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 12		5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 12
5.1 Ordering of the new options . . . . . . . . . . . . 12		5.1 Ordering of the new options . . . . . . . . . . . . 12
5.2 CGA Option . . . . . . . . . . . . . . . . . . . . . 12		5.2 CGA Option . . . . . . . . . . . . . . . . . . . . . 12
5.2.1 Processing Rules for Senders . . . . . . . . .14		5.2.1 Processing Rules for Senders . . . . . . . . .14
5.2.2 Processing Rules for Receivers . . . . . . . .15		5.2.2 Processing Rules for Receivers . . . . . . . .15
5.2.3 Configuration . . . . . . . . . . . . . . . .15		5.2.3 Configuration . . . . . . . . . . . . . . . .15
5.3 Signature Option . . . . . . . . . . . . . . . . . . 16		5.3 Signature Option . . . . . . . . . . . . . . . . . . 16
Skipping to change at page 3, line 24:
11.2 How SEND Counters Threats to Neighbor Discovery . . 47		11.2 How SEND Counters Threats to Neighbor Discovery . . 47
11.2.1 Neighbor Solicitation/Advertisement Spoofing .47		11.2.1 Neighbor Solicitation/Advertisement Spoofing .47
11.2.2 Neighbor Unreachability Detection Failure . .48		11.2.2 Neighbor Unreachability Detection Failure . .48
11.2.3 Duplicate Address Detection DoS Attack . . . .48		11.2.3 Duplicate Address Detection DoS Attack . . . .48
11.2.4 Router Solicitation and Advertisement Attacks 49		11.2.4 Router Solicitation and Advertisement Attacks 49
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49		11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49		11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49
11.3 Attacks against SEND Itself . . . . . . . . . . . . 50		11.3 Attacks against SEND Itself . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51		12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 52		Normative References . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . 54		Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55		Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 57		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 55
B. IPR Considerations . . . . . . . . . . . . . . . . . . . . 58		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 59		C. Cache Management . . . . . . . . . . . . . . . . . . . . . 57
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 60		D. Comparison to AH-Based Approach . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . 63		Intellectual Property and Copyright Statements . . . . . . 61
1. Introduction		1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [6].		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
Detection (NUD), Duplicate Address Detection (DAD), and Redirection.		Detection (NUD), Duplicate Address Detection (DAD), and Redirection.
RFC 2461 called for the use of IPsec for protecting the NDP messages.		RFC 2461 called for the use of IPsec for protecting the NDP messages.
However, it does not specify detailed instructions for using IPsec to		However, it does not specify detailed instructions for using IPsec to
secure NDP. It turns out that in this particular application, IPsec		secure NDP. It turns out that in this particular application, IPsec
can only be used with a manual configuration of security		can only be used with a manual configuration of security
associations, due to chicken-and-egg problems in using IKE [22, 19].		associations, due to chicken-and-egg problems in using IKE [22, 17].
Furthermore, the number of such manually configured security		Furthermore, the number of such manually configured security
associations needed for protecting NDP can be very large [23], making		associations needed for protecting NDP can be very large [23], making
that approach impractical for most purposes.		that approach impractical for most purposes.
This document is organized as follows. Section 4 describes the		This document is organized as follows. Section 4 describes the
overall approach to securing NDP. This approach involves the use of		overall approach to securing NDP. This approach involves the use of
new NDP options to carry public-key based signatures. A		new NDP options to carry public-key based signatures. A
zero-configuration mechanism is used for showing address ownership on		zero-configuration mechanism is used for showing address ownership on
individual nodes; routers are certified by a trust anchor [11]. The		individual nodes; routers are certified by a trust anchor [10]. The
formats, procedures, and cryptographic mechanisms for the		formats, procedures, and cryptographic mechanisms for the
zero-configuration mechanism are described in a related specification		zero-configuration mechanism are described in a related specification
[26].		[12].
Section 6 describes the mechanism for distributing certificate chains		Section 6 describes the mechanism for distributing certificate chains
to establish an authorization delegation chain to a common trust		to establish an authorization delegation chain to a common trust
anchor. The required new NDP options are discussed in Section 5.		anchor. The required new NDP options are discussed in Section 5.
Section 7 and Section 8 show how to apply these components to		Section 7 and Section 8 show how to apply these components to
securing Neighbor and Router Discovery.		securing Neighbor and Router Discovery.
Finally, Section 9 discusses the co-existence of secure and		Finally, Section 9 discusses the co-existence of secure and
non-secure Neighbor Discovery on the same link, Section 10 discusses		non-secure Neighbor Discovery on the same link, Section 10 discusses
performance considerations, and Section 11 discusses security		performance considerations, and Section 11 discusses security
considerations for Secure Neighbor Discovery.		considerations for Secure Neighbor Discovery.
		1.1 Specification of Requirements
		In this document, several words are used to signify the requirements
		of the specification. These words are often capitalized. The key
		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
		are to be interpreted as described in [2].
2. Terms		2. Terms
Authorization Delegation Discovery (ADD)		Authorization Delegation Discovery (ADD)
A process through which SEND nodes can acquire a certificate chain		A process through which SEND nodes can acquire a certificate chain
from a peer node to a trust anchor.		from a peer node to a trust anchor.
Cryptographically Generated Addresses (CGAs)		Cryptographically Generated Addresses (CGAs)
A technique [26, 30] where the IPv6 address of a node is		A technique [12] where the IPv6 address of a node is
cryptographically generated using a one-way hash function from the		cryptographically generated using a one-way hash function from the
node's public key and some other parameters.		node's public key and some other parameters.
Duplicate Address Detection (DAD)		Duplicate Address Detection (DAD)
A mechanism defined in RFC 2462 [7] that assures that two IPv6		A mechanism defined in RFC 2462 [8] that assures that two IPv6
nodes on the same link are not using the same addresses.		nodes on the same link are not using the same addresses.
Internet Control Message Protocol version 6 (ICMPv6)		Internet Control Message Protocol version 6 (ICMPv6)
The IPv6 control signaling protocol. Neighbor Discovery is a part		The IPv6 control signaling protocol. Neighbor Discovery is a part
of ICMPv6.		of ICMPv6.
Neighbor Discovery Protocol (NDP)		Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [6].		The IPv6 Neighbor Discovery Protocol [7].
Neighbor Discovery (ND)		Neighbor Discovery (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol		The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains also other functions but ND.		(NDP). NDP contains also other functions but ND.
Neighbor Unreachability Detection (NUD)		Neighbor Unreachability Detection (NUD)
This mechanism defined in RFC 2461 [6] is used for tracking the		This mechanism defined in RFC 2461 [7] is used for tracking the
reachability of neighbors.		reachability of neighbors.
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 [11] PKC certificate using the profile specified in		An X.509v3 [10] PKC certificate using the profile specified in
Section 6.5.1.		Section 6.5.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 15:
3. Neighbor and Router Discovery Overview		3. Neighbor and Router Discovery Overview
IPv6 Neighbor and Router Discovery have several functions. Many of		IPv6 Neighbor and Router Discovery have several functions. Many of
these functions are overloaded on a few central message types, such		these functions are overloaded on a few central message types, such
as the ICMPv6 Neighbor Discovery message. In this section we review		as the ICMPv6 Neighbor Discovery message. In this section we review
some of these tasks and their effects in order to understand better		some of these tasks and their effects in order to understand better
how the messages should be treated. This section is not normative,		how the messages should be treated. This section is not normative,
and if this section and the original Neighbor Discovery RFCs are in		and if this section and the original Neighbor Discovery RFCs are in
conflict, the original RFCs take precedence.		conflict, the original RFCs take precedence.
In IPv6, many of the tasks traditionally preformed 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 Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is		reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [6]. NUD is		defined in Section 7.3 of RFC 2461 [7]. NUD is
security-sensitive, because an attacker could falsely claim that		security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not.		reachability exists when it in fact does not.
o Duplicate Address Detection (DAD) is used for preventing address		o Duplicate Address Detection (DAD) is used for preventing address
collisions [7]. A node that intends to assign a new address to		collisions [8]. A node that intends to assign a new address to
one of its interfaces first runs the DAD procedure to verify that		one of its interfaces first runs the DAD procedure to verify that
there is no other node using the same address. Since the rules		there is no other node using the same address. Since the rules
forbid the use of an address until it has been found unique, no		forbid the use of an address until it has been found unique, no
higher layer traffic is possible until this procedure has been		higher layer traffic is possible until this procedure has been
completed. Thus, preventing attacks against DAD can help ensure		completed. Thus, preventing attacks against DAD can help ensure
the availability of communications for the node in question.		the availability of communications for the node in question.
o Address Resolution is similar to IPv4 ARP [18]. 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 [6], 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 Address Autoconfiguration is used for automatically assigning
addresses to a host [7]. This allows hosts to operate without		addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The Address		explicit configuration related to IP connectivity. The Address
Autoconfiguration mechanism defined in [7] is stateless. To		Autoconfiguration mechanism defined in [8] is stateless. To
create IP addresses, the hosts use any prefix information		create IP addresses, the hosts use any prefix information
delivered to them during Router Discovery, and then test the newly		delivered to them during Router Discovery, and then test the newly
formed addresses for uniqueness using the DAD procedure. A		formed addresses for uniqueness using the DAD procedure. A
stateful mechanism, DHCPv6 [24], provides additional		stateful mechanism, DHCPv6 [24], provides additional
Autoconfiguration features. Router and Prefix Discovery and		Autoconfiguration features. Router and Prefix Discovery and
Duplicate Address Detection have an effect on the Address		Duplicate Address Detection have an effect on the Address
Autoconfiguration tasks.		Autoconfiguration tasks.
o The Redirect function is used for automatically redirecting hosts		o The Redirect function is used for automatically redirecting hosts
to an alternate router. Redirect is specified in Section 8 of RFC		to an alternate router. Redirect is specified in Section 8 of RFC
2461 [6]. It is similar to the ICMPv4 Redirect function [17].		2461 [7]. It is similar to the ICMPv4 Redirect function [15].
o The Router Discovery function allows IPv6 hosts to discover the		o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described		local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [6]. The main purpose of Router		in Section 6 of RFC 2461 [7]. The main purpose of Router
Discovery is to find neighboring routers that are willing to		Discovery is to find neighboring routers that are willing to
forward packets on behalf of hosts. Prefix discovery involves		forward packets on behalf of hosts. Prefix discovery involves
determining which destinations are directly on a link; this		determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should		information is necessary in order to know whether a packet should
be sent to a router or to the destination node directly.		be sent to a router or to the destination node directly.
Typically, address autoconfiguration and other tasks can not		Typically, address autoconfiguration and other tasks can not
proceed until suitable routers and prefixes have been found.		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		They have ICMPv6 types from 133 to 137. The IPv6 Next Header value
Skipping to change at page 9, line 41:
o Neighbor Solicitation: The destination address is either the		o Neighbor Solicitation: The destination address is either the
Solicited-Node multicast address, a unicast address, or an anycast		Solicited-Node multicast address, a unicast address, or an anycast
address. The source address is either the unspecified address (in		address. The source address is either the unspecified address (in
DAD) or a unicast address assigned to the sending interface. In a		DAD) or a unicast address assigned to the sending interface. In a
typical case, the source address is equal to the source address of		typical case, the source address is equal to the source address of
the outgoing packet, locally triggering the need to send the		the outgoing packet, locally triggering the need to send the
solicitation.		solicitation.
o Neighbor Advertisement: The destination address is either a		o Neighbor Advertisement: The destination address is either a
unicast address or the link-scoped All-Nodes multicast address		unicast address or the link-scoped All-Nodes multicast address
[12]. The source address is a unicast address assigned to the		[21]. The source address is a unicast address assigned to the
sending interface.		sending interface.
o Router Solicitation: The destination address is typically the		o Router Solicitation: The destination address is typically the
All-Routers multicast address [12]. The source address is either		All-Routers multicast address [21]. The source address is either
the unspecified address or a unicast address assigned to the		the unspecified address or a unicast address assigned to the
sending interface. An unspecified source address does not have		sending interface. An unspecified source address does not have
any special semantics; it is just an optimization for startup.		any special semantics; it is just an optimization for startup.
o Router Advertisement: The destination address can be either a		o Router Advertisement: The destination address can be either a
unicast or the link-scoped All-Nodes multicast address [12]. The		unicast or the link-scoped All-Nodes multicast address [21]. The
source address is a link-local address assigned to the sending		source address is a link-local address assigned to the sending
interface.		interface.
o Redirect: This message is always sent to the source address of the		o Redirect: This message is always sent to the source address of the
packet that triggered the Redirect. Hosts verify that the IP		packet that triggered the Redirect. Hosts verify that the IP
source address of the Redirect is the same as the current		source address of the Redirect is the same as the current
first-hop router for the specified ICMP Destination Address.		first-hop router for the specified ICMP Destination Address.
Rules in [12] dictate that anycast, or multicast addresses may not		Rules in [21] dictate that anycast, or multicast addresses may not
be used as source addresses. If the source address is an		be used as source addresses. If the source address is an
unspecified address, it is impossible to send a Redirect, since		unspecified address, it is impossible to send a Redirect, since
the unspecified address is forbidden as the destination address.		the unspecified address is forbidden as the destination address.
Therefore, the destination address must always be a unicast		Therefore, the destination address must always be a unicast
address.		address.
The source address is a link-local address assigned to the sending		The source address is a link-local address assigned to the sending
interface.		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 introduced. They are used in to protect Neighbor and Router		options is introduced. They are used in to protect Neighbor and
Discovery messages. This specification introduces these options, an		Router Discovery messages. This specification introduces these
authorization delegation discovery process, an address ownership		options, an authorization delegation discovery process, an address
proof mechanism, and requirements for the use of these components for		ownership proof mechanism, and requirements for the use of these
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
follows:		follows:
o Certificate chains, anchored on trusted parties, are expected to		o Certificate chains, anchored on trusted parties, are expected to
certify the authority of routers. A host and a router must have		certify the authority of routers. A host and a router must have
at least one common trust anchor before the host can adopt the		at least one common trust anchor before the host can adopt the
router as its default router. Delegation Chain Solicitation and		router as its default router. Delegation Chain Solicitation and
Advertisement messages are used to discover a certificate chain to		Advertisement messages are used to discover a certificate chain to
the trust anchor without requiring the actual Router Discovery		the trust anchor without requiring the actual Router Discovery
Skipping to change at page 13, line 38:
TBD <To be assigned by IANA> for CGA.		TBD <To be assigned by IANA> for CGA.
Length		Length
The length of the option, in units of 8 octets.		The length of the option, in units of 8 octets.
Modifier		Modifier
A random number used in CGA generation. Its semantics are defined		A random number used in CGA generation. Its semantics are defined
in [26].		in [12].
Collision Cnt		Collision Cnt
An 8-bit collision count, which can get values 0, 1 and 2. Its		An 8-bit collision count, which can get values 0, 1 and 2. Its
semantics are defined in [26].		semantics are defined in [12].
Reserved		Reserved
A 24-bit field reserved for future use. The value MUST be		A 24-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the		initialized to zero by the sender, and MUST be ignored by the
receiver.		receiver.
Key Information		Key Information
A variable length field containing the public key of the sender,		A variable length field containing the public key of the sender,
represented as an ASN.1 type SubjectPublicKeyInfo [11], encoded as		represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as
described in Section 4 of [26].		described in Section 4 of [12].
This specification requires that if both the CGA option and the		This specification requires that if both the CGA option and the
Signature option are present, then the publicKey field in the		Signature option are present, then the publicKey field in the
former option MUST be the public key referred by the Key Hash		former option MUST be the public key referred by the Key Hash
field in the latter option. Packets received with two different		field in the latter option. Packets received with two different
keys MUST be silently discarded. Note that a future extension may		keys MUST be silently discarded. Note that a future extension may
provide a mechanism which allows the owner of an address and the		provide a mechanism which allows the owner of an address and the
signer to be different parties.		signer to be different parties.
The length of the Key Information field is determined by the ASN.1		The length of the Key Information field is determined by the ASN.1
Skipping to change at page 14, line 36:
and continues to the end of the option, as specified by the Length		and continues to the end of the option, as specified by the Length
field.		field.
5.2.1 Processing Rules for Senders		5.2.1 Processing Rules for Senders
A node sending a message using the CGA option MUST construct the		A node sending a message using the CGA option MUST construct the
message as follows.		message as follows.
The Modifier, Collision Cnt, and Key Information fields in the CGA		The Modifier, Collision Cnt, and Key Information fields in the CGA
option are filled in according to the rules presented above and in		option are filled in according to the rules presented above and in
[26]. The used public key is taken from configuration; typically		[12]. The used public key is taken from configuration; typically
from a data structure associated with the source address.		from a data structure associated with the source address.
An address MUST be constructed as specified in Section 4 of [26]. In		An address MUST be constructed as specified in Section 4 of [12]. In
the typical case, the address is constructed long before it is used.		the typical case, the address is constructed long before it is used.
Depending on the type of the message, this address appears in		Depending on the type of the message, this address appears in
different places:		different places:
Redirect		Redirect
The address MUST be the source address of the message.		The address MUST be the source address of the message.
Neighbor Solicitation		Neighbor Solicitation
Skipping to change at page 15, line 26:
Router Advertisement		Router Advertisement
The address MUST be the source address of the message.		The address MUST be the source address of the message.
5.2.2 Processing Rules for Receivers		5.2.2 Processing Rules for Receivers
A message containing a CGA option MUST be checked as follows:		A message containing a CGA option MUST be checked as follows:
If the interface has been configued to use CGA, it is REQUIRED		If the interface has been configued to use CGA, it is REQUIRED
that the receiving node verifies the source address of the packet		that the receiving node verifies the source address of the packet
using the algorithm described in Section 5 of [26]. The inputs		using the algorithm described in Section 5 of [12]. The inputs
for the algorithm are the contents of the Modifier, Collision Cnt,		for the algorithm are the contents of the Modifier, Collision Cnt,
and the Key Information fields, the claimed address in the packet		and the Key Information fields, the claimed address in the packet
(as discussed in the previous section), and the minimum acceptable		(as discussed in the previous section), and the minimum acceptable
Sec value. If the CGA verification is successful, the recipient		Sec value. If the CGA verification is successful, the recipient
proceeds with the cryptographically more time consuming check of		proceeds with the cryptographically more time consuming check of
the signature.		the signature.
Note that a receiver which does not support CGA or has not specified		Note that a receiver which does not support CGA or has not specified
its use for a given interface can still verify packets using trust		its use for a given interface can still verify packets using trust
anchors, even if CGA had been used on a packet. In such a case, the		anchors, even if CGA had been used on a packet. In such a case, the
Skipping to change at page 17, line 27:
associate the signature to a particular key known by the receiver.		associate the signature to a particular key known by the receiver.
Such a key can be either stored in the certificate cache of the		Such a key can be either stored in the certificate cache of the
receiver, or be received in the CGA option in the same message.		receiver, or be received in the CGA option in the same message.
Digital Signature		Digital Signature
A variable length field contains the signature constructed using		A variable length field contains the signature constructed using
the sender's private key, over the the following sequence of		the sender's private key, over the the following sequence of
octets:		octets:
1. The 128-bit CGA Type Tag [26] value for SEND, 0xXXXX XXXX XXXX		1. The 128-bit CGA Type Tag [12] value for SEND, 0xXXXX XXXX XXXX
XXXX XXXX XXXX XXXX XXXX (To be generated randomly).		XXXX XXXX XXXX XXXX XXXX (To be generated randomly).
2. The 128-bit Source Address field from the IP header.		2. The 128-bit Source Address field from the IP header.
3. The 128-bit Destination Address field from the IP header.		3. The 128-bit Destination Address field from the IP header.
4. The 32-bit ICMP header, i.e., the Type, Code, and Checksum		4. The 32-bit ICMP header, i.e., the Type, Code, and Checksum
fields.		fields.
5. The Neighbor Discovery message header, i.e., the Reserved		5. The Neighbor Discovery message header, i.e., the Reserved
Skipping to change at page 17, line 49:
M, O, Reserved, Router Lifetime, Reachable Time, and Retrans		M, O, Reserved, Router Lifetime, Reachable Time, and Retrans
Timer fields in the Router Advertisement message, Reserved and		Timer fields in the Router Advertisement message, Reserved and
Target Address fields in the Neighbor Solicitation message, R,		Target Address fields in the Neighbor Solicitation message, R,
S, O, Reserved, and Target Address fields in the Neighbor		S, O, Reserved, and Target Address fields in the Neighbor
Advertisement message, and Reserved, Target Address, and		Advertisement message, and Reserved, Target Address, and
Destination Address fields in the Redirect message.		Destination Address fields in the Redirect message.
6. All NDP options preceding the Signature option.		6. All NDP options preceding the Signature option.
The signature is constructed using the RSA algorithm and MUST be		The signature is constructed using the RSA algorithm and MUST be
encoded as private key encryption in PKCS#1 format [15]. The		encoded as private key encryption in PKCS#1 format [13]. The
signature value is computed with the RSASSA-PKCS1-v1_5 algorithm		signature value is computed with the RSASSA-PKCS1-v1_5 algorithm
and SHA-1 hash as defined in [15].		and SHA-1 hash as defined in [13].
This field starts after the Key Hash field. The length of the		This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the		Digital Signature field is determined by the length of the
Signature option minus the length of the other fields (including		Signature option minus the length of the other fields (including
the variable length Pad field).		the variable length Pad field).
This variable length field contains padding, as many bytes as is		This variable length field contains padding, as many bytes as is
given by the Pad Length Field.		given by the Pad Length Field.
5.3.1 Processing Rules for Senders		5.3.1 Processing Rules for Senders
Skipping to change at page 18, line 45:
configured private key, and the resulting PKCS#1 signature is put		configured private key, and the resulting PKCS#1 signature is put
to the Digital Signature field.		to the Digital Signature field.
5.3.2 Processing Rules for Receivers		5.3.2 Processing Rules for Receivers
A message containing a Signature option MUST be checked as follows:		A message containing a Signature option MUST be checked as follows:
o The Signature option MUST appear as the last option.		o The Signature option MUST appear as the last option.
o The Key Hash field MUST indicate the use of a known public key,		o The Key Hash field MUST indicate the use of a known public key,
either one learned from a preceeding CGA option, or one known by		either one learned from a preceding CGA option, or one known by
other means.		other means.
o TheDigital Signature field MUST have correct encoding, and do not		o TheDigital Signature field MUST have correct encoding, and do not
exceed the length of the Signature option.		exceed the length of the Signature option.
o The Digital Signature verification MUST show that the signature		o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section.		has been calculated as specified in the previous section.
o If the use of a trust anchor has been configured, a valid		o If the use of a trust anchor has been configured, a valid
authorization delegation chain MUST be known between the		authorization delegation chain MUST be known between the
Skipping to change at page 19, line 40:
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.5. 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 [26]. 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
Both the trust anchor and the CGA verification is required.		Both the trust anchor and the CGA verification is required.
trust anchor or CGA		trust anchor or CGA
Either the trust anchor or the CGA verification is required.		Either the trust anchor or the CGA verification is required.
anchor		anchor
The public keys of the allowed trust anchor(s), if authorization		The public keys of the allowed trust anchor(s), if authorization
method is not set to CGA.		method is not set to CGA.
minSec		minSec
The minimum acceptable Sec value, if CGA verification is required		The minimum acceptable Sec value, if CGA verification is required
(see Section 2 in [26]). This parameter is intended to facilitate		(see Section 2 in [12]). This parameter is intended to facilitate
future extensions and experimental work. Currently, the minSec		future extensions and experimental work. Currently, the minSec
value SHOULD always be set to zero.		value SHOULD always be set to zero.
All nodes that support the sending of Signature options MUST record		All nodes that support the sending of Signature options MUST record
the following configuration information:		the following configuration information:
keypair		keypair
A public-private key pair. If authorization delegation is in use,		A public-private key pair. If authorization delegation is in use,
there must exist a delegation chain from a trust anchor to this		there must exist a delegation chain from a trust anchor to this
Skipping to change at page 22, line 46:
received solicitation. When sending a solication, the sender MUST		received solicitation. When sending a solication, the sender MUST
store the nonce internally so that it can recognize any replies		store the nonce internally so that it can recognize any replies
containing that particular nonce.		containing that particular nonce.
All NDP messages MUST include a Timestamp. Senders SHOULD set the		All NDP messages MUST include a Timestamp. Senders SHOULD set the
Timestamp field to the current time, according to their real time		Timestamp field to the current time, according to their real time
clock.		clock.
If a message has both Nonce and Timestamp options, the Nonce option		If a message has both Nonce and Timestamp options, the Nonce option
SHOULD precede the Timestamp option in order. The receiver MUST be		SHOULD precede the Timestamp option in order. The receiver MUST be
prepared to receive them in any order, as per RFC 2461 [6] Section 9.		prepared to receive them in any order, as per RFC 2461 [7] Section 9.
5.4.4 Processing rules for receivers		5.4.4 Processing rules for receivers
The processing of the Nonce and Timestamp options depends on whether		The processing of the Nonce and Timestamp options depends on whether
a packet is a solicited-for advertisement or not. A system may		a packet is a solicited-for advertisement or not. A system may
implement the distinction in various means. Section 5.4.4.1 defines		implement the distinction in various means. Section 5.4.4.1 defines
the processing rules for solicited-for advertisements. Section		the processing rules for solicited-for advertisements. Section
5.4.4.2 defines the processing rules for all other messages.		5.4.4.2 defines the processing rules for all other messages.
An implementation may utilize some mechanism such as a timestamp		An implementation may utilize some mechanism such as a timestamp
Skipping to change at page 23, line 41:
not recognized, the message MUST be silently dropped.		not recognized, the message MUST be silently dropped.
If the message is accepted, the receiver SHOULD store the receive		If the message is accepted, the receiver SHOULD store the receive
time of the message and the time stamp time in the message, as		time of the message and the time stamp time in the message, as
specified in Section 5.4.4.2		specified in Section 5.4.4.2
5.4.4.2 Processing all other messages		5.4.4.2 Processing all other messages
Receivers SHOULD be configured with an allowed timestamp Delta value		Receivers SHOULD be configured with an allowed timestamp Delta value
and an allowed clock drift parameter. The recommended default value		and an allowed clock drift parameter. The recommended default value
for the allowed Delta is 3,600 seconds (1 hour) and for clock dritf		for the allowed Delta is 3,600 seconds (1 hour) and for clock drift
1% (0.01).		1% (0.01).
To facilitate timestamp checking, each node SHOULD store the		To facilitate timestamp checking, each node SHOULD store the
following information per each peer:		following information per each peer:
The receive time of the last received, acepted SEND message. This		The receive time of the last received, accepted SEND message.
is called RDlast.		This is called RDlast.
The time stamp in the last received, accepted SEND message. This		The time stamp in the last received, accepted SEND message. This
is called TSlast.		is called TSlast.
Receivers SHOULD then check the Timestamp field as follows:		Receivers SHOULD then check the Timestamp field as follows:
o When a message is received from a new peer, i.e., one that is not		o When a message is received from a new peer, i.e., one that is not
stored in the cache, the received timestamp, TSnew, is checked and		stored in the cache, the received timestamp, TSnew, is checked and
the packet is accepted if the timestamp is recent enough with		the packet is accepted if the timestamp is recent enough with
respect to the receival time of the packet, RDnew:		respect to the receival time of the packet, RDnew:
Skipping to change at page 26, line 44:
Type		Type
TBD <To be assigned by IANA> for Delegation Chain Solicitation.		TBD <To be assigned by IANA> for Delegation Chain Solicitation.
Code		Code
0		0
Checksum		Checksum
The ICMP checksum [8].		The ICMP checksum [9].
Identifier		Identifier
A 16-bit unsigned integer field, acting as an identifier to		A 16-bit unsigned integer field, acting as an identifier to
help matching advertisements to solicitations. The Identifier		help matching advertisements to solicitations. The Identifier
field MUST NOT be zero, and its value SHOULD be randomly		field MUST NOT be zero, and its value SHOULD be randomly
generated. (This randomness does not need to be		generated. (This randomness does not need to be
cryptographically hard, though. Its purpose is to avoid		cryptographically hard, though. Its purpose is to avoid
collisions.)		collisions.)
Skipping to change at page 28, line 27:
TBD <To be assigned by IANA> for Delegation Chain		TBD <To be assigned by IANA> for Delegation Chain
Advertisement.		Advertisement.
Code		Code
0		0
Checksum		Checksum
The ICMP checksum [8].		The ICMP checksum [9].
Identifier		Identifier
A 16-bit unsigned integer field, acting as an identifier to		A 16-bit unsigned integer field, acting as an identifier to
help matching advertisements to solicitations. The Identifier		help matching advertisements to solicitations. The Identifier
field MUST be zero for unsolicited advertisements and MUST NOT		field MUST be zero for unsolicited advertisements and MUST NOT
be zero for solicited advertisements.		be zero for solicited advertisements.
Component		Component
Skipping to change at page 30, line 39:
When the Name Type field is set to 1, the Name field contains a		When the Name Type field is set to 1, the Name field contains a
DER encoded X.501 certificate Name, represented and encoded		DER encoded X.501 certificate Name, represented and encoded
exactly as in the matching X.509v3 trust anchor certificate.		exactly as in the matching X.509v3 trust anchor certificate.
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
[11] 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.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
Skipping to change at page 31, line 41:
Pad Length		Pad Length
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 [11], as described in Section		contains an X.509v3 certificate [10], as described in Section
6.5.1.		6.5.1.
6.5 Router Authorization Certificate Format		6.5 Router Authorization Certificate Format
The certificate chain of a router terminates in a Router		The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act		Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization chains are not a common practice		as a router. Because authorization chains are not a common practice
in the Internet at the time this specification is being written, the		in the Internet at the time this specification is being written, the
chain MUST consist of standard Public Key Certificates (PKC, in the		chain MUST consist of standard Public Key Certificates (PKC, in the
sense of [21]). The certificates chain MUST start from the identity		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		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		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		trust anchor. Note that there MAY be multiple certificates issued by
a single trust anchor.		a single trust anchor.
6.5.1 Router Authorization Certificate Profile		6.5.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined		Router Authorization Certificates be X.509v3 certificates, as defined
in RFC 3280 [11], and MUST contain at least one instance of the X.509		in RFC 3280 [10], and MUST contain at least one instance of the X.509
extension for IP addresses, as defined in [13]. The parent		extension for IP addresses, as defined in [11]. The parent
certificates in the certificate chain MUST contain one or more X.509		certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to the delegating authority (the		IP address extensions, back up to the delegating authority (the
Regional Address Registry or IANA) that delegated the original IP		Regional Address Registry or IANA) that delegated the original IP
address space block. The certificates for intermediate delegating		address space block. The certificates for intermediate delegating
authorities MUST contain X.509 IP address extension(s) for		authorities MUST contain X.509 IP address extension(s) for
subdelegations. The router's certificate is signed by the delegating		subdelegations. The router's certificate is signed by the delegating
authority for the prefixes the router is authorized to to advertize.		authority for the prefixes the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one		The X.509 IP address extension MUST contain at least one
addressesOrRanges element that contains an addressPrefix element with		addressesOrRanges element that contains an addressPrefix element with
an IPv6 address prefix for a prefix the router or the intermediate		an IPv6 address prefix for a prefix the router or the intermediate
entity is authorized to advertize. If the entity is allowed to route		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.		any prefix, the used IPv6 address prefix is the null prefix, 0/0.
The addressFamily element of the containing IPAddrBlocks sequence		The addressFamily element of the containing IPAddrBlocks sequence
element MUST contain the IPv6 AFI (0002), as specified in [13] for		element MUST contain the IPv6 Address Family Identifier (0002), as
IPv6 prefixes. Instead of an addressPrefix element, the		specified in [11] for IPv6 prefixes. Instead of an addressPrefix
addressesOrRange element MAY contain an addressRange element for a		element, the addressesOrRange element MAY contain an addressRange
range of prefixes, if more than one prefix is authorized. The X.509		element for a range of prefixes, if more than one prefix is
IP address extension MAY contain additional IPv6 prefixes, expressed		authorized. The X.509 IP address extension MAY contain additional
either as an addressPrefix or an addressRange.		IPv6 prefixes, expressed either as an addressPrefix or an
		addressRange.
A SEND node receiving a Router Authorization Certificate MUST first		A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the		check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the		delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are		addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's		contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any		certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If		addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the		an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attept to		delegating authority's prefixes or ranges, the client MAY attept to
Skipping to change at page 33, line 51:
backward-incompatible changes may use different Code values. The		backward-incompatible changes may use different Code values. The
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 Router Solicitation messages MUST be ignored and the packet		with Router Solicitation messages MUST be ignored and the packet
processed in the normal manner. The only defined option that may		processed in the normal manner. The only defined option that may
appear is the Trust Anchor option. A solicitation that passes the		appear is the Trust Anchor option. A solicitation that passes the
validity checks is called a "valid solicitation".		validity checks is called a "valid solicitation".
Routers MAY send unsolicited Delegation Chain Advertisements for		Routers MAY send unsolicited Delegation Chain Advertisements for
their configured trust anchor(s). When such advertisements are sent,		their configured trust anchor(s). When such advertisements are sent,
their timing MUST follow the rules given for Router Advertisements in		their timing MUST follow the rules given for Router Advertisements in
RFC 2461 [6]. The only defined options that may appear are the		RFC 2461 [7]. The only defined options that may appear are the
Certificate and Trust Anchor options. At least one Certificate		Certificate and Trust Anchor options. At least one Certificate
option MUST be present. Router SHOULD also include at least one		option MUST be present. Router SHOULD also include at least one
Trust Anchor option to indicate the trust anchor on which the		Trust Anchor option to indicate the trust anchor on which the
Certificate is based.		Certificate is based.
In addition to sending periodic, unsolicited advertisements, a router		In addition to sending periodic, unsolicited advertisements, a router
sends advertisements in response to valid solicitations received on		sends advertisements in response to valid solicitations received on
an advertising interface. If the source address in the solicitation		an advertising interface. If the source address in the solicitation
was the unspecified address, the router MUST send the response to the		was the unspecified address, the router MUST send the response to the
link-scoped All-Nodes multicast address. If the source address was a		link-scoped All-Nodes multicast address. If the source address was a
Skipping to change at page 34, line 34:
subjectAltName field of the anchor's certificate. The router SHOULD		subjectAltName field of the anchor's certificate. The router SHOULD
include the Trust Anchor option(s) in the advertisement for which the		include the Trust Anchor option(s) in the advertisement for which the
delegation chain was found.		delegation 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.
Rate limiting of Delegation Chain Advertisements is performed as		Rate limiting of Delegation Chain Advertisements is performed as
specified for Router Advertisements in RFC 2461 [6].		specified for Router Advertisements in RFC 2461 [7].
6.7 Processing Rules for Hosts		6.7 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
Skipping to change at page 36, line 42:
address, if it has not selected a default router yet, or to the		address, if it has not selected a default router yet, or to the
default router's IP address, if it has already been selected.		default router's IP address, if it has already been selected.
If two hosts want to establish trust with the DCS and DCA messages,		If two hosts want to establish trust with the DCS and DCA messages,
the DCS message SHOULD be sent to the Solicited-Node multicast		the DCS message SHOULD be sent to the Solicited-Node multicast
address of the receiver. The advertisements SHOULD be sent as		address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are left for		specified above for routers. However, the exact details are left for
a future specification.		a future specification.
Delegation Chain Solicitations SHOULD be rate limited and timed		Delegation Chain Solicitations SHOULD be rate limited and timed
similarly with Router Solicitations, as specified in RFC 2461 [6].		similarly with Router Solicitations, as specified in RFC 2461 [7].
When processing possible advertisements sent as responses to a		When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process first those		solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the		advertisements with the same Identifier field value as in the
solicitation. This makes Denial-of-Service attacks against the		solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 11.3).		mechanism harder (see Section 11.3).
7. Securing Neighbor Discovery with SEND		7. Securing Neighbor Discovery with SEND
This section describes how to use the mechanisms from Section 5,		This section describes how to use the mechanisms from Section 5,
Section 6, and the reference [26] in order to provide security for		Section 6, and the reference [12] in order to provide security for
Neighbor Discovery.		Neighbor Discovery.
There is no requirement that nodes use both Secure Neighbor Discovery		There is no requirement that nodes use both Secure Neighbor Discovery
(as described in this Section) and Secure Router Discovery (as		(as described in this Section) and Secure Router Discovery (as
described in Section 8. They MAY be used indepedently.		described in Section 8. They MAY be used indepedently.
7.1 Neighbor Solicitation Messages		7.1 Neighbor Solicitation Messages
All Neighbor Solicitation messages are protected with SEND.		All Neighbor Solicitation messages are protected with SEND.
Skipping to change at page 38, line 24:
Neighbor Advertisements sent in response to a Neighbor		Neighbor Advertisements sent in response to a Neighbor
Solicitation MUST additionally contain a copy of the Nonce option		Solicitation MUST additionally contain a copy of the Nonce option
included in the solicitation.		included in the solicitation.
7.2.2 Receiving Secure Neighbor Advertisements		7.2.2 Receiving Secure Neighbor Advertisements
Received Neighbor Advertisement messages are processed as described		Received Neighbor Advertisement messages are processed as described
in RFC 2461 and 2462, with the additional SEND-related requirements		in RFC 2461 and 2462, with the additional SEND-related requirements
as listed in the following:		as listed in the following:
Any eighbor Advertisement messages received without the Timestamp		Any Neighbor Advertisement messages received without the Timestamp
or Signature options MUST be silently discarded. The Signature		or Signature options MUST be silently discarded. The Signature
option MUST be constructed with the expected authorization		option MUST be constructed with the expected authorization
method(s), the used key being within the configured minimum (and		method(s), the used key being within the configured minimum (and
maximum) allowable key size, and if applicable, using an		maximum) allowable key size, and if applicable, using an
acceptable trust anchor and/or minSec value.		acceptable trust anchor and/or minSec value.
Received Neighbor Advertisements sent to a unicast destination		Received Neighbor Advertisements sent to a unicast destination
address without a Nonce option MUST be silently discarded.		address without a Nonce option MUST be silently discarded.
7.3 Other Requirements		7.3 Other Requirements
Upon receiving a message for which the receiver has no certificate		Upon receiving a message for which the receiver has no certificate
chain to a trust anchor, the receiver MAY use Authorization		chain to a trust anchor, the receiver MAY use Authorization
Delegation Discovery to learn the certificate chain of the peer.		Delegation Discovery to learn the certificate chain of the peer.
Nodes that use stateless address autoconfiguration, SHOULD generate a		Nodes that use stateless address autoconfiguration, SHOULD generate a
new CGA as specified in Section 4 of [26] for each new		new CGA as specified in Section 4 of [12] for each new
autoconfiguration run. The nodes MAY continue to use the same public		autoconfiguration run. The nodes MAY continue to use the same public
key and modifier, and start the process from Step 4.		key and modifier, and start the process from Step 4.
This specification does not address the protection of Neighbor		This specification does not address the protection of Neighbor
Discovery packets for nodes that are configured with a static address		Discovery packets for nodes that are configured with a static address
(e.g., PREFIX::1). Future certificate chain based authorization		(e.g., PREFIX::1). Future certificate chain based authorization
specifications are needed for such nodes.		specifications are needed for such nodes.
It is outside the scope of this specification to describe the use of		It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing		trust anchor authorization between nodes with dynamically changing
addresses. Such dynamically changing addresses may be the result of		addresses. Such dynamically changing addresses may be the result of
stateful or stateless address autoconfiguration, or through the use		stateful or stateless address autoconfiguration, or through the use
of RFC 3041 [9] addresses. If the CGA method is not used, nodes		of RFC 3041 [19] addresses. If the CGA method is not used, nodes
would be required to exchange certificate chains that terminate in a		would be required to exchange certificate chains that terminate in a
certificate authorizing a node to use an IP address having a		certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify		particular interface identifier. This specification does not specify
the format of such certificates, since there are currently a few		the format of such certificates, since there are currently a few
cases where such certificates are required by the link layer and it		cases where such certificates are required by the link layer and it
is up to the link layer to provide certification for the interface		is up to the link layer to provide certification for the interface
identifier. This may be the subject of a future specification. It		identifier. This may be the subject of a future specification. It
is also outside the scope of this specification to describe how		is also outside the scope of this specification to describe how
stateful address autoconfiguration works with the CGA method.		stateful address autoconfiguration works with the CGA method.
8. Securing Router Discovery with SEND		8. Securing Router Discovery with SEND
This section describes how to use the mechanisms from Section 5,		This section describes how to use the mechanisms from Section 5,
Section 6, and the reference [26] in order to provide security for		Section 6, and the reference [12] in order to provide security for
Router Discovery.		Router Discovery.
8.1 Router Solicitation Messages		8.1 Router Solicitation Messages
All Router Solicitation messages are protected with SEND.		All Router Solicitation messages are protected with SEND.
8.1.1 Sending Secure Router Solicitations		8.1.1 Sending Secure Router Solicitations
Secure Router Solicitation messages are sent as described in RFC		Secure Router Solicitation messages are sent as described in RFC
2461, with the additional requirements as listed in the following:		2461, with the additional requirements as listed in the following:
Skipping to change at page 43, line 21:
same time.		same time.
In a mixed environment, SEND nodes receive both secure and insecure		In a mixed environment, SEND nodes receive both secure and insecure
messages but give priority to "secured" ones. Here, the "secured"		messages but give priority to "secured" ones. Here, the "secured"
messages are ones that contain a valid signature option, as specified		messages are ones that contain a valid signature option, as specified
above, and "insecure" messages are ones that contain no signature		above, and "insecure" messages are ones that contain no signature
option.		option.
SEND nodes send only secured messages. Legacy Neighbor Discovery		SEND nodes send only secured messages. Legacy Neighbor Discovery
nodes will obviously send only insecure messages. Such nodes will		nodes will obviously send only insecure messages. Such nodes will
(as per RFC 2461 [6]) ignore the unknown options and will treat		(as per RFC 2461 [7]) ignore the unknown options and will treat
secured messages in the same way as they treat insecure ones.		secured messages in the same way as they treat insecure ones.
Secured and insecure nodes share the same network resources, such as		Secured and insecure nodes share the same network resources, such as
prefixes and address spaces.		prefixes and address spaces.
In a mixed environment SEND routers and hosts follow the protocols		In a mixed environment SEND routers and hosts follow the protocols
defined in RFC 2461 and RFC 2462 with the following exceptions:		defined in RFC 2461 and RFC 2462 with the following exceptions:
All solicitations sent by SEND nodes MUST be secured.		All solicitations sent by SEND nodes MUST be secured.
Unsolicited Neighbor and Router Advertisements sent by a SEND		Unsolicited Neighbor and Router Advertisements sent by a SEND
Skipping to change at page 46, line 21:
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
Advertisement having the source address on the link layer frame of a		Advertisement having the source address on the link layer frame of a
victim, a valid CGA address and a valid signature corresponding to		victim, a valid CGA address and a valid signature corresponding to
itself, and a Target Link-layer Address extension corresponding to		itself, and a Target Link-layer Address extension corresponding to
the victim. The attacker could then proceed to cause a traffic		the victim. The attacker could then proceed to cause a traffic
stream to bombard the victim in a DoS attack. To protect against		stream to bombard the victim in a DoS attack. To protect against
such attacks, link layer security MUST be used. An example of such		such attacks, link layer security MUST be used. An example of such
for 802 type networks is port-based access control defined in the		for 802 type networks is port-based access control defined in the
802.1X standard [34].		802.1X standard [28].
Specifically, the 802.1X standard provides a mechanism by which a		Specifically, the 802.1X standard provides a mechanism by which a
nodes can be authenticated to a particular point of attachment to a		nodes can be authenticated to a particular point of attachment to a
LAN (called a "port" in the standard). If the MAC on frames sent by		LAN (called a "port" in the standard). If the MAC on frames sent by
a node does not correspond to the MAC of the node originally		a node does not correspond to the MAC of the node originally
authenticated to this port, then the point of attachment drops the		authenticated to this port, then the point of attachment drops the
frames. Authorization to use the port is determined by the MAC		frames. Authorization to use the port is determined by the MAC
address of the node that originally authenticated to the port. The		address of the node that originally authenticated to the port. The
way 802.1X protects against this attack is that, if a node		way 802.1X protects against this attack is that, if a node
authenticated to a particular port attempts to spoof the MAC address		authenticated to a particular port attempts to spoof the MAC address
Skipping to change at page 47, line 4:
check this binding), and neither does SEND. 802.1X provides		check this binding), and neither does SEND. 802.1X provides
authentication and filtering of MAC address to port; SEND provides		authentication and filtering of MAC address to port; SEND provides
protection for the layer 2 - layer 3 binding information in the		protection for the layer 2 - layer 3 binding information in the
Neighbor Discovery packet, via the CGA address (authorization to use		Neighbor Discovery packet, via the CGA address (authorization to use
the address via the public key) and the signature on the packet		the address via the public key) and the signature on the packet
(authentication of contents as from authorized IP address possessor).		(authentication of contents as from authorized IP address possessor).
Prior to participating in Neighbor Discovery and Duplicate Address		Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes		Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the		Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming for their addresses; RFC 2461 [6].		address that they are claiming for their addresses; RFC 2461 [7].
Subscribing to a multicast group requires that the nodes use MLD		Subscribing to a multicast group requires that the nodes use MLD
[20]. MLD contains no provision for security. An attacker could		[18]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the		send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be able		Solicited-Node Multicast address. However, the victim should be able
to detect such an attack because the router sends a		to detect such an attack because the router sends a
Multicast-Address-Specific Query to determine whether any listeners		Multicast-Address-Specific Query to determine whether any listeners
are still on the address, at which point the victim can respond to		are still on the address, at which point the victim can respond to
avoid being dropped from the group. This technique will work if the		avoid being dropped from the group. This technique will work if the
router on the link has not been compromised. Other attacks using MLD		router on the link has not been compromised. Other attacks using MLD
are possible, but they primarily lead to extraneous (but not		are possible, but they primarily lead to extraneous (but not
overwhelming) traffic.		overwhelming) traffic.
11.2 How SEND Counters Threats to Neighbor Discovery		11.2 How SEND Counters Threats to Neighbor Discovery
The SEND protocol is designed to counter the threats to IPv6 Neighbor		The SEND protocol is designed to counter the threats to IPv6 Neighbor
Discovery, as outlined in [27]. The following subsections contain a		Discovery, as outlined in [26]. The following subsections contain a
regression of the SEND protocol against the threats, to illustrate		regression of the SEND protocol against the threats, to illustrate
what aspects of the protocol counter each threat.		what aspects of the protocol counter each threat.
11.2.1 Neighbor Solicitation/Advertisement Spoofing		11.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [27]. The threat is that		This threat is defined in Section 4.1.1 of [26]. The threat is that
a spoofed Neighbor Solicitation or Neighbor Advertisement causes a		a spoofed Neighbor Solicitation or Neighbor Advertisement causes a
false entry in a node's Neighbor Cache. There are two cases:		false entry in a node's Neighbor Cache. There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or		1. Entries made as a side effect of a Neighbor Solicitation or
Router Solicitation. There are two cases:		Router Solicitation. There are two cases:
1. A router receiving a Router Solicitation with a firm IPv6		1. A router receiving a Router Solicitation with a firm IPv6
source address and a Target Link-Layer Address extension		source address and a Target Link-Layer Address extension
inserts an entry for the IPv6 address into its Neighbor		inserts an entry for the IPv6 address into its Neighbor
Cache.		Cache.
Skipping to change at page 48, line 29:
the node's interface identifier either be a CGA, or that the node be		the node's interface identifier either be a CGA, or that the node be
able to produce a certificate authorizing that node to use the public		able to produce a certificate authorizing that node to use the public
key.		key.
The Neighbor Solicitation and Advertisement pairs implement a		The Neighbor Solicitation and Advertisement pairs implement a
challenge-response protocol, as explained in Section 7 and discussed		challenge-response protocol, as explained in Section 7 and discussed
in Section 11.2.5 below.		in Section 11.2.5 below.
11.2.2 Neighbor Unreachability Detection Failure		11.2.2 Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [27]. SEND counters		This attack is described in Section 4.1.2 of [26]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations		this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include a Signature option and proof of		sent as NUD probes to include a Signature option and proof of
authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
probed. If these prerequisites are not met, the node performing NUD		probed. If these prerequisites are not met, the node performing NUD
discards the responses.		discards the responses.
11.2.3 Duplicate Address Detection DoS Attack		11.2.3 Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [27]. SEND counters		This attack is described in Section 4.1.3 of [26]. SEND counters
this attack by requiring the Neighbor Advertisements sent as		this attack by requiring the Neighbor Advertisements sent as
responses to DAD to include a Signature option and proof of		responses to DAD to include a Signature option and proof of
authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
tested. If these prerequisites are not met, the node performing DAD		tested. If these prerequisites are not met, the node performing DAD
discards the responses.		discards the responses.
When a SEND node is used on a link that also connects to non-SEND		When a SEND node is used on a link that also connects to non-SEND
nodes, the SEND node ignores any insecure Neighbor Solicitations or		nodes, the SEND node ignores any insecure Neighbor Solicitations or
Advertisements that may be send by the non-SEND nodes. This protects		Advertisements that may be send by the non-SEND nodes. This protects
the SEND node from DAD DoS attacks by non-SEND nodes or attackers		the SEND node from DAD DoS attacks by non-SEND nodes or attackers
simulating to non-SEND nodes, at the cost of a potential address		simulating to non-SEND nodes, at the cost of a potential address
collision between a SEND node and non-SEND node. The probability and		collision between a SEND node and non-SEND node. The probability and
effects of such an address collision are discussed in [26].		effects of such an address collision are discussed in [12].
11.2.4 Router Solicitation and Advertisement Attacks		11.2.4 Router Solicitation and Advertisement Attacks
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,		These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [27]. SEND counters these attacks by requiring Router		and 4.2.7 of [26]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature		Advertisements to contain a Signature option, and that the signature
is calculated using the public key of a node that can prove its		is calculated using the public key of a node that can prove its
authorization to route the subnet prefixes contained in any Prefix		authorization to route the subnet prefixes contained in any Prefix
Information Options. The router proves its authorization by showing		Information Options. The router proves its authorization by showing
a certificate containing the specific prefix or the indication that		a certificate containing the specific prefix or the indication that
the router is allowed to route any prefix. A Router Advertisement		the router is allowed to route any prefix. A Router Advertisement
without these protections is dropped.		without these protections is dropped.
SEND does not protect against brute force attacks on the router, such		SEND does not protect against brute force attacks on the router, such
as DoS attacks, or compromise of the router, as described in Sections		as DoS attacks, or compromise of the router, as described in Sections
4.4.2 and 4.4.3 of [27].		4.4.2 and 4.4.3 of [26].
11.2.5 Replay Attacks		11.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [27]. SEND protects		This attack is described in Section 4.3.1 of [26]. SEND protects
against attacks in Router Solicitation/Router Advertisement and		against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by		Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring the		including a Nonce option in the solicitation and requiring the
advertisement to include a matching option. Together with the		advertisement to include a matching option. Together with the
signatures this forms a challenge-response protocol. SEND protects		signatures this forms a challenge-response protocol. SEND protects
against attacks from unsolicited messages such as Neighbor		against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a		Advertisements, Router Advertisements, and Redirects by including a
Timestamp option. A window of vulnerability for replay attacks		Timestamp option. A window of vulnerability for replay attacks
exists until the timestamp expires.		exists until the timestamp expires.
Skipping to change at page 49, line 46:
containing the timestamp. The cached state allows the node to		containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node		protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the		flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid.		state by replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained		Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 5.4.1, this may affect some		timestamps, as explained in Section 5.4.1, this may affect some
nodes.		nodes.
11.2.6 Neighbor Discovery DoS Attack		11.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [27]. In this attack,		This attack is described in Section 4.3.2 of [26]. In this attack,
the attacker bombards the router with packets for fictitious		the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to busy itself with		addresses on the link, causing the router to busy itself with
performing Neighbor Solicitations for addresses that do not exist.		performing Neighbor Solicitations for addresses that do not exist.
SEND does not address this threat because it can be addressed by		SEND does not address this threat because it can be addressed by
techniques such as rate limiting Neighbor Solicitations, restricting		techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever		the amount of state reserved for unresolved solicitations, and clever
cache management. These are all techniques involved in implementing		cache management. These are all techniques involved in implementing
Neighbor Discovery on the router.		Neighbor Discovery on the router.
11.3 Attacks against SEND Itself		11.3 Attacks against SEND Itself
The CGAs have a 59-bit hash value. The security of the CGA mechanism		The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [26].		has been discussed in [12].
Some Denial-of-Service attacks against NDP and SEND itself remain.		Some Denial-of-Service attacks against NDP and SEND itself remain.
For instance, an attacker may try to produce a very high number of		For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify using asymmetric		packets that a victim host or router has to verify using asymmetric
methods. While safeguards are required to prevent an excessive use		methods. While safeguards are required to prevent an excessive use
of resources, this can still render SEND non-operational.		of resources, this can still render SEND non-operational.
When CGA protection is used, SEND deals with the DoS attacks using		When CGA protection is used, SEND deals with the DoS attacks using
the verification process described in Section 5.3.2. In this		the verification process described in Section 5.3.2. In this
process, a simple hash verification of the CGA property of the		process, a simple hash verification of the CGA property of the
Skipping to change at page 51, line 17:
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.1.
o The Delegation Chain Advertisement message, described in Section		o The Delegation Chain Advertisement message, described in Section
6.2.		6.2.
This document defines six new Neighbor Discovery Protocol [6]		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.3.
o The Certificate option, described in Section 6.4.		o The Certificate option, described in Section 6.4.
o The CGA option, described in Section 5.2.		o The CGA option, described in Section 5.2.
o The Signature option, described in Section 5.3.		o The Signature option, described in Section 5.3.
o The Timestamp option, described in Section 5.4.1.		o The Timestamp option, described in Section 5.4.1.
o The Nonce option, described in Section 5.4.2.		o The Nonce option, described in Section 5.4.2.
This document defines a new 128-bit CGA Message Type [26] value,		This document defines a new 128-bit CGA Message Type [12] value,
0xXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly).		0xXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly).
XXX: Use existing name spaces for these?		XXX: Use existing name spaces for these?
This document defines a new name space for the Name Type field in the		This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated		Trust Anchor option. Future values of this field can be allocated
using standards action [5].		using standards action [6].
Another new name space is allocated for the Cert Type field in the		Another new name space is allocated for the Cert Type field in the
Certificate option. Future values of this field can be allocated		Certificate option. Future values of this field can be allocated
using standards action [5].		using standards action [6].
Normative References		Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD		[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.		13, RFC 1034, November 1987.
[2] Kent, S. and R. Atkinson, "Security Architecture for the		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
		Levels", BCP 14, RFC 2119, March 1997.
		[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,		[4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.		November 1998.
[4] Piper, D., "The Internet IP Security Domain of Interpretation		[5] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.		for ISAKMP", RFC 2407, November 1998.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October		Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.		1998.
[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery		[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address		[8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
[8] Conta, A. and S. Deering, "Internet Control Message Protocol		[9] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[10] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002.
[11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate		Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.		Revocation List (CRL) Profile", RFC 3280, April 2002.
[12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[11] Lynn, C., "X.509 Extensions for IP Addresses and AS
Addressing Architecture", RFC 3513, April 2003.
[13] Lynn, C., "X.509 Extensions for IP Addresses and AS
Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in		Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in
progress), September 2003.		progress), September 2003.
[14] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[12] Aura, T., "Cryptographically Generated Addresses (CGA)",
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June		draft-ietf-send-cga-03 (work in progress), December 2003.
2003.
[15] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS		[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002.		1, November 2002.
[16] National Institute of Standards and Technology, "Secure Hash		[14] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http://		Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>.		www.itl.nist.gov/fipspubs/fip180-1.htm>.
Informative References		Informative References
[17] Postel, J., "Internet Control Message Protocol", STD 5, RFC		[15] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.		792, September 1981.
[18] Plummer, D., "Ethernet Address Resolution Protocol: Or		[16] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet		converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC		address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982.		826, November 1982.
[19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.		RFC 2409, November 1998.
[20] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener		[18] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.		Discovery (MLD) for IPv6", RFC 2710, October 1999.
[21] Farrell, S. and R. Housley, "An Internet Attribute Certificate		[19] Narten, T. and R. Draves, "Privacy Extensions for Stateless
		Address Autoconfiguration in IPv6", RFC 3041, January 2001.
		[20] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.		Profile for Authorization", RFC 3281, April 2002.
		[21] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
		Addressing Architecture", RFC 3513, April 2003.
[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",		[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
draft-arkko-icmpv6-ike-effects-02 (work in progress), March		draft-arkko-icmpv6-ike-effects-02 (work in progress), March
2003.		2003.
[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local		[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),		Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
June 2002.		June 2002.
[24] Droms, R., "Dynamic Host Configuration Protocol for IPv6		[24] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),		(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.		November 2002.
[25] Kent, S., "IP Encapsulating Security Payload (ESP)",		[25] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.		draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[26] Aura, T., "Cryptographically Generated Addresses (CGA)",		[26] Nikander, P., "IPv6 Neighbor Discovery trust models and
draft-ietf-send-cga-03 (work in progress), December 2003.
[27] Nikander, P., "IPv6 Neighbor Discovery trust models and
threats", draft-ietf-send-psreq-00 (work in progress), October		threats", draft-ietf-send-psreq-00 (work in progress), October
2002.		2002.
[28] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and		[27] International Organization for Standardization, "The Directory
Addresses", draft-montenegro-sucv-03 (work in progress), July
2002.
[29] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.		- Authentication Framework", ISO Standard X.509, 2000.
[30] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",		[28] Institute of Electrical and Electronics Engineers, "Local and
Computer Communications Review, April 2001.
[31] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Proceedings of the Cambridge
Security Protocols Workshop, April 2001.
[32] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and
M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security
Workshop, September 2002.
[33] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses",
NDSS, February 2002.
[34] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",		Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.		IEEE Standard 802.1X, September 2001.
Authors' Addresses		Authors' Addresses
Jari Arkko		Jari Arkko
Ericsson		Ericsson
Jorvas 02420		Jorvas 02420
Finland		Finland
Skipping to change at page 58, line 5:
Jorvas 02420		Jorvas 02420
Finland		Finland
EMail: Pekka.Nikander@nomadiclab.com		EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors		Appendix A. Contributors
Tuomas Aura contributed the transition mechanism specification in		Tuomas Aura contributed the transition mechanism specification in
Section 9.		Section 9.
Appendix B. IPR Considerations		Appendix B. Acknowledgements
The optional CGA part of SEND uses public keys and hashes to prove		The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel
address ownership. Several IPR claims have been made about such		Montenegro, Pasi Eronen, and Francis Dupont for interesting
methods.		discussions in this problem space.
Appendix C. Cache Management		Appendix C. Cache Management
In this section we outline a cache management algorithm that allows a		In this section we outline a cache management algorithm that allows a
node to remain partially functional even under a cache filling DoS		node to remain partially functional even under a cache filling DoS
attack. This appendix is informational, and real implementations		attack. This appendix is informational, and real implementations
SHOULD use different algorithms in order to avoid he dangers of		SHOULD use different algorithms in order to avoid he dangers of
monocultural code.		monocultural code.
There are at least two distinct cache related attack scenarios:		There are at least two distinct cache related attack scenarios:
Skipping to change at page 63, line 27:
obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can		proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
Director.		Director.
		The IETF has been notified of intellectual property rights claimed in
		regard to some or all of the specification contained in this
		document. For more information consult the online list of claimed
		rights.
Full Copyright Statement		Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this

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