base.txt		issue70.txt
	Secure Neighbor Discovery Working J. Arkko (Editor)		Secure Neighbor Discovery Working J. Arkko (Editor)
	Group Ericsson		Group Ericsson
	Internet-Draft J. Kempf		Internet-Draft J. Kempf
	Expires: September 30, 2004 DoCoMo Communications Labs USA		Expires: October 5, 2004 DoCoMo Communications Labs USA
	B. Sommerfeld		B. Sommerfeld
	Sun Microsystems		Sun Microsystems
	B. Zill		B. Zill
	Microsoft		Microsoft
	P. Nikander		P. Nikander
	Ericsson		Ericsson
	April 1, 2004		April 6, 2004
	SEcure Neighbor Discovery (SEND)		SEcure Neighbor Discovery (SEND)
	draft-ietf-send-ndopt-05pre1		draft-ietf-send-ndopt-05pre1
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 30, 2004.		This Internet-Draft will expire on October 5, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover		IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
	other nodes on the link, to determine the link-layer addresses of		other nodes on the link, to determine the link-layer addresses of
	other nodes on the link, to find routers, and to maintain		other nodes on the link, to find routers, and to maintain
	skipping to change at page 2, line 19		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 . . . . . . . . . . . . . . . . . . .15		5.2 Signature Option . . . . . . . . . . . . . . . . . . .14
	5.2.1 Processing Rules for Senders . . . . . . . . . 17		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 . . . . . . . . . . . . .20		5.3 Timestamp and Nonce options . . . . . . . . . . . . .19
	5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20		5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19
	5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21		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
	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
	7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
	7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38		7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38
	7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38		7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38
	7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38		7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38
	7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39		7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39
	8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41		8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 40
	9. Security Considerations . . . . . . . . . . . . . . . . . . 43		9. Security Considerations . . . . . . . . . . . . . . . . . . 42
	9.1 Threats to the Local Link Not Covered by SEND . . . .43		9.1 Threats to the Local Link Not Covered by SEND . . . .42
	9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43		9.2 How SEND Counters Threats to NDP . . . . . . . . . . .42
	9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44		9.2.1 Neighbor Solicitation/Advertisement Spoofing . 43
	9.2.2 Neighbor Unreachability Detection Failure . . 44		9.2.2 Neighbor Unreachability Detection Failure . . 43
	9.2.3 Duplicate Address Detection DoS Attack . . . . 44		9.2.3 Duplicate Address Detection DoS Attack . . . . 43
	9.2.4 Router Solicitation and Advertisement Attacks 45		9.2.4 Router Solicitation and Advertisement Attacks 44
	9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45		9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 44
	9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46		9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 45
	9.3 Attacks against SEND Itself . . . . . . . . . . . . .46		9.3 Attacks against SEND Itself . . . . . . . . . . . . .45
	10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48		10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 47
	11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 49		11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 48
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
	Normative References . . . . . . . . . . . . . . . . . . . . 51		Normative References . . . . . . . . . . . . . . . . . . . . 50
	Informative References . . . . . . . . . . . . . . . . . . . 53		Informative References . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55
	C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 57		C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56
	Intellectual Property and Copyright Statements . . . . . . . 58		Intellectual Property and Copyright Statements . . . . . . . 57
	1. Introduction		1. Introduction
	IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]		IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
	and 2462 [8]. Nodes on the same link use NDP to discover each		and 2462 [8]. Nodes on the same link use NDP to discover each
	other's presence, to determine each other's link-layer addresses, to		other's presence, to determine each other's link-layer addresses, to
	find routers, and to maintain reachability information about the		find routers, and to maintain reachability information about the
	paths to active neighbors. NDP is used both by hosts and routers.		paths to active neighbors. NDP is used both by hosts and routers.
	Its functions include Neighbor Discovery (ND), Router Discovery (RD),		Its functions include Neighbor Discovery (ND), Router Discovery (RD),
	Address Autoconfiguration, Address Resolution, Neighbor		Address Autoconfiguration, Address Resolution, Neighbor
	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
	[21, 16]. Furthermore, the number of such manually configured		[21, 16]. 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
	[22], making that approach impractical for most purposes.		[22], making that approach impractical for most purposes.
	This document is organized as follows. Section 2 and Section 3		This document is organized as follows. Section 2 and Section 3 define
	define some terminology and present a brief review of NDP,		some terminology and present a brief review of NDP, respectively.
	respectively. Section 4 describes the overall approach to securing		Section 4 describes the overall approach to securing NDP. This
	NDP. This approach involves the use of new NDP options to carry		approach involves the use of new NDP options to carry public-key
	public-key based signatures. A zero-configuration mechanism is used		based signatures. A zero-configuration mechanism is used for showing
	for showing address ownership on individual nodes; routers are		address ownership on individual nodes; routers are certified by a
	certified by a trust anchor [10]. The formats, procedures, and		trust anchor [10]. The formats, procedures, and cryptographic
	cryptographic mechanisms for the zero-configuration mechanism are		mechanisms for the zero-configuration mechanism are described in a
	described in a related specification [13].		related specification [13].
	The required new NDP options are discussed in Section 5. Section 6		The required new NDP options are discussed in Section 5. Section 6
	describes the mechanism for distributing certificate chains to		describes the mechanism for distributing certificate chains to
	establish an authorization delegation chain to a common trust anchor.		establish an authorization delegation chain to a common trust anchor.
	Finally, Section 8 discusses the co-existence of secure and		Finally, Section 8 discusses the co-existence of secure and
	non-secure NDP on the same link and Section 9 discusses security		non-secure NDP on the same link and Section 9 discusses security
	considerations for Secure Neighbor Discovery (SEND).		considerations for Secure Neighbor Discovery (SEND).
	1.1 Specification of Requirements		1.1 Specification of Requirements
	skipping to change at page 7, line 36		skipping to change at page 7, line 36
	to a better first-hop router, or to inform hosts that a		to a better first-hop router, or to inform hosts that a
	destination is in fact a neighbor (i.e., on-link). Redirect is		destination is in fact a neighbor (i.e., on-link). Redirect is
	specified in Section 8 of RFC 2461 [7].		specified in Section 8 of RFC 2461 [7].
	o Address Autoconfiguration is used for automatically assigning		o Address Autoconfiguration is used for automatically assigning
	addresses to a host [8]. This allows hosts to operate without		addresses to a host [8]. This allows hosts to operate without
	explicit configuration related to IP connectivity. The default		explicit configuration related to IP connectivity. The default
	autoconfiguration mechanism is stateless. To create IP addresses,		autoconfiguration mechanism is stateless. To create IP addresses,
	hosts use any prefix information delivered to them during Router		hosts use any prefix information delivered to them during Router
	Discovery, and then test the newly formed addresses for		Discovery, and then test the newly formed addresses for
	uniqueness. A stateful mechanism, DHCPv6 [20], provides		uniqueness. A stateful mechanism, DHCPv6 [20], provides additional
	additional autoconfiguration features.		autoconfiguration features.
	o Duplicate Address Detection (DAD) is used for preventing address		o Duplicate Address Detection (DAD) is used for preventing address
	collisions [8], for instance during Address Autoconfiguration. A		collisions [8], for instance during Address Autoconfiguration. A
	node that intends to assign a new address to one of its interfaces		node that intends to assign a new address to one of its interfaces
	first runs the DAD procedure to verify that there is no other node		first runs the DAD procedure to verify that there is no other node
	using the same address. Since the rules forbid the use of an		using the same address. Since the rules forbid the use of an
	address until it has been found unique, no higher layer traffic is		address until it has been found unique, no higher layer traffic is
	possible until this procedure has been completed. Thus,		possible until this procedure has been completed. Thus,
	preventing attacks against DAD can help ensure the availability of		preventing attacks against DAD can help ensure the availability of
	communications for the node in question.		communications for the node in question.
	o The Address Resolution function allows a node on the link to		o The Address Resolution function allows a node on the link to
	resolve another node's IPv6 address to the corresponding		resolve another node's IPv6 address to the corresponding
	link-layer address. Address Resolution is defined in Section 7.2		link-layer address. Address Resolution is defined in Section 7.2
	of RFC 2461 [7], and it is used for hosts and routers alike.		of RFC 2461 [7], and it is used for hosts and routers alike.
	Again, no higher level traffic can proceed until the sender knows		Again, no higher level traffic can proceed until the sender knows
	the link layer address of the destination node or the next hop		the link layer address of the destination node or the next hop
	router. Note the source link layer address on link layer frames		router. Note the source link layer address on link layer frames is
	is not checked against the information learned through Address		not checked against the information learned through Address
	Resolution. This allows for an easier addition of network		Resolution. This allows for an easier addition of network
	elements such as bridges and proxies, and eases the stack		elements such as bridges and proxies, and eases the stack
	implementation requirements as less information needs to be passed		implementation requirements as less information needs to be passed
	from layer to layer.		from layer to layer.
	o Neighbor Unreachability Detection (NUD) is used for tracking the		o Neighbor Unreachability Detection (NUD) is used for tracking the
	reachability of neighboring nodes, both hosts and routers. NUD is		reachability of neighboring nodes, both hosts and routers. NUD is
	defined in Section 7.3 of RFC 2461 [7]. NUD is		defined in Section 7.3 of RFC 2461 [7]. NUD is
	security-sensitive, because an attacker could falsely claim that		security-sensitive, because an attacker could falsely claim that
	reachability exists when it in fact does not.		reachability exists when it in fact does not.
	skipping to change at page 11, line 17		skipping to change at page 11, line 17
	nodes.		nodes.
	5.1 CGA Option		5.1 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 | Pad Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| Modifier |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Key Information .		. CGA Parameters .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Padding .		. Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD <To be assigned by IANA for CGA>.		TBD <To be assigned by IANA for CGA>.
	Length		Length
	The length of the option (including the Type, Length, Collision		The length of the option (including the Type, Length, Pad Length,
	Cnt, Reserved, Modifier, Key Information, and Padding fields) in		Reserved, CGA Parameters, and Padding fields) in units of 8
	units of 8 octets.		octets.
	Collision Cnt		Pad Length
	An 8-bit collision count, which can be 0, 1 or 2. Its semantics		The number of padding octets beyond the end of the CGA Parameters
	are defined in [13].		field but within the length specified by the Length field. Padding
			octets MUST be set to zero by senders and ignored by receivers.
	Reserved		Reserved
	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.
	Modifier		CGA Parameters
	A random 128-bit number used in CGA generation. Its semantics are
	defined in [13].
	Key Information
	A variable length field containing the public key of the sender,		A variable length field containing the CGA Parameters data
	represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as		structure described in Section 4 of [13].
	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 publicKey field in the CGA		Signature option are present, then the public key found from the
	option MUST be the public key referred by the Key Hash field in		CGA Parameters field in the CGA option MUST be the public key
	the Signature option. Packets received with two different keys		referred by the Key Hash field in the Signature option. Packets
	MUST be silently discarded. Note that a future extension may		received with two different keys MUST be silently discarded. Note
	provide a mechanism which allows the owner of an address and the		that a future extension may provide a mechanism which allows the
	signer to be different parties.		owner of an address and the signer to be different parties.
	The length of the Key Information field is determined by the ASN.1
	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,
	beginning after the ASN.1 encoding of the previous field ends, and		containing as many octets as specified in the Pad Length field.
	continuing to the end of the option, as specified by the 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
	messages unless they are sent with the unspecified source address.		messages unless they are sent with the unspecified source address.
	The CGA option MAY be present in other messages.		The CGA option MAY be present in other messages.
	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 CGA Parameter field in the CGA option is filled in according to
	option are filled in according to the rules presented above and in		the rules presented above and in [13]. The public key in the field is
	[13]. The public key in the Key Information field is taken from the		taken from the node's configuration used to generate the CGA;
	node's configuration used to generate the CGA; typically from a data		typically from a data structure associated with the source address.
	structure associated with the source address. The address MUST be		The address MUST be constructed as specified in Section 4 of [13].
	constructed as specified in Section 4 of [13]. Depending on the type		Depending on the type of the message, this address appears in
	of the message, this address appears in different places:		different places:
	Redirect		Redirect
	The address MUST be the source address of the message.		The address MUST be the source address of the message.
	Neighbor Solicitation		Neighbor Solicitation
	The address MUST be the Target Address for solicitations sent for		The address MUST be the Target Address for solicitations sent for
	Duplicate Address Detection, and the source address of the message		Duplicate Address Detection, and the source address of the message
	otherwise.		otherwise.
	skipping to change at page 14, line 5		skipping to change at page 13, line 37
	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:		A message 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 concatenation from left to right of the following		section, and the CGA Parameters field.
	data: the contents of the 8-octet Modifier field, the 8-octet
	subnet-prefix part of the claimed address, the content of the
	1-octet Collision Cnt field, and contents of the variable-length
	Key Information 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
	the validity of the use can be made, until the signature has been		the validity of the use can be made, until the signature has been
	checked.		checked.
	Note that a receiver that does not support CGA or has not specified		Note that a receiver that 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 a CGA is used on a packet. In such a case, the CGA		anchors, even if a CGA is used on a packet. In such a case, the CGA
	skipping to change at page 14, line 33		skipping to change at page 14, line 15
	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 public keys used in the		The minimum acceptable key length for public keys used in the
	generation of CGAs. The default SHOULD be 1024 bits.		generation of CGAs. 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. The upper limit SHOULD be		that use these security associations. The upper limit SHOULD be at
	at 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.
	minSec		minSec
	The minimum acceptable Sec value, if CGA verification is required.		The minimum acceptable Sec value, if CGA verification is required.
	This parameter is intended to facilitate future extensions and		This parameter is intended to facilitate future extensions and
	experimental work. Currently, the minSec value SHOULD always be		experimental work. Currently, the minSec value SHOULD always be
	set to zero.		set to zero.
	See Section 2 in [13].		See Section 2 in [13].
	skipping to change at page 15, line 12		skipping to change at page 14, line 39
	following configuration information:		following configuration information:
	CGA parameters		CGA parameters
	Any information required to construct CGAs, including the used Sec		Any information required to construct CGAs, including the used Sec
	and Modifier values, and the CGA address itself.		and Modifier values, and the CGA address itself.
	5.2 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. Configured trust anchors, CGAs, or both		attached to NDP messages. Configured trust anchors, CGAs, or both are
	are supported as the trusted root. The format of the Signature		supported as the trusted root. The format of the Signature option is
	option is described in the following diagram:		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 45		skipping to change at page 15, line 33
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD <To be assigned by IANA for Signature>.		TBD <To be assigned by IANA for Signature>.
	Length		Length
	The length of the option (including the Type, Length, Pad Length,		The length of the option (including the Type, Length, Reserved,
	Reserved, Key Hash, Digital Signature, and Padding fields) in		Key Hash, Digital Signature, and Padding fields) in units of 8
	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
	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.
	Key Hash		Key Hash
	A 128-bit field containing the most significant (leftmost)		A 128-bit field containing the most significant (leftmost)
	128-bits of a SHA-1 hash of the public key used for constructing		128-bits of a SHA-1 hash of the public key used for constructing
	the signature. The SHA-1 hash is taken over the presentation used		the signature. The SHA-1 hash is taken over the presentation used
	in the Key Information field of the CGA option. Its purpose is to		in the Public Key field of the CGA Parameters data structure that
	associate the signature to a particular key known by the receiver.		is carried in the CGA option. Its purpose is to associate the
	Such a key can be either stored in the certificate cache of the		signature to a particular key known by the receiver. Such a key
	receiver, or be received in the CGA option in the same message.		can be either stored in the certificate cache of the receiver, or
			be received in the CGA option in the same message.
	Digital Signature		Digital Signature
	A variable length field containing a PKCS#1 signature, constructed		A variable length field containing a PKCS#1 signature, constructed
	using the sender's private key, over the the following sequence of		using the sender's private key, over the the following sequence of
	octets:		octets:
	1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F		1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F
	CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been		CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
	generated randomly by the editor of this specification.).		generated randomly by the editor of this specification.).
	skipping to change at page 19, line 28		skipping to change at page 19, line 12
	the following configuration information:		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		A flag that indicates whether CGA is used or not. This flag may be
	be per interface or per node. (Note that in future extensions of		per interface or per node. (Note that in future extensions of the
	the SEND protocol, this flag may be per subnet-prefix.)		SEND protocol, this flag may be per subnet-prefix.)
	5.2.4 Performance Considerations		5.2.4 Performance Considerations
	The construction and verification of this option is computationally		The construction and verification of this option is computationally
	expensive. In the NDP context, however, the hosts typically have the		expensive. In the NDP context, however, the hosts typically have the
	need to perform only a few signature operations as they enter a link,		need to perform only a few signature operations as they enter a link,
	and a few operations as they find a new on-link peer with which to		and a few operations as they find a new on-link peer with which to
	communicate.		communicate.
	Routers are required to perform a larger number of operations,		Routers are required to perform a larger number of operations,
	particularly when the frequency of router advertisements is high due		particularly when the frequency of router advertisements is high due
	to mobility requirements. Still, the number of required signature		to mobility requirements. Still, the number of required signature
	operations is on the order of a few dozen per second, some of which		operations is on the order of a few dozen per second, some of which
	can be precomputed as explained below. A large number of router		can be precomputed as explained below. A large number of router
	solicitations may cause higher demand for performing asymmetric		solicitations may cause higher demand for performing asymmetric
	operations, although RFC 2461 limits the rate at which responses to		operations, although RFC 2461 limits the rate at which responses to
	solicitations can be sent.		solicitations can be sent.
	Signatures can be precomputed for unsolicited (multicast) Neighbor		Signatures can be precomputed for unsolicited (multicast) Neighbor
	and Router Advertisements if the timing of such future advertisements		and Router Advertisements if the timing of such future advertisements
	is known. Typically, solicited advertisements are sent to the		is known. Typically, solicited advertisements are sent to the unicast
	unicast address from which the solicitation was sent. Given that the		address from which the solicitation was sent. Given that the IPv6
	IPv6 header is covered by the signature, it is not possible to		header is covered by the signature, it is not possible to precompute
	precompute solicited advertisements.		solicited advertisements.
	5.3 Timestamp and Nonce options		5.3 Timestamp and Nonce options
	5.3.1 Timestamp Option		5.3.1 Timestamp Option
	The purpose of the Timestamp option is to assure that unsolicited		The purpose of the Timestamp option is to assure that unsolicited
	advertisements and redirects have not been replayed. The format of		advertisements and redirects have not been replayed. The format of
	this option is described in the following:		this option is described in the following:
	0 1 2 3		0 1 2 3
	skipping to change at page 21, line 34		skipping to change at page 21, line 28
	Length		Length
	The length of the option (including the Type, Length, and Nonce		The length of the option (including the Type, Length, and Nonce
	fields) in units of 8 octets.		fields) 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. The length of the random number MUST be selected		least 6 bytes. The length of the random number MUST be selected so
	so that the length of the nonce option is a multiple of 8 octets.		that the length of the nonce option is a multiple of 8 octets.
	5.3.3 Processing rules for senders		5.3.3 Processing rules for senders
	All solicitation messages MUST include a Nonce. When sending a		All solicitation messages MUST include a Nonce. When sending a
	solicitation, the sender MUST store the nonce internally so that it		solicitation, the sender MUST store the nonce internally so that it
	can recognize any replies containing that particular nonce.		can recognize any replies containing that particular nonce.
	All solicited advertisements MUST include a Nonce, copied from the		All solicited advertisements MUST include a Nonce, copied from the
	received solicitation. Note that routers may decide to send a		received solicitation. Note that routers may decide to send a
	multicast advertisement to all nodes instead of a response to a		multicast advertisement to all nodes instead of a response to a
	skipping to change at page 25, line 49		skipping to change at page 25, line 49
	single trust anchor.		single trust anchor.
	6.1.1 Router Authorization Certificate Profile		6.1.1 Router Authorization Certificate Profile
	Router Authorization Certificates are X.509v3 certificates, as		Router Authorization Certificates are X.509v3 certificates, as
	defined in RFC 3280 [10], and MUST contain at least one instance of		defined in RFC 3280 [10], and MUST contain at least one instance of
	the X.509 extension for IP addresses, as defined in [12]. The parent		the X.509 extension for IP addresses, as defined in [12]. The parent
	certificates in the certificate chain MUST contain one or more X.509		certificates in the certificate chain MUST contain one or more X.509
	IP address extensions, back up to a trusted party (such as the user's		IP address extensions, back up to a trusted party (such as the user's
	ISP) that configured the original IP address space block for the		ISP) that configured the original IP address space block for the
	router in question, or delegated the right to do so. The		router in question, or delegated the right to do so. The certificates
	certificates for the intermediate delegating authorities MUST contain		for the intermediate delegating authorities MUST contain X.509 IP
	X.509 IP address extension(s) for subdelegations. The router's		address extension(s) for subdelegations. The router's certificate is
	certificate is signed by the delegating authority for the prefixes		signed by the delegating authority for the prefixes the router is
	the router is authorized to to advertise.		authorized to to advertise.
	The X.509 IP address extension MUST contain at least one		The X.509 IP address extension MUST contain at least one
	addressesOrRanges element. This element MUST contain an		addressesOrRanges element. This element MUST contain an addressPrefix
	addressPrefix element containing an IPv6 address prefix for a prefix		element containing an IPv6 address prefix for a prefix the router or
	the router or the intermediate entity is authorized to route. If the		the intermediate entity is authorized to route. If the entity is
	entity is allowed to route any prefix, the used IPv6 address prefix		allowed to route any prefix, the used IPv6 address prefix is the null
	is the null prefix, ::/0. The addressFamily element of the		prefix, ::/0. The addressFamily element of the containing
	containing IPAddrBlocks sequence element MUST contain the IPv6		IPAddrBlocks sequence element MUST contain the IPv6 Address Family
	Address Family Identifier (0002), as specified in [12] for IPv6		Identifier (0002), as specified in [12] for IPv6 prefixes. Instead
	prefixes. Instead of an addressPrefix element, the addressesOrRange		of an addressPrefix element, the addressesOrRange element MAY contain
	element MAY contain an addressRange element for a range of prefixes,		an addressRange element for a range of prefixes, if more than one
	if more than one prefix is authorized. The X.509 IP address		prefix is authorized. The X.509 IP address extension MAY contain
	extension MAY contain additional IPv6 prefixes, expressed either as		additional IPv6 prefixes, expressed either as an addressPrefix or an
	an addressPrefix or an addressRange.		addressRange.
	A SEND node receiving a Router Authorization Certificate MUST first		A SEND node receiving a Router Authorization Certificate MUST first
	check whether the certificate's signature was generated by the		check whether the certificate's signature was generated by the
	delegating authority. Then the client MUST check whether all the		delegating authority. Then the client MUST check whether all the
	addressPrefix or addressRange entries in the router's certificate are		addressPrefix or addressRange entries in the router's certificate are
	contained within the address ranges in the delegating authority's		contained within the address ranges in the delegating authority's
	certificate, and whether the addressPrefix entries match any		certificate, and whether the addressPrefix entries match any
	addressPrefix entries in the delegating authority's certificate. If		addressPrefix entries in the delegating authority's certificate. If
	an addressPrefix or addressRange is not contained within the		an addressPrefix or addressRange is not contained within the
	delegating authority's prefixes or ranges, the client MAY attempt to		delegating authority's prefixes or ranges, the client MAY attempt to
	skipping to change at page 28, line 8		skipping to change at page 28, line 8
	... other certificate parameters ...		... other certificate parameters ...
	When processing the three certificates, the usual RFC 3280 [10]		When processing the three certificates, the usual RFC 3280 [10]
	certificate path validation is performed. Note, however, that at the		certificate path validation is performed. Note, however, that at the
	time a node is checking certificates received in a DCA from a router,		time a node is checking certificates received in a DCA from a router,
	it typically does not have a connection to the Internet yet, and so		it typically does not have a connection to the Internet yet, and so
	it is not possible to perform an on-line Certificate Revocation List		it is not possible to perform an on-line Certificate Revocation List
	(CRL) check if such a check is necessary. Until such a check is		(CRL) check if such a check is necessary. Until such a check is
	performed, acceptance of the certificate MUST be considered		performed, acceptance of the certificate MUST be considered
	provisional, and the node MUST perform a check as soon as it has		provisional, and the node MUST perform a check as soon as it has
	established a connection with the Internet through the router. If		established a connection with the Internet through the router. If the
	the router has been compromised, it could interfere with the CRL		router has been compromised, it could interfere with the CRL check.
	check. Should performance of the CRL check be disrupted or should		Should performance of the CRL check be disrupted or should the check
	the check fail, the node SHOULD immediately stop using the router as		fail, the node SHOULD immediately stop using the router as a default
	a default and use another router on the link instead.		and use another router on the link instead.
	In addition, the IP addresses in the delegation extension must be a		In addition, the IP addresses in the delegation extension must be a
	subset of the IP addresses in the delegation extension of the		subset of the IP addresses in the delegation extension of the
	issuer's certificate. So in this example, R1, ..., Rs must be a		issuer's certificate. So in this example, R1, ..., Rs must be a
	subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If		subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If
	the certificate chain is valid, then router_foo.isp_foo_example.com		the certificate chain is valid, then router_foo.isp_foo_example.com
	is authorized to route the prefixes R1,...,Rs.		is authorized to route the prefixes R1,...,Rs.
	6.2 Certificate Transport		6.2 Certificate Transport
	skipping to change at page 36, line 45		skipping to change at page 36, line 45
	options that are not specified to be used with Delegation Chain		options that are not specified to be used with Delegation Chain
	Advertisement messages MUST be ignored and the packet processed in		Advertisement messages MUST be ignored and the packet processed in
	the normal manner. The only defined options that may appear are the		the normal manner. The only defined options that may appear are the
	Certificate and Trust Anchor options. An advertisement that passes		Certificate and Trust Anchor options. An advertisement that passes
	the validity checks is called a "valid advertisement".		the validity checks is called a "valid advertisement".
	Hosts SHOULD store certificate chains retrieved in Delegation Chain		Hosts SHOULD store certificate chains retrieved in Delegation Chain
	Discovery messages if they start from an anchor trusted by the host.		Discovery messages if they start from an anchor trusted by the host.
	The certificate chains MUST be verified, as defined in Section 6.1,		The certificate chains MUST be verified, as defined in Section 6.1,
	before storing them. Routers MUST send the certificates one by one,		before storing them. Routers MUST send the certificates one by one,
	starting from the trust anchor end of the chain. Except for		starting from the trust anchor end of the chain. Except for temporary
	temporary purposes to allow for message loss and reordering, hosts		purposes to allow for message loss and reordering, hosts SHOULD NOT
	SHOULD NOT store certificates received in a Delegation Chain		store certificates received in a Delegation Chain Advertisement
	Advertisement unless they contain a certificate which can be		unless they contain a certificate which can be immediately verified
	immediately verified either to the trust anchor or to a certificate		either to the trust anchor or to a certificate that has been verified
	that has been verified earlier.		earlier.
	Note that caching this information and the implied verification		Note that caching this information and the implied verification
	results between network attachments for use over multiple attachments		results between network attachments for use over multiple attachments
	to the network can help improve performance. But periodic		to the network can help improve performance. But periodic certificate
	certificate revocation checks are still needed even with cached		revocation checks are still needed even with cached results, to make
	results, to make sure that the certificates are still valid.		sure that the certificates are still valid.
	The host has a need to retrieve a delegation chain when a Router		The host has a need to retrieve a delegation chain when a Router
	Advertisement has been received with a public key that is not stored		Advertisement has been received with a public key that is not stored
	in the hosts' cache of certificates, or there is no authorization		in the hosts' cache of certificates, or there is no authorization
	delegation chain to the host's trust anchor. In these situations,		delegation chain to the host's trust anchor. In these situations, the
	the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain		host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
	Solicitation messages, each separated by at least DCS_INTERVAL		Solicitation messages, each separated by at least DCS_INTERVAL
	seconds.		seconds.
	Delegation Chain Solicitations SHOULD NOT be sent if the host has a		Delegation Chain Solicitations SHOULD NOT be sent if the host has a
	currently valid certificate chain from a reachable router to a trust		currently valid certificate chain from a reachable router to a trust
	anchor.		anchor.
	When soliciting certificates for a router, a host MUST send		When soliciting certificates for a router, a host MUST send
	Delegation Chain Solicitations either to the All-Routers multicast		Delegation Chain Solicitations either to the All-Routers multicast
	address, if it has not selected a default router yet, or to the		address, if it has not selected a default router yet, or to the
	skipping to change at page 38, line 9		skipping to change at page 38, line 9
	solicitation, the host MAY prefer to process first those		solicitation, the host MAY prefer to process first those
	advertisements with the same Identifier field value as in the		advertisements with the same Identifier field value as in the
	solicitation. This makes Denial-of-Service attacks against the		solicitation. This makes Denial-of-Service attacks against the
	mechanism harder (see Section 9.3).		mechanism harder (see Section 9.3).
	7. Addressing		7. Addressing
	7.1 CGAs		7.1 CGAs
	Nodes that use stateless address autoconfiguration SHOULD generate a		Nodes that use stateless address autoconfiguration SHOULD generate a
	new CGA as specified in Section 4 of [13] each time they run the		new CGA and a CGA Parameters data structure as specified in Section 4
	autoconfiguration procedure. The nodes MAY continue to use the same		of [13] each time they run the autoconfiguration procedure.
	public key and modifier, and start the process from Step 4 of the
	generation algorithm.
	By default, a SEND-enabled node SHOULD use only CGAs for its own		By default, a SEND-enabled node SHOULD use only CGAs for its own
	addresses. Other types of addresses MAY be used in testing,		addresses. Other types of addresses MAY be used in testing,
	diagnostics or for other purposes. However, this document does not		diagnostics or for other purposes. However, this document does not
	describe how to choose between different types of addresses for		describe how to choose between different types of addresses for
	different communications. A dynamic selection can be provided by an		different communications. A dynamic selection can be provided by an
	API, such as the one defined in [23].		API, such as the one defined in [23].
	7.2 Redirect Addresses		7.2 Redirect Addresses
	skipping to change at page 39, line 20		skipping to change at page 39, line 18
	should configure routers with certificates containing either the		should configure routers with certificates containing either the
	null prefix or no prefix extension at all.		null prefix or no prefix extension at all.
	Upon processing a Prefix Information option within a Router		Upon processing a Prefix Information option within a Router
	Advertisement, nodes SHOULD verify that the prefix specified in this		Advertisement, nodes SHOULD verify that the prefix specified in this
	option falls within the range defined by the certificate, if the		option falls within the range defined by the certificate, if the
	certificate contains a prefix extension. Options failing this check		certificate contains a prefix extension. Options failing this check
	are treated as containing uncertified prefixes.		are treated as containing uncertified prefixes.
	Nodes SHOULD use one of the certified prefixes for stateless		Nodes SHOULD use one of the certified prefixes for stateless
	autoconfiguration. If none of the advertised prefixes match, the		autoconfiguration. If none of the advertised prefixes match, the host
	host SHOULD use a different advertising router as its default router,		SHOULD use a different advertising router as its default router, if
	if available. If the node is performing stateful autoconfiguration,		available. If the node is performing stateful autoconfiguration, it
	it SHOULD check the address provided by the DHCP server against the		SHOULD check the address provided by the DHCP server against the
	certified prefixes and SHOULD NOT use the address if the prefix is		certified prefixes and SHOULD NOT use the address if the prefix is
	not certified.		not certified.
	7.4 Limitations		7.4 Limitations
	This specification does not address the protection of NDP packets for		This specification does not address the protection of NDP packets for
	nodes that are configured with a static address (e.g., PREFIX::1).		nodes that are configured with a static address (e.g., PREFIX::1).
	Future certificate chain-based authorization specifications are		Future certificate chain-based authorization specifications are
	needed for such nodes.		needed for such nodes.
	skipping to change at page 40, line 3		skipping to change at page 39, line 49
	particular interface identifier. This specification does not specify		particular interface identifier. This specification does not specify
	the format of such certificates, since there are currently a few		the format of such certificates, since there are currently a few
	cases where such certificates are required by the link layer and it		cases where such certificates are required by the link layer and it
	is up to the link layer to provide certification for the interface		is up to the link layer to provide certification for the interface
	identifier. This may be the subject of a future specification. It		identifier. This may be the subject of a future specification. It
	is also outside the scope of this specification to describe how		is also outside the scope of this specification to describe how
	stateful address autoconfiguration works with the CGA method.		stateful address autoconfiguration works with the CGA method.
	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
	this specification.		specification.
	8. Transition Issues		8. Transition Issues
	During the transition to secure links or as a policy consideration,		During the transition to secure links or as a policy consideration,
	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"
	skipping to change at page 42, line 14		skipping to change at page 41, line 14
	Detection for the first tentative address. This configuration		Detection for the first tentative address. This configuration
	option SHOULD be disabled by default. This is a recovery		option SHOULD be disabled by default. This is a recovery
	mechanism, in case attacks against the first address become		mechanism, in case attacks against the first address become
	common.		common.
	o The Neighbor Cache, Prefix List and Default Router list entries		o The Neighbor Cache, Prefix List and Default Router list entries
	MUST have a secured/insecure flag that indicates whether the		MUST have a secured/insecure flag that indicates whether the
	message that caused the creation or last update of the entry was		message that caused the creation or last update of the entry was
	secured or insecure. Received insecure messages MUST NOT cause		secured or insecure. Received insecure messages MUST NOT cause
	changes to existing secured entries in the Neighbor Cache, Prefix		changes to existing secured entries in the Neighbor Cache, Prefix
	List or Default Router List. The Neighbor Cache SHOULD implement		List or Default Router List. The Neighbor Cache SHOULD implement a
	a flag on entries indicating whether the entry issecured.		flag on entries indicating whether the entry issecured. Received
	Received secured messages MUST cause an update of the matching		secured messages MUST cause an update of the matching entries and
	entries and flagging of them as secured.		flagging of them as secured.
	o The conceptual sending algorithm is modified so that an insecure		o The conceptual sending algorithm is modified so that an insecure
	router is selected only if there is no reachable SEND router for		router is selected only if there is no reachable SEND router for
	the prefix. That is, the algorithm for selecting a default router		the prefix. That is, the algorithm for selecting a default router
	favors reachable SEND routers over reachable non-SEND ones.		favors reachable SEND routers over reachable non-SEND ones.
	o A node MAY adopt an insecure router, including a SEND router for		o A node MAY adopt an insecure router, including a SEND router for
	which full security checks have not yet been completed, while		which full security checks have not yet been completed, while
	security checking for the SEND router is underway. Security		security checking for the SEND router is underway. Security checks
	checks in this case include delegation chain solicitation,		in this case include delegation chain solicitation, certificate
	certificate verification, CRL checks, and RA signature checks. A		verification, CRL checks, and RA signature checks. A node MAY also
	node MAY also adopt an insecure router if a SEND router becomes		adopt an insecure router if a SEND router becomes unreachable, but
	unreachable, but SHOULD attempt to find a SEND router as soon as		SHOULD attempt to find a SEND router as soon as possible, since
	possible, since the unreachability may be the result of an attack.		the unreachability may be the result of an attack. Note that while
	Note that while this can speed up attachment to a new network,		this can speed up attachment to a new network, accepting an
	accepting an insecure router opens the node to possible attacks,		insecure router opens the node to possible attacks, and nodes that
	and nodes that choose to accept insecure routers do so at their		choose to accept insecure routers do so at their own risk. The
	own risk. The node SHOULD in any case prefer the SEND router as		node SHOULD in any case prefer the SEND router as soon as one is
	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		o A SEND node SHOULD have a configuration option that causes it to
	ignore all insecure Neighbor Solicitation and Advertisement,		ignore all insecure Neighbor Solicitation and Advertisement,
	Router Solicitation and Advertisement, and Redirect messages.		Router Solicitation and Advertisement, and Redirect messages. This
	This can be used to enforce SEND-only networks.		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.
	skipping to change at page 43, line 27		skipping to change at page 42, line 27
	attacker could disrupt IP service by sending out a Neighbor		attacker could disrupt IP service by sending out a Neighbor
	Advertisement having the source address on the link layer frame of a		Advertisement having the source address on the link layer frame of a
	victim, a valid CGA address and a valid signature corresponding to		victim, a valid CGA address and a valid signature corresponding to
	itself, and a Target Link-layer Address extension corresponding to		itself, and a Target Link-layer Address extension corresponding to
	the victim. The attacker could then proceed to cause a traffic		the victim. The attacker could then proceed to cause a traffic
	stream to bombard the victim in a DoS attack. This attack cannot be		stream to bombard the victim in a DoS attack. This attack cannot be
	prevented just by securing the link layer.		prevented just by securing the link layer.
	Even on a secure link layer, SEND does not require that the addresses		Even on a secure link layer, SEND does not require that the addresses
	on the link layer and Neighbor Advertisements correspond to each		on the link layer and Neighbor Advertisements correspond to each
	other. However, it is RECOMMENDED that such checks be performed		other. However, it is RECOMMENDED that such checks be performed where
	where this is possible on the given link layer technology.		this is possible on the given link layer technology.
	Prior to participating in Neighbor Discovery and Duplicate Address		Prior to participating in Neighbor Discovery and Duplicate Address
	Detection, nodes must subscribe to the link-scoped All-Nodes		Detection, nodes must subscribe to the link-scoped All-Nodes
	Multicast Group and the Solicited-Node Multicast Group for the		Multicast Group and the Solicited-Node Multicast Group for the
	address that they are claiming for their addresses; RFC 2461 [7].		address that they are claiming for their addresses; RFC 2461 [7].
	Subscribing to a multicast group requires that the nodes use MLD		Subscribing to a multicast group requires that the nodes use MLD
	[17]. MLD contains no provision for security. An attacker could		[17]. MLD contains no provision for security. An attacker could
	send an MLD Done message to unsubscribe a victim from the		send an MLD Done message to unsubscribe a victim from the
	Solicited-Node Multicast address. However, the victim should be able		Solicited-Node Multicast address. However, the victim should be able
	to detect such an attack because the router sends a		to detect such an attack because the router sends a
	skipping to change at page 44, line 14		skipping to change at page 43, line 14
	9.2.1 Neighbor Solicitation/Advertisement Spoofing		9.2.1 Neighbor Solicitation/Advertisement Spoofing
	This threat is defined in Section 4.1.1 of [24]. The threat is that		This threat is defined in Section 4.1.1 of [24]. The threat is that
	a spoofed message may cause a false entry in a node's Neighbor Cache.		a spoofed message may cause a false entry in a node's Neighbor Cache.
	There are two cases:		There are two cases:
	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		the IPv6 address into its Neighbor Cache. Also, a node performing
	performing Duplicate Address Detection (DAD) that receives a		Duplicate Address Detection (DAD) that receives a Neighbor
	Neighbor Solicitation for the same address regards the situation		Solicitation for the same address regards the situation as a
	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
	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.
	skipping to change at page 46, line 28		skipping to change at page 45, line 28
	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 [13].		has been discussed in [13].
	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.2.2. In this		the verification process described in Section 5.2.2. In this process,
	process, a simple hash verification of the CGA property of the		a simple hash verification of the CGA property of the address is
	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 Signature option, and start selectively discarding
	packets if too many resources are spent. Implementations MAY also		packets if too many resources are spent. Implementations MAY also
	first discard packets that are not protected with CGA.		first discard packets that are not protected with CGA.
	skipping to change at page 55, line 7		skipping to change at page 54, line 7
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: Pekka.Nikander@nomadiclab.com		EMail: Pekka.Nikander@nomadiclab.com
	Appendix A. Contributors		Appendix A. Contributors
	Tuomas Aura contributed the transition mechanism specification in		Tuomas Aura contributed the transition mechanism specification in
	Section 8. Jonathan Trostle contributed the certificate chain		Section 8. Jonathan Trostle contributed the certificate chain example
	example in Section 6.1.1.		in Section 6.1.1.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel		The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel
	Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier,		Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier,
	Francis Dupont, and Pekka Savola for interesting discussions in this		Francis Dupont, and Pekka Savola for interesting discussions in this
	problem space and feedback regarding the SEND protocol.		problem space and feedback regarding the SEND protocol.
	Appendix C. Cache Management		Appendix C. Cache Management
	skipping to change at page 59, line 11		skipping to change at page 58, line 11
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/