base.txt		issue85.txt
	skipping to change at page 2, line 27		skipping to change at page 2, line 27
	5.1.3 Configuration . . . . . . . . . . . . . . . . . 14		5.1.3 Configuration . . . . . . . . . . . . . . . . . 14
	5.2 Signature Option . . . . . . . . . . . . . . . . . . . 14		5.2 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 . . . . . . . . . 21		5.3.4 Processing rules for receivers . . . . . . . . . 22
	6. Authorization Delegation Discovery . . . . . . . . . . . . . 25		6. Authorization Delegation Discovery . . . . . . . . . . . . . 25
	6.1 Certificate Format . . . . . . . . . . . . . . . . . . 25		6.1 Certificate Format . . . . . . . . . . . . . . . . . . 25
	6.1.1 Router Authorization Certificate Profile . . . . 25		6.1.1 Router Authorization Certificate Profile . . . . 25
	6.2 Certificate Transport . . . . . . . . . . . . . . . . 28		6.2 Certificate Transport . . . . . . . . . . . . . . . . 28
	6.2.1 Delegation Chain Solicitation Message Format . . 28		6.2.1 Delegation Chain Solicitation Message Format . . 28
	6.2.2 Delegation Chain Advertisement Message Format . 30		6.2.2 Delegation Chain Advertisement Message Format . 30
	6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 32		6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 32
	6.2.4 Certificate Option . . . . . . . . . . . . . . . 34		6.2.4 Certificate Option . . . . . . . . . . . . . . . 34
	6.2.5 Processing Rules for Routers . . . . . . . . . . 35		6.2.5 Processing Rules for Routers . . . . . . . . . . 35
	6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36		6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36
	skipping to change at page 13, line 31		skipping to change at page 13, line 31
	option MUST be treated as insecure, i.e., processed in the same way		option MUST be treated as insecure, i.e., processed in the same way
	as NDP messages sent by a non-SEND node. The processing of insecure		as NDP messages sent by a non-SEND node. The processing of insecure
	messages is specified in Section 8. Note that SEND nodes that do not		messages is specified in Section 8. Note that SEND nodes that do not
	attempt to interoperate with non-SEND nodes MAY simply discard the		attempt to interoperate with non-SEND nodes MAY simply discard the
	insecure messages.		insecure messages.
	Router Solicitation messages without the CGA option MUST be also		Router Solicitation messages without the CGA option MUST be also
	treated as insecure, unless the source address of the message is the		treated as insecure, unless the source address of the message is the
	unspecified address.		unspecified address.
	A message containing a CGA option MUST be checked as follows:		Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
			Solicitation, and Router Advertisement messages containing a CGA
			option MUST be checked as follows:
	If the interface has been configured to use CGA, the receiving		If the interface has been configured to use CGA, the receiving
	node MUST verify the source address of the packet using the		node MUST verify the source address of the packet using the
	algorithm described in Section 5 of [13]. The inputs to the		algorithm described in Section 5 of [13]. The inputs to the
	algorithm are the claimed address, as defined in the previous		algorithm are the claimed address, as defined in the previous
	section, and the CGA Parameters field.		section, and the CGA Parameters field.
	If the CGA verification is successful, the recipient proceeds with		If the CGA verification is successful, the recipient proceeds with
	the cryptographically more time consuming check of the signature.		the cryptographically more time consuming check of the signature.
	However, even if the CGA verification succeeds, no claims about		However, even if the CGA verification succeeds, no claims about
	skipping to change at page 17, line 24		skipping to change at page 17, line 24
	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 Signature option MUST be treated as
	insecure, i.e., processed in the same way as NDP messages sent by a		insecure, i.e., processed in the same way as NDP messages sent by a
	non-SEND node. See Section 8.		non-SEND node. See Section 8.
	Router Solicitation messages without the Signature option MUST be		Router Solicitation messages without the 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.
	A message containing a Signature option MUST be checked as follows:		Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
			Solicitation, and Router Advertisement messages containing a
			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
	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
	skipping to change at page 17, line 49		skipping to change at page 18, line 3
	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
	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 also otherwise silently discard packets,		discarded if the host has been configured to only accept secure ND
	e.g., as a response to an apparent CPU exhausting DoS attack.		messages. The messages MAY be accepted it the host has been
			configured to accept both secure and insecure messages, but MUST be
			treated as an insecure message. The receiver MAY also otherwise
			silently discard packets, e.g., as a response to an apparent CPU
			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 Signature options MUST be
	configured with the following information for each separate NDP		configured with the following information for each separate NDP
	message type:		message type:
	authorization method		authorization method
	This parameter determines the method through which the authority		This parameter determines the method through which the authority
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/