base.txt		issue78.txt
	skipping to change at page 41, line 17		skipping to change at page 41, line 17
	network operators may want to run a particular link with a mixture of		network operators may want to run a particular link with a mixture of
	secure and insecure nodes. Nodes that support SEND SHOULD support		secure and insecure nodes. Nodes that support SEND SHOULD support
	the use of SEND and plain NDP at the same time.		the use of SEND and plain NDP at the 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.
			A SEND node SHOULD have a configuration option that causes it to
			ignore all insecure Neighbor Solicitation and Advertisement, Router
			Solicitation and Advertisement, and Redirect messages. This can be
			used to enforce SEND-only networks. The default for this
			configuration option SHOULD be that both secure and insecure messages
			are allowed.
	SEND nodes MUST send only secured messages. Plain (non-SEND)		SEND nodes MUST send only secured messages. Plain (non-SEND)
	Neighbor Discovery nodes will obviously send only insecure messages.		Neighbor Discovery nodes will obviously send only insecure messages.
	Per RFC 2461 [7], such nodes will ignore the unknown options and will		Per RFC 2461 [7], such nodes will ignore the unknown options and will
	treat secured messages in the same way as they treat insecure ones.		treat 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 nodes follow the protocols defined in RFC		In a mixed environment SEND nodes follow the protocols defined in RFC
	2461 and RFC 2462 with the following exceptions:		2461 and RFC 2462 with the following exceptions:
	skipping to change at page 42, line 38		skipping to change at page 43, line 4
	verification, CRL checks, and RA signature checks. A node MAY also		verification, CRL checks, and RA signature checks. A node MAY also
	adopt an insecure router if a SEND router becomes unreachable, but		adopt an insecure router if a SEND router becomes unreachable, but
	SHOULD attempt to find a SEND router as soon as possible, since		SHOULD attempt to find a SEND router as soon as possible, since
	the unreachability may be the result of an attack. Note that while		the unreachability may be the result of an attack. Note that while
	this can speed up attachment to a new network, accepting an		this can speed up attachment to a new network, accepting an
	insecure router opens the node to possible attacks, and nodes that		insecure router opens the node to possible attacks, and nodes that
	choose to accept insecure routers do so at their own risk. The		choose to accept insecure routers do so at their own risk. The
	node SHOULD in any case prefer the SEND router as soon as one is		node SHOULD in any case prefer the SEND router as soon as one is
	available with completed security checks.		available with completed security checks.
	o A SEND node SHOULD have a configuration option that causes it to
	ignore all insecure Neighbor Solicitation and Advertisement,
	Router Solicitation and Advertisement, and Redirect messages. This
	can be used to enforce SEND-only networks.
	9. Security Considerations		9. Security Considerations
	9.1 Threats to the Local Link Not Covered by SEND		9.1 Threats to the Local Link Not Covered by SEND
	SEND does not provide confidentiality for NDP communications.		SEND does not provide confidentiality for NDP communications.
	SEND does not compensate for an insecure link layer. For instance,		SEND does not compensate for an insecure link layer. For instance,
	there is no assurance that payload packets actually come from the		there is no assurance that payload packets actually come from the
	same peer that the NDP was run against.		same peer that the NDP was run against.
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/