1/base.txt		2/issue40.txt
Skipping to change at page 2, line 16:
specifications, these mechanisms do not make use of IPsec.		specifications, these mechanisms do not make use of IPsec.
Table of Contents		Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . 4		1.1 Specification of Requirements . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . 7		3. Neighbor and Router Discovery Overview . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 11		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 11
5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 12		5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 12
5.1 Ordering of the new options . . . . . . . . . . . . 12		5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . 12
5.2 CGA Option . . . . . . . . . . . . . . . . . . . . . 12		5.1.1 Processing Rules for Senders . . . . . . . . .14
5.2.1 Processing Rules for Senders . . . . . . . . .14		5.1.2 Processing Rules for Receivers . . . . . . . .14
5.2.2 Processing Rules for Receivers . . . . . . . .15		5.1.3 Configuration . . . . . . . . . . . . . . . .15
5.2.3 Configuration . . . . . . . . . . . . . . . .15		5.2 Signature Option . . . . . . . . . . . . . . . . . . 15
5.3 Signature Option . . . . . . . . . . . . . . . . . . 16		5.2.1 Processing Rules for Senders . . . . . . . . .18
5.3.1 Processing Rules for Senders . . . . . . . . .18		5.2.2 Processing Rules for Receivers . . . . . . . .18
5.3.2 Processing Rules for Receivers . . . . . . . .18		5.2.3 Configuration . . . . . . . . . . . . . . . .19
5.3.3 Configuration . . . . . . . . . . . . . . . .19		5.3 Timestamp and Nonce options . . . . . . . . . . . . 20
5.4 Timestamp and Nonce options . . . . . . . . . . . . 20		5.3.1 Timestamp Option . . . . . . . . . . . . . . .20
5.4.1 Timestamp Option . . . . . . . . . . . . . . .20		5.3.2 Nonce Option . . . . . . . . . . . . . . . . .21
5.4.2 Nonce Option . . . . . . . . . . . . . . . . .21		5.3.3 Processing rules for senders . . . . . . . . .22
5.4.3 Processing rules for senders . . . . . . . . .22		5.3.4 Processing rules for receivers . . . . . . . .22
5.4.4 Processing rules for receivers . . . . . . . .22		5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 24
5.5 Proxy Neighbor Discovery . . . . . . . . . . . . . . 24
6. Authorization Delegation Discovery . . . . . . . . . . . . 25		6. Authorization Delegation Discovery . . . . . . . . . . . . 25
6.1 Delegation Chain Solicitation Message Format . . . . 25		6.1 Delegation Chain Solicitation Message Format . . . . 25
6.2 Delegation Chain Advertisement Message Format . . . 27		6.2 Delegation Chain Advertisement Message Format . . . 27
6.3 Trust Anchor Option . . . . . . . . . . . . . . . . 29		6.3 Trust Anchor Option . . . . . . . . . . . . . . . . 29
6.4 Certificate Option . . . . . . . . . . . . . . . . . 30		6.4 Certificate Option . . . . . . . . . . . . . . . . . 30
6.5 Router Authorization Certificate Format . . . . . . 31		6.5 Router Authorization Certificate Format . . . . . . 31
6.5.1 Router Authorization Certificate Profile . . .32		6.5.1 Router Authorization Certificate Profile . . .32
6.6 Processing Rules for Routers . . . . . . . . . . . . 33		6.6 Processing Rules for Routers . . . . . . . . . . . . 33
6.7 Processing Rules for Hosts . . . . . . . . . . . . . 34		6.7 Processing Rules for Hosts . . . . . . . . . . . . . 34
7. Securing Neighbor Discovery with SEND . . . . . . . . . . 37		7. Securing Neighbor Discovery with SEND . . . . . . . . . . 37
Skipping to change at page 12, line 25:
o The Nonce option is REQUIRED in all Neighbor Discovery		o The Nonce option is REQUIRED in all Neighbor Discovery
solicitations, and in all solicited advertisements.		solicitations, and in all solicited advertisements.
o The Timestamp option is REQUIRED in all Neighbor Discovery		o The Timestamp option is REQUIRED in all Neighbor Discovery
advertisements and Redirects.		advertisements and Redirects.
o Proxy Neighbor Discovery is not supported by this specification;		o Proxy Neighbor Discovery is not supported by this specification;
it is planned to be specified in a future document.		it is planned to be specified in a future document.
5.1 Ordering of the new options		5.1 CGA Option
The ordering of the new options MUST obey the following rules:
The CGA option MUST appear before the Signature option.
The Nonce option SHOULD appear before the Timestamp option.
The Signature option MUST NOT be be followed CGA, Nonce, or
Timestamp options.
It is RECOMMENDED that the options appear in the following order:
CGA, Nonce, Timestamp, Signature.
5.2 CGA Option
The CGA option allows the verification of the sender's CGA. The		The CGA option allows the verification of the sender's CGA. The
format of the CGA option is described as follows.		format of the CGA option is described as follows.
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 | Collision Cnt | Reserved |		| Type | Length | Collision Cnt | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
Skipping to change at page 14, line 29:
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
encoding.		encoding.
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.
It begins after the ASN.1 encoding of the previous field has ends,		It begins after the ASN.1 encoding of the previous field has ends,
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.1.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
[12]. 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 [12]. In		An address MUST be constructed as specified in Section 4 of [12]. In
Skipping to change at page 15, line 20:
Router Solicitation		Router Solicitation
The address MUST be the source address of the message, unless the		The address MUST be the source address of the message, unless the
source address is the unspecified address.		source address is the unspecified address.
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.1.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 [12]. The inputs		using the algorithm described in Section 5 of [12]. The inputs
for the algorithm are the contents of the Collision Cnt, Modifier,		for the algorithm are the contents of the Collision Cnt, Modifier,
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
CGA property of the address is simply left unverified.		CGA property of the address is simply left unverified.
5.2.3 Configuration		5.1.3 Configuration
All nodes that support the verification of the CGA option MUST record		All nodes that support the verification of the CGA option MUST record
the following configuration information:		the following configuration information:
minbits		minbits
The minimum acceptable key length for the public keys used in the		The minimum acceptable key length for the public keys used in the
generation of the CGA address. The default SHOULD be 1024 bits.		generation of the CGA address. The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit in order to limit the		Implementations MAY also set an upper limit in order to limit the
amount of computation they need to perform when verifying packets		amount of computation they need to perform when verifying packets
that use these security associations. Any implementation should		that use these security associations. Any implementation should
follow prudent cryptographic practise in determining the		follow prudent cryptographic practise in determining the
appropriate key lengths.		appropriate key lengths.
5.3 Signature Option		5.2 Signature Option
The Signature option allows public-key based signatures to be		The Signature option allows public-key based signatures to be
attached to NDP messages. Both trust anchor authentication and CGAs		attached to NDP messages. Both trust anchor authentication and CGAs
can be used. The format of the Signature option is described in the		can be used. The format of the Signature option is described in the
following:		following:
0 1 2 3		0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | Reserved |		| Type | Length | Pad Length | Reserved |
Skipping to change at page 18, line 13:
and SHA-1 hash as defined in [13].		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.2.1 Processing Rules for Senders
A node sending a message using the Signature option MUST construct		A node sending a message using the Signature option MUST construct
the message as follows:		the message as follows:
o The message is constructed in its entirety.		o The message is constructed in its entirety.
o The Signature option is added as the last option in the message.		o The Signature option is added as the last option in the message.
o For the purpose of constructing a signature, the following data		o For the purpose of constructing a signature, the following data
items are concatenated:		items are concatenated:
Skipping to change at page 18, line 38:
* The destination address of the message.		* The destination address of the message.
* The contents of the message, starting from the ICMPv6 header,		* The contents of the message, starting from the ICMPv6 header,
up to but excluding the Signature option.		up to but excluding the Signature option.
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.3.2 Processing Rules for Receivers		5.2.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 preceding CGA option, or one known by		either one learned from a preceding CGA option, or one known by
other means.		other means.
o The Digital Signature field MUST have correct encoding, and do not		o The Digital Signature field MUST have correct encoding, and do not
Skipping to change at page 19, line 20:
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
anchor.		anchor.
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. The receiver MAY silently drop packets also otherwise,		discarded. The receiver MAY silently drop packets also otherwise,
e.g., as a response to an apparent CPU exhausting DoS attack.		e.g., as a response to an apparent CPU exhausting DoS attack.
5.3.3 Configuration		5.2.3 Configuration
All nodes that support the reception of the Signature options MUST		All nodes that support the reception of the Signature options MUST
record the following configuration information for each separate		record the following configuration information for each separate
Neighbor Discovery Protocol message type:		Neighbor Discovery Protocol message type:
authorization method		authorization method
This parameter determines the method through which the authority		This parameter determines the method through which the authority
of the sender is determined. It can have four values:		of the sender is determined. It can have four values:
Skipping to change at page 20, line 36:
CGA flag		CGA flag
A flag that indicates whether CGA is used or is not used. This		A flag that indicates whether CGA is used or is not used. This
flag may be per interface or per node.		flag may be per interface or per node.
CGA parameters		CGA parameters
Optionally any information required to construct CGAs, including		Optionally any information required to construct CGAs, including
the used Sec and Modifier values, and the CGA address itself.		the used Sec and Modifier values, and the CGA address itself.
5.4 Timestamp and Nonce options		5.3 Timestamp and Nonce options
5.4.1 Timestamp Option		5.3.1 Timestamp Option
The purpose of the Timestamp option is to ensure that unsolicited		The purpose of the Timestamp option is to ensure that unsolicited
advertisements and redirects have not been replayed. The format of		advertisements and redirects have not been replayed. The format of
the Timestamp option is described in the following:		the Timestamp option is described in the following:
0 1 2 3		0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |		| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Skipping to change at page 21, line 42:
Timestamp		Timestamp
A 64-bit unsigned integer field containing a timestamp. The value		A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1,, 1970 00:00 UTC,		indicates the number of seconds since January 1,, 1970 00:00 UTC,
using a fixed point format. In this format the integer number of		using a fixed point format. In this format the integer number of
seconds is contained in the first 48 bits of the field, and the		seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a		remaining 16 bits indicate the number of 1/64K fractions of a
second.		second.
5.4.2 Nonce Option		5.3.2 Nonce Option
The purpose of the Nonce option is to ensure that an advertisement is		The purpose of the Nonce option is to ensure that an advertisement is
a fresh response to a solicitation sent earlier by the receiving same		a fresh response to a solicitation sent earlier by the receiving same
node. The format of the Nonce option is as described in the		node. The format of the Nonce option is as described in the
following:		following:
0 1 2 3		0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce ... |		| Type | Length | Nonce ... |
Skipping to change at page 22, line 32:
Length		Length
The length of the option, in units of 8 octets.		The length of the option, in units of 8 octets.
Nonce		Nonce
A field containing a random number selected by the sender of the		A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at		solicitation message. The length of the random number MUST be at
least 6 bytes.		least 6 bytes.
5.4.3 Processing rules for senders		5.3.3 Processing rules for senders
All solicitation messages MUST include a Nonce. All solicited-for		All solicitation messages MUST include a Nonce. All solicited-for
announcements MUST include a Nonce, copying the nonce value from the		announcements MUST include a Nonce, copying the nonce value from the
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 [7] Section 9.		prepared to receive them in any order, as per RFC 2461 [7] Section 9.
5.4.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-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.3.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.3.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
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 filling		very large number of nodes on the same link, or when a cache filling
attack is in progress, it is possible that the cache holding the most		attack is in progress, it is possible that the cache holding the most
recent timestamp per sender becomes full. In this case the node MUST		recent timestamp per sender becomes full. In this case the node MUST
remove some entries from the cache or refuse some new requested		remove some entries from the cache or refuse some new requested
entries. The specific policy as to which entries are preferred over		entries. The specific policy as to which entries are preferred over
the others is left as an implementation decision. However, typical		the others is left as an implementation decision. However, typical
policies may prefer existing entries over new ones, CGAs with a large		policies may prefer existing entries over new ones, CGAs with a large
Sec value over smaller Sec values, and so on. The issue is briefly		Sec value over smaller Sec values, and so on. The issue is briefly
discussed in Appendix C.		discussed in Appendix C.
5.4.4.1 Processing solicited-for advertisements		5.3.4.1 Processing solicited-for advertisements
The receiver MUST verify that it has recently send a matching		The receiver MUST verify that it has recently send a matching
solicitation, and that the received advertisement does contain a copy		solicitation, and that the received advertisement does contain a copy
of the Nonce sent in the solicitation.		of the Nonce sent in the solicitation.
If the message does not contain a Nonce option, it MAY be considered		If the message does not contain a Nonce option, it MAY be considered
as a non-solicited-for announcement, and processed according to		as a non-solicited-for announcement, and processed according to
Section 5.4.4.2.		Section 5.3.4.2.
If the message does contain a Nonce option, but the Nonce value is		If the message does contain a Nonce option, but the Nonce value is
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.3.4.2
5.4.4.2 Processing all other messages		5.3.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 drift		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, accepted SEND message.		The receive time of the last received, accepted SEND message.
Skipping to change at page 24, line 37:
against the previously received SEND message:		against the previously received SEND message:
TSnew > TSlast + (RDnew - RDlast) x (1 - drift)		TSnew > TSlast + (RDnew - RDlast) x (1 - drift)
o If TSnew < TSlast, which is possible if packets arrive rapidly and		o If TSnew < TSlast, which is possible if packets arrive rapidly and
out of order, TSlast MUST NOT be updated, i.e., the stored TSlast		out of order, TSlast MUST NOT be updated, i.e., the stored TSlast
for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD		for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD
be updated. Independent on whether TSlast is updated or not,		be updated. Independent on whether TSlast is updated or not,
RDlast is updated in any case.		RDlast is updated in any case.
5.5 Proxy Neighbor Discovery		5.4 Proxy Neighbor Discovery
The Target Address in Neighbor Advertisement is required to be equal		The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in the case of proxy		to the source address of the packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by		Neighbor Discovery. Proxy Neighbor Discovery is not supported by
this specification; it is planned to be specified in a future		this specification; it is planned to be specified in a future
document.		document.
6. Authorization Delegation Discovery		6. Authorization Delegation Discovery
Several protocols, including the IPv6 Neighbor Discovery Protocol,		Several protocols, including the IPv6 Neighbor Discovery Protocol,
Skipping to change at page 49, line 41:
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.
When timestamps are used, SEND nodes are protected against replay		When timestamps are used, SEND nodes are protected against replay
attacks as long as they cache the state created by the message		attacks as long as they cache the state created by the message
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.3.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 [26]. 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
Skipping to change at page 50, line 19:
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 [12].		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.2.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
address is performed first before performing the more expensive		address is performed first before performing the more expensive
signature verification.		signature verification.
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 dropping		received with the Signature option, and start selectively dropping
packets if too many resources are spent. Implementations MAY also		packets if too many resources are spent. Implementations MAY also
first drop packets that are not protected with CGA.		first drop packets that are not protected with CGA.
Skipping to change at page 52, line 25:
6.2.		6.2.
This document defines six new Neighbor Discovery Protocol [7]		This document defines six new Neighbor Discovery Protocol [7]
options, which must be assigned Option Type values within the option		options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages:		numbering space for Neighbor Discovery Protocol messages:
o The Trust Anchor option, described in Section 6.3.		o The Trust Anchor option, described in Section 6.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.1.
o The Signature option, described in Section 5.3.		o The Signature option, described in Section 5.2.
o The Timestamp option, described in Section 5.4.1.		o The Timestamp option, described in Section 5.3.1.
o The Nonce option, described in Section 5.4.2.		o The Nonce option, described in Section 5.3.2.
This document defines a new 128-bit CGA Message Type [12] value,		This document defines a new 128-bit CGA Message Type [12] value,
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 [6].		using standards action [6].

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