draft-ietf-ipv6-ndproxy-01.txt		draft-ietf-ipv6-ndproxy-02.txt
	IPv6 Working Group D. Thaler		IPv6 Working Group D. Thaler
	INTERNET-DRAFT M. Talwar		INTERNET-DRAFT M. Talwar
	February 15, 2005 Microsoft		May 5, 2005 Microsoft
	Expires August 2005 C. Patel		Expires November 2005 C. Patel
	All Play, No Work		All Play, No Work
	Bridge-like Neighbor Discovery Proxies (ND Proxy)		Bridge-like Neighbor Discovery Proxies (ND Proxy)
	<draft-ietf-ipv6-ndproxy-01.txt>		<draft-ietf-ipv6-ndproxy-02.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been		applicable patent or other IPR claims of which he or she is aware
	disclosed, or will be disclosed, and any of which I become aware		have been or will be disclosed, and any of which he or she becomes
	will be disclosed, in accordance with RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Draft ND Proxy February 2005		Draft ND Proxy May 2005
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	Bridging multiple links into a single entity has several		Bridging multiple links into a single entity has several
	operational advantages. A single subnet prefix is sufficient to		operational advantages. A single subnet prefix is sufficient to
	support multiple physical links. There is no need to allocate		support multiple physical links. There is no need to allocate
	subnet numbers to the different networks, simplifying management.		subnet numbers to the different networks, simplifying management.
	Bridging some types of media requires network-layer support,		Bridging some types of media requires network-layer support,
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	o It requires all ports to support the same type of link-layer		o It requires all ports to support the same type of link-layer
	addressing (in particular, IEEE 802 addressing).		addressing (in particular, IEEE 802 addressing).
	As a result, two common scenarios, described below, are not		As a result, two common scenarios, described below, are not
	solved, and it is these two scenarios we specifically target in		solved, and it is these two scenarios we specifically target in
	this document. While the mechanism described herein may apply to		this document. While the mechanism described herein may apply to
	other scenarios as well, we will concentrate our discussion on		other scenarios as well, we will concentrate our discussion on
	these two scenarios.		these two scenarios.
	Draft ND Proxy February 2005		Draft ND Proxy May 2005
	1.1. SCENARIO 1: Wireless upstream		1.1. SCENARIO 1: Wireless upstream
	The following figure illustrates a likely example:		The following figure illustrates a likely example:
	| +-------+ +--------+		| +-------+ +--------+
	local |Ethernet | | Wireless | Access |		local |Ethernet | | Wireless | Access |
	+---------+ A +-))) (((-+ +--> rest of network		+---------+ A +-))) (((-+ +--> rest of network
	hosts | | | link | Point |		hosts | | | link | Point |
	| +-------+ +--------+		| +-------+ +--------+
	skipping to change at page 3, line 29		skipping to change at page 3, line 29
	encryption so that wireless clients may not see each other's data.		encryption so that wireless clients may not see each other's data.
	Classic bridging requires the bridge (node A in the above diagram)		Classic bridging requires the bridge (node A in the above diagram)
	to be in promiscuous mode. In this wireless scenario, A cannot		to be in promiscuous mode. In this wireless scenario, A cannot
	put its wireless interface into promiscuous mode, since one		put its wireless interface into promiscuous mode, since one
	wireless node cannot see traffic to/from other wireless nodes.		wireless node cannot see traffic to/from other wireless nodes.
	This document describes a solution for both IPv4 and IPv6 which		This document describes a solution for both IPv4 and IPv6 which
	does not involve NAT or require any change to the access point or		does not involve NAT or require any change to the access point or
	router.		router.
	IPv4 ARP proxying has been used for some years to solve this		Multiple variants of IPv4 ARP proxying have been used for some
	problem, but the behavior has not been described in a		years to solve this problem. ARP-based bridges were first
	specification. In this document, we describe how this may be		described in [ARPPROXY], but that variant decrements the TTL, does
	implemented, and also enable equivalent functionality for IPv6 to		not forward all-ones broadcasts, and requires proxies to keep per-
	remove this incentive to deploy NATs in IPv6.		packet state on recent subnet broadcasts. The first two
			characteristics can cause problems with applications and protocols
			which assume that nodes in the subnet prefix can be reached with
			TTL 1 (or with TTL 255, with TTL 255 verified on receipt) and/or
			with a subnet broadcast. The third characteristic results in
			scalability issues in proxy implementations. As a result,
			multiple variants have emerged in different implementations over
			time. In this document, we describe one such variant, and enable
			equivalent functionality for IPv6 to remove this incentive to
			deploy NATs in IPv6.
	We also note that Prefix Delegation [PD] could also be used to		We also note that Prefix Delegation [PD] could also be used to
	solve this scenario. There are, however, two disadvantages to		solve this scenario. There are, however, two disadvantages to
	this. First, if an implementation already supports IPv4 ARP		this. First, if an implementation already supports IPv4 ARP
	proxying (which is indeed supported in a number of implementations		proxying (which is indeed supported in a number of implementations
	today), then IPv6 Prefix Delegation would result in separate IPv6		today), then IPv6 Prefix Delegation would result in separate IPv6
	subnets on either side of the device, while a single IPv4 subnet		subnets on either side of the device, while a single IPv4 subnet
	would span both segments. This topological discrepancy can		would span both segments. This topological discrepancy can
	complicate applications and protocols which use the concept of a		complicate applications and protocols which use the concept of a
			Draft ND Proxy May 2005
	local subnet. Secondly, the extent to which Prefix Delegation is		local subnet. Secondly, the extent to which Prefix Delegation is
	supported, and supported without additional charge, is up to the		supported, and supported without additional charge, is up to the
	service provider. Hence, there is no guarantee that Prefix		service provider. Hence, there is no guarantee that Prefix
	Delegation will work without explicit configuration or additional		Delegation will work without explicit configuration or additional
	charge. Bridging, on the other hand, allows the device to work		charge. Bridging, on the other hand, allows the device to work
	with zero configuration, regardless of the service provider's		with zero configuration, regardless of the service provider's
	policies, just as a NAT does. Hence bridging avoids the incentive		policies, just as a NAT does. Hence bridging avoids the incentive
	to NAT IPv6 just to avoid paying for, or requiring configuration		to NAT IPv6 just to avoid paying for, or requiring configuration
	to get, another prefix.		to get, another prefix.
	Draft ND Proxy February 2005
	1.2. SCENARIO 2: PPP upstream		1.2. SCENARIO 2: PPP upstream
	The following figure illustrates another likely example:		The following figure illustrates another likely example:
	| +-------+ +--------+		| +-------+ +--------+
	local |Ethernet | | PPP link | |		local |Ethernet | | PPP link | |
	+---------+ A +-----------+ Router +--> rest of network		+---------+ A +-----------+ Router +--> rest of network
	hosts | | | | |		hosts | | | | |
	| +-------+ +--------+		| +-------+ +--------+
	In this scenario, the router believes that the other end of the		In this scenario, the router believes that the other end of the
	skipping to change at page 4, line 41		skipping to change at page 5, line 4
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
	in this document are to be interpreted as described in BCP 14, RFC		in this document are to be interpreted as described in BCP 14, RFC
	2119 [KEYWORDS].		2119 [KEYWORDS].
	The term "proxy interface" will be used to refer to an interface		The term "proxy interface" will be used to refer to an interface
	(which could itself be a bridge interface) over which network		(which could itself be a bridge interface) over which network
	layer proxying is done as defined herein.		layer proxying is done as defined herein.
	In this document we make no distinction between a "link" (in the		In this document we make no distinction between a "link" (in the
	classic IPv6 sense) and a "subnet". We use the term "segment" to		classic IPv6 sense) and a "subnet". We use the term "segment" to
			Draft ND Proxy May 2005
	apply to a bridged component of the link.		apply to a bridged component of the link.
	Finally, while it is possible that functionality equivalent to		Finally, while it is possible that functionality equivalent to
	that described herein may be achieved by nodes which do not		that described herein may be achieved by nodes which do not
	fulfill all the requirements in [NODEREQ], in the remainder of		fulfill all the requirements in [NODEREQ], in the remainder of
	this document we will describe behavior in terms of an IPv6 node		this document we will describe behavior in terms of an IPv6 node
	as defined in that document.		as defined in that document.
	Draft ND Proxy February 2005
	3. Requirements		3. Requirements
	Bridge-like proxy behavior is designed with the following		Bridge-like proxy behavior is designed with the following
	requirements in mind:		requirements in mind:
	o Support connecting multiple segments with a single subnet		o Support connecting multiple segments with a single subnet
	prefix.		prefix.
	o Support media which cannot be bridged at the link-layer.		o Support media which cannot be bridged at the link-layer.
	Note, this document does not support bridging of non-802		Note, this document does not support bridging of non-802
	skipping to change at page 5, line 42		skipping to change at page 6, line 5
	o Also work in the absence of any routers.		o Also work in the absence of any routers.
	o Support nodes moving between segments. For example, a node		o Support nodes moving between segments. For example, a node
	should be able to keep its address without seeing its address		should be able to keep its address without seeing its address
	as a duplicate due to any cache maintained at the proxy.		as a duplicate due to any cache maintained at the proxy.
	o Allow dynamic addition of a proxy without adversely		o Allow dynamic addition of a proxy without adversely
	disrupting the network.		disrupting the network.
			Draft ND Proxy May 2005
	o The proxy behavior should not break any existing classic		o The proxy behavior should not break any existing classic
	bridges in use on a network segment.		bridges in use on a network segment.
	3.1. Non-requirements		3.1. Non-requirements
	The following items are not considered requirements, as they are		The following items are not considered requirements, as they are
	not met by classic bridges:		not met by classic bridges:
	Draft ND Proxy February 2005
	o Show up as a hop in a traceroute.		o Show up as a hop in a traceroute.
	o Use the shortest path between two nodes on different		o Use the shortest path between two nodes on different
	segments.		segments.
	o Be able to use all available interfaces simultaneously.		o Be able to use all available interfaces simultaneously.
	Instead, bridging technology relies on disabling redundant		Instead, bridging technology relies on disabling redundant
	interfaces to prevent loops.		interfaces to prevent loops.
	o Support connecting media on which Neighbor Discovery is not		o Support connecting media on which Neighbor Discovery is not
	skipping to change at page 6, line 41		skipping to change at page 7, line 5
	for securing these protocols do not use IPsec so this is		for securing these protocols do not use IPsec so this is
	considered acceptable.		considered acceptable.
	o Support Redirects for off-subnet destinations that point to a		o Support Redirects for off-subnet destinations that point to a
	router on a different segment from the redirected host.		router on a different segment from the redirected host.
	While this scenario may be desirable, no solution is		While this scenario may be desirable, no solution is
	currently known which does not have undesirable side effects		currently known which does not have undesirable side effects
	outside the subnet. As a result, this scenario is outside		outside the subnet. As a result, this scenario is outside
	the scope of this document.		the scope of this document.
			Draft ND Proxy May 2005
	4. Bridge-Like Proxy Behavior		4. Bridge-Like Proxy Behavior
	Network layer support for proxying between multiple interfaces		Network layer support for proxying between multiple interfaces
	SHOULD be used only when classic bridging is not possible.		SHOULD be used only when classic bridging is not possible.
	When a proxy interface comes up, the node puts it in "all-		When a proxy interface comes up, the node puts it in "all-
	multicast" mode so that it will receive all multicast packets. It		multicast" mode so that it will receive all multicast packets. It
	is common for interfaces to not support full promiscuous mode		is common for interfaces to not support full promiscuous mode
	(e.g., on a wireless client), but all-multicast mode is generally		(e.g., on a wireless client), but all-multicast mode is generally
	still supported.		still supported.
	Draft ND Proxy February 2005
	As with all other interfaces, IPv4 and IPv6 maintain a neighbor		As with all other interfaces, IPv4 and IPv6 maintain a neighbor
	cache (aka "ARP cache") for each proxy interface, which will be		cache (aka "ARP cache") for each proxy interface, which will be
	used as described below. For readability, we will describe the		used as described below. For readability, we will describe the
	neighbor cache as if both IPv4 and IPv6 neighbors use the same		neighbor cache as if both IPv4 and IPv6 neighbors use the same
	state machine described in [ND].		state machine described in [ND].
	4.1. Forwarding Packets		4.1. Forwarding Packets
	When a packet from any IP source address other than the		When a packet from any IP source address other than the
	unspecified address is received on a proxy interface, the neighbor		unspecified address is received on a proxy interface, the neighbor
	skipping to change at page 7, line 32		skipping to change at page 7, line 43
	must be parsed to see whether it is known to be of a type that		must be parsed to see whether it is known to be of a type that
	negotiates link-layer addresses. This document covers the		negotiates link-layer addresses. This document covers the
	following types: ARP, IPv6 Neighbor Discovery, IPv6 Router		following types: ARP, IPv6 Neighbor Discovery, IPv6 Router
	Discovery, IPv6 Redirects, and DHCPv4. These packets are ones		Discovery, IPv6 Redirects, and DHCPv4. These packets are ones
	that can carry link-layer addresses, and hence must be proxied (as		that can carry link-layer addresses, and hence must be proxied (as
	described below) so that packets between nodes on different		described below) so that packets between nodes on different
	segments can be received by the proxy and have the correct link-		segments can be received by the proxy and have the correct link-
	layer address type on each segment.		layer address type on each segment.
	When any other IP broadcast or multicast packet (other than to the		When any other IP broadcast or multicast packet (other than to the
	IPv6 Link-scoped STP Multicast Group) is received on a proxy		IPv6 Link-scoped RSTP Multicast Group) is received on a proxy
	interface, in addition to any normal IP behavior such as being		interface, in addition to any normal IP behavior such as being
	delivered locally, it is forwarded unchanged (other than using a		delivered locally, it is forwarded unchanged (other than using a
	new link-layer header) out all other proxy interfaces on the same		new link-layer header) out all other proxy interfaces on the same
	link. (As specified in [BRIDGE], the proxy may instead support		link. (As specified in [BRIDGE], the proxy may instead support
	multicast learning and filtering but this is OPTIONAL.) In		multicast learning and filtering but this is OPTIONAL.) In
	particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and no		particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and no
	ICMP errors (except as noted in Section 4.1.1 below) are sent as a		ICMP errors (except as noted in Section 4.1.1 below) are sent as a
			Draft ND Proxy May 2005
	result of attempting this forwarding.		result of attempting this forwarding.
	When any other IP unicast packet is received on a proxy interface,		When any other IP unicast packet is received on a proxy interface,
	if it is not locally destined then it is forwarded unchanged		if it is not locally destined then it is forwarded unchanged
	(other than using a new link-layer header) to the proxy interface		(other than using a new link-layer header) to the proxy interface
	for which the next hop address appears in the neighbor cache.		for which the next hop address appears in the neighbor cache.
	Again the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP		Again the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP
	errors (except as noted in Section 4.1.1 below) are sent as a		errors (except as noted in Section 4.1.1 below) are sent as a
	result of attempting this forwarding. To choose a proxy interface		result of attempting this forwarding. To choose a proxy interface
	to forward to, the neighbor cache is consulted, and the interface		to forward to, the neighbor cache is consulted, and the interface
	with the neighbor entry in the "best" state is used. In order of		with the neighbor entry in the "best" state is used. In order of
	Draft ND Proxy February 2005
	least to most preferred, the states (per [ND]) are INCOMPLETE,		least to most preferred, the states (per [ND]) are INCOMPLETE,
	STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back		STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back
	out the same interface on which it arrived; such a packet is		out the same interface on which it arrived; such a packet is
	instead silently dropped.		instead silently dropped.
	If no cache entry exists (as may happen if the proxy has		If no cache entry exists (as may happen if the proxy has
	previously evicted the cache entry or if the proxy is restarted),		previously evicted the cache entry or if the proxy is restarted),
	the proxy SHOULD queue the packet and initiate Neighbor Discovery		the proxy SHOULD queue the packet and initiate Neighbor Discovery
	as if the packet were being locally generated. The proxy MAY		as if the packet were being locally generated. The proxy MAY
	instead silently drop the packet. In this case, the entry will		instead silently drop the packet. In this case, the entry will
	skipping to change at page 8, line 40		skipping to change at page 9, line 4
	the address of the outgoing interface.		the address of the outgoing interface.
	4.1.1. Sending Packet Too Big Messages		4.1.1. Sending Packet Too Big Messages
	Whenever any IPv4 packet is to be forwarded out an interface whose		Whenever any IPv4 packet is to be forwarded out an interface whose
	MTU is smaller than the size of the packet, and the Dont Fragment		MTU is smaller than the size of the packet, and the Dont Fragment
	bit is set, the ARP proxy drops the packet and sends a		bit is set, the ARP proxy drops the packet and sends a
	Fragmentation Needed message back to the source.		Fragmentation Needed message back to the source.
	Similarly, whenever any IPv6 packet is to be forwarded out an		Similarly, whenever any IPv6 packet is to be forwarded out an
			Draft ND Proxy May 2005
	interface whose MTU is smaller than the size of the packet, the ND		interface whose MTU is smaller than the size of the packet, the ND
	proxy drops the packet and sends a Packet Too Big message back to		proxy drops the packet and sends a Packet Too Big message back to
	the source, as described in [ICMPv6].		the source, as described in [ICMPv6].
	4.1.2. Proxying Packets With Link-Layer Addresses		4.1.2. Proxying Packets With Link-Layer Addresses
	Once it is determined that the packet is either		Once it is determined that the packet is either
	multicast/broadcast or else is not locally destined (if unicast),		multicast/broadcast or else is not locally destined (if unicast),
	the special types enumerated above (ARP, etc.) that carry link-		the special types enumerated above (ARP, etc.) that carry link-
	layer addresses are handled by generating a proxy packet that		layer addresses are handled by generating a proxy packet that
	Draft ND Proxy February 2005
	contains the proxy's link-layer address on the outgoing interface		contains the proxy's link-layer address on the outgoing interface
	instead. Section 7, "Guidelines to proxy developers", describes		instead. Section 7, "Guidelines to proxy developers", describes
	the scenarios in which the link-layer address substitution in the		the scenarios in which the link-layer address substitution in the
	payload should be performed.		payload should be performed.
	As with all forwarded packets, the link-layer header is also new.		As with all forwarded packets, the link-layer header is also new.
	Note that any change to the length of a proxied packet, such as		Note that any change to the length of a proxied packet, such as
	when the link-layer address length changes, will require		when the link-layer address length changes, will require
	corresponding changes to fields in the IP header, namely the IPv4		corresponding changes to fields in the IP header, namely the IPv4
	Total Length and Header Checksum fields, or the IPv6 Payload		Total Length and Header Checksum fields, or the IPv6 Payload
	skipping to change at page 9, line 38		skipping to change at page 10, line 4
	locally but no ARP REPLY is generated immediately. Instead, the		locally but no ARP REPLY is generated immediately. Instead, the
	ARP REQUEST is proxied (as described above) and the ARP REPLY will		ARP REQUEST is proxied (as described above) and the ARP REPLY will
	be proxied when it is received. This ensures that the proxy does		be proxied when it is received. This ensures that the proxy does
	not interfere with hosts moving from one segment to another since		not interfere with hosts moving from one segment to another since
	it never responds to an ARP REQUEST based on its own cache.		it never responds to an ARP REQUEST based on its own cache.
	4.1.3.2. ARP REPLY Packets		4.1.3.2. ARP REPLY Packets
	If the received packet is an ARP REPLY, the neighbor cache on the		If the received packet is an ARP REPLY, the neighbor cache on the
	receiving interface is first updated as if the ARP REPLY were		receiving interface is first updated as if the ARP REPLY were
			Draft ND Proxy May 2005
	locally destined, and then the ARP REPLY is proxied as described		locally destined, and then the ARP REPLY is proxied as described
	above.		above.
	4.1.3.3. DHCPv4 Packets		4.1.3.3. DHCPv4 Packets
	If the received packet is a DHCPv4 DISCOVER or REQUEST message,		If the received packet is a DHCPv4 DISCOVER or REQUEST message,
	then instead of changing the client's hardware address in the		then instead of changing the client's hardware address in the
	payload, the BROADCAST (B) flag is set in the proxied packet.		payload, the BROADCAST (B) flag is set in the proxied packet.
	This ensures that the proxy will be able to receive and proxy the		This ensures that the proxy will be able to receive and proxy the
	response since the response will be broadcast rather than unicast		response since the response will be broadcast rather than unicast
	Draft ND Proxy February 2005
	to that hardware address. The hardware address is thus used only		to that hardware address. The hardware address is thus used only
	as a unique identifier and hence need not be a link-layer address		as a unique identifier and hence need not be a link-layer address
	on the same segment.		on the same segment.
	One limitation of this rule is that if the authentication protocol		One limitation of this rule is that if the authentication protocol
	for DHCPv4 described in [DHCPAUTH] is used, only clients that set		for DHCPv4 described in [DHCPAUTH] is used, only clients that set
	the BROADCAST flag themselves will be able to use DHCPv4 through		the BROADCAST flag themselves will be able to use DHCPv4 through
	the proxy. If [DHCPAUTH] is not used, a DHCPv4 client might still		the proxy. If [DHCPAUTH] is not used, a DHCPv4 client might still
	detect, with previously undefined behavior, that the broadcast bit		detect, with previously undefined behavior, that the broadcast bit
	has been changed from the setting in the message originally set by		has been changed from the setting in the message originally set by
	skipping to change at page 10, line 37		skipping to change at page 11, line 5
	4.1.4.1. ICMPv6 Neighbor Solicitations		4.1.4.1. ICMPv6 Neighbor Solicitations
	If the received packet is an ICMPv6 Neighbor Solicitation, the NS		If the received packet is an ICMPv6 Neighbor Solicitation, the NS
	is processed locally as described in section 7.2.3 of [ND] but no		is processed locally as described in section 7.2.3 of [ND] but no
	NA is generated immediately. Instead the NS is proxied as		NA is generated immediately. Instead the NS is proxied as
	described above and the NA will be proxied when it is received.		described above and the NA will be proxied when it is received.
	This ensures that the proxy does not interfere with hosts moving		This ensures that the proxy does not interfere with hosts moving
	from one segment to another since it never responds to an NS based		from one segment to another since it never responds to an NS based
	on its own cache.		on its own cache.
			Draft ND Proxy May 2005
	4.1.4.2. ICMPv6 Neighbor Advertisements		4.1.4.2. ICMPv6 Neighbor Advertisements
	If the received packet is an ICMPv6 Neighbor Advertisement, the		If the received packet is an ICMPv6 Neighbor Advertisement, the
	neighbor cache on the receiving interface is first updated as if		neighbor cache on the receiving interface is first updated as if
	the NA were locally destined, and then the NA is proxied as		the NA were locally destined, and then the NA is proxied as
	described above.		described above.
	4.1.4.3. ICMPv6 Router Advertisements		4.1.4.3. ICMPv6 Router Advertisements
	Unless STP is implemented as described in section 6, the following		Unless RSTP is implemented as described in section 6, the
	special processing is done for IPv6 Router Advertisements (RAs).		following special processing is done for IPv6 Router
			Advertisements (RAs).
	Draft ND Proxy February 2005
	A new "Proxy" bit is defined in the existing Router Advertisement		A new "Proxy" bit is defined in the existing Router Advertisement
	flags field as follows:		flags field as follows:
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|M|O|H|Prf|P|Rsv|		|M|O|H|Prf|P|Rsv|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	where "P" indicates the location of the Proxy bit, and "Rsv		where "P" indicates the location of the Proxy bit, and "Rsv
	indicates the remaining reserved bits.		indicates the remaining reserved bits.
	The proxy determines an "upstream" proxy interface, typically		The proxy determines an "upstream" proxy interface, typically
	skipping to change at page 11, line 32		skipping to change at page 11, line 45
	If an RA with the P bit set has arrived on a given interface		If an RA with the P bit set has arrived on a given interface
	(including the upstream interface) within the last 60 minutes,		(including the upstream interface) within the last 60 minutes,
	that interface MUST NOT be used as a proxy interface; i.e., proxy		that interface MUST NOT be used as a proxy interface; i.e., proxy
	functionality is disabled on that interface.		functionality is disabled on that interface.
	Furthermore, if any RA (regardless of the value of the P bit) has		Furthermore, if any RA (regardless of the value of the P bit) has
	arrived on a "downstream" proxy interface within the last 60		arrived on a "downstream" proxy interface within the last 60
	minutes, that interface MUST NOT be used as a proxy interface.		minutes, that interface MUST NOT be used as a proxy interface.
			If, on the other hand, RSTP is implemented as described in section
			6, no special processing is done for RAs. That is, the P bit is
			ignored, and the P bit is unmodified in RAs proxied to other
			interfaces.
			Draft ND Proxy May 2005
	4.1.4.4. ICMPv6 Redirects		4.1.4.4. ICMPv6 Redirects
	If the received packet is an ICMPv6 Redirect message, then the		If the received packet is an ICMPv6 Redirect message, then the
	proxied packet should be modified as follows. If the proxy has a		proxied packet should be modified as follows. If the proxy has a
	valid (i.e., not INCOMPLETE) neighbor entry for the target address		valid (i.e., not INCOMPLETE) neighbor entry for the target address
	on the same interface as the redirected host, then the TLLA option		on the same interface as the redirected host, then the TLLA option
	in the proxied Redirect simply contains the link-layer address of		in the proxied Redirect simply contains the link-layer address of
	the target as found in the proxy's neighbor entry, since the		the target as found in the proxy's neighbor entry, since the
	redirected host may reach the target address directly. Otherwise,		redirected host may reach the target address directly. Otherwise,
	if the proxy has a valid neighbor entry for the target address on		if the proxy has a valid neighbor entry for the target address on
	some other interface, then the TLLA option in the proxied packet		some other interface, then the TLLA option in the proxied packet
	contains the link-layer address of the proxy on the sending		contains the link-layer address of the proxy on the sending
	interface, since the redirected host must reach the target address		interface, since the redirected host must reach the target address
	through the proxy. Otherwise, the proxy has no valid neighbor		through the proxy. Otherwise, the proxy has no valid neighbor
	entry for the target address, and the proxied packet contains no		entry for the target address, and the proxied packet contains no
	TLLA option, which will cause the redirected host to perform		TLLA option, which will cause the redirected host to perform
	neighbor discovery for the target address.		neighbor discovery for the target address.
	Draft ND Proxy February 2005
	4.2. Originating Packets		4.2. Originating Packets
	Locally originated packets that are sent on a proxy interface also		Locally originated packets that are sent on a proxy interface also
	follow the same rules as packets received on a proxy interface.		follow the same rules as packets received on a proxy interface.
	If no neighbor entry exists when a unicast packet is to be locally		If no neighbor entry exists when a unicast packet is to be locally
	originated, an interface can be chosen in any implementation-		originated, an interface can be chosen in any implementation-
	specific fashion. Once the neighbor is resolved, the actual		specific fashion. Once the neighbor is resolved, the actual
	interface will be discovered and the packet will be sent on that		interface will be discovered and the packet will be sent on that
	interface. When a multicast or broadcast packet is to be locally		interface. When a multicast or broadcast packet is to be locally
	originated, an interface can be chosen in any implementation-		originated, an interface can be chosen in any implementation-
	skipping to change at page 12, line 32		skipping to change at page 13, line 4
	Consider the following topology, where A and B are nodes on		Consider the following topology, where A and B are nodes on
	separate segments which are connected by a bridge-like proxy P:		separate segments which are connected by a bridge-like proxy P:
	A---|---P---|---B		A---|---P---|---B
	a p1 p2 b		a p1 p2 b
	A and B have link-layer addresses a and b, respectively. P has		A and B have link-layer addresses a and b, respectively. P has
	link-layer addresses p1 and p2 on the two segments. We now walk		link-layer addresses p1 and p2 on the two segments. We now walk
	through the actions that happen when A attempts to send an initial		through the actions that happen when A attempts to send an initial
			Draft ND Proxy May 2005
	IPv6 packet to B.		IPv6 packet to B.
	A first does a route lookup on the destination address B. This		A first does a route lookup on the destination address B. This
	matches the on-link subnet prefix, and a destination cache entry		matches the on-link subnet prefix, and a destination cache entry
	is created as well as a neighbor cache entry in the INCOMPLETE		is created as well as a neighbor cache entry in the INCOMPLETE
	state. Before the packet can be sent, A needs to resolve B's		state. Before the packet can be sent, A needs to resolve B's
	link-layer address and sends a Neighbor Solicitation (NS) to the		link-layer address and sends a Neighbor Solicitation (NS) to the
	solicited-node multicast address for B. The SLLA option in the		solicited-node multicast address for B. The SLLA option in the
	solicitation contains A's link-layer address.		solicitation contains A's link-layer address.
	P receives the solicitation (since it is receiving all link-layer		P receives the solicitation (since it is receiving all link-layer
	multicast packets) and processes it as it would any multicast		multicast packets) and processes it as it would any multicast
	packet by forwarding it out to other segments on the link.		packet by forwarding it out to other segments on the link.
	However, before actually sending the packet, it determines if the		However, before actually sending the packet, it determines if the
	packet being sent is one which requires proxying. Since it is an		packet being sent is one which requires proxying. Since it is an
	NS, it creates a neighbor entry for A on interface 1 and records		NS, it creates a neighbor entry for A on interface 1 and records
	its link-layer address. It also creates a neighbor entry for B		its link-layer address. It also creates a neighbor entry for B
	(on an arbitrary proxy interface) in the INCOMPLETE state. Since		(on an arbitrary proxy interface) in the INCOMPLETE state. Since
	the packet is multicast, P then needs to proxy the NS out all		the packet is multicast, P then needs to proxy the NS out all
	Draft ND Proxy February 2005
	other proxy interfaces on the subnet. Before sending the packet		other proxy interfaces on the subnet. Before sending the packet
	out interface 2, it replaces the link-layer address in the SLLA		out interface 2, it replaces the link-layer address in the SLLA
	option with its own link-layer address, p2.		option with its own link-layer address, p2.
	B receives this NS, processing it as usual. Hence it creates a		B receives this NS, processing it as usual. Hence it creates a
	neighbor entry for A mapping it to the link-layer address p2. It		neighbor entry for A mapping it to the link-layer address p2. It
	responds with a Neighbor Advertisement (NA) sent to A containing		responds with a Neighbor Advertisement (NA) sent to A containing
	B's link-layer address b. The NA is sent using A's neighbor		B's link-layer address b. The NA is sent using A's neighbor
	entry, i.e. to the link-layer address p2.		entry, i.e. to the link-layer address p2.
	skipping to change at page 13, line 31		skipping to change at page 14, line 5
	which requires proxying. Since it is an NA, it updates its		which requires proxying. Since it is an NA, it updates its
	neighbor entry for B to be REACHABLE and records the link-layer		neighbor entry for B to be REACHABLE and records the link-layer
	address b. P then replaces the link-layer address in the TLLA		address b. P then replaces the link-layer address in the TLLA
	option with its own link-layer address on the outgoing interface,		option with its own link-layer address on the outgoing interface,
	p1. The packet is then sent out interface 1.		p1. The packet is then sent out interface 1.
	A receives this NA, processing it as usual. Hence it creates a		A receives this NA, processing it as usual. Hence it creates a
	neighbor entry for B on interface 2 in the REACHABLE state and		neighbor entry for B on interface 2 in the REACHABLE state and
	records the link-layer address p1.		records the link-layer address p1.
			Draft ND Proxy May 2005
	6. Loop Prevention		6. Loop Prevention
	An implementation MUST ensure that loops are prevented, via		An implementation MUST ensure that loops are prevented, via
	either:		either:
	a) by using the P bit in RA's as described below, or		a) by using the P bit in RA's as described below, or
	b) by running the Spanning Tree Algorithm and Protocol defined		b) by running the Rapid Spanning Tree Protocol (RSTP) defined in
	in [BRIDGE] on all proxy interfaces as described below, or		[BRIDGE] on all proxy interfaces as described below.
	c) by being physically deployable only in an environment where
	physical loops cannot occur. For example, in a cell phone
	which proxies between a PPP dialup link and a local Ethernet
	interface, it is typically safe to assume that physical loops
	are not possible and hence there is no need to support the
	Spanning Tree Protocol (STP).
	Loop prevention using STP would typically be done by devices that		Loop prevention using RSTP would typically be done by devices that
	already implement this protocol as a result of supporting normal		already implement this protocol as a result of supporting normal
	briding functionality, and is done here as follows. IEEE 802		briding functionality, and is done here as follows. IEEE 802
	Draft ND Proxy February 2005
	interfaces use the protocol exactly as specified in [BRIDGE].		interfaces use the protocol exactly as specified in [BRIDGE].
	Operation of STP over other types of link layers is done by		Operation of RSTP over other types of link layers is done by
	encapsulating the STP frame in an IPv6 header. The Next Header		encapsulating the RSTP frame in an IPv6 header. The Next Header
	field is set to [TBA by IANA], indicating that an STP header		field is set to [TBA by IANA], indicating that an RSTP header
	follows. The Destination Address field is set to the Link-scoped		follows. The Destination Address field is set to the Link-scoped
	STP Multicast Group [TBA by IANA]. All proxies operating on non-		RSTP Multicast Group [TBA by IANA]. All proxies operating on non-
	IEEE 802 media join this group so they will receive STP packets.		IEEE 802 media join this group so they will receive RSTP packets.
	STP packets are never forwarded or proxied.		RSTP packets are never forwarded or proxied.
	Loop avoidance using the P bit in RAs is done as follows. The		Loop avoidance using the P bit in RAs is done as follows. The
	proxy determines an "upstream" proxy interface, typically through		proxy determines an "upstream" proxy interface, typically through
	a physical choice dictated by the scenario (see Scenarios 1 and 2		a physical choice dictated by the scenario (see Scenarios 1 and 2
	above), or through manual configuration. As described in Section		above), or through manual configuration. As described in Section
	4.1.3.3, only the upstream interface is allowed to receive RAs,		4.1.3.3, only the upstream interface is allowed to receive RAs,
	and never from other proxies. Proxy functionality is disabled on		and never from other proxies. Proxy functionality is disabled on
	an interface otherwise. Finally, a proxy MUST wait until it has		an interface otherwise. Finally, a proxy MUST wait until it has
	sent two P bit RAs on a given "downstream" interface before it		sent two P bit RAs on a given "downstream" interface before it
	enables forwarding on that interface.		enables forwarding on that interface.
			Note that it is possible that a site has a mixture of P bit
			proxies and RSTP-capable proxies. To understand how this works,
			consider the case where only P bit proxies are present. However,
			within each link, there may be classic IEEE 802 bridges. Those
			classic bridges are responsible for ensuring that that link is
			loop-free. To P bit proxies, proxies which run RSTP are the same
			in this respect as classic IEEE 802 bridges.
	7. Guidelines to proxy developers		7. Guidelines to proxy developers
	Proxy developers will have to accomodate protocols or protocol		Proxy developers will have to accomodate protocols or protocol
	options (for example, new ICMP messages) that are developed in the		options (for example, new ICMP messages) that are developed in the
			Draft ND Proxy May 2005
	future, or protocols that are not mentioned in this document (for		future, or protocols that are not mentioned in this document (for
	example, proprietary protocols). This section prescribes		example, proprietary protocols). This section prescribes
	guidelines that can be used by proxy developers to accomodate		guidelines that can be used by proxy developers to accomodate
	protocols that are not mentioned herein.		protocols that are not mentioned herein.
	1) If a link-layer address carried in the payload of the		1) If a link-layer address carried in the payload of the
	protocol can be used in the link-layer header of future		protocol can be used in the link-layer header of future
	messages, then the proxy should substitute it with its own		messages, then the proxy should substitute it with its own
	address. For example the link-layer address in NA messages is		address. For example the link-layer address in NA messages is
	used in the link-layer header for future messages, and,		used in the link-layer header for future messages, and,
	hence, the proxy substitutes it with its own address.		hence, the proxy substitutes it with its own address.
	For broadcast/multicast packets, the link-layer address		For broadcast/multicast packets, the link-layer address
	substituted within the payload will be different for each		substituted within the payload will be different for each
	outgoing interface.		outgoing interface.
	2) If the link-layer address in the payload of the protocol will		2) If the link-layer address in the payload of the protocol will
	never be used in any link-layer header, then the proxy should		never be used in any link-layer header, then the proxy should
	not substitute it with its own address. No special actions		not substitute it with its own address. No special actions
	are required for supporting these protocols. For example,		are required for supporting these protocols. For example,
	Draft ND Proxy February 2005
	[DHCPv6] is in this category.		[DHCPv6] is in this category.
	8. IANA Considerations		8. IANA Considerations
	To support loop prevention over non-802 media, IANA should assign:		To support loop prevention over non-802 media, IANA should assign:
	1) a Protocol Number for STP, and		1) a Protocol Number for RSTP, and
	2) an IPv6 Link-Local Scope multicast address for All-STP-		2) an IPv6 Link-Local Scope multicast address for All-RSTP-
	Speakers.		Speakers.
	9. Security Considerations		9. Security Considerations
	Proxies are susceptible to the same kind of security issues that		Proxies are susceptible to the same kind of security issues that
	plague hosts using unsecured Neighbor Discovery or ARP. Even if		plague hosts using unsecured Neighbor Discovery or ARP. Even if
	these protocols are secured, the proxies may process unsecured		these protocols are secured, the proxies may process unsecured
	messages, and update the neighbor cache. Malicious nodes within		messages, and update the neighbor cache. Malicious nodes within
	the subnet can take advantage of this property, and hijack		the subnet can take advantage of this property, and hijack
	traffic. The threats are discussed in detail in [PSREQ].		traffic. The threats are discussed in detail in [PSREQ].
	As a result, securing Neighbor Discovery or ARP must take into		As a result, securing Neighbor Discovery or ARP must take into
	account the ability to proxy messages. This document does not		account the ability to proxy messages. This document does not
			Draft ND Proxy May 2005
	introduce any new requirements in this regard.		introduce any new requirements in this regard.
	From an IPv6 perspective, RFC 2461 [ND] already defines the		From an IPv6 perspective, RFC 2461 [ND] already defines the
	ability to proxy Neighbor Advertisements. Since the ND packets		ability to proxy Neighbor Advertisements. Since the ND packets
	must be modified whenever the link-layer address formats are		must be modified whenever the link-layer address formats are
	different (as with PPP) or promiscuous reception is not possible		different (as with PPP) or promiscuous reception is not possible
	(as with 802.11), securing any solution in this space requires		(as with 802.11), securing any solution in this space requires
	that hosts have a secure relationship with the proxy.		that hosts have a secure relationship with the proxy.
	It is reasonable for nodes on the leaf subnet to have a secure		It is reasonable for nodes on the leaf subnet to have a secure
	skipping to change at page 16, line 4		skipping to change at page 16, line 28
	owner of a specific address (normal SEND), or which it can verify		owner of a specific address (normal SEND), or which it can verify
	are from a trusted proxy (see below).		are from a trusted proxy (see below).
	For nodes on the external subnet, there is a tradeoff between		For nodes on the external subnet, there is a tradeoff between
	security (where all nodes have a secure relationship with the		security (where all nodes have a secure relationship with the
	proxy) and privacy (where no nodes are aware that the proxy is a		proxy) and privacy (where no nodes are aware that the proxy is a
	proxy). In the case of a point-to-point external link (Scenario		proxy). In the case of a point-to-point external link (Scenario
	2) however, SEND may not be a requirement on that link.		2) however, SEND may not be a requirement on that link.
	Verifying that ND packets come from a trusted proxy requires an		Verifying that ND packets come from a trusted proxy requires an
	Draft ND Proxy February 2005
	extension to the SEND protocol and is left for future work, but is		extension to the SEND protocol and is left for future work, but is
	similar to the problem of securing Router Advertisements which is		similar to the problem of securing Router Advertisements which is
	supported today.		supported today.
	10. Appendix A: Comparison with Naive RA Proxy		10. Appendix A: Comparison with Naive RA Proxy
	It has been suggested that a simple Router Advertisement (RA)		It has been suggested that a simple Router Advertisement (RA)
	proxy would be sufficient, where the subnet prefix in an RA is		proxy would be sufficient, where the subnet prefix in an RA is
	"stolen" by the proxy and applied to a downstream link instead of		"stolen" by the proxy and applied to a downstream link instead of
	an upstream link. Other ND messages are not proxied.		an upstream link. Other ND messages are not proxied.
	skipping to change at page 16, line 30		skipping to change at page 17, line 4
	(including the router sending the RA) can have an address in the		(including the router sending the RA) can have an address in the
	subnet or it will not have connectivity with nodes on the		subnet or it will not have connectivity with nodes on the
	downstream link. This is because when a node on a downstream link		downstream link. This is because when a node on a downstream link
	tries to do Neighbor Discovery, and the proxy does not send the NS		tries to do Neighbor Discovery, and the proxy does not send the NS
	on the upstream link, it will never discover the neighbor on the		on the upstream link, it will never discover the neighbor on the
	upstream link. Similarly, if messages are not proxied during DAD,		upstream link. Similarly, if messages are not proxied during DAD,
	conflicts can occur.		conflicts can occur.
	Second, if the proxy assumes that no nodes on the upstream link		Second, if the proxy assumes that no nodes on the upstream link
	have addresses in the prefix, such a proxy could not be safely		have addresses in the prefix, such a proxy could not be safely
			Draft ND Proxy May 2005
	deployed without cooperation from the network administrator since		deployed without cooperation from the network administrator since
	it introduces a requirement that the router itself not have an		it introduces a requirement that the router itself not have an
	address in the prefix. This rules out use in situations where		address in the prefix. This rules out use in situations where
	bridges and Network Address Translators (NATs) are used today,		bridges and Network Address Translators (NATs) are used today,
	which is the problem this document is directly addressing.		which is the problem this document is directly addressing.
	Instead, where a prefix is desired for use on one or more		Instead, where a prefix is desired for use on one or more
	downstream links in cooperation with the network administrator,		downstream links in cooperation with the network administrator,
	Prefix Delegation [PD] should be used instead.		Prefix Delegation [PD] should be used instead.
	11. Authors' Addresses		11. Authors' Addresses
	Dave Thaler		Dave Thaler
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	Phone: +1 425 703 8835		Phone: +1 425 703 8835
	EMail: dthaler@microsoft.com		EMail: dthaler@microsoft.com
	Mohit Talwar		Mohit Talwar
	Microsoft Corporation		Microsoft Corporation
	Draft ND Proxy February 2005
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	Phone: +1 425 705 3131		Phone: +1 425 705 3131
	EMail: mohitt@microsoft.com		EMail: mohitt@microsoft.com
	Chirayu Patel		Chirayu Patel
	All Play, No Work		All Play, No Work
	Bangalore, Karnataka 560038		Bangalore, Karnataka 560038
	Phone: +91-98452-88078		Phone: +91-98452-88078
	EMail: chirayu@chirayu.org		EMail: chirayu@chirayu.org
	12. Normative References		12. Normative References
	[ARP]		[ARP]
	D. Plummer, "An Ethernet Address Resolution Protocol", STD		D. Plummer, "An Ethernet Address Resolution Protocol", STD
	37, RFC 826, November 1982.		37, RFC 826, November 1982.
			[ARPPROXY]
			J. Postel, "Multi-LAN address resolution", RFC 925, October
			1984.
			Draft ND Proxy May 2005
	[BRIDGE]		[BRIDGE]
	T. Jeffree, editor, "Media Access Control (MAC) Bridges",		T. Jeffree, editor, "Media Access Control (MAC) Bridges",
	ANSI/IEEE Std 802.1D, 1998,		ANSI/IEEE Std 802.1D, 2004,
	http://standards.ieee.org/getieee802/download/802.1D-1998.pdf.		http://standards.ieee.org/getieee802/download/802.1D-2004.pdf.
	[DHCPv4]		[DHCPv4]
	R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,		R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[ICMPv6]		[ICMPv6]
	Conta, A. and S. Deering, "Internet Control Message Protocol		Conta, A. and S. Deering, "Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
	[KEYWORDS]		[KEYWORDS]
	S. Bradner, "Key words for use in RFCs to Indicate		S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March, 1997.		Requirement Levels", BCP 14, RFC 2119, March, 1997.
	[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery		[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	Draft ND Proxy February 2005
	[NODEREQ]		[NODEREQ]
	J. Loughney, "IPv6 Node Requirements", Work in progress,		J. Loughney, "IPv6 Node Requirements", Work in progress,
	draft-ietf-ipv6-node-requirements-11.txt, August 2004.		draft-ietf-ipv6-node-requirements-11.txt, August 2004.
	13. Informative References		13. Informative References
	[6TO4]		[6TO4]
	Carpenter, B. and K. Moore, "Connection of IPv6 Domains via		Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
	IPv4 Clouds", RFC 3056, February 2001.		IPv4 Clouds", RFC 3056, February 2001.
	[DHCPAUTH]		[DHCPAUTH]
	Droms, R. and W. Arbaugh, Eds., "Autentication for DHCP		Droms, R. and W. Arbaugh, Eds., "Autentication for DHCP
	Messages", RFC 3118, June 2001.		Messages", RFC 3118, June 2001.
	[DHCPv6]		[DHCPv6]
	Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C.		Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C.
			Draft ND Proxy May 2005
	and M. Carney, "Dynamic Host Configuration Protocol for IPv6		and M. Carney, "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.		(DHCPv6)", RFC 3315, July 2003.
	[NAT]		[NAT]
	Srisuresh, P. and K. Egevang, "Traditional IP Network Address		Srisuresh, P. and K. Egevang, "Traditional IP Network Address
	Translator (Traditional NAT)", RFC 3022, January 2001.		Translator (Traditional NAT)", RFC 3022, January 2001.
	[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host		[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
	Configuration Protocol (DHCP) version 6", RFC 3633, December		Configuration Protocol (DHCP) version 6", RFC 3633, December
	2003.		2003.
	skipping to change at page 19, line 5		skipping to change at page 19, line 29
	Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor		Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
	Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.		Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
	14. Full Copyright Statement		14. Full Copyright Statement
	Copyright (C) The Internet Society (2005). This document is		Copyright (C) The Internet Society (2005). This document is
	subject to the rights, licenses and restrictions contained in BCP		subject to the rights, licenses and restrictions contained in BCP
	78, and except as set forth therein, the authors retain all their		78, and except as set forth therein, the authors retain all their
	rights.		rights.
	Draft ND Proxy February 2005
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.		PARTICULAR PURPOSE.
	15. Intellectual Property		15. Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology		to pertain to the implementation or use of the technology
	described in this document or the extent to which any license		described in this document or the extent to which any license
	under such rights might or might not be available; nor does it		under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any		represent that it has made any independent effort to identify any
	such rights. Information on the procedures with respect to rights		such rights. Information on the procedures with respect to rights
			Draft ND Proxy May 2005
	in RFC documents can be found in BCP 78 and BCP 79.		in RFC documents can be found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention		The IETF invites any interested party to bring to its attention
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/