base.txt		issue94.txt
	skipping to change at page 2, line 3		skipping to change at page 2, line 3
	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
	reachability information about the paths to active neighbors. If not		reachability information about the paths to active neighbors. If not
	secured, NDP is vulnerable to various attacks. This document		secured, NDP is vulnerable to various attacks. This document
	specifies security mechanisms for NDP. Unlike to the original NDP		specifies security mechanisms for NDP. Unlike the original NDP
	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 . . . . . . . . . . . . 5		1.1 Specification of Requirements . . . . . . . . . . . . 5
	2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Neighbor and Router Discovery Overview . . . . . . . . . . . 8		3. Neighbor and Router Discovery Overview . . . . . . . . . . . 8
	4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 10		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 10
	5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 12		5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 12
	skipping to change at page 2, line 38		skipping to change at page 2, line 38
	6. Authorization Delegation Discovery . . . . . . . . . . . . . 26		6. Authorization Delegation Discovery . . . . . . . . . . . . . 26
	6.1 Certificate Format . . . . . . . . . . . . . . . . . . 26		6.1 Certificate Format . . . . . . . . . . . . . . . . . . 26
	6.1.1 Router Authorization Certificate Profile . . . . 26		6.1.1 Router Authorization Certificate Profile . . . . 26
	6.2 Certificate Transport . . . . . . . . . . . . . . . . 29		6.2 Certificate Transport . . . . . . . . . . . . . . . . 29
	6.2.1 Certification Path Solicitation Message Format . 29		6.2.1 Certification Path Solicitation Message Format . 29
	6.2.2 Certification Path Advertisement Message Format 31		6.2.2 Certification Path Advertisement Message Format 31
	6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 34		6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 34
	6.2.4 Certificate Option . . . . . . . . . . . . . . . 35		6.2.4 Certificate Option . . . . . . . . . . . . . . . 35
	6.2.5 Processing Rules for Routers . . . . . . . . . . 36		6.2.5 Processing Rules for Routers . . . . . . . . . . 36
	6.2.6 Processing Rules for Hosts . . . . . . . . . . . 37		6.2.6 Processing Rules for Hosts . . . . . . . . . . . 37
	6.3 Configuration . . . . . . . . . . . . . . . . . . . . 38		6.3 Configuration . . . . . . . . . . . . . . . . . . . . 39
	6.4 Deployment Model . . . . . . . . . . . . . . . . . . . 39		6.4 Deployment Model . . . . . . . . . . . . . . . . . . . 39
	7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 41		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 41
	7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 41		7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 41
	7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 41		7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 41
	7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 41		7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 41
	7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 42		7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 42
	8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 44		8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 44
	9. Security Considerations . . . . . . . . . . . . . . . . . . 46		9. Security Considerations . . . . . . . . . . . . . . . . . . 46
	9.1 Threats to the Local Link Not Covered by SEND . . . . 46		9.1 Threats to the Local Link Not Covered by SEND . . . . 46
	9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 46		9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 46
	9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 47		9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 47
	9.2.2 Neighbor Unreachability Detection Failure . . . 47		9.2.2 Neighbor Unreachability Detection Failure . . . 47
	9.2.3 Duplicate Address Detection DoS Attack . . . . . 47		9.2.3 Duplicate Address Detection DoS Attack . . . . . 47
	9.2.4 Router Solicitation and Advertisement Attacks . 48		9.2.4 Router Solicitation and Advertisement Attacks . 48
	9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 48		9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 48
	9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 49		9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 49
	9.3 Attacks against SEND Itself . . . . . . . . . . . . . 49		9.3 Attacks against SEND Itself . . . . . . . . . . . . . 49
	10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 51		10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 51
	11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 52		10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 51
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53		10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 51
	Normative References . . . . . . . . . . . . . . . . . . . . 54		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 52
	Informative References . . . . . . . . . . . . . . . . . . . 56		Normative References . . . . . . . . . . . . . . . . . . . . 53
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56		Informative References . . . . . . . . . . . . . . . . . . . 55
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 58		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 59		A. Contributors and Acknowledgments . . . . . . . . . . . . . . 57
	C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 60		B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 58
	D. Message Size When Carrying Certificates . . . . . . . . . . 61		C. Message Size When Carrying Certificates . . . . . . . . . . 59
	Intellectual Property and Copyright Statements . . . . . . . 62		Intellectual Property and Copyright Statements . . . . . . . 60
	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
	Unreachability Detection (NUD), Duplicate Address Detection (DAD),		Unreachability Detection (NUD), Duplicate Address Detection (DAD),
	and Redirection.		and Redirection.
	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, 17]. 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.
	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 [13].		related specification [14].
	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 certification paths to		describes the mechanism for distributing certification paths 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).
	Out of scope for this document is the use of identity certificates		Out of scope for this document is the use of identity certificates
	skipping to change at page 6, line 11		skipping to change at page 6, line 11
	words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and		words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
	"MAY" in this document are to be interpreted as described in [2].		"MAY" in this document are to be interpreted as described in [2].
	2. Terms		2. Terms
	Authorization Delegation Discovery (ADD)		Authorization Delegation Discovery (ADD)
	A process through which SEND nodes can acquire a certification		A process through which SEND nodes can acquire a certification
	path from a peer node to a trust anchor.		path from a peer node to a trust anchor.
			Certificate Revocation List (CRL)
			In one method of certificate revocation, an authority periodically
			issues a signed data structure called the Certificate Revocation
			List. This list is a time stamped list identifying revoked
			certificates, signed by the issuer, and made freely available in a
			public repository.
			Certification Path Advertisement (CPA)
			The advertisement message used in the ADD process.
			Certification Path Solicitation (CPS)
			The solicitation message used in the ADD process.
	Cryptographically Generated Address (CGA)		Cryptographically Generated Address (CGA)
	A technique [13] whereby an IPv6 address of a node is		A technique [14] whereby an IPv6 address of a node is
	cryptographically generated using a one-way hash function from the		cryptographically generated using a one-way hash function from the
	node's public key and some other parameters.		node's public key and some other parameters.
			Distinguished Encoding Rules (DER)
			An encoding scheme for data values, defined in [15].
	Duplicate Address Detection (DAD)		Duplicate Address Detection (DAD)
	A mechanism which assures that two IPv6 nodes on the same link are		A mechanism which assures that two IPv6 nodes on the same link are
	not using the same address.		not using the same address.
	Neighbor Discovery Protocol (NDP)		Fully Qualified Domain Name (FQDN)
	The IPv6 Neighbor Discovery Protocol [7, 8].		A fully qualified domain name consists of a host and domain name,
			including top-level domain.
	Neighbor Discovery Protocol is a part of ICMPv6 [9].		Internationalized Domain Name (IDN)
			Internationalized Domain Names can be used to represent domain
			names that contain characters outside the ASCII repertoire. See
			RFC 3490 [12].
	Neighbor Discovery (ND)		Neighbor Discovery (ND)
	The Neighbor Discovery function of the Neighbor Discovery Protocol		The Neighbor Discovery function of the Neighbor Discovery Protocol
	(NDP). NDP contains also other functions besides ND.		(NDP). NDP contains other functions besides ND.
			Neighbor Discovery Protocol (NDP)
			The IPv6 Neighbor Discovery Protocol [7, 8].
			Neighbor Discovery Protocol is a part of ICMPv6 [9].
	Neighbor Unreachability Detection (NUD)		Neighbor Unreachability Detection (NUD)
	A mechanism used for tracking the reachability of neighbors.		A mechanism used for tracking the reachability of neighbors.
			Non-SEND node
			An IPv6 node that does not implement this specification but uses
			only RFC 2461 and RFC 2462 without security.
	Nonce		Nonce
	An unpredictable random or pseudorandom number generated by a node		An unpredictable random or pseudorandom number generated by a node
	and used exactly once. In SEND, nonces are used to assure that a		and used exactly once. In SEND, nonces are used to assure that a
	particular advertisement is linked to the solicitation that		particular advertisement is linked to the solicitation that
	triggered it.		triggered it.
	Router Authorization Certificate		Router Authorization Certificate
	An X.509v3 [10] public key certificate using the profile specified		An X.509v3 [10] public key certificate using the profile specified
	in Section 6.1.1.		in Section 6.1.1.
	SEND node		SEND node
	An IPv6 node that implements this specification.		An IPv6 node that implements this specification.
	Non-SEND node
	An IPv6 node that does not implement this specification but uses
	only RFC 2461 and RFC 2462 without security.
	Router Discovery (RD)		Router Discovery (RD)
	Router Discovery allows the hosts to discover what routers exist		Router Discovery allows the hosts to discover what routers exist
	on the link, and what prefixes are available. Router Discovery is		on the link, and what prefixes are available. Router Discovery is
	a part of the Neighbor Discovery Protocol.		a part of the Neighbor Discovery Protocol.
	3. Neighbor and Router Discovery Overview		3. Neighbor and Router Discovery Overview
	The Neighbor Discovery Protocol has several functions. Many of these		The Neighbor Discovery Protocol has several functions. Many of these
	functions are overloaded on a few central message types, such as the		functions are overloaded on a few central message types, such as the
	skipping to change at page 10, line 35		skipping to change at page 10, line 35
	process.		process.
	o Cryptographically Generated Addresses are used to assure that the		o Cryptographically Generated Addresses are used to assure that the
	sender of a Neighbor Discovery message is the "owner" of the		sender of a Neighbor Discovery message is the "owner" of the
	claimed address. A public-private key pair is generated by all		claimed address. A public-private key pair is generated by all
	nodes before they can claim an address. A new NDP option, the CGA		nodes before they can claim an address. A new NDP option, the CGA
	option, is used to carry the public key and associated parameters.		option, is used to carry the public key and associated parameters.
	This specification also allows a node to use non-CGAs with		This specification also allows a node to use non-CGAs with
	certificates to authorize their use. However, the details of such		certificates to authorize their use. However, the details of such
	use are beyond the scope of this specification.		use are beyond the scope of this specification and are left for
			future work.
	o A new NDP option, the RSA Signature option, is used to protect all		o A new NDP option, the RSA Signature option, is used to protect all
	messages relating to Neighbor and Router discovery.		messages relating to Neighbor and Router discovery.
	Public key signatures protect the integrity of the messages and		Public key signatures protect the integrity of the messages and
	authenticate the identity of their sender. The authority of a		authenticate the identity of their sender. The authority of a
	public key is established either with the authorization delegation		public key is established either with the authorization delegation
	process, using certificates, or through the address ownership		process, using certificates, or through the address ownership
	proof mechanism, using CGAs, or both, depending on configuration		proof mechanism, using CGAs, or both, depending on configuration
	and the type of the message protected.		and the type of the message protected.
	skipping to change at page 12, line 6		skipping to change at page 12, line 6
	o In order to prevent replay attacks, two new Neighbor Discovery		o In order to prevent replay attacks, two new Neighbor Discovery
	options, Timestamp and Nonce, are introduced. Given that Neighbor		options, Timestamp and Nonce, are introduced. Given that Neighbor
	and Router Discovery messages are in some cases sent to multicast		and Router Discovery messages are in some cases sent to multicast
	addresses, the Timestamp option offers replay protection without		addresses, the Timestamp option offers replay protection without
	any previously established state or sequence numbers. When the		any previously established state or sequence numbers. When the
	messages are used in solicitation - advertisement pairs, they are		messages are used in solicitation - advertisement pairs, they are
	protected using the Nonce option.		protected using the Nonce option.
	5. Neighbor Discovery Protocol Options		5. Neighbor Discovery Protocol Options
	The options described in this section MUST be supported by all SEND		The options described in this section MUST be supported.
	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 | Pad Length | Reserved |		| Type | Length | Pad Length | Reserved |
	skipping to change at page 13, line 8		skipping to change at page 13, line 7
	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.
	CGA Parameters		CGA Parameters
	A variable length field containing the CGA Parameters data		A variable length field containing the CGA Parameters data
	structure described in Section 4 of [13].		structure described in Section 4 of [14].
	This specification requires that if both the CGA option and the		This specification requires that if both the CGA option and the
	RSA Signature option are present, then the public key found from		RSA Signature option are present, then the public key found from
	the CGA Parameters field in the CGA option MUST be the public key		the CGA Parameters field in the CGA option MUST be the public key
	referred by the Key Hash field in the RSA Signature option.		referred by the Key Hash field in the RSA Signature option.
	Packets received with two different keys MUST be silently		Packets received with two different keys MUST be silently
	discarded. Note that a future extension may provide a mechanism		discarded. Note that a future extension may provide a mechanism
	which allows the owner of an address and the signer to be		which allows the owner of an address and the signer to be
	different parties.		different parties.
	skipping to change at page 13, line 36		skipping to change at page 13, line 35
	If the node has been configured to use SEND, the CGA option MUST be		If the node has been configured to use SEND, the CGA option MUST be
	present in all Neighbor Solicitation and Advertisement messages, and		present in all Neighbor Solicitation and Advertisement messages, and
	MUST be present in Router Solicitation messages unless they are sent		MUST be present in Router Solicitation messages unless they are sent
	with the unspecified source address. The CGA option MAY be present in		with the unspecified source address. The CGA option MAY be present in
	other messages.		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 CGA Parameter field in the CGA option is filled in according to		The CGA Parameter field in the CGA option is filled in according to
	the rules presented above and in [13]. The public key in the field is		the rules presented above and in [14]. The public key in the field is
	taken from the node's configuration used to generate the CGA;		taken from the node's configuration used to generate the CGA;
	typically from a data structure associated with the source address.		typically from a data structure associated with the source address.
	The address MUST be constructed as specified in Section 4 of [13].		The address MUST be constructed as specified in Section 4 of [14].
	Depending on the type of the message, this address appears in		Depending on the type 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
	skipping to change at page 14, line 29		skipping to change at page 14, line 27
	5.1.2 Processing Rules for Receivers		5.1.2 Processing Rules for Receivers
	Neighbor Solicitation and Advertisement messages without the CGA		Neighbor Solicitation and Advertisement messages without the CGA
	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 also be
	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.
	Redirect, Neighbor Solicitation, Neighbor Advertisement, Router		Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
	Solicitation, and Router Advertisement messages containing a CGA		Solicitation, and Router Advertisement messages containing a CGA
	option MUST be checked as follows:		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 [14]. 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
	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
	skipping to change at page 15, line 27		skipping to change at page 15, line 24
	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 at		that use these security associations. The upper limit SHOULD be 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.
	All nodes that support the sending of the CGA option MUST record the		All nodes that support the sending of the CGA option MUST record the
	following configuration information:		following configuration information:
	CGA parameters		CGA parameters
	Any information required to construct CGAs, as described in [13].		Any information required to construct CGAs, as described in [14].
	5.2 RSA Signature Option		5.2 RSA Signature Option
	The RSA Signature option allows public-key based signatures to be		The RSA Signature option allows public-key based signatures to be
	attached to NDP messages. Configured trust anchors, CGAs, or both are		attached to NDP messages. Configured trust anchors, CGAs, or both are
	supported as the trusted root. The format of the RSA Signature		supported as the trusted root. The format of the RSA Signature
	option is described in the following diagram:		option is 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
	skipping to change at page 17, line 11		skipping to change at page 17, line 11
	signature to a particular key known by the receiver. Such a key		signature to a particular key known by the receiver. Such a key
	can be either stored in the certificate cache of the receiver, or		can be either stored in the certificate cache of the receiver, or
	be received in the CGA option in the same message.		be received in the CGA option in the same message.
	Digital Signature		Digital Signature
	A variable length field containing a PKCS#1 v1.5 signature,		A variable length field containing a PKCS#1 v1.5 signature,
	constructed using the sender's private key, over the the following		constructed using the sender's private key, over the the following
	sequence of octets:		sequence of octets:
	1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F		1. The 128-bit CGA Message Type tag [14] 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.).
	2. The 128-bit Source Address field from the IP header.		2. The 128-bit Source Address field from the IP header.
	3. The 128-bit Destination Address field from the IP header.		3. The 128-bit Destination Address field from the IP header.
	4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from		4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from
	the ICMP header.		the ICMP header.
	5. The NDP message header, starting from the octet after the ICMP		5. The NDP message header, starting from the octet after the ICMP
	Checksum field and continuing up to but not including NDP		Checksum field and continuing up to but not including NDP
	options.		options.
	6. All NDP options preceding the RSA Signature option.		6. All NDP options preceding the RSA Signature option.
	The signature value is computed with the RSASSA-PKCS1-v1_5		The signature value is computed with the RSASSA-PKCS1-v1_5
	algorithm and SHA-1 hash as defined in [15].		algorithm and SHA-1 hash as defined in [16].
	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 RSA		Digital Signature field is determined by the length of the RSA
	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).
	Padding		Padding
	This variable length field contains padding, as many bytes as		This variable length field contains padding, as many bytes as
	remains after end of the signature.		remains after end of the signature.
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	Signature option.		Signature option.
	o The RSA Signature option is added as the last option in the		o The RSA Signature option is added as the last option in the
	message.		message.
	o The data to be signed is constructed as explained in Section 5.2,		o The data to be signed is constructed as explained in Section 5.2,
	under the description of the Digital Signature field.		under the description of the Digital Signature field.
	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 v1.5 signature is		configured private key, and the resulting PKCS#1 v1.5 signature is
	put to the Digital Signature field.		put in the Digital Signature field.
	5.2.2 Processing Rules for Receivers		5.2.2 Processing Rules for Receivers
	Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,		Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
	and Redirect messages without the RSA Signature option MUST be		and Redirect messages without the RSA Signature option MUST be
	treated as insecure, i.e., processed in the same way as NDP messages		treated as insecure, i.e., processed in the same way as NDP messages
	sent by a non-SEND node. See Section 8.		sent by a non-SEND node. See Section 8.
	Router Solicitation messages without the RSA Signature option MUST be		Router Solicitation messages without the RSA Signature option MUST
	also treated as insecure, unless the source address of the message is		also be treated as insecure, unless the source address of the message
	the unspecified address.		is the unspecified address.
	Redirect, Neighbor Solicitation, Neighbor Advertisement, Router		Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
	Solicitation, and Router Advertisement messages containing an RSA		Solicitation, and Router Advertisement messages containing an RSA
	Signature option MUST be checked as follows:		Signature option MUST be checked as follows:
	o The receiver MUST ignore any options that come after the first RSA		o The receiver MUST ignore any options that come after the first RSA
	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,
	skipping to change at page 19, line 36		skipping to change at page 19, line 36
	trust anchor		trust anchor
	The authority of the sender is verified as described in Section		The authority of the sender is verified as described in Section
	6.1. The sender may claim additional authorization through the		6.1. The sender may claim additional authorization through the
	use of CGAs, but that is neither required nor verified.		use of CGAs, but that is neither required nor verified.
	CGA		CGA
	The CGA property of the sender's address is verified as		The CGA property of the sender's address is verified as
	described in [13]. The sender may claim additional authority		described in [14]. The sender may claim additional authority
	through a trust anchor, but that is neither required nor		through a trust anchor, but that is neither required nor
	verified.		verified.
	trust anchor and CGA		trust anchor and CGA
	Both the trust anchor and the CGA verification is required.		Both the trust anchor and the CGA verification is required.
	trust anchor or CGA		trust anchor or CGA
	Either the trust anchor or the CGA verification is required.		Either the trust anchor or the CGA verification is required.
	skipping to change at page 23, line 40		skipping to change at page 23, line 40
	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		very large number of nodes on the same link, or when a cache
	filling attack is in progress, it is possible that the cache		filling attack is in progress, it is possible that the cache
	holding the most recent timestamp per sender becomes full. In		holding the most recent timestamp per sender becomes full. In
	this case the node MUST remove some entries from the cache or		this case the node MUST remove some entries from the cache or
	refuse some new requested entries. The specific policy as to		refuse some new requested entries. The specific policy as to
	which entries are preferred over the others is left as an		which entries are preferred over the others is left as an
	implementation decision. However, typical policies may prefer		implementation decision. However, typical policies may prefer
	existing entries over new ones, CGAs with a large Sec value over		existing entries over new ones, CGAs with a large Sec value over
	smaller Sec values, and so on. The issue is briefly discussed in		smaller Sec values, and so on. The issue is briefly discussed in
	Appendix C.		Appendix B.
	o The receiver MUST be prepared to receive the Timestamp and Nonce		o The receiver MUST be prepared to receive the Timestamp and Nonce
	options in any order, as per RFC 2461 [7] Section 9.		options in any order, as per RFC 2461 [7] Section 9.
	5.3.4.1 Processing solicited advertisements		5.3.4.1 Processing solicited advertisements
	The receiver MUST verify that it has recently sent a matching		The receiver MUST verify that it has recently sent a matching
	solicitation, and that the received advertisement contains a copy of		solicitation, and that the received advertisement contains a copy of
	the Nonce sent in the solicitation.		the Nonce sent in the solicitation.
	skipping to change at page 24, line 21		skipping to change at page 24, line 21
	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.3.4.2.		specified in Section 5.3.4.2.
	5.3.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,
	a "fuzz factor" for comparisons, and an allowed clock drift		a "fuzz factor" for comparisons, and an allowed clock drift
	parameter. The recommended default value for the allowed Delta is		parameter. The recommended default value for the allowed Delta is
	TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift		TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift
	TIMESTAMP_DRIFT (see Section 11).		TIMESTAMP_DRIFT (see Section 10.2).
	To facilitate timestamp checking, each node SHOULD store the		To facilitate timestamp checking, each node SHOULD store the
	following information for each peer:		following information for each peer:
	o The receive time of the last received and accepted SEND message.		o The receive time of the last received and accepted SEND message.
	This is called RDlast.		This is called RDlast.
	o The time stamp in the last received and accepted SEND message.		o The time stamp in the last received and accepted SEND message.
	This is called TSlast.		This is called TSlast.
	skipping to change at page 26, line 19		skipping to change at page 26, line 19
	and it is particularly difficult for a node to distinguish between		and it is particularly difficult for a node to distinguish between
	valid and invalid sources of router information, because the node		valid and invalid sources of router information, because the node
	needs this information before being able to communicate with nodes		needs this information before being able to communicate with nodes
	outside of the link.		outside of the link.
	Since the newly-connected node cannot communicate off-link, it cannot		Since the newly-connected node cannot communicate off-link, it cannot
	be responsible for searching information to help validate the		be responsible for searching information to help validate the
	router(s); however, given a certification path, the node can check		router(s); however, given a certification path, the node can check
	someone else's search results and conclude that a particular message		someone else's search results and conclude that a particular message
	comes from an authorized source. In the typical case, a router		comes from an authorized source. In the typical case, a router
	already connected to beyond the link, can (if necessary) communicate		already connected beyond the link, can (if necessary) communicate
	with off-link nodes and construct such a certification path.		with off-link nodes and construct such a certification path.
	The Secure Neighbor Discovery Protocol mandates a certificate format		The Secure Neighbor Discovery Protocol mandates a certificate format
	and introduces two new ICMPv6 messages that are used between hosts		and introduces two new ICMPv6 messages that are used between hosts
	and routers to allow the host to learn a certification path with the		and routers to allow the host to learn a certification path with the
	assistance of the router.		assistance of the router.
	6.1 Certificate Format		6.1 Certificate Format
	The certification path of a router terminates in a Router		The certification path of a router terminates in a Router
	Authorization Certificate that authorizes a specific IPv6 node to act		Authorization Certificate that authorizes a specific IPv6 node to act
	as a router. Because authorization paths are not a common practice		as a router. Because authorization paths are not a common practice
	in the Internet at the time this specification was written, the path		in the Internet at the time this specification was written, the path
	MUST consist of standard Public Key Certificates (PKC, in the sense		MUST consist of standard Public Key Certificates (PKC, in the sense
	of [20]). The certification path MUST start from the identity of a		of [11]). The certification path MUST start from the identity of a
	trust anchor that is shared by the host and the router. This allows		trust anchor that is shared by the host and the router. This allows
	the host to anchor trust for the router's public key in the trust		the host to anchor trust for the router's public key in the trust
	anchor. Note that there MAY be multiple certificates issued by a		anchor. Note that there MAY be multiple certificates issued by a
	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 [13]. The parent
	certificates in the certification path MUST contain one or more X.509		certificates in the certification path 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 certificates		router in question, or delegated the right to do so. The certificates
	for the intermediate delegating authorities MUST contain X.509 IP		for the intermediate delegating authorities MUST contain X.509 IP
	address extension(s) for subdelegations. The router's certificate is		address extension(s) for subdelegations. The router's certificate is
	signed by the delegating authority for the prefixes the router is		signed by the delegating authority for the prefixes the router is
	authorized to to advertise.		authorized 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 addressPrefix		addressesOrRanges element. This element MUST contain an addressPrefix
	element containing an IPv6 address prefix for a prefix the router or		element containing an IPv6 address prefix for a prefix the router or
	the intermediate entity is authorized to route. If the entity is		the intermediate entity is authorized to route. If the entity is
	allowed to route any prefix, the used IPv6 address prefix is the null		allowed to route any prefix, the used IPv6 address prefix is the null
	prefix, ::/0. The addressFamily element of the containing		prefix, ::/0. The addressFamily element of the containing
	IPAddrBlocks sequence element MUST contain the IPv6 Address Family		IPAddrBlocks sequence element MUST contain the IPv6 Address Family
	Identifier (0002), as specified in [12] for IPv6 prefixes. Instead		Identifier (0002), as specified in [13] for IPv6 prefixes. Instead
	of an addressPrefix element, the addressesOrRange element MAY contain		of an addressPrefix element, the addressesOrRange element MAY contain
	an addressRange element for a range of prefixes, if more than one		an addressRange element for a range of prefixes, if more than one
	prefix is authorized. The X.509 IP address extension MAY contain		prefix is authorized. The X.509 IP address extension MAY contain
	additional IPv6 prefixes, expressed either as an addressPrefix or an		additional IPv6 prefixes, expressed either as an addressPrefix or an
	addressRange.		addressRange.
	A SEND node receiving a Router Authorization Certificate MUST first		A node receiving a Router Authorization Certificate MUST first check
	check whether the certificate's signature was generated by the		whether the certificate's signature was generated by the delegating
	delegating authority. Then the client MUST check whether all the		authority. Then the client MUST check whether all the addressPrefix
	addressPrefix or addressRange entries in the router's certificate are		or addressRange entries in the router's certificate are contained
	contained within the address ranges in the delegating authority's		within the address ranges in the delegating authority's certificate,
	certificate, and whether the addressPrefix entries match any		and whether the addressPrefix entries match any addressPrefix entries
	addressPrefix entries in the delegating authority's certificate. If		in the delegating authority's certificate. If an addressPrefix or
	an addressPrefix or addressRange is not contained within the		addressRange is not contained within the delegating authority's
	delegating authority's prefixes or ranges, the client MAY attempt to		prefixes or ranges, the client MAY attempt to take an intersection of
	take an intersection of the ranges/prefixes, and use that		the ranges/prefixes, and use that intersection. If the addressPrefix
	intersection. If the addressPrefix in the certificate is the null		in the certificate is the null prefix, ::/0, such an intersection
	prefix, ::/0, such an intersection SHOULD be used. (In that case the		SHOULD be used. (In that case the intersection is the parent prefix
	intersection is the parent prefix or range.) If the resulting		or range.) If the resulting intersection is empty, the client MUST
	intersection is empty, the client MUST NOT accept the certificate.		NOT accept the certificate.
	The above check SHOULD be done for all certificates in the path. If		The above check SHOULD be done for all certificates in the path. If
	any of the checks fail, the client MUST NOT accept the certificate.		any of the checks fail, the client MUST NOT accept the certificate.
	The client also needs to perform validation of advertised prefixes as		The client also needs to perform validation of advertised prefixes as
	discussed in Section 7.3.		discussed in Section 7.3.
	Hosts MUST check the subjectPublicKeyInfo field within the last		Hosts MUST check the subjectPublicKeyInfo field within the last
	certificate in the certificate path to ensure that only RSA public		certificate in the certificate path to ensure that only RSA public
	keys are used to attempt validation of router signatures, and MUST		keys are used to attempt validation of router signatures, and MUST
	disregard the certificate for SEND if it does not contain an RSA key.		disregard the certificate for SEND if it does not contain an RSA key.
	skipping to change at page 29, line 6		skipping to change at page 29, line 6
	Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
	Subject: router_x.isp_foo_example.net		Subject: router_x.isp_foo_example.net
	Extensions:		Extensions:
	IP address delegation extension:		IP address delegation extension:
	Prefixes R1, ..., Rk		Prefixes R1, ..., Rk
	... possibly other extensions ...		... possibly other extensions ...
	... 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 CPA from a router,		time a node is checking certificates received from a router, it
	it typically does not have a connection to the Internet yet, and so		typically does not have a connection to the Internet yet, and so it
	it is not possible to perform an on-line Certificate Revocation List		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 the		established a connection with the Internet through the router. If the
	router has been compromised, it could interfere with the CRL check.		router has been compromised, it could interfere with the CRL check.
	Should performance of the CRL check be disrupted or should the check		Should performance of the CRL check be disrupted or should the check
	fail, the node SHOULD immediately stop using the router as a default		fail, the node SHOULD immediately stop using the router as 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 certification path is valid, then router_foo.isp_foo_example.com		the certification path 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
	The Certification Path Solicitation (CPS) message is sent by a host		The Certification Path Solicitation (CPS) message is sent by a host
	when it wishes to request a certification path between a router and		when it wishes to request a certification path between a router and
	the one of the host's trust anchors. The Certification Path		one of the host's trust anchors. The Certification Path
	Advertisement (CPA) message is sent in reply to the CPS message.		Advertisement (CPA) message is sent in reply to the CPS message.
	These messages are separate from the rest of Neighbor and Router		These messages are separate from the rest of Neighbor and Router
	Discovery, in order to reduce the effect of the potentially		Discovery, in order to reduce the effect of the potentially
	voluminous certification path information on other messages.		voluminous certification path information on other messages.
	The Authorization Delegation Discovery (ADD) process does not exclude		The Authorization Delegation Discovery (ADD) process does not exclude
	other forms of discovering certification paths. For instance, during		other forms of discovering certification paths. For instance, during
	fast movements mobile nodes may learn information - including the		fast movements mobile nodes may learn information - including the
	certification paths - of the next router from a previous router, or		certification paths - of the next router from a previous router, or
	nodes may be preconfigured with certification paths from roaming		nodes may be preconfigured with certification paths from roaming
	skipping to change at page 32, line 48		skipping to change at page 32, line 48
	A 16-bit unsigned integer field, acting as an identifier to		A 16-bit unsigned integer field, acting as an identifier to
	help matching advertisements to solicitations. The Identifier		help matching advertisements to solicitations. The Identifier
	field MUST be zero for advertisements sent to the All-Nodes		field MUST be zero for advertisements sent to the All-Nodes
	multicast address and MUST NOT be zero for others.		multicast address and MUST NOT be zero for others.
	All Components		All Components
	A 16-bit unsigned integer field, used for informing the		A 16-bit unsigned integer field, used for informing the
	receiver how many certificates there are in the whole path.		receiver how many certificates there are in the whole path.
	A single advertisement MUST be broken into separately sent		A single advertisement SHOULD be broken into separately sent
	components if there is more than one Certificate option, in		components if there is more than one Certificate option, in
	order to avoid excessive fragmentation at the IP layer. Unlike		order to avoid excessive fragmentation at the IP layer. Unlike
	the fragmentation at the IP layer, individual components of an		the fragmentation at the IP layer, individual components of an
	advertisement may be stored and used before all the components		advertisement may be stored and used before all the components
	have arrived; this makes them slightly more reliable and less		have arrived; this makes them slightly more reliable and less
	prone to Denial-of-Service attacks.		prone to Denial-of-Service attacks.
	Example packet lengths of Certification Path Advertisement		Example packet lengths of Certification Path Advertisement
	messages for typical certification paths are listed in Appendix		messages for typical certification paths are listed in Appendix
	D.		C.
	Component		Component
	A 16-bit unsigned integer field, used for informing the		A 16-bit unsigned integer field, used for informing the
	receiver which certificate is being sent.		receiver which certificate is being sent.
	The first message in a N-component advertisement has the		The first message in a N-component advertisement has the
	Component field set to N-1, the second set to N-2, and so on.		Component field set to N-1, the second set to N-2, and so on.
	Zero indicates that there are no more components coming in this		Zero indicates that there are no more components coming in this
	advertisement.		advertisement.
	The components MUST be ordered so that the certificate after		The components SHOULD be ordered so that the certificate after
	the trust anchor is the one sent first. Each certificate sent		the trust anchor is the one sent first. Each certificate sent
	after the first can be verified with the previously sent		after the first can be verified with the previously sent
	certificates. The certificate of the sender comes last.		certificates. The certificate of the sender comes last.
	Reserved		Reserved
	An unused field. It MUST be initialized to zero by the sender		An unused field. It MUST be initialized to zero by the sender
	and MUST be ignored by the receiver.		and MUST be ignored by the receiver.
	Valid Options:		Valid Options:
	skipping to change at page 35, line 4		skipping to change at page 35, line 4
	Pad Length		Pad Length
	The number of padding octets beyond the end of the Name field but		The number of padding octets beyond the end of the Name field but
	within the length specified by the Length field. Padding octets		within the length specified by the Length field. Padding octets
	MUST be set to zero by senders and ignored by receivers.		MUST be set to zero by senders and ignored by receivers.
	Name		Name
	When the Name Type field is set to 1, the Name field contains a		When the Name Type field is set to 1, the Name field contains a
	DER encoded X.501 Name identifying the trust anchor. The value is		DER encoded X.501 Name identifying the trust anchor. The value is
	encoded as defined in [14] and [10].		encoded as defined in [15] and [10].
	When the Name Type field is set to 2, the Name field contains a		When the Name Type field is set to 2, the Name field contains a
	Fully Qualified Domain Name of the trust anchor, for example,		Fully Qualified Domain Name of the trust anchor, for example,
	"trustanchor.example.com". The name is stored as a string, in the		"trustanchor.example.com". The name is stored as a string, in the
	"preferred name syntax" DNS format, as specified in RFC 1034 [1]		DNS wire format, as specified in RFC 1034 [1]. Additionally, the
	Section 3.5. Additionally, the restrictions discussed in RFC 3280		restrictions discussed in RFC 3280 [10] Section 4.2.1.7 apply.
	[10] Section 4.2.1.7 apply.
	In the FQDN case, the Name field is an "IDN-unaware domain name		In the FQDN case, the Name field is an "IDN-unaware domain name
	slot" as defined in [11]. That is, it can contain only ASCII		slot" as defined in [12]. That is, it can contain only ASCII
	characters. An implementation MAY support internationalized		characters. An implementation MAY support internationalized
	domain names (IDNs) using the ToASCII operation; see [11] for more		domain names (IDNs) using the ToASCII operation; see [12] for more
	information.		information.
	All systems MUST support the DER Encoded X.501 Name.		All systems MUST support the DER Encoded X.501 Name.
	Implementations MAY support the FQDN name type.		Implementations MAY support the FQDN name type.
	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 previous field ends, and continuing to the end		beginning after the previous field ends, and continuing to the end
	of the option, as specified by the Length field.		of the option, as specified by the Length field.
	skipping to change at page 36, line 26		skipping to change at page 36, line 26
	Certificate		Certificate
	When the Cert Type field is set to 1, the Certificate field		When the Cert Type field is set to 1, the Certificate field
	contains an X.509v3 certificate [10], as described in Section		contains an X.509v3 certificate [10], as described in Section
	6.1.1.		6.1.1.
	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 [10, 14]		beginning after the ASN.1 encoding of the previous field [10, 15]
	ends, and continuing to the end of the option, as specified by the		ends, and continuing to the end of the option, as specified by the
	Length field.		Length field.
	6.2.5 Processing Rules for Routers		6.2.5 Processing Rules for Routers
	A router MUST silently discard any received Certification Path		A router MUST silently discard any received Certification Path
	Solicitation messages that do not conform to the message format		Solicitation messages that do not conform to the message format
	defined in Section 6.2.1. The contents of the Reserved field, and of		defined in Section 6.2.1. The contents of the Reserved field, and of
	any unrecognized options, MUST be ignored. Future,		any unrecognized options, MUST be ignored. Future,
	backward-compatible changes to the protocol may specify the contents		backward-compatible changes to the protocol may specify the contents
	skipping to change at page 37, line 13		skipping to change at page 37, line 13
	source address, except when under load, as specified below. Routers		source address, except when under load, as specified below. Routers
	SHOULD NOT send Certification Path Advertisements more than		SHOULD NOT send Certification Path Advertisements more than
	MAX_CPA_RATE times within a second. When there are more		MAX_CPA_RATE times within a second. When there are more
	solicitations, the router SHOULD send the response to the All-Nodes		solicitations, the router SHOULD send the response to the All-Nodes
	multicast address regardless of the source address that appeared in		multicast address regardless of the source address that appeared in
	the solicitation.		the solicitation.
	In an advertisement, the router SHOULD include suitable Certificate		In an advertisement, the router SHOULD include suitable Certificate
	options so that a certification path to the solicited trust anchor		options so that a certification path to the solicited trust anchor
	can be established (or a part of it, if the Component field in the		can be established (or a part of it, if the Component field in the
	solicitation is not equal to 65,535). The anchor is identified by		solicitation is not equal to 65,535). Note also that a single
	the Trust Anchor option. If the Trust Anchor option is represented as		advertisement is broken into separately sent components and ordered
	a DER Encoded X.501 Name, then the Name must be equal to the Subject		in a particular way (see Section 6.2.2) when there is more than one
	field in the anchor's certificate. If the Trust Anchor option is		Certificate option.
	represented as an FQDN, the FQDN must be equal to an FQDN in the
	subjectAltName field of the anchor's certificate. The router SHOULD		The anchor is identified by the Trust Anchor option. If the Trust
	include the Trust Anchor option(s) in the advertisement for which the		Anchor option is represented as a DER Encoded X.501 Name, then the
	certification path was found.		Name must be equal to the Subject field in the anchor's certificate.
			If the Trust Anchor option is represented as an FQDN, the FQDN must
			be equal to an FQDN in the subjectAltName field of the anchor's
			certificate. The router SHOULD include the Trust Anchor option(s) in
			the advertisement for which the certification path was found.
	If the router is unable to find a path to the requested anchor, it		If the router is unable to find a path to the requested anchor, it
	SHOULD send an advertisement without any certificates. In this case		SHOULD send an advertisement without any certificates. In this case
	the router SHOULD include the Trust Anchor options which were		the router SHOULD include the Trust Anchor options which were
	solicited.		solicited.
	6.2.6 Processing Rules for Hosts		6.2.6 Processing Rules for Hosts
	A host MUST silently discard any received Certification Path		A host MUST silently discard any received Certification Path
	Advertisement messages that do not conform to the message format		Advertisement messages that do not conform to the message format
	skipping to change at page 37, line 44		skipping to change at page 37, line 48
	of the Reserved field or add new options; backward-incompatible		of the Reserved field or add new options; backward-incompatible
	changes MUST use different Code values. The contents of any defined		changes MUST use different Code values. The contents of any defined
	options that are not specified to be used with Certification Path		options that are not specified to be used with Certification Path
	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 certification paths retrieved in Certification		Hosts SHOULD store certification paths retrieved in Certification
	Path Discovery messages if they start from an anchor trusted by the		Path Discovery messages if they start from an anchor trusted by the
	host. The certification paths MUST be verified, as defined in		host. The certification paths MUST be verified, as defined in Section
	Section 6.1, before storing them. Routers MUST send the certificates		6.1, before storing them. Routers send the certificates one by one,
	one by one, starting from the trust anchor end of the path.		starting from the trust anchor end of the path.
	Note: except for temporary purposes to allow for message loss and		Note: except for temporary purposes to allow for message loss and
	reordering, hosts might not store certificates received in a		reordering, hosts might not store certificates received in a
	Certification Path Advertisement unless they contain a certificate		Certification Path Advertisement unless they contain a certificate
	which can be immediately verified either to the trust anchor or to a		which can be immediately verified either to the trust anchor or to a
	certificate that has been verified earlier. This measure is to		certificate that has been verified earlier. This measure is to
	prevent Denial-of-Service attacks, whereby an attacker floods a host		prevent Denial-of-Service attacks, whereby an attacker floods a host
	with certificates that the host cannot validate and overwhelms memory		with certificates that the host cannot validate and overwhelms memory
	for certificate storage.		for certificate storage.
	skipping to change at page 42, line 38		skipping to change at page 42, line 38
	Future certification path-based authorization specifications are		Future certification path-based authorization specifications are
	needed for such nodes. This specification also does not apply to		needed for such nodes. This specification also does not apply to
	addresses generated by the IPv6 stateless address autoconfiguration		addresses generated by the IPv6 stateless address autoconfiguration
	using other fixed forms of interface identifiers (such as EUI-64) as		using other fixed forms of interface identifiers (such as EUI-64) as
	a basis.		a basis.
	It is outside the scope of this specification to describe the use of		It is outside the scope of this specification to describe the use of
	trust anchor authorization between nodes with dynamically changing		trust anchor authorization between nodes with dynamically changing
	addresses. Such dynamically changing addresses may be the result of		addresses. Such dynamically changing addresses may be the result of
	stateful or stateless address autoconfiguration, or through the use		stateful or stateless address autoconfiguration, or through the use
	of RFC 3041 [19] addresses. If the CGA method is not used, nodes		of RFC 3041 [20] addresses. If the CGA method is not used, nodes
	would be required to exchange certification paths that terminate in a		would be required to exchange certification paths that terminate in a
	certificate authorizing a node to use an IP address having a		certificate authorizing a node to use an IP address having a
	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.
	skipping to change at page 45, line 13		skipping to change at page 45, line 13
	tentative address is already in use, generate a new tentative CGA.		tentative address is already in use, generate a new tentative CGA.
	If after 3 consecutive attempts no non-unique address was		If after 3 consecutive attempts no non-unique address was
	generated, log a system error and give up attempting to generate		generated, log a system error and give up attempting to generate
	an address for that interface.		an address for that interface.
	When performing Duplicate Address Detection for the first		When performing Duplicate Address Detection for the first
	tentative address, accept both secured and insecure Neighbor		tentative address, accept both secured and insecure Neighbor
	Advertisements and Solicitations received as response to the		Advertisements and Solicitations received as response to the
	Neighbor Solicitations. When performing Duplicate Address		Neighbor Solicitations. When performing Duplicate Address
	Detection for the second or third tentative address, ignore		Detection for the second or third tentative address, ignore
	insecure Neighbor Advertisements and Solicitations.		insecure Neighbor Advertisements and Solicitations. (The security
			implications of this are discussed in Section 9.2.3 and [14].)
	o The node MAY have a configuration option that causes it to ignore		o The node MAY have a configuration option that causes it to ignore
	insecure advertisements even when performing Duplicate Address		insecure advertisements even when performing Duplicate Address
	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
	skipping to change at page 46, line 35		skipping to change at page 46, line 35
	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 where		other. However, it is RECOMMENDED that such checks be performed 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
	[18]. MLD contains no provision for security. An attacker could		[19]. 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
	Multicast-Address-Specific Query to determine whether any listeners		Multicast-Address-Specific Query to determine whether any listeners
	are still on the address, at which point the victim can respond to		are still on the address, at which point the victim can respond to
	avoid being dropped from the group. This technique will work if the		avoid being dropped from the group. This technique will work if the
	router on the link has not been compromised. Other attacks using MLD		router on the link has not been compromised. Other attacks using MLD
	are possible, but they primarily lead to extraneous (but not		are possible, but they primarily lead to extraneous (but not
	overwhelming) traffic.		overwhelming) traffic.
	skipping to change at page 48, line 10		skipping to change at page 48, line 10
	authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
	tested. If these prerequisites are not met, the node performing DAD		tested. If these prerequisites are not met, the node performing DAD
	discards the responses.		discards the responses.
	When a SEND node is performing DAD, it may listen for address		When a SEND node is performing DAD, it may listen for address
	collisions from non-SEND nodes for the first address it generates,		collisions from non-SEND nodes for the first address it generates,
	but not for new attempts. This protects the SEND node from DAD DoS		but not for new attempts. This protects the SEND node from DAD DoS
	attacks by non-SEND nodes or attackers simulating to non-SEND nodes,		attacks by non-SEND nodes or attackers simulating to non-SEND nodes,
	at the cost of a potential address collision between a SEND node and		at the cost of a potential address collision between a SEND node and
	non-SEND node. The probability and effects of such an address		non-SEND node. The probability and effects of such an address
	collision are discussed in [13].		collision are discussed in [14].
	9.2.4 Router Solicitation and Advertisement Attacks		9.2.4 Router Solicitation and Advertisement Attacks
	These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,		These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
	and 4.2.7 of [25]. SEND counters these attacks by requiring Router		and 4.2.7 of [25]. SEND counters these attacks by requiring Router
	Advertisements to contain an RSA Signature option, and that the		Advertisements to contain an RSA Signature option, and that the
	signature is calculated using the public key of a node that can prove		signature is calculated using the public key of a node that can prove
	its authorization to route the subnet prefixes contained in any		its authorization to route the subnet prefixes contained in any
	Prefix Information Options. The router proves its authorization by		Prefix Information Options. The router proves its authorization by
	showing a certificate containing the specific prefix or the		showing a certificate containing the specific prefix or the
	skipping to change at page 49, line 37		skipping to change at page 49, line 37
	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
	the amount of state reserved for unresolved solicitations, and clever		the amount of state reserved for unresolved solicitations, and clever
	cache management. These are all techniques involved in implementing		cache management. These are all techniques involved in implementing
	Neighbor Discovery on the router.		Neighbor Discovery on the router.
	9.3 Attacks against SEND Itself		9.3 Attacks against SEND Itself
	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 [14].
	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 process,		the verification process described in Section 5.2.2. In this process,
	a simple hash verification of the CGA property of the address is		a simple hash verification of the CGA property of the address is
	skipping to change at page 51, line 4		skipping to change at page 51, line 4
	in.		in.
	Attackers may also target hosts by sending a large number of		Attackers may also target hosts by sending a large number of
	unnecessary certification paths, forcing hosts to spend useless		unnecessary certification paths, forcing hosts to spend useless
	memory and verification resources for them. Hosts can defend against		memory and verification resources for them. Hosts can defend against
	such attacks by limiting the amount of resources devoted to the		such attacks by limiting the amount of resources devoted to the
	certification paths and their verification. Hosts SHOULD also		certification paths and their verification. Hosts SHOULD also
	prioritize advertisements that sent as a response to their		prioritize advertisements that sent as a response to their
	solicitations above unsolicited advertisements.		solicitations above unsolicited advertisements.
	10. Protocol Constants		10. Protocol Values
			10.1 Constants
	Host constants:		Host constants:
	MAX_CPS_MESSAGES 3 transmissions		MAX_CPS_MESSAGES 3 transmissions
	CPS_INTERVAL 4 seconds		CPS_INTERVAL 4 seconds
	Router constants:		Router constants:
	MAX_CPA_RATE 10 times per second		MAX_CPA_RATE 10 times per second
	11. Protocol Variables		10.2 Variables
	TIMESTAMP_DELTA 300 seconds (5 minutes)		TIMESTAMP_DELTA 300 seconds (5 minutes)
	TIMESTAMP_FUZZ 1 second		TIMESTAMP_FUZZ 1 second
	TIMESTAMP_DRIFT 1 % (0.01)		TIMESTAMP_DRIFT 1 % (0.01)
	12. IANA Considerations		11. IANA Considerations
	This document defines two new ICMP message types, used in		This document defines two new ICMP message types, used in
	Authorization Delegation Discovery. These messages must be assigned		Authorization Delegation Discovery. These messages must be assigned
	ICMPv6 type numbers from the informational message range:		ICMPv6 type numbers from the informational message range:
	o The Certification Path Solicitation message, described in Section		o The Certification Path Solicitation message, described in Section
	6.2.1.		6.2.1.
	o The Certification Path Advertisement message, described in Section		o The Certification Path Advertisement message, described in Section
	6.2.2.		6.2.2.
	skipping to change at page 53, line 33		skipping to change at page 52, line 33
	o The Timestamp option, described in Section 5.3.1.		o The Timestamp option, described in Section 5.3.1.
	o The Nonce option, described in Section 5.3.2.		o The Nonce option, described in Section 5.3.2.
	o The Trust Anchor option, described in Section 6.2.3.		o The Trust Anchor option, described in Section 6.2.3.
	o The Certificate option, described in Section 6.2.4.		o The Certificate option, described in Section 6.2.4.
	This document defines a new 128-bit value under the CGA Message Type		This document defines a new 128-bit value under the CGA Message Type
	[13] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.		[14] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
	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]. The current values for this field are:		using Standards Action [6]. The current values for this field are:
	1 DER Encoded X.501 Name		1 DER Encoded X.501 Name
	2 FQDN		2 FQDN
	Another new name space is allocated for the Cert Type field in the		Another new name space is allocated for the Cert Type field in the
	skipping to change at page 54, line 39		skipping to change at page 53, line 39
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[9] Conta, A. and S. Deering, "Internet Control Message Protocol		[9] Conta, A. and S. Deering, "Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
	[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509		[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
	Public Key Infrastructure Certificate and Certificate		Public Key Infrastructure Certificate and Certificate
	Revocation List (CRL) Profile", RFC 3280, April 2002.		Revocation List (CRL) Profile", RFC 3280, April 2002.
	[11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing		[11] Farrell, S. and R. Housley, "An Internet Attribute Certificate
			Profile for Authorization", RFC 3281, April 2002.
			[12] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
	Domain Names in Applications (IDNA)", RFC 3490, March 2003.		Domain Names in Applications (IDNA)", RFC 3490, March 2003.
	[12] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP		[13] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers",		Addresses and AS Identifiers",
	draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress),		draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress),
	September 2003.		September 2003.
	[13] Aura, T., "Cryptographically Generated Addresses (CGA)",		[14] Aura, T., "Cryptographically Generated Addresses (CGA)",
	draft-ietf-send-cga-06 (work in progress), April 2004.		draft-ietf-send-cga-06 (work in progress), April 2004.
	[14] International Telecommunications Union, "Information Technology		[15] International Telecommunications Union, "Information Technology
	- ASN.1 encoding rules: Specification of Basic Encoding Rules		- ASN.1 encoding rules: Specification of Basic Encoding Rules
	(BER), Canonical Encoding Rules (CER) and Distinguished		(BER), Canonical Encoding Rules (CER) and Distinguished
	Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.		Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
	[15] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS		[16] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
	1, November 2002.		1, November 2002.
	[16] National Institute of Standards and Technology, "Secure Hash		[17] National Institute of Standards and Technology, "Secure Hash
	Standard", FIPS PUB 180-1, April 1995, <http://		Standard", FIPS PUB 180-1, April 1995, <http://
	www.itl.nist.gov/fipspubs/fip180-1.htm>.		www.itl.nist.gov/fipspubs/fip180-1.htm>.
	Informative References		Informative References
	[17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[18] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
	RFC 2409, November 1998.		RFC 2409, November 1998.
	[18] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener		[19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
	Discovery (MLD) for IPv6", RFC 2710, October 1999.		Discovery (MLD) for IPv6", RFC 2710, October 1999.
	[19] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[20] Narten, T. and R. Draves, "Privacy Extensions for Stateless
	Address Autoconfiguration in IPv6", RFC 3041, January 2001.		Address Autoconfiguration in IPv6", RFC 3041, January 2001.
	[20] Farrell, S. and R. Housley, "An Internet Attribute Certificate
	Profile for Authorization", RFC 3281, April 2002.
	[21] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.		[21] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
	Carney, "Dynamic Host Configuration Protocol for IPv6		Carney, "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.		(DHCPv6)", RFC 3315, July 2003.
	[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",		[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
	draft-arkko-icmpv6-ike-effects-02 (work in progress), March		draft-arkko-icmpv6-ike-effects-02 (work in progress), March
	2003.		2003.
	[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local		[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local
	Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),		Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
	skipping to change at page 58, line 4		skipping to change at page 57, line 4
	EMail: bzill@microsoft.com		EMail: bzill@microsoft.com
	Pekka Nikander		Pekka Nikander
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: Pekka.Nikander@nomadiclab.com		EMail: Pekka.Nikander@nomadiclab.com
	Appendix A. Contributors		Appendix A. Contributors and Acknowledgments
	Tuomas Aura contributed the transition mechanism specification in		Tuomas Aura contributed the transition mechanism specification in
	Section 8. Jonathan Trostle contributed the certification path		Section 8. Jonathan Trostle contributed the certification path
	example in Section 6.1.1.		example in Section 6.1.1.
	Appendix B. Acknowledgments		The authors would also like to thank Tuomas Aura, Erik Nordmark,
			Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien
	The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel		Laganier, Francis Dupont, Pekka Savola, Valtteri Niemi, Mike Roe,
	Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier,		Russ Housley, Thomas Narten, and Steven Bellovin for interesting
	Francis Dupont, and Pekka Savola for interesting discussions in this		discussions in this problem space and feedback regarding the SEND
	problem space and feedback regarding the SEND protocol.		protocol.
	Appendix C. Cache Management		Appendix B. Cache Management
	In this section we outline a cache management algorithm that allows a		In this section we outline a cache management algorithm that allows a
	node to remain partially functional even under a cache filling DoS		node to remain partially functional even under a cache filling DoS
	attack. This appendix is informational, and real implementations		attack. This appendix is informational, and real implementations
	SHOULD use different algorithms in order to avoid he dangers of		SHOULD use different algorithms in order to avoid the dangers of
	mono-cultural code.		mono-cultural code.
	There are at least two distinct cache related attack scenarios:		There are at least two distinct cache related attack scenarios:
	1. There are a number of nodes on a link, and someone launches a		1. There are a number of nodes on a link, and someone launches a
	cache filling attack. The goal here is clearly make sure that		cache filling attack. The goal here is to make sure that the
	the nodes can continue to communicate even if the attack is going		nodes can continue to communicate even if the attack is going on.
	on.
	2. There is already a cache filling attack going on, and a new node		2. There is already a cache filling attack going on, and a new node
	arrives to the link. The goal here is to make it possible for		arrives to the link. The goal here is to make it possible for
	the new node to become attached to the network, in spite of the		the new node to become attached to the network, in spite of the
	attack.		attack.
	From this point of view, it is clearly better to be very selective in		From this point of view, it is clearly better to be very selective in
	how to throw out entries. Reducing the timestamp Delta value is very		how to throw out entries. Reducing the timestamp Delta value is very
	discriminative against those nodes that have a large clock		discriminatory against those nodes that have a large clock
	difference, while an attacker can reduce its clock difference into		difference, while an attacker can reduce its clock difference to
	arbitrarily small. Throwing out old entries just because their clock		arbitrarily small. Throwing out old entries just because their clock
	difference is large seems like a bad approach.		difference is large seems like a bad approach.
	A reasonable idea seems to be to have a separate cache space for new		A reasonable idea seems to be to have a separate cache space for new
	entries and old entries, and under an attack more eagerly drop new		entries and old entries, and under an attack more eagerly drop new
	cache entries than old ones. One could track traffic, and only allow		cache entries than old ones. One could track traffic, and only allow
	those new entries that receive genuine traffic to be converted into		those new entries that receive genuine traffic to be converted into
	old cache entries. While such a scheme will make attacks harder, it		old cache entries. While such a scheme will make attacks harder, it
	will not fully prevent them. For example, an attacker could send a		will not fully prevent them. For example, an attacker could send a
	little traffic (i.e. a ping or TCP syn) after each NS to trick the		little traffic (i.e. a ping or TCP syn) after each NS to trick the
	victim into promoting its cache entry to the old cache. Hence, the		victim into promoting its cache entry to the old cache. Hence, the
	node may be more intelligent in keeping its cache entries, and not		node may be more intelligent in keeping its cache entries, and not
	just have a black/white old/new boundary.		just have a black/white old/new boundary.
	It also looks like a good idea to consider the sec parameter when		It also looks like a good idea to consider the Sec parameter when
	forcing cache entries out, and let those entries with a larger sec a		forcing cache entries out, and let those entries with a larger Sec a
	higher chance of staying in.		higher chance of staying in.
	Appendix D. Message Size When Carrying Certificates		Appendix C. Message Size When Carrying Certificates
	TBD.		TBD.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/