base.txt		issue92.txt
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	6.2.2 Delegation Chain Advertisement Message Format . 30		6.2.2 Delegation Chain Advertisement Message Format . 30
	6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 33		6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 33
	6.2.4 Certificate Option . . . . . . . . . . . . . . . 34		6.2.4 Certificate Option . . . . . . . . . . . . . . . 34
	6.2.5 Processing Rules for Routers . . . . . . . . . . 35		6.2.5 Processing Rules for Routers . . . . . . . . . . 35
	6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36		6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36
	7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 39		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 39
	7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 39		7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 39
	7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 39		7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 39
	7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 39		7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 39
	7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 40		7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 40
	8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41		8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 42
	9. Security Considerations . . . . . . . . . . . . . . . . . . 43		9. Security Considerations . . . . . . . . . . . . . . . . . . 44
	9.1 Threats to the Local Link Not Covered by SEND . . . . 43		9.1 Threats to the Local Link Not Covered by SEND . . . . 44
	9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 43		9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 44
	9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 44		9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 45
	9.2.2 Neighbor Unreachability Detection Failure . . . 44		9.2.2 Neighbor Unreachability Detection Failure . . . 45
	9.2.3 Duplicate Address Detection DoS Attack . . . . . 44		9.2.3 Duplicate Address Detection DoS Attack . . . . . 45
	9.2.4 Router Solicitation and Advertisement Attacks . 45		9.2.4 Router Solicitation and Advertisement Attacks . 46
	9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 45		9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 46
	9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 46		9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 47
	9.3 Attacks against SEND Itself . . . . . . . . . . . . . 46		9.3 Attacks against SEND Itself . . . . . . . . . . . . . 47
	10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48		10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 49
	11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 49		11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 50
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 51
	Normative References . . . . . . . . . . . . . . . . . . . . 51		Normative References . . . . . . . . . . . . . . . . . . . . 52
	Informative References . . . . . . . . . . . . . . . . . . . 53		Informative References . . . . . . . . . . . . . . . . . . . 54
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 57
	C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 57		C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 58
	D. Message Size When Carrying Certificates . . . . . . . . . . 58		D. Message Size When Carrying Certificates . . . . . . . . . . 59
	Intellectual Property and Copyright Statements . . . . . . . 59		Intellectual Property and Copyright Statements . . . . . . . 60
	1. Introduction		1. Introduction
	IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]		IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
	and 2462 [8]. Nodes on the same link use NDP to discover each		and 2462 [8]. Nodes on the same link use NDP to discover each
	other's presence, to determine each other's link-layer addresses, to		other's presence, to determine each other's link-layer addresses, to
	find routers, and to maintain reachability information about the		find routers, and to maintain reachability information about the
	paths to active neighbors. NDP is used both by hosts and routers.		paths to active neighbors. NDP is used both by hosts and routers.
	Its functions include Neighbor Discovery (ND), Router Discovery (RD),		Its functions include Neighbor Discovery (ND), Router Discovery (RD),
	Address Autoconfiguration, Address Resolution, Neighbor		Address Autoconfiguration, Address Resolution, Neighbor
	skipping to change at page 16, line 19		skipping to change at page 16, line 19
	octets:		octets:
	1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F		1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F
	CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been		CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
	generated randomly by the editor of this specification.).		generated randomly by the editor of this specification.).
	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 32-bit ICMP header.		4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from
			the ICMP header.
	5. The NDP message header.		5. The NDP message header, starting from the octet after the ICMP
			Checksum field and continuing up to but not including NDP
			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 [14].
	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).
	skipping to change at page 17, line 30		skipping to change at page 17, line 33
	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
	the unspecified address.		the unspecified address.
	Redirect, Neighbor Solicitation, Neighbor Advertisement, Router		Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
	Solicitation, and Router Advertisement messages containing an RSA		Solicitation, and Router Advertisement messages containing an RSA
	Signature option MUST be checked as follows:		Signature option MUST be checked as follows:
	o The receiver MUST ignore any options the come after the first RSA		o The receiver MUST ignore any options that come after the first RSA
	Signature option. (The options are ignored for both signature		Signature option. (The options are ignored for both signature
	verification and NDP processing purposes.)		verification and NDP processing purposes.)
	o The Key Hash field MUST indicate the use of a known public key,		o The Key Hash field MUST indicate the use of a known public key,
	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.
	skipping to change at page 18, line 16		skipping to change at page 18, line 19
	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
	treated as an insecure message. The receiver MAY also otherwise		treated as an insecure message. The receiver MAY also otherwise
	silently discard packets, e.g., as a response to an apparent CPU		silently discard packets, e.g., as a response to an apparent CPU
	exhausting DoS attack.		exhausting DoS attack.
	5.2.3 Configuration		5.2.3 Configuration
	All nodes that support the reception of the RSA Signature options		All nodes that support the reception of the RSA Signature options
	MUST be configured with the following information for each separate		MUST allow the following information to be configured for each
	NDP message type:		separate NDP message type:
	authorization method		authorization method
	This parameter determines the method through which the authority		This parameter determines the method through which the authority
	of the sender is determined. It can have four values:		of the sender is determined. It can have four values:
	trust anchor		trust anchor
	The authority of the sender is verified as described in Section		The authority of the sender is verified as described in Section
	6.1. The sender may claim additional authorization through the		6.1. The sender may claim additional authorization through the
	skipping to change at page 23, line 21		skipping to change at page 23, line 21
	If the message is accepted, the receiver SHOULD store the receive		If the message is accepted, the receiver SHOULD store the receive
	time of the message and the time stamp time in the message, as		time of the message and the time stamp time in the message, as
	specified in Section 5.3.4.2.		specified in Section 5.3.4.2.
	5.3.4.2 Processing all other messages		5.3.4.2 Processing all other messages
	Receivers SHOULD be configured with an allowed timestamp Delta value,		Receivers SHOULD be configured with an allowed timestamp Delta value,
	a "fuzz factor" for comparisons, and an allowed clock drift		a "fuzz factor" for comparisons, and an allowed clock drift
	parameter. The recommended default value for the allowed Delta is		parameter. The recommended default value for the allowed Delta is
	TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift		TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift
	TIMESTAMP_DRIFT (see Section 11.		TIMESTAMP_DRIFT (see Section 11).
	To facilitate timestamp checking, each node SHOULD store the		To facilitate timestamp checking, each node SHOULD store the
	following information for each peer:		following information for each peer:
	o The receive time of the last received and accepted SEND message.		o The receive time of the last received and accepted SEND message.
	This is called RDlast.		This is called RDlast.
	o The time stamp in the last received and accepted SEND message.		o The time stamp in the last received and accepted SEND message.
	This is called TSlast.		This is called TSlast.
	skipping to change at page 34, line 13		skipping to change at page 34, line 13
	DER encoded X.501 certificate Name, represented and encoded		DER encoded X.501 certificate Name, represented and encoded
	exactly as in the matching X.509v3 trust anchor certificate.		exactly as in the matching X.509v3 trust anchor certificate.
	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
	skipping to change at page 39, line 25		skipping to change at page 39, line 25
	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.
	Note that RFC 2461 rules prevent a host from accepting a Redirect		Note that RFC 2461 rules prevent a host from accepting a Redirect
	message from a router that is not its default router. This prevents		message from a router that the host is not using to reach the
	an attacker from tricking a node into redirecting traffic when the		destination mentioned in the redirect. This prevents an attacker from
	attacker is not the default router.		tricking a node into redirecting traffic when the attacker is not the
			default router.
	7.3 Advertised Prefixes		7.3 Advertised Prefixes
	The router's certificate defines the address range(s) that it is		The router's certificate defines the address range(s) that it is
	allowed to advertise securely. A router MAY, however, advertise a		allowed to advertise securely. A router MAY, however, advertise a
	combination of certified and uncertified prefixes. Uncertified		combination of certified and uncertified prefixes. Uncertified
	prefixes are treated as insecure, i.e., processed in the same way as		prefixes are treated as insecure, i.e., processed in the same way as
	insecure router advertisements sent by non-SEND routers. The		insecure router advertisements sent by non-SEND routers. The
	processing of insecure messages is specified in Section 8. Note that		processing of insecure messages is specified in Section 8. Note that
	SEND nodes that do not attempt to interoperate with non-SEND nodes		SEND nodes that do not attempt to interoperate with non-SEND nodes
	skipping to change at page 40, line 29		skipping to change at page 40, line 29
	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 certificate chain-based authorization specifications are
	needed for such nodes.		needed for such nodes. This specification also does not apply to
			addresses generated by the IPv6 stateless address autoconfiguration
			using other fixed forms of interface identifiers (such as EUI-64) as
			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 [18] 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 certificate chains 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
	skipping to change at page 41, line 22		skipping to change at page 42, line 22
	messages but give priority to "secured" ones. Here, the "secured"		messages but give priority to "secured" ones. Here, the "secured"
	messages are ones that contain a valid signature option, as specified		messages are ones that contain a valid signature option, as specified
	above, and "insecure" messages are ones that contain no signature		above, and "insecure" messages are ones that contain no signature
	option.		option.
	A SEND node SHOULD have a configuration option that causes it to		A SEND node SHOULD have a configuration option that causes it to
	ignore all insecure Neighbor Solicitation and Advertisement, Router		ignore all insecure Neighbor Solicitation and Advertisement, Router
	Solicitation and Advertisement, and Redirect messages. This can be		Solicitation and Advertisement, and Redirect messages. This can be
	used to enforce SEND-only networks. The default for this		used to enforce SEND-only networks. The default for this
	configuration option SHOULD be that both secure and insecure messages		configuration option SHOULD be that both secure and insecure messages
	are allowed. A SEND node MAY also have a configuration option that		are allowed.
	causes it to disable the use of SEND even the messages it sends
	itself.
	SEND nodes MUST send only secured messages. Plain (non-SEND)		A SEND node MAY also have a configuration option that causes it to
	Neighbor Discovery nodes will obviously send only insecure messages.		disable the use of SEND completely, even for the messages it sends
	Per RFC 2461 [7], such nodes will ignore the unknown options and will		itself. The default for this configuration option SHOULD be that SEND
	treat secured messages in the same way as they treat insecure ones.		is used. Plain (non-SEND) Neighbor Discovery nodes will obviously
	Secured and insecure nodes share the same network resources, such as		send only insecure messages. Per RFC 2461 [7], such nodes will
	prefixes and address spaces.		ignore the unknown options and will treat secured messages in the
			same way as they treat insecure ones. Secured and insecure nodes
			share the same network resources, such as prefixes and address
			spaces.
	In a mixed environment SEND nodes follow the protocols defined in RFC		SEND nodes configured to use SEND at least in their own messages
	2461 and RFC 2462 with the following exceptions:		behave in a mixed environment as is explained below.
			Protocols defined in RFC 2461 and RFC 2462 are followed with the
			following exceptions:
	o All solicitations sent by a SEND node MUST be secured.		o All solicitations sent by a SEND node MUST be secured.
	o Unsolicited advertisements sent by a SEND node MUST be secured.		o Unsolicited advertisements sent by a SEND node MUST be secured.
	o A SEND node MUST send a secured advertisement in response to a		o A SEND node MUST send a secured advertisement in response to a
	secured solicitation. Advertisements sent in response to an		secured solicitation. Advertisements sent in response to an
	insecure solicitation MUST be secured as well, but MUST NOT		insecure solicitation MUST be secured as well, but MUST NOT
	contain the Nonce option.		contain the Nonce option.
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/