base.txt		issue91.txt
	skipping to change at page 2, line 9		skipping to change at page 2, line 9
	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 to 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 . . . . . . . . . . . . 4		1.1 Specification of Requirements . . . . . . . . . . . . 5
	2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7		3. Neighbor and Router Discovery Overview . . . . . . . . . . . 8
	4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 10
	5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11		5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 12
	5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 11		5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 12
	5.1.1 Processing Rules for Senders . . . . . . . . . . 12		5.1.1 Processing Rules for Senders . . . . . . . . . . 13
	5.1.2 Processing Rules for Receivers . . . . . . . . . 13		5.1.2 Processing Rules for Receivers . . . . . . . . . 14
	5.1.3 Configuration . . . . . . . . . . . . . . . . . 14		5.1.3 Configuration . . . . . . . . . . . . . . . . . 15
	5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 14		5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 15
	5.2.1 Processing Rules for Senders . . . . . . . . . . 16		5.2.1 Processing Rules for Senders . . . . . . . . . . 17
	5.2.2 Processing Rules for Receivers . . . . . . . . . 17		5.2.2 Processing Rules for Receivers . . . . . . . . . 18
	5.2.3 Configuration . . . . . . . . . . . . . . . . . 18		5.2.3 Configuration . . . . . . . . . . . . . . . . . 19
	5.2.4 Performance Considerations . . . . . . . . . . . 19		5.2.4 Performance Considerations . . . . . . . . . . . 20
	5.3 Timestamp and Nonce options . . . . . . . . . . . . . 19		5.3 Timestamp and Nonce options . . . . . . . . . . . . . 20
	5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 19		5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 20
	5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 20		5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 21
	5.3.3 Processing rules for senders . . . . . . . . . . 21		5.3.3 Processing rules for senders . . . . . . . . . . 22
	5.3.4 Processing rules for receivers . . . . . . . . . 22		5.3.4 Processing rules for receivers . . . . . . . . . 23
	6. Authorization Delegation Discovery . . . . . . . . . . . . . 25		6. Authorization Delegation Discovery . . . . . . . . . . . . . 26
	6.1 Certificate Format . . . . . . . . . . . . . . . . . . 25		6.1 Certificate Format . . . . . . . . . . . . . . . . . . 26
	6.1.1 Router Authorization Certificate Profile . . . . 25		6.1.1 Router Authorization Certificate Profile . . . . 26
	6.2 Certificate Transport . . . . . . . . . . . . . . . . 28		6.2 Certificate Transport . . . . . . . . . . . . . . . . 29
	6.2.1 Delegation Chain Solicitation Message Format . . 28		6.2.1 Certification Path Solicitation Message Format . 29
	6.2.2 Delegation Chain Advertisement Message Format . 30		6.2.2 Certification Path Advertisement Message Format 31
	6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 33		6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 34
	6.2.4 Certificate Option . . . . . . . . . . . . . . . 34		6.2.4 Certificate Option . . . . . . . . . . . . . . . 35
	6.2.5 Processing Rules for Routers . . . . . . . . . . 35		6.2.5 Processing Rules for Routers . . . . . . . . . . 36
	6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36		6.2.6 Processing Rules for Hosts . . . . . . . . . . . 37
	7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 39		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 40
	7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 39		7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 40
	7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 39		7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 40
	7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 39		7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 40
	7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 40		7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 41
	8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 42		8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 43
	9. Security Considerations . . . . . . . . . . . . . . . . . . 44		9. Security Considerations . . . . . . . . . . . . . . . . . . 45
	9.1 Threats to the Local Link Not Covered by SEND . . . . 44		9.1 Threats to the Local Link Not Covered by SEND . . . . 45
	9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 44		9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 45
	9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 45		9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 46
	9.2.2 Neighbor Unreachability Detection Failure . . . 45		9.2.2 Neighbor Unreachability Detection Failure . . . 46
	9.2.3 Duplicate Address Detection DoS Attack . . . . . 45		9.2.3 Duplicate Address Detection DoS Attack . . . . . 46
	9.2.4 Router Solicitation and Advertisement Attacks . 46		9.2.4 Router Solicitation and Advertisement Attacks . 47
	9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 46		9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 47
	9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 47		9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 48
	9.3 Attacks against SEND Itself . . . . . . . . . . . . . 47		9.3 Attacks against SEND Itself . . . . . . . . . . . . . 48
	10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 49		10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 50
	11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 50		11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 51
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 51		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 52
	Normative References . . . . . . . . . . . . . . . . . . . . 52		Normative References . . . . . . . . . . . . . . . . . . . . 53
	Informative References . . . . . . . . . . . . . . . . . . . 54		Informative References . . . . . . . . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 57		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 58
	C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 58		C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 59
	D. Message Size When Carrying Certificates . . . . . . . . . . 59		D. Message Size When Carrying Certificates . . . . . . . . . . 60
	Intellectual Property and Copyright Statements . . . . . . . 60		Intellectual Property and Copyright Statements . . . . . . . 61
	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
	[21, 16]. Furthermore, the number of such manually configured		[22, 17]. 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.		[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 [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 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
			provisioned on end hosts for authorizing address use, and security of
			NDP when the entity defending an address is not the same as the
			entity claiming that adddress (also known as "proxy ND"). These are
			extensions of SEND that may be treated in separate documents should
			the need arise.
	1.1 Specification of Requirements		1.1 Specification of Requirements
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
	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 certificate chain		A process through which SEND nodes can acquire a certification
	from a peer node to a trust anchor.		path from a peer node to a trust anchor.
	Cryptographically Generated Address (CGA)		Cryptographically Generated Address (CGA)
	A technique [13] whereby an IPv6 address of a node is		A technique [13] 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.
	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
	skipping to change at page 7, line 36		skipping to change at page 8, 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 additional		uniqueness. A stateful mechanism, DHCPv6 [21], provides 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
	skipping to change at page 9, line 16		skipping to change at page 10, line 16
	To secure the various functions in NDP, a set of new Neighbor		To secure the various functions in NDP, a set of new Neighbor
	Discovery options is introduced. They are used to protect NDP		Discovery options is introduced. They are used to protect NDP
	messages. This specification introduces these options, an		messages. This specification introduces these options, an
	authorization delegation discovery process, an address ownership		authorization delegation discovery process, an address ownership
	proof mechanism, and requirements for the use of these components in		proof mechanism, and requirements for the use of these components in
	NDP.		NDP.
	The components of the solution specified in this document are as		The components of the solution specified in this document are as
	follows:		follows:
	o Certificate chains, anchored on trusted parties, are expected to		o Certification paths, anchored on trusted parties, are expected to
	certify the authority of routers. A host and a router must have		certify the authority of routers. A host and a router must have
	at least one common trust anchor before the host can adopt the		at least one common trust anchor before the host can adopt the
	router as its default router. Delegation Chain Solicitation and		router as its default router. Certification Path Solicitation and
	Advertisement messages are used to discover a certificate chain to		Advertisement messages are used to discover a certification path
	the trust anchor without requiring the actual Router Discovery		to the trust anchor without requiring the actual Router Discovery
	messages to carry lengthy certificate chains. The receipt of a		messages to carry lengthy certification paths. The receipt of a
	protected Router Advertisement message for which no certificate		protected Router Advertisement message for which no certification
	chain is available triggers the authorization delegation discovery		path is available triggers the authorization delegation discovery
	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
	skipping to change at page 16, line 7		skipping to change at page 17, line 7
	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 Public Key field of the CGA Parameters data structure that		in the Public Key field of the CGA Parameters data structure that
	is carried in the CGA option. Its purpose is to associate the		is carried in the CGA option. Its purpose is to associate the
	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 signature, constructed		A variable length field containing a PKCS#1 v1.5 signature,
	using the sender's private key, over the the following sequence of		constructed using the sender's private key, over the the following
	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 [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.).
	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 [14].		algorithm and SHA-1 hash as defined in [15].
	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 17, line 15		skipping to change at page 18, line 15
	o The message is constructed in its entirety, without the RSA		o The message is constructed in its entirety, without the RSA
	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 signature is put		configured private key, and the resulting PKCS#1 v1.5 signature is
	to the Digital Signature field.		put to 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 be
	also treated as insecure, unless the source address of the message is		also treated as insecure, unless the source address of the message is
	skipping to change at page 17, line 48		skipping to change at page 18, line 48
	either one learned from a preceding CGA option in the same		either one learned from a preceding CGA option in the same
	message, or one known by other means.		message, or one known by other means.
	o The Digital Signature field MUST have correct encoding, and not		o The Digital Signature field MUST have correct encoding, and not
	exceed the length of the RSA Signature option minus the Padding.		exceed the length of the RSA Signature option minus the Padding.
	o The Digital Signature verification MUST show that the signature		o The Digital Signature verification MUST show that the signature
	has been calculated as specified in the previous section.		has been calculated as specified in the previous section.
	o If the use of a trust anchor has been configured, a valid		o If the use of a trust anchor has been configured, a valid
	authorization delegation chain MUST be known between the		certification path (see Section 6.1) MUST be known between the
	receiver's trust anchor and the sender's public key.		receiver's trust anchor and the sender's public key.
	Note that the receiver may verify just the CGA property of a		Note that the receiver may verify just the CGA property of a
	packet, even if, in addition to CGA, the sender has used a trust		packet, even if, in addition to CGA, the sender has used a trust
	anchor.		anchor.
	Messages that do not pass all the above tests MUST be silently		Messages that do not pass all the above tests MUST be silently
	discarded if the host has been configured to only accept secure ND		discarded if the host has been configured to only accept secure ND
	messages. The messages MAY be accepted it the host has been		messages. The messages MAY be accepted it the host has been
	configured to accept both secure and insecure messages, but MUST be		configured to accept both secure and insecure messages, but MUST be
	skipping to change at page 19, line 8		skipping to change at page 20, line 8
	The public keys and names of the allowed trust anchor(s), if the		The public keys and names of the allowed trust anchor(s), if the
	authorization method is not set to CGA.		authorization method is not set to CGA.
	All nodes that support the sending of RSA Signature options MUST		All nodes that support the sending of RSA Signature options MUST
	record the following configuration information:		record 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 certification path 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 be		A flag that indicates whether CGA is used or not. This flag may be
	per interface or per node. (Note that in future extensions of the		per interface or per node. (Note that in future extensions of 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
	skipping to change at page 25, line 16		skipping to change at page 26, line 16
	NDP allows a node to automatically configure itself based on		NDP allows a node to automatically configure itself based on
	information learned shortly after connecting to a new link. It is		information learned shortly after connecting to a new link. It is
	particularly easy to configure "rogue" routers on an unsecured link,		particularly easy to configure "rogue" routers on an unsecured link,
	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 chain of appropriately signed		router(s); however, given a certification path, the node can check
	certificates, it can check someone else's search results and conclude		someone else's search results and conclude that a particular message
	that a particular message comes from an authorized source. In the		comes from an authorized source. In the typical case, a router
	typical case, a router already connected to beyond the link, can (if		already connected to beyond the link, can (if necessary) communicate
	necessary) communicate with off-link nodes and construct such a		with off-link nodes and construct such a certification path.
	certificate chain.
	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 certificate chain 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 certificate chain 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 chains 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 chain		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 [19]). The certificate chain MUST start from the identity of a		of [20]). 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 [12]. The parent
	certificates in the certificate chain 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 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
	skipping to change at page 26, line 35		skipping to change at page 27, line 34
	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
	take an intersection of the ranges/prefixes, and use that		take an intersection of the ranges/prefixes, and use that
	intersection. If the addressPrefix in the certificate is the null		intersection. If the addressPrefix in the certificate is the null
	prefix, ::/0, such an intersection SHOULD be used. (In that case the		prefix, ::/0, such an intersection SHOULD be used. (In that case the
	intersection is the parent prefix or range.) If the resulting		intersection is the parent prefix or range.) If the resulting
	intersection is empty, the client MUST NOT accept the certificate.		intersection is empty, the client MUST NOT accept the certificate.
	The above check SHOULD be done for all certificates in the chain. 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
			certificate in the certificate path to ensure that only RSA public
			keys are used to attempt validation of router signatures, and MUST
			disregard the certificate for SEND if it does not contain an RSA key.
	Care should be taken if the certificates used in SEND are re-used to		Care should be taken if the certificates used in SEND are re-used to
	provide authorization in other circumstances, for example with		provide authorization in other circumstances, for example with
	routing protocols. It is necessary to ensure that the authorization		routing protocols. It is necessary to ensure that the authorization
	information is appropriate for all applications. SEND certificates		information is appropriate for all applications. SEND certificates
	may authorize a larger set of prefixes than the router is really		may authorize a larger set of prefixes than the router is really
	authorized to advertise on a given interface. For instance, SEND		authorized to advertise on a given interface. For instance, SEND
	allows the use of the null prefix. This prefix might cause		allows the use of the null prefix. This prefix might cause
	verification or routing problems in other applications. It is		verification or routing problems in other applications. It is
	RECOMMENDED that SEND certificates containing the null prefix are		RECOMMENDED that SEND certificates containing the null prefix are
	only used for SEND.		only used for SEND.
	Since it is possible that some public key certificates used with SEND		Since it is possible that some public key certificates used with SEND
	do not immediately contain the X.509 IP address extension element, an		do not immediately contain the X.509 IP address extension element, an
	implementation MAY contain facilities that allow the prefix and range		implementation MAY contain facilities that allow the prefix and range
	checks to be relaxed. However, any such configuration options SHOULD		checks to be relaxed. However, any such configuration options SHOULD
	be off by default. That is, the system SHOULD have a default		be off by default. That is, the system SHOULD have a default
	configuration that requires rigorous prefix and range checks.		configuration that requires rigorous prefix and range checks.
	The following is an example of a certificate chain. Suppose that		The following is an example of a certification path. Suppose that
	isp_group_example.net is the trust anchor. The host has this		isp_group_example.net is the trust anchor. The host has this
	certificate:		certificate:
	Certificate 1:		Certificate 1:
	Issuer: isp_group_example.net		Issuer: isp_group_example.net
	Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
	Subject: isp_group_example.net		Subject: isp_group_example.net
	Extensions:		Extensions:
	IP address delegation extension:		IP address delegation extension:
	Prefixes: P1, ..., Pk		Prefixes: P1, ..., Pk
	... possibly other extensions ...		... possibly other extensions ...
	... other certificate parameters ...		... other certificate parameters ...
	When the host attaches to a link served by		When the host attaches to a link served by
	router_x.isp_foo_example.net, it receives the following certificate		router_x.isp_foo_example.net, it receives the following certification
	chain:		path:
	Certificate 2:		Certificate 2:
	Issuer: isp_group_example.net		Issuer: isp_group_example.net
	Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
	Subject: isp_foo_example.net		Subject: isp_foo_example.net
	Extensions:		Extensions:
	IP address delegation extension:		IP address delegation extension:
	Prefixes: Q1, ..., Qk		Prefixes: Q1, ..., Qk
	... possibly other extensions ...		... possibly other extensions ...
	... other certificate parameters ...		... other certificate parameters ...
	skipping to change at page 27, line 51		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 DCA from a router,		time a node is checking certificates received in a CPA 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 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 certificate chain 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 Delegation Chain Solicitation (DCS) message is sent by a host		The Certification Path Solicitation (CPS) message is sent by a host
	when it wishes to request a certificate chain 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 Delegation Chain		the one of the host's trust anchors. The Certification Path
	Advertisement (DCA) message is sent in reply to the DCS 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 certificate chain 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 certificate chains. 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
	certificate chains - 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 certificate chains from roaming		nodes may be preconfigured with certification paths from roaming
	partners.		partners.
	Where hosts themselves are certified by a trust anchor, these		Where hosts themselves are certified by a trust anchor, these
	messages MAY also optionally be used between hosts to acquire the		messages MAY also optionally be used between hosts to acquire the
	peer's certificate chain. However, the details of such usage are		peer's certification path. However, the details of such usage are
	beyond the scope of this specification.		beyond the scope of this specification.
	6.2.1 Delegation Chain Solicitation Message Format		6.2.1 Certification Path Solicitation Message Format
	Hosts send Delegation Chain Solicitations in order to prompt routers		Hosts send Certification Path Solicitations in order to prompt
	to generate Delegation Chain Advertisements.		routers to generate Certification Path Advertisements.
	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 | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier | Component |		| Identifier | Component |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options ...		| Options ...
	+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-
	skipping to change at page 29, line 35		skipping to change at page 30, line 35
	multicast address, or the address of the host's default router.		multicast address, or the address of the host's default router.
	Hop Limit		Hop Limit
	255		255
	ICMP Fields:		ICMP Fields:
	Type		Type
	TBD <To be assigned by IANA for Delegation Chain Solicitation>.		TBD <To be assigned by IANA for Certification Path
			Solicitation>.
	Code		Code
	0		0
	Checksum		Checksum
	The ICMP checksum [9].		The ICMP checksum [9].
	Identifier		Identifier
	skipping to change at page 30, line 30		skipping to change at page 31, line 31
	one Trust Anchor option, the options past the first one may		one Trust Anchor option, the options past the first one may
	contain any type of trust anchor.		contain any type of trust anchor.
	Future versions of this protocol may define new option types.		Future versions of this protocol may define new option types.
	Receivers MUST silently ignore any options they do not recognize		Receivers MUST silently ignore any options they do not recognize
	and continue processing the message. All included options MUST		and continue processing the message. All included options MUST
	have a length that is greater than zero.		have a length that is greater than zero.
	ICMP length (derived from the IP length) MUST be 8 or more octets.		ICMP length (derived from the IP length) MUST be 8 or more octets.
	6.2.2 Delegation Chain Advertisement Message Format		6.2.2 Certification Path Advertisement Message Format
	Routers send out Delegation Chain Advertisement messages in response		Routers send out Certification Path Advertisement messages in
	to a Delegation Chain Solicitation.		response to a Certification Path Solicitation.
	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 | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier | All Components |		| Identifier | All Components |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Component | Reserved |		| Component | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 31, line 25		skipping to change at page 32, line 25
	the link-scoped All-Nodes multicast address.		the link-scoped All-Nodes multicast address.
	Hop Limit		Hop Limit
	255		255
	ICMP Fields:		ICMP Fields:
	Type		Type
	TBD <To be assigned by IANA for Delegation Chain		TBD <To be assigned by IANA for Certification Path
	Advertisement>.		Advertisement>.
	Code		Code
	0		0
	Checksum		Checksum
	The ICMP checksum [9].		The ICMP checksum [9].
	Identifier		Identifier
	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 chain.		receiver how many certificates there are in the whole path.
	A single advertisement MUST be broken into separately sent		A single advertisement MUST 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 Delegation Chain Advertisement		Example packet lengths of Certification Path Advertisement
	messages for typical certificate chains are listed in Appendix		messages for typical certification paths are listed in Appendix
	D.		D.
	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
	skipping to change at page 32, line 37		skipping to change at page 33, line 37
	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:
	Certificate		Certificate
	One certificate is provided in each Certificate option, to		One certificate is provided in each Certificate option, to
	establish a (part of a) certificate chain to a trust anchor.		establish a (part of a) certification path to a trust anchor.
	The certificate of the trust anchor itself SHOULD NOT be		The certificate of the trust anchor itself SHOULD NOT be
	included.		included.
	Trust Anchor		Trust Anchor
	Zero or more Trust Anchor options may be included to help		Zero or more Trust Anchor options may be included to help
	receivers decide which advertisements are useful for them. If		receivers decide which advertisements are useful for them. If
	present, these options MUST appear in the first component of a		present, these options MUST appear in the first component of a
	multi-component advertisement.		multi-component advertisement.
	skipping to change at page 34, line 3		skipping to change at page 35, line 3
	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 certificate Name, represented and encoded		DER encoded X.501 Name identifying the trust anchor. The value is
	exactly as in the matching X.509v3 trust anchor certificate.		encoded as defined in [14] 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]		"preferred name syntax" DNS format, as specified in RFC 1034 [1]
	Section 3.5. Additionally, the restrictions discussed in RFC 3280		Section 3.5. Additionally, the 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 [11]. 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 [11] 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 ASN.1 encoding of the previous field ends, and		beginning after the previous field ends, and continuing to the end
	continuing to the end of the option, as specified by the Length		of the option, as specified by the Length field.
	field.
	6.2.4 Certificate Option		6.2.4 Certificate Option
	The format of the certificate option is described in the following:		The format of the certificate option is described in the following:
	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 | Cert Type | Reserved |		| Type | Length | Cert Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 35, line 27		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 ends, and		beginning after the ASN.1 encoding of the previous field [10, 14]
	continuing to the end of the option, as specified by the Length		ends, and continuing to the end of the option, as specified by the
	field.		Length field.
	6.2.5 Processing Rules for Routers		6.2.5 Processing Rules for Routers
	If the router has been configured to use SEND, it should be		If the router has been configured to use SEND, it should be
	configured with a key pair and a certificate from at least one		configured with a key pair and a certificate from at least one
	certificate authority.		certificate authority.
	A router MUST silently discard any received Delegation Chain		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
	of the Reserved field or add new options; backward-incompatible		of the Reserved field or add new options; backward-incompatible
	changes may use different Code values. The contents of any defined		changes may use different Code values. The contents of any defined
	options that are not specified to be used with Router Solicitation		options that are not specified to be used with Router Solicitation
	messages MUST be ignored and the packet processed in the normal		messages MUST be ignored and the packet processed in the normal
	manner. The only defined option that may appear is the Trust Anchor		manner. The only defined option that may appear is the Trust Anchor
	option. A solicitation that passes the validity checks is called a		option. A solicitation that passes the validity checks is called a
	"valid solicitation".		"valid solicitation".
	Routers SHOULD send advertisements in response to valid solicitations		Routers SHOULD send advertisements in response to valid solicitations
	received on an advertising interface. If the source address in the		received on an advertising interface. If the source address in the
	solicitation was the unspecified address, the router MUST send the		solicitation was the unspecified address, the router MUST send the
	response to the link-scoped All-Nodes multicast address. If the		response to the link-scoped All-Nodes multicast address. If the
	source address was a unicast address, the router MUST send the		source address was a unicast address, the router MUST send the
	response to the Solicited-Node multicast address corresponding to the		response to the Solicited-Node multicast address corresponding to the
	source address, except when under load, as specified below. Routers		source address, except when under load, as specified below. Routers
	SHOULD NOT send Delegation Chain Advertisements more than		SHOULD NOT send Certification Path Advertisements more than
	MAX_DCA_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 delegation chain to the solicited trust anchor can		options so that a certification path to the solicited trust anchor
	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). The anchor is identified by
	the Trust Anchor option. If the Trust Anchor option is represented as		the Trust Anchor option. If the Trust Anchor option is represented as
	a DER Encoded X.501 Name, then the Name must be equal to the Subject		a DER Encoded X.501 Name, then the Name must be equal to the Subject
	field in the anchor's certificate. If the Trust Anchor option is		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		represented as an FQDN, the FQDN must be equal to an FQDN in the
	subjectAltName field of the anchor's certificate. The router SHOULD		subjectAltName field of the anchor's certificate. The router SHOULD
	include the Trust Anchor option(s) in the advertisement for which the		include the Trust Anchor option(s) in the advertisement for which the
	delegation chain was found.		certification path was found.
	If the router is unable to find a chain 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
	If the host has been configured to use SEND, it SHOULD possess the		If the host has been configured to use SEND, it SHOULD possess the
	public key and trust anchor name of at least one certificate		public key and trust anchor name of at least one certificate
	authority, they SHOULD possess their own key pair, and they MAY		authority, they SHOULD possess their own key pair, and they MAY
	possess certificates from certificate authorities.		possess certificates from certificate authorities.
	A host MUST silently discard any received Delegation Chain		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
	defined in Section 6.2.2. The contents of the Reserved field, and of		defined in Section 6.2.2. 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
	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 Delegation Chain		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 certificate chains retrieved in Delegation Chain		Hosts SHOULD store certification paths retrieved in Certification
	Discovery messages if they start from an anchor trusted by the host.		Path Discovery messages if they start from an anchor trusted by the
	The certificate chains MUST be verified, as defined in Section 6.1,		host. The certification paths MUST be verified, as defined in
	before storing them. Routers MUST send the certificates one by one,		Section 6.1, before storing them. Routers MUST send the certificates
	starting from the trust anchor end of the chain.		one by one, 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
	Delegation Chain 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.
	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 certificate		to the network can help improve performance. But periodic certificate
	revocation checks are still needed even with cached results, to make		revocation checks are still needed even with cached 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 certification path 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 certification
	delegation chain to the host's trust anchor. In these situations, the		path to the host's trust anchor. In these situations, the host MAY
	host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain		transmit up to MAX_CPS_MESSAGES Certification Path Solicitation
	Solicitation messages, each separated by at least DCS_INTERVAL		messages, each separated by at least CPS_INTERVAL seconds. In
	seconds. In addition, hosts MAY also transmit up to MAX_DCS_MESSAGES		addition, hosts MAY also transmit up to MAX_CPS_MESSAGES
	Delegation Chain Solicitation messages with the Component field set		Certification Path Solicitation messages with the Component field set
	to a value not equal to 65,535, if they have received only a part of		to a value not equal to 65,535, if they have received only a part of
	a certificate chain.		a certification path.
	Delegation Chain Solicitations SHOULD NOT be sent if the host has a		Certification Path Solicitations SHOULD NOT be sent if the host has a
	currently valid certificate chain from a reachable router to a trust		currently valid certification path 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		Certification Path 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
	default router's IP address, if a default router has already been		default router's IP address, if a default router has already been
	selected.		selected.
	If two hosts want to establish trust with the DCS and DCA messages,		If two hosts want to establish trust with the CPS and CPA messages,
	the DCS message SHOULD be sent to the Solicited-Node multicast		the CPS message SHOULD be sent to the Solicited-Node multicast
	address of the receiver. The advertisements SHOULD be sent as		address of the receiver. The advertisements SHOULD be sent as
	specified above for routers. However, the exact details are outside		specified above for routers. However, the exact details are outside
	the scope of this specification.		the scope of this specification.
	When processing possible advertisements sent as responses to a		When processing possible advertisements sent as responses to a
	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
	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 [24].
	7.2 Redirect Addresses		7.2 Redirect Addresses
	If the Target Address and Destination Address fields in the ICMP		If the Target Address and Destination Address fields in the ICMP
	Redirect message are equal, then this message is used to inform hosts		Redirect message are equal, then this message is used to inform hosts
	that a destination is in fact a neighbor. In this case the receiver		that a destination is in fact a neighbor. In this case the receiver
	MUST verify that the given address falls within the range defined by		MUST verify that the given address falls within the range defined by
	the router's certificate. Redirect messages failing this check MUST		the router's certificate. Redirect messages failing this check MUST
	be treated as insecure, as described in Section 7.3.		be treated as insecure, as described in Section 7.3.
	skipping to change at page 40, line 28		skipping to change at page 41, line 28
	SHOULD use a different advertising router as its default router, if		SHOULD use a different advertising router as its default router, if
	available. If the node is performing stateful autoconfiguration, it		available. If the node is performing stateful autoconfiguration, 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 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 [18] addresses. If the CGA method is not used, nodes		of RFC 3041 [19] addresses. If the CGA method is not used, nodes
	would be required to exchange certificate chains 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.
	The Target Address in Neighbor Advertisement is required to be equal		The Target Address in Neighbor Advertisement is required to be equal
	skipping to change at page 43, line 40		skipping to change at page 44, line 40
	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 checks		security checking for the SEND router is underway. Security checks
	in this case include delegation chain solicitation, certificate		in this case include certification path solicitation, certificate
	verification, CRL checks, and RA signature checks. A node MAY also		verification, CRL checks, and RA signature checks. A node MAY also
	adopt an insecure router if a SEND router becomes unreachable, but		adopt an insecure router if a SEND router becomes unreachable, but
	SHOULD attempt to find a SEND router as soon as possible, since		SHOULD attempt to find a SEND router as soon as possible, since
	the unreachability may be the result of an attack. Note that while		the unreachability may be the result of an attack. Note that while
	this can speed up attachment to a new network, accepting an		this can speed up attachment to a new network, accepting an
	insecure router opens the node to possible attacks, and nodes that		insecure router opens the node to possible attacks, and nodes that
	choose to accept insecure routers do so at their own risk. The		choose to accept insecure routers do so at their own risk. The
	node SHOULD in any case prefer the SEND router as soon as one is		node SHOULD in any case prefer the SEND router as soon as one is
	available with completed security checks.		available with completed security checks.
	skipping to change at page 44, line 35		skipping to change at page 45, 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
	[17]. MLD contains no provision for security. An attacker could		[18]. 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.
	9.2 How SEND Counters Threats to NDP		9.2 How SEND Counters Threats to NDP
	The SEND protocol is designed to counter the threats to NDP, as		The SEND protocol is designed to counter the threats to NDP, as
	outlined in [24]. The following subsections contain a regression of		outlined in [25]. The following subsections contain a regression of
	the SEND protocol against the threats, to illustrate what aspects of		the SEND protocol against the threats, to illustrate what aspects of
	the protocol counter each threat.		the protocol counter each threat.
	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 [25]. 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 performing		the IPv6 address into its Neighbor Cache. Also, a node performing
	Duplicate Address Detection (DAD) that receives a Neighbor		Duplicate Address Detection (DAD) that receives a Neighbor
	Solicitation for the same address regards the situation as a		Solicitation for the same address regards the situation as a
	skipping to change at page 45, line 37		skipping to change at page 46, line 37
	2. Entries made as a result of a Neighbor Advertisement message.		2. Entries made as a result of a Neighbor Advertisement message.
	SEND counters this threat by requiring the RSA Signature and CGA		SEND counters this threat by requiring the RSA Signature and CGA
	options to be present in these advertisements.		options to be present in these advertisements.
	See also Section 9.2.5, below, for discussion about replay protection		See also Section 9.2.5, below, for discussion about replay protection
	and timestamps.		and timestamps.
	9.2.2 Neighbor Unreachability Detection Failure		9.2.2 Neighbor Unreachability Detection Failure
	This attack is described in Section 4.1.2 of [24]. SEND counters		This attack is described in Section 4.1.2 of [25]. SEND counters
	this attack by requiring a node responding to Neighbor Solicitations		this attack by requiring a node responding to Neighbor Solicitations
	sent as NUD probes to include an RSA Signature option and proof of		sent as NUD probes to include an RSA Signature option and proof of
	authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
	probed. If these prerequisites are not met, the node performing NUD		probed. If these prerequisites are not met, the node performing NUD
	discards the responses.		discards the responses.
	9.2.3 Duplicate Address Detection DoS Attack		9.2.3 Duplicate Address Detection DoS Attack
	This attack is described in Section 4.1.3 of [24]. SEND counters		This attack is described in Section 4.1.3 of [25]. SEND counters
	this attack by requiring the Neighbor Advertisements sent as		this attack by requiring the Neighbor Advertisements sent as
	responses to DAD to include an RSA Signature option and proof of		responses to DAD to include an RSA Signature option and proof of
	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 [13].
	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 [24]. 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
	indication that the router is allowed to route any prefix. A Router		indication that the router is allowed to route any prefix. A Router
	Advertisement without these protections is discarded.		Advertisement without these protections is discarded.
	SEND does not protect against brute force attacks on the router, such		SEND does not protect against brute force attacks on the router, such
	as DoS attacks, or compromise of the router, as described in Sections		as DoS attacks, or compromise of the router, as described in Sections
	4.4.2 and 4.4.3 of [24].		4.4.2 and 4.4.3 of [25].
	9.2.5 Replay Attacks		9.2.5 Replay Attacks
	This attack is described in Section 4.3.1 of [24]. SEND protects		This attack is described in Section 4.3.1 of [25]. SEND protects
	against attacks in Router Solicitation/Router Advertisement and		against attacks in Router Solicitation/Router Advertisement and
	Neighbor Solicitation/Neighbor Advertisement transactions by		Neighbor Solicitation/Neighbor Advertisement transactions by
	including a Nonce option in the solicitation and requiring the		including a Nonce option in the solicitation and requiring the
	advertisement to include a matching option. Together with the		advertisement to include a matching option. Together with the
	signatures this forms a challenge-response protocol.		signatures this forms a challenge-response protocol.
	SEND protects against attacks from unsolicited messages such as		SEND protects against attacks from unsolicited messages such as
	Neighbor Advertisements, Router Advertisements, and Redirects by		Neighbor Advertisements, Router Advertisements, and Redirects by
	including a Timestamp option. The following security issues are		including a Timestamp option. The following security issues are
	relevant only for unsolicited messages:		relevant only for unsolicited messages:
	skipping to change at page 47, line 14		skipping to change at page 48, line 14
	SEND nodes are also protected against replay attacks as long as		SEND nodes are also protected against replay attacks as long as
	they cache the state created by the message containing the		they cache the state created by the message containing the
	timestamp. The cached state allows the node to protect itself		timestamp. The cached state allows the node to protect itself
	against replayed messages. However, once the node flushes the		against replayed messages. However, once the node flushes the
	state for whatever reason, an attacker can re-create the state by		state for whatever reason, an attacker can re-create the state by
	replaying an old message while the timestamp is still valid.		replaying an old message while the timestamp is still valid.
	Since most SEND nodes are likely to use fairly coarse grained		Since most SEND nodes are likely to use fairly coarse grained
	timestamps, as explained in Section 5.3.1, this may affect some		timestamps, as explained in Section 5.3.1, this may affect some
	nodes.		nodes.
	o Attacks against time synchronization protocols such as NTP [25]		o Attacks against time synchronization protocols such as NTP [26]
	may cause SEND nodes to have an incorrect timestamp value. This		may cause SEND nodes to have an incorrect timestamp value. This
	can be used to launch replay attacks even outside the normal		can be used to launch replay attacks even outside the normal
	window of vulnerability. To protect against such attacks, it is		window of vulnerability. To protect against such attacks, it is
	recommended that SEND nodes keep independently maintained clocks,		recommended that SEND nodes keep independently maintained clocks,
	or apply suitable security measures for the time synchronization		or apply suitable security measures for the time synchronization
	protocols.		protocols.
	9.2.6 Neighbor Discovery DoS Attack		9.2.6 Neighbor Discovery DoS Attack
	This attack is described in Section 4.3.2 of [24]. In this attack,		This attack is described in Section 4.3.2 of [25]. In this attack,
	the attacker bombards the router with packets for fictitious		the attacker bombards the router with packets for fictitious
	addresses on the link, causing the router to busy itself with		addresses on the link, causing the router to busy itself with
	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
	skipping to change at page 48, line 14		skipping to change at page 49, line 14
	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 RSA Signature option, and start selectively		received with the RSA Signature option, and start selectively
	discarding packets if too many resources are spent. Implementations		discarding packets if too many resources are spent. Implementations
	MAY also first discard packets that are not protected with CGA.		MAY also first discard packets that are not protected with CGA.
	The Authorization Delegation Discovery process may also be vulnerable		The Authorization Delegation Discovery process may also be vulnerable
	to Denial-of-Service attacks. An attack may target a router by		to Denial-of-Service attacks. An attack may target a router by
	requesting a large number of delegation chains to be discovered for		requesting a large number of certification paths to be discovered for
	different trust anchors. Routers SHOULD defend against such attacks		different trust anchors. Routers SHOULD defend against such attacks
	by caching discovered information (including negative responses) and		by caching discovered information (including negative responses) and
	by limiting the number of different discovery processes they engage		by limiting the number of different discovery processes they engage
	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 certificate chains, forcing hosts to spend useless memory		unnecessary certification paths, forcing hosts to spend useless
	and verification resources for them. Hosts can defend against such		memory and verification resources for them. Hosts can defend against
	attacks by limiting the amount of resources devoted to the		such attacks by limiting the amount of resources devoted to the
	certificate chains 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 Constants
	Host constants:		Host constants:
	MAX_DCS_MESSAGES 3 transmissions		MAX_CPS_MESSAGES 3 transmissions
	DCS_INTERVAL 4 seconds		CPS_INTERVAL 4 seconds
	Router constants:		Router constants:
	MAX_DCA_RATE 10 times per second		MAX_CPA_RATE 10 times per second
	11. Protocol Variables		11. Protocol 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		12. 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 Delegation Chain Solicitation message, described in Section		o The Certification Path Solicitation message, described in Section
	6.2.1.		6.2.1.
	o The Delegation Chain Advertisement message, described in Section		o The Certification Path Advertisement message, described in Section
	6.2.2.		6.2.2.
	This document defines six new Neighbor Discovery Protocol [7]		This document defines six new Neighbor Discovery Protocol [7]
	options, which must be assigned Option Type values within the option		options, which must be assigned Option Type values within the option
	numbering space for Neighbor Discovery Protocol messages:		numbering space for Neighbor Discovery Protocol messages:
	o The CGA option, described in Section 5.1.		o The CGA option, described in Section 5.1.
	o The RSA Signature option, described in Section 5.2.		o The RSA Signature option, described in Section 5.2.
	skipping to change at page 52, line 50		skipping to change at page 53, line 50
	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		[12] 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)",		[13] 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] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS		[14] International Telecommunications Union, "Information Technology
			- ASN.1 encoding rules: Specification of Basic Encoding Rules
			(BER), Canonical Encoding Rules (CER) and Distinguished
			Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
			[15] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
	1, November 2002.		1, November 2002.
	[15] National Institute of Standards and Technology, "Secure Hash		[16] 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
	[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
	RFC 2409, November 1998.		RFC 2409, November 1998.
	[17] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener		[18] 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.
	[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[19] 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.
	[19] Farrell, S. and R. Housley, "An Internet Attribute Certificate		[20] Farrell, S. and R. Housley, "An Internet Attribute Certificate
	Profile for Authorization", RFC 3281, April 2002.		Profile for Authorization", RFC 3281, April 2002.
	[20] 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.
	[21] 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.
	[22] 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),
	June 2002.		June 2002.
	[23] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API		[24] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
	for Address Selection", draft-chakrabarti-ipv6-addrselect-02		for Address Selection", draft-chakrabarti-ipv6-addrselect-02
	(work in progress), October 2003.		(work in progress), October 2003.
	[24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor		[25] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
	Discovery trust models and threats", draft-ietf-send-psreq-04		Discovery trust models and threats", draft-ietf-send-psreq-04
	(work in progress), October 2003.		(work in progress), October 2003.
	[25] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth		[26] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth
	Annual Computer Security Conference Proceedings, December 1990.		Annual Computer Security Conference Proceedings, December 1990.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	skipping to change at page 56, line 7		skipping to change at page 57, 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 example		Section 8. Jonathan Trostle contributed the certification path
	in Section 6.1.1.		example 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
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/