base.txt		issue55.txt
Skipping to change at page 1, line 48:
This Internet-Draft will expire on July 1, 2004.		This Internet-Draft will expire on July 1, 2004.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract		Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover		IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine each the link-layer addresses		other nodes on the link, to determine the link-layer addresses of the
of the nodes on the link, to find routers, and to maintain		nodes on the link, to find routers, and to maintain reachability
reachability information about the paths to active neighbors. If not		information about the paths to active neighbors. If not secured, NDP
secured, NDP is vulnerable to various attacks. This document		is vulnerable to various attacks. This document specifies security
specifies security mechanisms for NDP. Unlike to the original NDP		mechanisms for NDP. Unlike to the original NDP specifications, these
specifications, these mechanisms do not make use of IPsec.		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 . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7		3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11		5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11		5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11
Skipping to change at page 4, line 22:
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.
Original NDP specifications called for the use of IPsec for		Original NDP specifications called for the use of IPsec for
protecting the NDP messages. However, the RFCs do not give detailed		protecting the NDP messages. However, the RFCs do not give detailed
instructions for using IPsec to secure NDP. It turns out that in		instructions for using IPsec to secure NDP. It turns out that in
this particular application, IPsec can only be used with a manual		this particular application, IPsec can only be used with a manual
configuration of security associations, due to chicken-and-egg		configuration of security associations, due to chicken-and-egg
problems in using IKE [20, 15]. Furthermore, the number of such		problems in using IKE [21, 15]. Furthermore, the number of such
manually configured security associations needed for protecting NDP		manually configured security associations needed for protecting NDP
can be very large [21], making that approach impractical for most		can be very large [22], making that approach impractical for most
purposes.		purposes.
This document is organized as follows. Section 4 describes the		This document is organized as follows. Section 4 describes the
overall approach to securing NDP. This approach involves the use of		overall approach to securing NDP. This approach involves the use of
new NDP options to carry public-key based signatures. A		new NDP options to carry public-key based signatures. A
zero-configuration mechanism is used for showing address ownership on		zero-configuration mechanism is used for showing address ownership on
individual nodes; routers are certified by a trust anchor [10]. The		individual nodes; routers are certified by a trust anchor [10]. The
formats, procedures, and cryptographic mechanisms for the		formats, procedures, and cryptographic mechanisms for the
zero-configuration mechanism are described in a related specification		zero-configuration mechanism are described in a related specification
[12].		[12].
Skipping to change at page 5, line 21:
Cryptographically Generated Address (CGA)		Cryptographically Generated Address (CGA)
A technique [12] where the IPv6 address of a node is		A technique [12] where the 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 that assures that two IPv6 nodes on the same link are		A mechanism that assures that two IPv6 nodes on the same link are
not using the same addresses.		not using the same address.
Internet Control Message Protocol version 6 (ICMPv6)
The IPv6 control signaling protocol. Neighbor Discovery Protocol
is a part of ICMPv6.
Neighbor Discovery Protocol (NDP)		Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8].		The IPv6 Neighbor Discovery Protocol [7, 8].
		Neighbor Discovery Protocol is a part of ICMPv6 [9].
Neighbor Discovery (ND)		Neighbor Discovery (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol		The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains also other functions but ND.		(NDP). NDP contains also other functions but ND.
Neighbor Unreachability Detection (NUD)		Neighbor Unreachability Detection (NUD)
This mechanism is used for tracking the reachability of neighbors.		This mechanism is used for tracking the reachability of neighbors.
Nonce		Nonce
A random number generated by a node and used exactly once. In		A random number generated by a node and used exactly once. In
SEND, nonces are used to ensure that a particular advertisement is		SEND, nonces are used to ensure that a particular advertisement is
linked to the solicitation that triggered it.		linked to the solicitation that triggered it.
Router Authorization Certificate		Router Authorization Certificate
An X.509v3 [10] PKC certificate using the profile specified in		An X.509v3 [10] certificate using the profile specified in Section
Section 6.1.1.		6.1.1.
SEND node		SEND node
An IPv6 node that implements this specification.		An IPv6 node that implements this specification.
non-SEND node		non-SEND node
An IPv6 node that does not implement this specification but uses		An IPv6 node that does not implement this specification but uses
the legacy RFC 2461 and RFC 2462 mechanisms.		only RFC 2461 and RFC 2462 mechanisms.
Router Discovery (RD)		Router Discovery (RD)
The Router Discovery function of the Neighbor Discovery Protocol.		Router Discovery allows the hosts to discover what routers exist
		on the link, and what prefixes are available. Router Discovery is
		a part of the Neighbor Discovery Protocol.
3. Neighbor and Router Discovery Overview		3. Neighbor and Router Discovery Overview
The Neighbor Discovery Protocol has several functions. Many of these		The Neighbor Discovery Protocol has several functions. Many of these
functions are overloaded on a few central message types, such as the		functions are overloaded on a few central message types, such as the
ICMPv6 Neighbor Advertisement message. In this section we review		ICMPv6 Neighbor Advertisement message. In this section we review
some of these tasks and their effects in order to understand better		some of these tasks and their effects in order to understand better
how the messages should be treated. This section is not normative,		how the messages should be treated. This section is not normative,
and if this section and the original Neighbor Discovery RFCs are in		and if this section and the original Neighbor Discovery RFCs are in
conflict, the original RFCs take precedence.		conflict, the original RFCs take precedence.
The main functions of NDP are the following.		The main functions of NDP are the following.
o The Router Discovery function allows IPv6 hosts to discover the		o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described		local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [7]. The main purpose of Router		in Section 6 of RFC 2461 [7]. The main purpose of Router
Discovery is to find neighboring routers that are willing to		Discovery is to find neighboring routers that are willing to
forward packets on behalf of hosts. Prefix discovery involves		forward packets on behalf of hosts. Prefix discovery involves
determining which destinations are directly on a link; this		determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should		information is necessary in order to know whether a packet should
be sent to a router or to the destination node directly.		be sent to a router or directly to the destination node.
o The Redirect function is used for automatically redirecting a host		o The Redirect function is used for automatically redirecting a host
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,
the hosts use any prefix information delivered to them during		the hosts use any prefix information delivered to them during
Router Discovery, and then test the newly formed addresses for		Router Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [23], provides		uniqueness. A stateful mechanism, DHCPv6 [19], provides
additional autoconfiguration features.		additional 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 11, line 42:
. .		. .
. Padding .		. Padding .
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described as follows.		The meaning of the fields is described as follows.
Type		Type
TBD <To be assigned by IANA> for CGA.		TBD <To be assigned by IANA for CGA>.
Length		Length
The length of the option (including the Type and Length fields) in		The length of the option (including the Type, Length, Collision
		Cnt, Reserved, Modifier, Key Information, and Padding fields) in
units of 8 octets.		units of 8 octets.
Collision Cnt		Collision Cnt
An 8-bit collision count, which can get values 0, 1 and 2. Its		An 8-bit collision count, which can get values 0, 1 and 2. Its
semantics are defined in [12].		semantics are defined in [12].
Reserved		Reserved
An 8-bit field reserved for future use. The value MUST be		An 8-bit field reserved for future use. The value MUST be
Skipping to change at page 15, line 32:
. .		. .
. Padding .		. Padding .
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described below:		The meaning of the fields is described below:
Type		Type
TBD <To be assigned by IANA> for Signature.		TBD <To be assigned by IANA for Signature>.
Length		Length
The length of the option (including the Type and Length fields) in		The length of the option (including the Type, Length, Pad Length,
		Reserved, Key Hash, Digital Signature, and Padding fields) in
units of 8 octets.		units of 8 octets.
Pad Length		Pad Length
An 8-bit integer field, giving the length of the Pad field in		An 8-bit integer field, giving the length of the Pad field in
units of an octet.		units of an octet.
Reserved		Reserved
An an 8-bit field reserved for future use. The value MUST be		An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the		initialized to zero by the sender, and MUST be ignored by the
receiver.		receiver.
Key Hash		Key Hash
A 128-bit field contains the most significant (leftmost) 128-bits		A 128-bit field contains the most significant (leftmost) 128-bits
of a SHA1 hash of the public key used for the constructing the		of a SHA1 hash of the public key used for the constructing the
signature. The SHA1 is taken over the presentation used in the		signature. The SHA1 is taken over the presentation used in the
Key Information field in the CGA option. Its purpose is to		Key Information field in the CGA option. Its purpose is to
associate the signature to a particular key known by the receiver.		associate the signature to a particular key known by the receiver.
Skipping to change at page 19, line 28:
The construction and verification of this option is computationally		The construction and verification of this option is computationally
expensive. In the NDP context, however, the hosts typically have the		expensive. In the NDP context, however, the hosts typically have the
need to perform only a few signature operations as they enter a link,		need to perform only a few signature operations as they enter a link,
and a few operations as they find a new on-link peer with which to		and a few operations as they find a new on-link peer with which to
communicate.		communicate.
Routers are required to perform a larger number of operations,		Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due		particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature		to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen ones per second, some of		operations is on the order of a few dozen per second, some of which
which can be precomputed as discussed below. A large number of		can be precomputed as discussed below. A large number of router
router solicitations may cause higher demand for performing		solicitations may cause higher demand for performing asymmetric
asymmetric operations, although RFC 2461 limits the rate at which		operations, although RFC 2461 limits the rate at which responses to
responses to solicitations can be sent.		solicitations can be sent.
Signatures can be precomputed for unsolicited (multicast) Neighbor		Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements, if the timing of such future		and Router Advertisements, if the timing of such future
advertisements is known. Typically, solicited advertisements are		advertisements is known. Typically, solicited advertisements are
sent to the unicast address from which the solicitation was sent.		sent to the unicast address from which the solicitation was sent.
Given that the IPv6 header is covered by the signature, it is not		Given that the IPv6 header is covered by the signature, it is not
possible to precompute solicited-for advertisements.		possible to precompute solicited-for advertisements.
5.3 Timestamp and Nonce options		5.3 Timestamp and Nonce options
Skipping to change at page 20, line 21:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
+ Timestamp +		+ Timestamp +
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:		Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA> for Timestamp.		TBD <To be assigned by IANA for Timestamp>.
Length		Length
The length of the option (including the Type and Length fields) in		The length of the option (including the Type, Length, Reserved,
units of 8 octets, i.e., 2.		and Timestamp fields) in units of 8 octets, i.e., 2.
Reserved		Reserved
A 48-bit field reserved for future use. The value MUST be		A 48-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the		initialized to zero by the sender, and MUST be ignored by the
receiver.		receiver.
Timestamp		Timestamp
A 64-bit unsigned integer field containing a timestamp. The value		A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1,, 1970 00:00 UTC,		indicates the number of seconds since January 1, 1970 00:00 UTC,
using a fixed point format. In this format the integer number of		using a fixed point format. In this format the integer number of
seconds is contained in the first 48 bits of the field, and the		seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a		remaining 16 bits indicate the number of 1/64K fractions of a
second.		second.
5.3.2 Nonce Option		5.3.2 Nonce Option
The purpose of the Nonce option is to ensure that an advertisement is		The purpose of the Nonce option is to ensure that an advertisement is
a fresh response to a solicitation sent earlier by the receiving same		a fresh response to a solicitation sent earlier by the receiving same
node. The format of this option is described in the following:		node. The format of this option is described in the following:
Skipping to change at page 21, line 20:
| |		| |
. .		. .
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:		Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA> for Nonce.		TBD <To be assigned by IANA for Nonce>.
Length		Length
The length of the option (including the Type and Length fields) in		The length of the option (including the Type, Length, and Nonce
units of 8 octets.		fields) in units of 8 octets.
Nonce		Nonce
A field containing a random number selected by the sender of the		A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at		solicitation message. The length of the random number MUST be at
least 6 bytes.		least 6 bytes.
5.3.3 Processing rules for senders		5.3.3 Processing rules for senders
All solicitation messages MUST include a Nonce. All solicited-for		All solicitation messages MUST include a Nonce. All solicited-for
Skipping to change at page 22, line 50:
If the message contains a Nonce option, but the Nonce value is not		If the message contains a Nonce option, but the Nonce value is not
recognized, the message MUST be silently discarded.		recognized, the message MUST be silently discarded.
Otherwise, if the message does not contain a Nonce option, it MAY be		Otherwise, if the message does not contain a Nonce option, it MAY be
considered as a non-solicited-for advertisement, and processed		considered as a non-solicited-for advertisement, and processed
according to Section 5.3.4.2.		according to Section 5.3.4.2.
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
3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift		3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift
1% (0.01).		1% (0.01).
To facilitate timestamp checking, each node SHOULD store the		To facilitate timestamp checking, each node SHOULD store the
Skipping to change at page 23, line 51:
o When a message is received from a known peer, i.e., one that		o When a message is received from a known peer, i.e., one that
already has an entry in the cache, the time stamp is checked		already has an entry in the cache, the time stamp is checked
against the previously received SEND message:		against the previously received SEND message:
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz		TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
o If TSnew < TSlast, which is possible if packets arrive rapidly and		o If TSnew < TSlast, which is possible if packets arrive rapidly and
out of order, TSlast MUST NOT be updated, i.e., the stored TSlast		out of order, TSlast MUST NOT be updated, i.e., the stored TSlast
for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD		for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD
be updated. Independent on whether TSlast is updated or not,		be updated. Independent of whether TSlast is updated or not,
RDlast is updated in any case.		RDlast is updated in any case.
6. Authorization Delegation Discovery		6. Authorization Delegation Discovery
Several protocols (NDP included) allow a node to automatically		Several protocols (NDP included) allow a node to automatically
configure itself based on information it learns shortly after		configure itself based on information it learns shortly after
connecting to a new link. It is particularly easy to configure		connecting to a new link. It is particularly easy to configure
"rogue" routers on an unsecured link, and it is particularly		"rogue" routers on an unsecured link, and it is particularly
difficult for a node to distinguish between valid and invalid sources		difficult for a node to distinguish between valid and invalid sources
of information, when the node needs this information before being		of information, when the node needs this information before being
Skipping to change at page 24, line 34:
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 certificate chain 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 certificate chain 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 chains are not a common practice
in the Internet at the time this specification is being written, the		in the Internet at the time this specification was written, the chain
chain MUST consist of standard Public Key Certificates (PKC, in the		MUST consist of standard Public Key Certificates (PKC, in the sense
sense of [18]). The certificate chain MUST start from the identity		of [18]). The certificate chain MUST start from the identity of a
of a trust anchor that is shared by the host and the router. This		trust anchor that is shared by the host and the router. This allows
allows the host to anchor trust for the router's public key in the		the host to anchor trust for the router's public key in the trust
trust anchor. Note that there MAY be multiple certificates issued by		anchor. Note that there MAY be multiple certificates issued by a
a single trust anchor.		single trust anchor.
6.1.1 Router Authorization Certificate Profile		6.1.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined		Router Authorization Certificates are X.509v3 certificates, as
in RFC 3280 [10], and MUST contain at least one instance of the X.509		defined in RFC 3280 [10], and MUST contain at least one instance of
extension for IP addresses, as defined in [11]. The parent		the X.509 extension for IP addresses, as defined in [11]. The parent
certificates in the certificate chain MUST contain one or more X.509		certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to a trusted party (such as the user's		IP address extensions, back up to a trusted party (such as the user's
ISP) that configured the original IP address space block for the		ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The		router in question, or delegated the right to do so for someone. The
certificates for intermediate delegating authorities MUST contain		certificates for intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's		X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes		certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise.		the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one		The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an		addressesOrRanges element. This element MUST contain an
addressPrefix element with an IPv6 address prefix for a prefix the		addressPrefix element with an IPv6 address prefix for a prefix the
router or the intermediate entity is authorized to route. If the		router or the intermediate entity is authorized to route. If the
entity is allowed to route any prefix, the used IPv6 address prefix		entity is allowed to route any prefix, the used IPv6 address prefix
is the null prefix, 0/0. The addressFamily element of the containing		is the null prefix, ::/0. The addressFamily element of the
IPAddrBlocks sequence element MUST contain the IPv6 Address Family		containing IPAddrBlocks sequence element MUST contain the IPv6
Identifier (0002), as specified in [11] for IPv6 prefixes. Instead		Address Family Identifier (0002), as specified in [11] for IPv6
of an addressPrefix element, the addressesOrRange element MAY contain		prefixes. Instead of an addressPrefix element, the addressesOrRange
an addressRange element for a range of prefixes, if more than one		element MAY contain an addressRange element for a range of prefixes,
prefix is authorized. The X.509 IP address extension MAY contain		if more than one prefix is authorized. The X.509 IP address
additional IPv6 prefixes, expressed either as an addressPrefix or an		extension MAY contain additional IPv6 prefixes, expressed either as
addressRange.		an addressPrefix or an addressRange.
A SEND node receiving a Router Authorization Certificate MUST first		A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the		check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the		delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are		addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's		contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any		certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If		addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the		an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attempt to		delegating authority's prefixes or ranges, the client MAY attempt to
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/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 chain. 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.
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 gateway protocols. It is necessary to ensure that the		routing protocols. It is necessary to ensure that the authorization
authorization information is appropriate for all applications. SEND		information is appropriate for all applications. SEND certificates
certificates may authorize a larger set of prefixes than the router		may authorize a larger set of prefixes than the router is really
is really authorized to advertise on a given interface. For		authorized to advertise on a given interface. For instance, SEND
instance, SEND allows the use of the null prefix. This prefix might		allows the use of the null prefix. This prefix might cause
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 PKC certificates used with SEND do not		Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an		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 certificate chain. Suppose that
ispgroup.com is the trust anchor. The host has this certificate for		isp_group_example.net is the trust anchor. The host has this
it:		certificate for it:
Certificate 1:		Certificate 1:
Issuer: isp_group.com		Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group.com		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 then to a linked served by		When the host attaches then to a linked served by
router_x.isp_foo.com, it receives the following certificate chain:		router_x.isp_foo_example.net, it receives the following certificate
		chain:
Certificate 2:		Certificate 2:
Issuer: isp_group.com		Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo.com		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 ...
Certificate 3:		Certificate 3:
Issuer: isp_foo.com		Issuer: isp_foo_example.net
Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo.com		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 procesing the three certificates, the usual RFC 3280 [10]		When procesing the three certificates, the usual RFC 3280 [10]
certificate path validation is performed. Note, however, that at the		certificate path validation is performed. Note, however, that at the
time a node is checking certificates received in a DCA from a router,		time a node is checking certificates received in a DCA from a router,
it typically does not have a connection to the Internet yet, and so		it typically does not have a connection to the Internet yet, and so
Skipping to change at page 28, line 36:
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 Delegation Chain Solicitation>.
Code		Code
0		0
Checksum		Checksum
The ICMP checksum [9].		The ICMP checksum [9].
Identifier		Identifier
Skipping to change at page 30, line 4:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...		| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:		IP Fields:
Source Address		Source Address
A link-local unicast address assigned to the interface from		A link-local unicast address assigned to the interface from
which this message is sent. Note that routers may use multiple		which this message is sent. Note that routers may use multiple
addresses, and therefore this address not sufficient for the		addresses, and therefore this address is not sufficient for the
unique identification of routers.		unique identification of routers.
Destination Address		Destination Address
Either the Solicited-Node multicast address of the receiver or		Either the Solicited-Node multicast address of the receiver or
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 Delegation Chain
Advertisement.		Advertisement>.
Code		Code
0		0
Checksum		Checksum
The ICMP checksum [9].		The ICMP checksum [9].
Identifier		Identifier
Skipping to change at page 32, line 17:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Name Type | Pad Length |		| Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...		| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:		Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA> for Trust Anchor.		TBD <To be assigned by IANA for Trust Anchor>.
Length		Length
The length of the option, (including the Type, Length, Name Type,		The length of the option, (including the Type, Length, Name Type,
Name Length, and Name fields,) in units of 8 octets.		Pad Length, and Name fields) in units of 8 octets.
Name Type		Name Type
The type of the name included in the Name field. This		The type of the name included in the Name field. This
specification defines only one legal value for this field:		specification defines two legal values for this field:
1 DER Encoded X.501 Name		1 DER Encoded X.501 Name
2 FQDN		2 FQDN
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.
Skipping to change at page 33, line 21:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Cert Type | Pad Length |		| Type | Length | Cert Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...		| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:		Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA> for Certificate.		TBD <To be assigned by IANA for Certificate>.
Length		Length
The length of the option, (including the Type, Length, Cert Type,		The length of the option, (including the Type, Length, Cert Type,
Pad Length, and Certificate fields,) in units of 8 octets.		Pad Length, and Certificate fields) in units of 8 octets.
Cert Type		Cert Type
The type of the certificate included in the Certificate field.		The type of the certificate included in the Certificate field.
This specification defines only one legal value for this field:		This specification defines only one legal value for this field:
1 X.509v3 Certificate, as specified below		1 X.509v3 Certificate, as specified below
Pad Length		Pad Length
Skipping to change at page 34, line 25:
processed in the normal manner. The only defined option that may		processed in the normal manner. The only defined option that may
appear is the Trust Anchor option. A solicitation that passes the		appear is the Trust Anchor option. A solicitation that passes the
validity checks is called a "valid solicitation".		validity checks is called a "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. Routers SHOULD NOT send Delegation Chain		source address, except when under load, as specified below. Routers
Advertisements more than MAX_DCA_RATE times within a second. When		SHOULD NOT send Delegation Chain Advertisements more than
there are more solicitations than this, the router SHOULD send the		MAX_DCA_RATE times within a second. When there are more
response to the All-Nodes multicast address regardless of the source		solicitations than this, the router SHOULD send the response to the
address that appeared in the solicitation.		All-Nodes multicast address regardless of the source address that
		appeared in 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 delegation chain to the solicited trust anchor can
be established. The anchor is identified by the Trust Anchor option.		be established. The anchor is identified by the Trust Anchor option.
If the Trust Anchor option is represented as a DER Encoded X.501		If the Trust Anchor option is represented as a DER Encoded X.501
Name, then the Name must be equal to the Subject field in the		Name, then the Name must be equal to the Subject field in the
anchor's certificate. If the Trust Anchor option is represented as		anchor's certificate. If the Trust Anchor option is represented as
an FQDN, the FQDN must be equal to an FQDN in the subjectAltName		an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
field of the anchor's certificate. The router SHOULD include the		field of the anchor's certificate. The router SHOULD include the
Trust Anchor option(s) in the advertisement for which the delegation		Trust Anchor option(s) in the advertisement for which the delegation
Skipping to change at page 34, line 51:
If the router is unable to find a chain to the requested anchor, it		If the router is unable to find a chain 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
Hosts SHOULD possess the public key and trust anchor name of at least		Hosts SHOULD possess the public key and trust anchor name of at least
one certificate authority, they SHOULD possess their own key pair,		one certificate authority, they SHOULD possess their own key pair,
and they MAY posses a certificate from the above mentioned		and they MAY possess a certificate from the above mentioned
certificate authority.		certificate authority.
A host MUST silently discard any received Delegation Chain		A host MUST silently discard any received Delegation Chain
Advertisement messages that do not satisfy all of the requirements		Advertisement messages that do not satisfy all of the requirements
listed in Section 6.2.2.		listed in Section 6.2.2.
The contents of the Reserved field, and of any unrecognized options,		The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol		MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options;		may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The		backward-incompatible changes may use different Code values. The
Skipping to change at page 37, line 9:
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 CGA Addresses		7.1 CGA Addresses
Nodes that use stateless address autoconfiguration, SHOULD generate a		Nodes that use stateless address autoconfiguration SHOULD generate a
new CGA as specified in Section 4 of [12] for each new		new CGA as specified in Section 4 of [12] for each new
autoconfiguration run. The nodes MAY continue to use the same public		autoconfiguration run. The nodes MAY continue to use the same public
key and modifier, and start the process from Step 4.		key and modifier, and start the process from Step 4.
By default, a SEND-enabled node SHOULD use only CGAs as its own		By default, a SEND-enabled node SHOULD use only CGAs as its own
addresses. Other types of addresses MAY be used in testing,		addresses. Other types of addresses MAY be used in testing,
diagnostics or other purposes. However, this document does not		diagnostics or 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 [22].		API, such as the one defined in [23].
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 silently discarded.		be silently discarded.
Skipping to change at page 39, line 10:
to the source address of the packet, except in the case of proxy		to the source address of the packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by		Neighbor Discovery. Proxy Neighbor Discovery is not supported by
this specification; it is planned to be specified in a future		this specification; it is planned to be specified in a future
document.		document.
8. Transition Issues		8. Transition Issues
During the transition to secure links or as a policy consideration,		During the transition to secure links or as a policy consideration,
network operators may want to run a particular link with a mixture of		network operators may want to run a particular link with a mixture of
secure and insecure nodes. Nodes that support SEND SHOULD support		secure and insecure nodes. Nodes that support SEND SHOULD support
the use of SEND and the legacy NDP at the same time.		the use of SEND and plain NDP at the same time.
In a mixed environment, SEND nodes receive both secure and insecure		In a mixed environment, SEND nodes receive both secure and insecure
messages but give priority to "secured" ones. Here, the "secured"		messages but give priority to "secured" ones. Here, the "secured"
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.
SEND nodes send only secured messages. Legacy Neighbor Discovery		SEND nodes send only secured messages. Plain (non-SEND) Neighbor
nodes will obviously send only insecure messages. Per RFC 2461 [7],		Discovery nodes will obviously send only insecure messages. Per RFC
such nodes will ignore the unknown options and will treat secured		2461 [7], such nodes will ignore the unknown options and will treat
messages in the same way as they treat insecure ones. Secured and		secured messages in the same way as they treat insecure ones.
insecure nodes share the same network resources, such as prefixes and		Secured and insecure nodes share the same network resources, such as
address spaces.		prefixes and address spaces.
In a mixed environment SEND nodes follow the protocols defined in RFC		In a mixed environment SEND nodes follow the protocols defined in RFC
2461 and RFC 2462 with the following exceptions:		2461 and RFC 2462 with the following exceptions:
o All solicitations sent by SEND nodes 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.
o A SEND node that uses the CGA authorization method for protecting		o A SEND node that uses the CGA authorization method for protecting
Neighbor Solicitations SHOULD perform Duplicate Address Detection		Neighbor Solicitations SHOULD perform Duplicate Address Detection
Skipping to change at page 47, line 38:
o The Trust Anchor option, described in Section 6.2.3.		o The Trust Anchor option, described in Section 6.2.3.
o The Certificate option, described in Section 6.2.4.		o The Certificate option, described in Section 6.2.4.
This document defines a new 128-bit value under the CGA Message Type		This document defines a new 128-bit value under the CGA Message Type
[12] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.		[12] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
This document defines a new name space for the Name Type field in the		This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated		Trust Anchor option. Future values of this field can be allocated
using standards action [6]. The current values for this field are:		using Standards Action [6]. The current values for this field are:
1 DER Encoded X.501 Name		1 DER Encoded X.501 Name
2 FQDN		2 FQDN
Another new name space is allocated for the Cert Type field in the		Another new name space is allocated for the Cert Type field in the
Certificate option. Future values of this field can be allocated		Certificate option. Future values of this field can be allocated
using standards action [6]. The current values for this field are:		using Standards Action [6]. The current values for this field are:
1 X.509v3 Certificate		1 X.509v3 Certificate
Normative References		Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD		[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.		13, RFC 1034, November 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
Skipping to change at page 50, line 19:
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener		[16] 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.
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[17] 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.
[18] Farrell, S. and R. Housley, "An Internet Attribute Certificate		[18] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.		Profile for Authorization", RFC 3281, April 2002.
[19] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[19] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
		Carney, "Dynamic Host Configuration Protocol for IPv6
		(DHCPv6)", RFC 3315, July 2003.
		[20] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.		Addressing Architecture", RFC 3513, April 2003.
[20] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",		[21] 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.
[21] Arkko, J., "Manual SA Configuration for IPv6 Link Local		[22] 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.
[22] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API		[23] 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.
[23] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.
[24] Kent, S., "IP Encapsulating Security Payload (ESP)",		[24] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.		draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[25] Nikander, P., "IPv6 Neighbor Discovery trust models and		[25] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
threats", draft-ietf-send-psreq-00 (work in progress), October		Discovery trust models and threats", draft-ietf-send-psreq-04
2002.		(work in progress), October 2003.
[26] International Organization for Standardization, "The Directory		[26] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.		- Authentication Framework", ISO Standard X.509, 2000.
[27] Institute of Electrical and Electronics Engineers, "Local and		[27] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",		Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.		IEEE Standard 802.1X, September 2001.
Authors' Addresses		Authors' Addresses
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/