base.txt		issue80.txt
	skipping to change at page 2, line 18		skipping to change at page 2, line 18
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Specification of Requirements . . . . . . . . . . . . 4		1.1 Specification of Requirements . . . . . . . . . . . . 4
	2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7		3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
	4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
	5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11		5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
	5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 11		5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 11
	5.1.1 Processing Rules for Senders . . . . . . . . . . 12		5.1.1 Processing Rules for Senders . . . . . . . . . . 12
	5.1.2 Processing Rules for Receivers . . . . . . . . . 13		5.1.2 Processing Rules for Receivers . . . . . . . . . 13
	5.1.3 Configuration . . . . . . . . . . . . . . . . . 14		5.1.3 Configuration . . . . . . . . . . . . . . . . . 14
	5.2 Signature Option . . . . . . . . . . . . . . . . . . . 14		5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 14
	5.2.1 Processing Rules for Senders . . . . . . . . . . 16		5.2.1 Processing Rules for Senders . . . . . . . . . . 16
	5.2.2 Processing Rules for Receivers . . . . . . . . . 17		5.2.2 Processing Rules for Receivers . . . . . . . . . 17
	5.2.3 Configuration . . . . . . . . . . . . . . . . . 18		5.2.3 Configuration . . . . . . . . . . . . . . . . . 18
	5.2.4 Performance Considerations . . . . . . . . . . . 19		5.2.4 Performance Considerations . . . . . . . . . . . 19
	5.3 Timestamp and Nonce options . . . . . . . . . . . . . 19		5.3 Timestamp and Nonce options . . . . . . . . . . . . . 19
	5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 19		5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 19
	5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 20		5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 20
	5.3.3 Processing rules for senders . . . . . . . . . . 21		5.3.3 Processing rules for senders . . . . . . . . . . 21
	5.3.4 Processing rules for receivers . . . . . . . . . 22		5.3.4 Processing rules for receivers . . . . . . . . . 22
	6. Authorization Delegation Discovery . . . . . . . . . . . . . 25		6. Authorization Delegation Discovery . . . . . . . . . . . . . 25
	skipping to change at page 9, line 37		skipping to change at page 9, line 37
	o Cryptographically Generated Addresses are used to assure that the		o Cryptographically Generated Addresses are used to assure that the
	sender of a Neighbor Discovery message is the "owner" of the		sender of a Neighbor Discovery message is the "owner" of the
	claimed address. A public-private key pair is generated by all		claimed address. A public-private key pair is generated by all
	nodes before they can claim an address. A new NDP option, the CGA		nodes before they can claim an address. A new NDP option, the CGA
	option, is used to carry the public key and associated parameters.		option, is used to carry the public key and associated parameters.
	This specification also allows a node to use non-CGAs with		This specification also allows a node to use non-CGAs with
	certificates to authorize their use. However, the details of such		certificates to authorize their use. However, the details of such
	use are beyond the scope of this specification.		use are beyond the scope of this specification.
	o A new NDP option, the Signature option, is used to protect all		o A new NDP option, the RSA Signature option, is used to protect all
	messages relating to Neighbor and Router discovery.		messages relating to Neighbor and Router discovery.
	Public key signatures protect the integrity of the messages and		Public key signatures protect the integrity of the messages and
	authenticate the identity of their sender. The authority of a		authenticate the identity of their sender. The authority of a
	public key is established either with the authorization delegation		public key is established either with the authorization delegation
	process, using certificates, or through the address ownership		process, using certificates, or through the address ownership
	proof mechanism, using CGAs, or both, depending on configuration		proof mechanism, using CGAs, or both, depending on configuration
	and the type of the message protected.		and the type of the message protected.
			Note: RSA is mandated because having multiple signature algorithms
			would break compatibility between implementations or increase
			implementation complexity by forcing implementation of multiple
			algorithms and the mechanism to select among them. A second
			signature algorithm is only necessary as a recovery mechanism, in
			case RSA is found to be insecure. If that happens, a stronger
			signature algorithm can be selected and SEND can be revised. The
			relationship between the new algorithm and the RSA-based SEND
			described in this document would be similar to that between the
			RSA-based SEND and Neighbor Discovery without SEND. Information
			signed with the stronger algorithm has precedence over that signed
			with RSA, in the same way as RSA-signed information now takes
			precedence over unsigned information. Implementations of the
			current and revised specs would still be compatible.
	o In order to prevent replay attacks, two new Neighbor Discovery		o In order to prevent replay attacks, two new Neighbor Discovery
	options, Timestamp and Nonce, are introduced. Given that Neighbor		options, Timestamp and Nonce, are introduced. Given that Neighbor
	and Router Discovery messages are in some cases sent to multicast		and Router Discovery messages are in some cases sent to multicast
	addresses, the Timestamp option offers replay protection without		addresses, the Timestamp option offers replay protection without
	any previously established state or sequence numbers. When the		any previously established state or sequence numbers. When the
	messages are used in solicitation - advertisement pairs, they are		messages are used in solicitation - advertisement pairs, they are
	protected using the Nonce option.		protected using the Nonce option.
	5. Neighbor Discovery Protocol Options		5. Neighbor Discovery Protocol Options
	skipping to change at page 12, line 11		skipping to change at page 12, line 11
	An 8-bit field reserved for future use. The value MUST be		An 8-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.
	CGA Parameters		CGA Parameters
	A variable length field containing the CGA Parameters data		A variable length field containing the CGA Parameters data
	structure described in Section 4 of [13].		structure described in Section 4 of [13].
	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 public key found from the		RSA Signature option are present, then the public key found from
	CGA Parameters field in the CGA option MUST be the public key		the CGA Parameters field in the CGA option MUST be the public key
	referred by the Key Hash field in the Signature option. Packets		referred by the Key Hash field in the RSA Signature option.
	received with two different keys MUST be silently discarded. Note		Packets received with two different keys MUST be silently
	that a future extension may provide a mechanism which allows the		discarded. Note that a future extension may provide a mechanism
	owner of an address and the signer to be different parties.		which allows the owner of an address and the signer to be
			different parties.
	Padding		Padding
	A variable length field making the option length a multiple of 8,		A variable length field making the option length a multiple of 8,
	containing as many octets as specified in the Pad Length field.		containing as many octets as specified in the Pad Length field.
	5.1.1 Processing Rules for Senders		5.1.1 Processing Rules for Senders
	The CGA option MUST be present in all Neighbor Solicitation and		The CGA option MUST be present in all Neighbor Solicitation and
	Advertisement messages, and MUST be present in Router Solicitation		Advertisement messages, and MUST be present in Router Solicitation
	skipping to change at page 14, line 26		skipping to change at page 14, line 28
	least 2048 bits. Any implementation should follow prudent		least 2048 bits. Any implementation should follow prudent
	cryptographic practice in determining the appropriate key lengths.		cryptographic practice in determining the appropriate key lengths.
	All nodes that support the sending of the CGA option MUST record the		All nodes that support the sending of the CGA option MUST record the
	following configuration information:		following configuration information:
	CGA parameters		CGA parameters
	Any information required to construct CGAs, as described in [13].		Any information required to construct CGAs, as described in [13].
	5.2 Signature Option		5.2 RSA Signature Option
	The Signature option allows public-key based signatures to be		The RSA Signature option allows public-key based signatures to be
	attached to NDP messages. Configured trust anchors, CGAs, or both are		attached to NDP messages. Configured trust anchors, CGAs, or both are
	supported as the trusted root. The format of the Signature option is		supported as the trusted root. The format of the RSA Signature
	described in the following diagram:		option is described in the following diagram:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Key Hash |		| Key Hash |
	| |		| |
	| |		| |
	skipping to change at page 15, line 29		skipping to change at page 15, line 29
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Padding .		. Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD <To be assigned by IANA for Signature>.		TBD <To be assigned by IANA for RSA Signature>.
	Length		Length
	The length of the option (including the Type, Length, Reserved,		The length of the option (including the Type, Length, Reserved,
	Key Hash, Digital Signature, and Padding fields) in units of 8		Key Hash, Digital Signature, and Padding fields) in units of 8
	octets.		octets.
	Reserved		Reserved
	A 16-bit field reserved for future use. The value MUST be		A 16-bit field reserved for future use. The value MUST be
	skipping to change at page 16, line 23		skipping to change at page 16, line 23
	generated randomly by the editor of this specification.).		generated randomly by the editor of this specification.).
	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.		4. The 32-bit ICMP header.
	5. The NDP message header.		5. The NDP message header.
	6. All NDP options preceding the Signature option.		6. All NDP options preceding the RSA Signature option.
	The signature value is computed with the RSASSA-PKCS1-v1_5		The signature value is computed with the RSASSA-PKCS1-v1_5
	algorithm and SHA-1 hash as defined in [14].		algorithm and SHA-1 hash as defined in [14].
	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 RSA
	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).
	Padding		Padding
	This variable length field contains padding, as many bytes as		This variable length field contains padding, as many bytes as
	remains after end of the signature.		remains after end of the signature.
	5.2.1 Processing Rules for Senders		5.2.1 Processing Rules for Senders
	Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,		Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
	and Redirect messages MUST contain the Signature option. Router		and Redirect messages MUST contain the RSA Signature option. Router
	Solicitation messages not sent with the unspecified source address		Solicitation messages not sent with the unspecified source address
	MUST contain the Signature option.		MUST contain the RSA Signature option.
	A node sending a message using the Signature option MUST construct		A node sending a message using the RSA Signature option MUST
	the message as follows:		construct the message as follows:
	o The message is constructed in its entirety, without the Signature		o The message is constructed in its entirety, without the RSA
	option.		Signature option.
	o The Signature option is added as the last option in the message.		o The RSA Signature option is added as the last option in the
			message.
	o The data to be signed is constructed as explained in Section 5.2,		o The data to be signed is constructed as explained in Section 5.2,
	under the description of the Digital Signature field.		under the description of the Digital Signature field.
	o The message, in the form defined above, is signed using the		o The message, in the form defined above, is signed using the
	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.2.2 Processing Rules for Receivers		5.2.2 Processing Rules for Receivers
	Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,		Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
	and Redirect messages without the Signature option MUST be treated as		and Redirect messages without the RSA Signature option MUST be
	insecure, i.e., processed in the same way as NDP messages sent by a		treated as insecure, i.e., processed in the same way as NDP messages
	non-SEND node. See Section 8.		sent by a non-SEND node. See Section 8.
	Router Solicitation messages without the Signature option MUST be		Router Solicitation messages without the RSA Signature option MUST be
	also treated as insecure, unless the source address of the message is		also treated as insecure, unless the source address of the message is
	the unspecified address.		the unspecified address.
	Redirect, Neighbor Solicitation, Neighbor Advertisement, Router		Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
	Solicitation, and Router Advertisement messages containing a		Solicitation, and Router Advertisement messages containing an RSA
	Signature option MUST be checked as follows:		Signature option MUST be checked as follows:
	o The receiver MUST ignore any options the come after the first		o The receiver MUST ignore any options the come after the first RSA
	Signature option. (The options are ignored for both signature		Signature option. (The options are ignored for both signature
	verification and NDP processing purposes.)		verification and NDP processing purposes.)
	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 preceding CGA option in the same		either one learned from a preceding CGA option in the same
	message, or one known by other means.		message, or one known by other means.
	o The Digital Signature field MUST have correct encoding, and not		o The Digital Signature field MUST have correct encoding, and not
	exceed the length of the Signature option minus the Padding.		exceed the length of the RSA Signature option minus the Padding.
	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
	receiver's trust anchor and the sender's public key.		receiver's trust anchor and the sender's public key.
	Note that the receiver may verify just the CGA property of a		Note that the receiver may verify just the CGA property of a
	packet, even if, in addition to CGA, the sender has used a trust		packet, even if, in addition to CGA, the sender has used a trust
	skipping to change at page 18, line 12		skipping to change at page 18, line 14
	Messages that do not pass all the above tests MUST be silently		Messages that do not pass all the above tests MUST be silently
	discarded if the host has been configured to only accept secure ND		discarded if the host has been configured to only accept secure ND
	messages. The messages MAY be accepted it the host has been		messages. The messages MAY be accepted it the host has been
	configured to accept both secure and insecure messages, but MUST be		configured to accept both secure and insecure messages, but MUST be
	treated as an insecure message. The receiver MAY also otherwise		treated as an insecure message. The receiver MAY also otherwise
	silently discard packets, e.g., as a response to an apparent CPU		silently discard packets, e.g., as a response to an apparent CPU
	exhausting DoS attack.		exhausting DoS attack.
	5.2.3 Configuration		5.2.3 Configuration
	All nodes that support the reception of the Signature options MUST be		All nodes that support the reception of the RSA Signature options
	configured with the following information for each separate NDP		MUST be configured with the following information for each separate
	message type:		NDP message type:
	authorization method		authorization method
	This parameter determines the method through which the authority		This parameter determines the method through which the authority
	of the sender is determined. It can have four values:		of the sender is determined. It can have four values:
	trust anchor		trust anchor
	The authority of the sender is verified as described in Section		The authority of the sender is verified as described in Section
	6.1. The sender may claim additional authorization through the		6.1. The sender may claim additional authorization through the
	skipping to change at page 18, line 47		skipping to change at page 18, line 49
	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 and names of the allowed trust anchor(s), if the		The public keys and names of the allowed trust anchor(s), if the
	authorization method is not set to CGA.		authorization method is not set to CGA.
	All nodes that support the sending of Signature options MUST record		All nodes that support the sending of RSA Signature options MUST
	the following configuration information:		record 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
	key pair.		key pair.
	CGA flag		CGA flag
	A flag that indicates whether CGA is used or not. This flag may be		A flag that indicates whether CGA is used or not. This flag may be
	skipping to change at page 22, line 14		skipping to change at page 22, line 14
	5.3.4 Processing rules for receivers		5.3.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 advertisement. A system may implement the		a packet is a solicited advertisement. A system may implement the
	distinction in various ways. Section 5.3.4.1 defines the processing		distinction in various ways. Section 5.3.4.1 defines the processing
	rules for solicited advertisements. Section 5.3.4.2 defines the		rules for solicited advertisements. Section 5.3.4.2 defines the
	processing rules for all other messages.		processing rules for all other messages.
	In addition, the following rules apply in all cases:		In addition, the following rules apply in all cases:
	o Messages received with the Signature option but without the		o Messages received with the RSA Signature option but without the
	Timestamp option MUST be silently discarded.		Timestamp option MUST be silently discarded.
	o Solicitation messages received with the Signature option but		o Solicitation messages received with the RSA Signature option but
	without the Nonce option MUST be silently discarded.		without the Nonce option MUST be silently discarded.
	o Advertisements sent to a unicast destination address with the		o Advertisements sent to a unicast destination address with the RSA
	Signature option but without a Nonce option MUST be silently		Signature option but without a Nonce option MUST be silently
	discarded.		discarded.
	o An implementation MAY utilize some mechanism such as a timestamp		o An implementation MAY utilize some mechanism such as a timestamp
	cache to strengthen resistance to replay attacks. When there is a		cache to strengthen resistance to replay attacks. When there is a
	very large number of nodes on the same link, or when a cache		very large number of nodes on the same link, or when a cache
	filling attack is in progress, it is possible that the cache		filling attack is in progress, it is possible that the cache
	holding the most recent timestamp per sender becomes full. In		holding the most recent timestamp per sender becomes full. In
	this case the node MUST remove some entries from the cache or		this case the node MUST remove some entries from the cache or
	refuse some new requested entries. The specific policy as to		refuse some new requested entries. The specific policy as to
	skipping to change at page 23, line 29		skipping to change at page 23, line 29
	o The receive time of the last received and accepted SEND message.		o The receive time of the last received and accepted SEND message.
	This is called RDlast.		This is called RDlast.
	o The time stamp in the last received and accepted SEND message.		o The time stamp in the last received and accepted SEND message.
	This is called TSlast.		This is called TSlast.
	An accepted SEND message is any successfully verified Neighbor		An accepted SEND message is any successfully verified Neighbor
	Solicitation, Neighbor Advertisement, Router Solicitation, Router		Solicitation, Neighbor Advertisement, Router Solicitation, Router
	Advertisement, or Redirect message from the given peer. It is		Advertisement, or Redirect message from the given peer. It is
	required that the Signature option has been used in such a message		required that the RSA Signature option has been used in such a
	before it can update the above variables.		message before it can update the above variables.
	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 reception time of the packet, RDnew:		respect to the reception time of the packet, RDnew:
	-Delta < (RDnew - TSnew) < +Delta		-Delta < (RDnew - TSnew) < +Delta
	skipping to change at page 44, line 19		skipping to change at page 44, line 19
	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. A router receiving a Router Solicitation		Router Solicitation. A router receiving a Router Solicitation
	with a Target Link-Layer Address extension and the IPv6 source		with a Target Link-Layer Address extension and the IPv6 source
	address not equal to the unspecified address inserts an entry for		address not equal to the unspecified address inserts an entry for
	the IPv6 address into its Neighbor Cache. Also, a node performing		the IPv6 address into its Neighbor Cache. Also, a node performing
	Duplicate Address Detection (DAD) that receives a Neighbor		Duplicate Address Detection (DAD) that receives a Neighbor
	Solicitation for the same address regards the situation as a		Solicitation for the same address regards the situation as a
	collision and ceases to solicit for the address.		collision and ceases to solicit for the address.
	In either case, SEND counters these treats by requiring the		In either case, SEND counters these treats by requiring the RSA
	Signature and CGA options to be present in such solicitations.		Signature and CGA options to be present in such solicitations.
	SEND nodes can send Router Solicitation messages with a CGA		SEND nodes can send Router Solicitation messages with a CGA
	source address and a CGA option, which the router can verify, so		source address and a CGA option, which the router can verify, so
	the Neighbor Cache binding is correct. If a SEND node must send		the Neighbor Cache binding is correct. If a SEND node must send
	a Router Solicitation with the unspecified address, the router		a Router Solicitation with the unspecified address, the router
	will not update its Neighbor Cache, as per RFC 2461.		will not update its Neighbor Cache, as per RFC 2461.
	2. Entries made as a result of a Neighbor Advertisement message.		2. Entries made as a result of a Neighbor Advertisement message.
	SEND counters this threat by requiring the Signature and CGA		SEND counters this threat by requiring the RSA Signature and CGA
	options to be present in these advertisements.		options to be present in these advertisements.
	See also Section 9.2.5, below, for discussion about replay protection		See also Section 9.2.5, below, for discussion about replay protection
	and timestamps.		and timestamps.
	9.2.2 Neighbor Unreachability Detection Failure		9.2.2 Neighbor Unreachability Detection Failure
	This attack is described in Section 4.1.2 of [24]. SEND counters		This attack is described in Section 4.1.2 of [24]. 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 an RSA 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.
	9.2.3 Duplicate Address Detection DoS Attack		9.2.3 Duplicate Address Detection DoS Attack
	This attack is described in Section 4.1.3 of [24]. SEND counters		This attack is described in Section 4.1.3 of [24]. 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 an RSA 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 performing DAD, it may listen for address		When a SEND node is performing DAD, it may listen for address
	collisions from non-SEND nodes for the first address it generates,		collisions from non-SEND nodes for the first address it generates,
	but not for new attempts. This protects the SEND node from DAD DoS		but not for new attempts. This protects the SEND node from DAD DoS
	attacks by non-SEND nodes or attackers simulating to non-SEND nodes,		attacks by non-SEND nodes or attackers simulating to non-SEND nodes,
	at the cost of a potential address collision between a SEND node and		at the cost of a potential address collision between a SEND node and
	non-SEND node. The probability and effects of such an address		non-SEND node. The probability and effects of such an address
	collision are discussed in [13].		collision are discussed in [13].
	9.2.4 Router Solicitation and Advertisement Attacks		9.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 [24]. SEND counters these attacks by requiring Router		and 4.2.7 of [24]. SEND counters these attacks by requiring Router
	Advertisements to contain a Signature option, and that the signature		Advertisements to contain an RSA Signature option, and that the
	is calculated using the public key of a node that can prove its		signature is calculated using the public key of a node that can prove
	authorization to route the subnet prefixes contained in any Prefix		its authorization to route the subnet prefixes contained in any
	Information Options. The router proves its authorization by showing		Prefix Information Options. The router proves its authorization by
	a certificate containing the specific prefix or the indication that		showing a certificate containing the specific prefix or the
	the router is allowed to route any prefix. A Router Advertisement		indication that the router is allowed to route any prefix. A Router
	without these protections is discarded.		Advertisement without these protections is discarded.
	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 [24].		4.4.2 and 4.4.3 of [24].
	9.2.5 Replay Attacks		9.2.5 Replay Attacks
	This attack is described in Section 4.3.1 of [24]. SEND protects		This attack is described in Section 4.3.1 of [24]. 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
	skipping to change at page 46, line 38		skipping to change at page 46, line 38
	the verification process described in Section 5.2.2. In this process,		the verification process described in Section 5.2.2. In this process,
	a simple hash verification of the CGA property of the address is		a simple hash verification of the CGA property of the address is
	performed before performing the more expensive signature		performed before performing the more expensive signature
	verification. However, even if the CGA verification succeeds, no		verification. However, even if the CGA verification succeeds, no
	claims about the validity of the message can be made, until the		claims about the validity of the message can be made, until the
	signature has been checked.		signature has been checked.
	When trust anchors and certificates are used for address validation		When trust anchors and certificates are used for address validation
	in SEND, the defenses are not quite as effective. Implementations		in SEND, the defenses are not quite as effective. Implementations
	SHOULD track the resources devoted to the processing of packets		SHOULD track the resources devoted to the processing of packets
	received with the Signature option, and start selectively discarding		received with the RSA Signature option, and start selectively
	packets if too many resources are spent. Implementations MAY also		discarding packets if too many resources are spent. Implementations
	first discard packets that are not protected with CGA.		MAY also first discard packets that are not protected with CGA.
	The Authorization Delegation Discovery process may also be vulnerable		The Authorization Delegation Discovery process may also be vulnerable
	to Denial-of-Service attacks. An attack may target a router by		to Denial-of-Service attacks. An attack may target a router by
	requesting a large number of delegation chains to be discovered for		requesting a large number of delegation chains to be discovered for
	different trust anchors. Routers SHOULD defend against such attacks		different trust anchors. Routers SHOULD defend against such attacks
	by caching discovered information (including negative responses) and		by caching discovered information (including negative responses) and
	by limiting the number of different discovery processes they engage		by limiting the number of different discovery processes they engage
	in.		in.
	Attackers may also target hosts by sending a large number of		Attackers may also target hosts by sending a large number of
	skipping to change at page 50, line 22		skipping to change at page 50, line 22
	o The Delegation Chain Advertisement message, described in Section		o The Delegation Chain Advertisement message, described in Section
	6.2.2.		6.2.2.
	This document defines six new Neighbor Discovery Protocol [7]		This document defines six new Neighbor Discovery Protocol [7]
	options, which must be assigned Option Type values within the option		options, which must be assigned Option Type values within the option
	numbering space for Neighbor Discovery Protocol messages:		numbering space for Neighbor Discovery Protocol messages:
	o The CGA option, described in Section 5.1.		o The CGA option, described in Section 5.1.
	o The Signature option, described in Section 5.2.		o The RSA Signature option, described in Section 5.2.
	o The Timestamp option, described in Section 5.3.1.		o The Timestamp option, described in Section 5.3.1.
	o The Nonce option, described in Section 5.3.2.		o The Nonce option, described in Section 5.3.2.
	o The Trust Anchor option, described in Section 6.2.3.		o The Trust Anchor option, described in Section 6.2.3.
	o The Certificate option, described in Section 6.2.4.		o The Certificate option, described in Section 6.2.4.
	This document defines a new 128-bit value under the CGA Message Type		This document defines a new 128-bit value under the CGA Message Type
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/