base.txt		issue74.txt
	skipping to change at page 4, line 25		skipping to change at page 4, line 25
	The original NDP specifications called for the use of IPsec to		The original NDP specifications called for the use of IPsec to
	protect NDP messages. However, the RFCs do not give detailed		protect NDP messages. However, the RFCs do not give detailed
	instructions for using IPsec for this. In this particular		instructions for using IPsec for this. In this particular
	application, IPsec can only be used with a manual configuration of		application, IPsec can only be used with a manual configuration of
	security associations, due to bootstrapping problems in using IKE		security associations, due to bootstrapping problems in using IKE
	[22, 18]. Furthermore, the number of such manually configured		[22, 18]. Furthermore, the number of such manually configured
	security associations needed for protecting NDP can be very large		security associations needed for protecting NDP can be very large
	[23], making that approach impractical for most purposes.		[23], making that approach impractical for most purposes.
			The SEND protocol is designed to counter the threats to NDP. These
			threats are described in detail in [25]. SEND is applicable in
			environments where physical security on the link is not assured (such
			as over wireless) and attacks on NDP are a concern.
	This document is organized as follows. Section 2 and Section 3 define		This document is organized as follows. Section 2 and Section 3 define
	some terminology and present a brief review of NDP, respectively.		some terminology and present a brief review of NDP, respectively.
	Section 4 describes the overall approach to securing NDP. This		Section 4 describes the overall approach to securing NDP. This
	approach involves the use of new NDP options to carry public-key		approach involves the use of new NDP options to carry public-key
	based signatures. A zero-configuration mechanism is used for showing		based signatures. A zero-configuration mechanism is used for showing
	address ownership on individual nodes; routers are certified by a		address ownership on individual nodes; routers are certified by a
	trust anchor [10]. The formats, procedures, and cryptographic		trust anchor [10]. The formats, procedures, and cryptographic
	mechanisms for the zero-configuration mechanism are described in a		mechanisms for the zero-configuration mechanism are described in a
	related specification [14].		related specification [14].
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/