draft-ietf-ipv6-ndproxy-04.txt		rfc4389.txt
	IPv6 Working Group D. Thaler		Network Working Group D. Thaler
	INTERNET-DRAFT M. Talwar		Request for Comments: 4389 M. Talwar
	October 20, 2005 Microsoft		Category: Experimental Microsoft
	Expires April 2006 C. Patel		C. Patel
	All Play, No Work		All Play, No Work
			April 2006
	Neighbor Discovery Proxies (ND Proxy)		Neighbor Discovery Proxies (ND Proxy)
	<draft-ietf-ipv6-ndproxy-04.txt>
	Status of this Memo
	By submitting this Internet-Draft, each author represents that any		Status of This Memo
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in
	progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This memo defines an Experimental Protocol for the Internet
	http://www.ietf.org/shadow.html.		community. It does not specify an Internet standard of any kind.
			Discussion and suggestions for improvement are requested.
			Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Draft ND Proxy October 2005		Copyright (C) The Internet Society (2006).
	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
	operational advantages. A single subnet prefix is sufficient to		advantages. A single subnet prefix is sufficient to support multiple
	support multiple physical links. There is no need to allocate		physical links. There is no need to allocate subnet numbers to the
	subnet numbers to the different networks, simplifying management.		different networks, simplifying management. Bridging some types of
	Bridging some types of media requires network-layer support,		media requires network-layer support, however. This document
	however. This document describes these cases and specifies the		describes these cases and specifies the IP-layer support that enables
	IP-layer support that enables bridging under these circumstances.		bridging under these circumstances.
			Table of Contents
			1. Introduction ....................................................3
			1.1. SCENARIO 1: Wireless Upstream ..............................3
			1.2. SCENARIO 2: PPP Upstream ...................................4
			1.3. Inapplicable Scenarios .....................................5
			2. Terminology .....................................................5
			3. Requirements ....................................................5
			3.1. Non-requirements ...........................................6
			4. Proxy Behavior ..................................................7
			4.1. Forwarding Packets .........................................7
			4.1.1. Sending Packet Too Big Messages .....................8
			4.1.2. Proxying Packets with Link-Layer Addresses ..........8
			4.1.3. IPv6 ND Proxying ....................................9
			4.1.3.1. ICMPv6 Neighbor Solicitations ..............9
			4.1.3.2. ICMPv6 Neighbor Advertisements .............9
			4.1.3.3. ICMPv6 Router Advertisements ...............9
			4.1.3.4. ICMPv6 Redirects ..........................10
			4.2. Originating Packets .......................................10
			5. Example ........................................................11
			6. Loop Prevention ................................................12
			7. Guidelines to Proxy Developers .................................12
			8. IANA Considerations ............................................13
			9. Security Considerations ........................................13
			10. Acknowledgements ..............................................14
			11. Normative References ..........................................14
			12. Informative References ........................................15
			Appendix A: Comparison with Naive RA Proxy ........................16
	1. Introduction		1. Introduction
	In the IPv4 Internet today, it is common for Network Address		In the IPv4 Internet today, it is common for Network Address
	Translators (NATs) [NAT] to be used to easily connect one or more		Translators (NATs) [NAT] to be used to easily connect one or more
	leaf links to an existing network without requiring any		leaf links to an existing network without requiring any coordination
	coordination with the network service provider. Since NATs modify		with the network service provider. Since NATs modify IP addresses in
	IP addresses in packets, they are problematic for many IP		packets, they are problematic for many IP applications. As a result,
	applications. As a result, it is desirable to address the problem		it is desirable to address the problem (for both IPv4 and IPv6)
	(for both IPv4 and IPv6) without the need for NATs, while still		without the need for NATs, while still maintaining the property that
	maintaining the property that no explicit cooperation from the		no explicit cooperation from the router is needed.
	router is needed.
	One common solution is IEEE 802 bridging, as specified in		One common solution is IEEE 802 bridging, as specified in [BRIDGE].
	[BRIDGE]. It is expected that whenever possible links will be		It is expected that whenever possible links will be bridged at the
	bridged at the link layer using classic bridge technology [BRIDGE]		link layer using classic bridge technology [BRIDGE] as opposed to
	as opposed to using the mechanisms herein. However, classic		using the mechanisms herein. However, classic bridging at the data-
	bridging at the data-link layer has the following limitations		link layer has the following limitations (among others):
	(among others):
	o It requires the ports to support promiscuous mode.		o It requires the ports to support promiscuous mode.
	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,
	solved, and it is these two scenarios we specifically target in		and it is these two scenarios we specifically target in this
	this document. While the mechanism described herein may apply to		document. While the mechanism described herein may apply to other
	other scenarios as well, we will concentrate our discussion on		scenarios as well, we will concentrate our discussion on these two
	these two scenarios.		scenarios.
	Draft ND Proxy October 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 |
	| +-------+ +--------+		| +-------+ +--------+
	In this scenario, the access point has assigned an IPv6 subnet		In this scenario, the access point has assigned an IPv6 subnet prefix
	prefix to the wireless link, and uses link-layer encryption so		to the wireless link, and uses link-layer encryption so that wireless
	that wireless clients may not see each other's data.		clients may not see each other's data.
	Classic bridging requires the bridge (node A in the above diagram)
	to be in promiscuous mode. In this wireless scenario, A cannot
	put its wireless interface into promiscuous mode, since one
	wireless node cannot see traffic to/from other wireless nodes.
	IPv4 ARP proxying has been used for some years to solve this		Classic bridging requires the bridge (node A in the above diagram) to
	problem without involving NAT or requiring any change to the		be in promiscuous mode. In this wireless scenario, A cannot put its
	access point or router. In this document, we describe equivalent		wireless interface into promiscuous mode, since one wireless node
	functionality for IPv6 to remove this incentive to deploy NATs in		cannot see traffic to/from other wireless nodes.
	IPv6.
	We also note that Prefix Delegation [PD] could also be used to		IPv4 Address Resolution Protocol (ARP) proxying has been used for
	solve this scenario. There are, however, two disadvantages to		some years to solve this problem without involving NAT or requiring
	this. First, if an implementation already supports IPv4 ARP		any change to the access point or router. In this document, we
	proxying (which is indeed the case in a number of implementations		describe equivalent functionality for IPv6 to remove this incentive
	today), then IPv6 Prefix Delegation would result in separate IPv6		to deploy NATs in IPv6.
	subnets on either side of the device, while a single IPv4 subnet
	would span both segments. This topological discrepancy can
	complicate applications and protocols which use the concept of a
	local subnet. Secondly, the extent to which Prefix Delegation is
	supported, and supported without additional charge, is up to the
	service provider. Hence, there is no guarantee that Prefix
	Delegation will work without explicit configuration or additional
	charge. Bridging, on the other hand, allows the device to work
	with zero configuration, regardless of the service provider's
	policies, just as a NAT does. Hence bridging avoids the incentive
	to NAT IPv6 just to avoid paying for, or requiring configuration
	to get, another prefix.
	Draft ND Proxy October 2005		We also note that Prefix Delegation [PD] could also be used to solve
			this scenario. There are, however, two disadvantages to this.
			First, if an implementation already supports IPv4 ARP proxying (which
			is indeed the case in a number of implementations today), then IPv6
			Prefix Delegation would result in separate IPv6 subnets on either
			side of the device, while a single IPv4 subnet would span both
			segments. This topological discrepancy can complicate applications
			and protocols that use the concept of a local subnet. Second, the
			extent to which Prefix Delegation is supported for any particular
			subscriber class is up to the service provider. Hence, there is no
			guarantee that Prefix Delegation will work without explicit
			configuration or additional charge. Bridging, on the other hand,
			allows the device to work with zero configuration, regardless of the
			service provider's policies, just as a NAT does. Hence bridging
			avoids the incentive to NAT IPv6 just to avoid paying for, or
			requiring configuration to get, another prefix.
	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 has assigned a /64 to the PPP link		In this scenario, the router has assigned a /64 to the PPP link and
	and advertises it in an IPv6 Router Advertisement.		advertises it in an IPv6 Router Advertisement.
	Classic bridging does not support non-802 media. The PPP Bridging		Classic bridging does not support non-802 media. The PPP Bridging
	Control Protocol [BCP] defines a mechanism for supporting bridging		Control Protocol [BCP] defines a mechanism for supporting bridging
	over PPP, but it requires both ends to be configured to support		over PPP, but it requires both ends to be configured to support it.
	it. Hence IPv4 connectivity is often solved by making the proxy		Hence IPv4 connectivity is often solved by making the proxy (node A
	(node A in the above diagram) be a NAT or an IPv4 ARP Proxy. This		in the above diagram) be a NAT or an IPv4 ARP proxy. This document
	document specifies a solution for IPv6 which does not involve NAT		specifies a solution for IPv6 that does not involve NAT or require
	or require any change to the router.		any change to the router.
	1.3. Inapplicable Scenarios		1.3. Inapplicable Scenarios
	This document is not applicable to scenarios with loops in the		This document is not applicable to scenarios with loops in the
	physical topology, or where routers exist on multiple segments.		physical topology, or where routers exist on multiple segments.
	These cases are detected and proxying is disabled (see Section 6).		These cases are detected and proxying is disabled (see Section 6).
	In addition, this document is not appropriate for scenarios where		In addition, this document is not appropriate for scenarios where
	classic bridging can be applied, or when configuration of the		classic bridging can be applied, or when configuration of the router
	router can be done.		can be done.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	in this document are to be interpreted as described in BCP 14, RFC		document are to be interpreted as described in BCP 14, RFC 2119
	2119 [KEYWORDS].		[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
	layer proxying is done as defined herein.		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
	apply to a bridged component of the link.		apply to a bridged component of the link.
	Draft ND Proxy October 2005		Finally, while it is possible that functionality equivalent to that
			described herein may be achieved by nodes that do not fulfill all the
	Finally, while it is possible that functionality equivalent to		requirements in [NODEREQ], in the remainder of this document we will
	that described herein may be achieved by nodes which do not		describe behavior in terms of an IPv6 node as defined in that
	fulfill all the requirements in [NODEREQ], in the remainder of		document.
	this document we will describe behavior in terms of an IPv6 node
	as defined in that document.
	3. Requirements		3. Requirements
	Proxy behavior is designed with the following requirements in		Proxy behavior is designed with the following requirements in mind:
	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 that cannot be bridged at the link layer.
	o Do not require any changes to existing routers. That is,		o Do not require any changes to existing routers. That is,
	routers on the subnet may be unaware that the subnet is being		routers on the subnet may be unaware that the subnet is being
	bridged.		bridged.
	o Provide full connectivity between all nodes in the subnet.		o Provide full connectivity between all nodes in the subnet.
	For example, if there are existing nodes (such as any routers		For example, if there are existing nodes (such as any routers
	on the subnet) which have addresses in the subnet prefix,		on the subnet) that have addresses in the subnet prefix,
	adding a proxy must allow bridged nodes to have full		adding a proxy must allow bridged nodes to have full
	connectivity with existing nodes on the subnet.		connectivity with existing nodes on the subnet.
	o Prevent loops.		o Prevent loops.
	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.
	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.
	Draft ND Proxy October 2005
	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
	not met by classic bridges:		met by classic bridges:
	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.
	skipping to change at page 6, line 37		skipping to change at page 7, line 8
	The following additional items are not considered requirements for		The following additional items are not considered requirements for
	this document:		this document:
	o Support network-layer protocols other than IPv6. We do not		o Support network-layer protocols other than IPv6. We do not
	preclude such support, but it is not specified in this		preclude such support, but it is not specified in this
	document.		document.
	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 that 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.
	4. Proxy Behavior		4. Proxy Behavior
	Network layer support for proxying between multiple interfaces		Network-layer support for proxying between multiple interfaces SHOULD
	SHOULD be used only when classic bridging is not possible.		be used only when classic bridging is not possible.
	When a proxy interface comes up, the node puts it in "all-
	multicast" mode so that it will receive all multicast packets. It
	is common for interfaces to not support full promiscuous mode
	(e.g., on a wireless client), but all-multicast mode is generally
	still supported.
	Draft ND Proxy October 2005		When a proxy interface comes up, the node puts it in "all-multicast"
			mode so that it will receive all multicast packets. It is common for
			interfaces not to support full promiscuous mode (e.g., on a wireless
			client), but all-multicast mode is generally still supported.
	As with all other interfaces, IPv6 maintains a neighbor cache for		As with all other interfaces, IPv6 maintains a neighbor cache for
	each proxy interface, which will be used as described below.		each proxy interface, which will be used as described below.
	4.1. Forwarding Packets		4.1. Forwarding Packets
	When a packet from any IPv6 source address other than the		When a packet from any IPv6 source address other than the unspecified
	unspecified address is received on a proxy interface, the neighbor		address is received on a proxy interface, the neighbor cache of that
	cache of that interface SHOULD be consulted to find an entry for		interface SHOULD be consulted to find an entry for the source IPv6
	the source IPv6 address. If no entry exists, one is created in		address. If no entry exists, one is created in the STALE state.
	the STALE state.
	When any IPv6 packet is received on a proxy interface, it must be		When any IPv6 packet is received on a proxy interface, it must be
	parsed to see whether it is known to be of a type that negotiates		parsed to see whether it is known to be of a type that negotiates
	link-layer addresses. This document covers the following types:		link-layer addresses. This document covers the following types:
	Neighbor Solicitations, Neighbor Advertisements, Router		Neighbor Solicitations, Neighbor Advertisements, Router
	Advertisements, and Redirects. These packets are ones that can		Advertisements, and Redirects. These packets are ones that can carry
	carry link-layer addresses, and hence must be proxied (as		link-layer addresses, and hence must be proxied (as described below)
	described below) so that packets between nodes on different		so that packets between nodes on different segments can be received
	segments can be received by the proxy and have the correct link-		by the proxy and have the correct link-layer address type on each
	layer address type on each segment.		segment.
	When any other IPv6 multicast packet is received on a proxy		When any other IPv6 multicast packet is received on a proxy
	interface, in addition to any normal IPv6 behavior such as being		interface, in addition to any normal IPv6 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
	new link-layer header) out all other proxy interfaces on the same		link-layer header) out all other proxy interfaces on the same link.
	link. (As specified in [BRIDGE], the proxy may instead support		(As specified in [BRIDGE], the proxy may instead support multicast
	multicast learning and filtering but this is OPTIONAL.) In		learning and filtering, but this is OPTIONAL.) In particular, the
	particular, the IPv6 Hop Limit is not updated, and no ICMP errors		IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in
	(except as noted in Section 4.1.1 below) are sent as a result of		Section 4.1.1 below) are sent as a result of attempting this
	attempting this forwarding.		forwarding.
	When any other IPv6 unicast packet is received on a proxy
	interface, if it is not locally destined then it is forwarded
	unchanged (other than using a new link-layer header) to the proxy
	interface for which the next hop address appears in the neighbor
	cache. Again the IPv6 Hop Limit is not updated, and no ICMP
	errors (except as noted in Section 4.1.1 below) are sent as a
	result of attempting this forwarding. To choose a proxy 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
	least to most preferred, the states (per [ND]) are INCOMPLETE,
	STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back
	out the same interface on which it arrived; such a packet is
	instead silently dropped.
	Draft ND Proxy October 2005		When any other IPv6 unicast packet is received on a proxy interface,
			if it is not locally destined then it is forwarded unchanged (other
			than using a new link-layer header) to the proxy interface for which
			the next hop address appears in the neighbor cache. Again the IPv6
			Hop Limit is not updated, and no ICMP errors (except as noted in
			Section 4.1.1 below) are sent as a result of attempting this
			forwarding. To choose a proxy 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 least to most preferred, the
			states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE. A
			packet is never forwarded back out the same interface on which it
			arrived; such a packet is 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
	previously evicted the cache entry or if the proxy is restarted),		evicted the cache entry or if the proxy is restarted), the proxy
	the proxy SHOULD queue the packet and initiate Neighbor Discovery		SHOULD queue the packet and initiate Neighbor Discovery as if the
	as if the packet were being locally generated. The proxy MAY		packet were being locally generated. The proxy MAY instead silently
	instead silently drop the packet. In this case, the entry will		drop the packet. In this case, the entry will eventually be re-
	eventually be recreated when the sender re-attempts neighbor		created when the sender re-attempts Neighbor Discovery.
	discovery.
	The link layer header, and the link-layer address within the		The link-layer header and the link-layer address within the payload
	payload for each forwarded packet will be modified as follows:		for each forwarded packet will be modified as follows:
	1) The source address will be the address of the outgoing		1) The source address will be the address of the outgoing
	interface.		interface.
	2) The destination address will be the address in the neighbor		2) The destination address will be the address in the neighbor
	entry corresponding to the destination IPv6 address.		entry corresponding to the destination IPv6 address.
	3) The link-layer address within the payload is substituted with		3) The link-layer address within the payload is substituted with
	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 IPv6 packet is to be forwarded out an interface whose		Whenever any IPv6 packet is to be forwarded out an interface whose
	MTU is smaller than the size of the packet, the ND proxy drops the		MTU is smaller than the size of the packet, the ND proxy drops the
	packet and sends a Packet Too Big message back to the source, as		packet and sends a Packet Too Big message back to the source, as
	described in [ICMPv6].		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 multicast or else
	is not locally destined (if unicast), the special types enumerated
	above (ARP, etc.) that carry link-layer addresses are handled by
	generating a proxy packet that contains the proxy's link-layer
	address on the outgoing interface instead. Such link-layer
	addresses occur in the link-layer header itself, as well as in the
	payloads of some protocols. As with all forwarded packets, the
	link-layer header is new.
	Section 4.1.3 enumerates the currently known cases where link-
	layer addresses must be changed in payloads. For guidance on
	handling future protocols, Section 7, "Guidelines to proxy
	developers", describes the scenarios in which the link-layer
	address substitution in the payload should be performed. Note
	Draft ND Proxy October 2005		Once it is determined that the packet is either multicast or else is
			not locally destined (if unicast), the special types enumerated above
			(ARP, etc.) that carry link-layer addresses are handled by generating
			a proxy packet that contains the proxy's link-layer address on the
			outgoing interface instead. Such link-layer addresses occur in the
			link-layer header itself, as well as in the payloads of some
			protocols. As with all forwarded packets, the link-layer header is
			new.
	that any change to the length of a proxied packet, such as when		Section 4.1.3 enumerates the currently known cases where link-layer
	the link-layer address length changes, will require a		addresses must be changed in payloads. For guidance on handling
	corresponding change to the IPv6 Payload Length field.		future protocols, Section 7, "Guidelines to Proxy Developers",
			describes the scenarios in which the link-layer address substitution
			in the payload should be performed. Note that any change to the
			length of a proxied packet, such as when the link-layer address
			length changes, will require a corresponding change to the IPv6
			Payload Length field.
	4.1.3. IPv6 ND Proxying		4.1.3. IPv6 ND Proxying
	When any IPv6 packet is received on a proxy interface, it must be		When any IPv6 packet is received on a proxy interface, it must be
	parsed to see whether it is known to be one of the following		parsed to see whether it is known to be one of the following types:
	types: Neighbor Solicitation, Neighbor Advertisement, Router		Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
	Advertisement, or Redirect.		or Redirect.
	4.1.3.1. ICMPv6 Neighbor Solicitations		4.1.3.1. ICMPv6 Neighbor Solicitations
	If the received packet is an ICMPv6 Neighbor Solicitation (NS),		If the received packet is an ICMPv6 Neighbor Solicitation (NS), the
	the NS is processed locally as described in section 7.2.3 of [ND]		NS is processed locally as described in Section 7.2.3 of [ND] but no
	but no NA is generated immediately. Instead the NS is proxied as		NA is generated immediately. Instead the NS is proxied as described
	described above and the NA will be proxied when it is received.		above and the NA will be proxied when it is received. This ensures
	This ensures that the proxy does not interfere with hosts moving		that the proxy does not interfere with hosts moving from one segment
	from one segment to another since it never responds to an NS based		to another since it never responds to an NS based on its own cache.
	on its own cache.
	4.1.3.2. ICMPv6 Neighbor Advertisements		4.1.3.2. ICMPv6 Neighbor Advertisements
	If the received packet is an ICMPv6 Neighbor Advertisement (NA),		If the received packet is an ICMPv6 Neighbor Advertisement (NA), the
	the neighbor cache on the receiving interface is first updated as		neighbor cache on the receiving interface is first updated as if the
	if the NA were locally destined, and then the NA is proxied as		NA were locally destined, and then the NA is proxied as described in
	described in 4.1.2 above.		4.1.2 above.
	4.1.3.3. ICMPv6 Router Advertisements		4.1.3.3. ICMPv6 Router Advertisements
	The following special processing is done for IPv6 Router		The following special processing is done for IPv6 Router
	Advertisements (RAs).		Advertisements (RAs).
	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.
	Draft ND Proxy October 2005		The proxy determines an "upstream" proxy interface, typically through
			a (zero-configuration) physical choice dictated by the scenario (see
	The proxy determines an "upstream" proxy interface, typically		Scenarios 1 and 2 above), or through manual configuration.
	through a (zero-configuration) physical choice dictated by the
	scenario (see Scenarios 1 and 2 above), or through manual
	configuration.
	When an RA with the P bit clear arrives on the upstream interface,		When an RA with the P bit clear arrives on the upstream interface,
	the P bit is set when the RA is proxied out all other		the P bit is set when the RA is proxied out all other ("downstream")
	("downstream") proxy interfaces (see section 6).		proxy interfaces (see Section 6).
	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
	that interface MUST NOT be used as a proxy interface; i.e., proxy		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,
	minutes, that interface MUST NOT be used as a proxy interface.		that interface MUST NOT be used as a proxy interface.
	The RA is processed locally as well as proxied as described in		The RA is processed locally as well as proxied as described in
	section 4.1.2, unless such proxying is disabled as noted above.		Section 4.1.2, unless such proxying is disabled as noted above.
	4.1.3.4. ICMPv6 Redirects		4.1.3.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
	on the same interface as the redirected host, then the TLLA option		the same interface as the redirected host, then the Target Link-Layer
	in the proxied Redirect simply contains the link-layer address of		Address (TLLA) option in the proxied Redirect simply contains the
	the target as found in the proxy's neighbor entry, since the		link-layer address of the target as found in the proxy's neighbor
	redirected host may reach the target address directly. Otherwise,		entry, since the redirected host may reach the target address
	if the proxy has a valid neighbor entry for the target address on		directly. Otherwise, if the proxy has a valid neighbor entry for the
	some other interface, then the TLLA option in the proxied packet		target address on some other interface, then the TLLA option in the
	contains the link-layer address of the proxy on the sending		proxied packet contains the link-layer address of the proxy on the
	interface, since the redirected host must reach the target address		sending interface, since the redirected host must reach the target
	through the proxy. Otherwise, the proxy has no valid neighbor		address through the proxy. Otherwise, the proxy has no valid
	entry for the target address, and the proxied packet contains no		neighbor entry for the target address, and the proxied packet
	TLLA option, which will cause the redirected host to perform		contains no TLLA option, which will cause the redirected host to
	neighbor discovery for the target address.		perform Neighbor Discovery for the target address.
	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
	Draft ND Proxy October 2005		originated, an interface can be chosen in any implementation-specific
			fashion. Once the neighbor is resolved, the actual interface will be
	If no neighbor entry exists when a unicast packet is to be locally		discovered and the packet will be sent on that interface. When a
	originated, an interface can be chosen in any implementation-		multicast packet is to be locally originated, an interface can be
	specific fashion. Once the neighbor is resolved, the actual		chosen in any implementation-specific fashion, and the packet will
	interface will be discovered and the packet will be sent on that		then be forwarded out other proxy interfaces on the same link as
	interface. When a multicast packet is to be locally originated,		described in Section 4.1 above.
	an interface can be chosen in any implementation-specific fashion,
	and the packet will then be forwarded out other proxy interfaces
	on the same link as described in Section 4.1 above.
	5. Example		5. Example
	Consider the following topology, where A and B are nodes on		Consider the following topology, where A and B are nodes on separate
	separate segments which are connected by a proxy P:		segments which are connected by a 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
	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
	is created as well as a neighbor cache entry in the INCOMPLETE		created as well as a neighbor cache entry in the INCOMPLETE state.
	state. Before the packet can be sent, A needs to resolve B's		Before the packet can be sent, A needs to resolve B's link-layer
	link-layer address and sends a Neighbor Solicitation (NS) to the		address and sends a Neighbor Solicitation (NS) to the solicited-node
	solicited-node multicast address for B. The SLLA option in the		multicast address for B. The Source Link-Layer Address (SLLA) option
	solicitation contains A's link-layer address.		in the 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
	packet by forwarding it out to other segments on the link.		by forwarding it out to other segments on the link. However, before
	However, before actually sending the packet, it determines if the		actually sending the packet, it determines if the packet being sent
	packet being sent is one which requires proxying. Since it is an		is one that requires proxying. Since it is an NS, it creates a
	NS, it creates a neighbor entry for A on interface 1 and records		neighbor entry for A on interface 1 and records its link-layer
	its link-layer address. It also creates a neighbor entry for B		address. It also creates a neighbor entry for B (on an arbitrary
	(on an arbitrary proxy interface) in the INCOMPLETE state. Since		proxy interface) in the INCOMPLETE state. Since the packet is
	the packet is multicast, P then needs to proxy the NS out all		multicast, P then needs to proxy the NS out all other proxy
	other proxy interfaces on the subnet. Before sending the packet		interfaces on the subnet. Before sending the packet out interface 2,
	out interface 2, it replaces the link-layer address in the SLLA		it replaces the link-layer address in the SLLA option with its own
	option with its own link-layer address, p2.		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
	Draft ND Proxy October 2005
	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
	B's link-layer address b. The NA is sent using A's neighbor		link-layer address b. The NA is sent using A's neighbor entry, i.e.,
	entry, i.e. to the link-layer address p2.		to the link-layer address p2.
	The NA is received by P, which then processes it as it would any		The NA is received by P, which then processes it as it would any
	unicast packet; i.e., it forwards this out interface 1, based on		unicast packet; i.e., it forwards this out interface 1, based on the
	the neighbor cache. However, before actually sending the packet		neighbor cache. However, before actually sending the packet out, it
	out, it inspects it to determine if the packet being sent is one		inspects it to determine if the packet being sent is one that
	which requires proxying. Since it is an NA, it updates its		requires proxying. Since it is an NA, it updates its neighbor entry
	neighbor entry for B to be REACHABLE and records the link-layer		for B to be REACHABLE and records the link-layer address b. P then
	address b. P then replaces the link-layer address in the TLLA		replaces the link-layer address in the TLLA option with its own
	option with its own link-layer address on the outgoing interface,		link-layer address on the outgoing interface, p1. The packet is then
	p1. The packet is then sent out interface 1.		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.
	6. Loop Prevention		6. Loop Prevention
	An implementation MUST ensure that loops are prevented by using		An implementation MUST ensure that loops are prevented by using the P
	the P bit in RA's as follows. The proxy determines an "upstream"		bit in RAs as follows. The proxy determines an "upstream" proxy
	proxy interface, typically through a (zero-configuration) physical		interface, typically through a (zero-configuration) physical choice
	choice dictated by the scenario (see Scenarios 1 and 2 above), or		dictated by the scenario (see Scenarios 1 and 2 above), or through
	through manual configuration. As described in Section 4.1.3.3,		manual configuration. As described in Section 4.1.3.3, only the
	only the upstream interface is allowed to receive RAs, and never		upstream interface is allowed to receive RAs, and never from other
	from other proxies. Proxy functionality is disabled on an		proxies. Proxy functionality is disabled on an interface otherwise.
	interface otherwise. Finally, a proxy MUST wait until it has sent		Finally, a proxy MUST wait until it has sent two P bit RAs on a given
	two P bit RAs on a given "downstream" interface before it enables		"downstream" interface before it enables forwarding on that
	forwarding on that interface.		interface.
	7. Guidelines to proxy developers		7. Guidelines to Proxy Developers
	Proxy developers will have to accomodate protocols or protocol		Proxy developers will have to accommodate 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
	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
	guidelines that can be used by proxy developers to accomodate		that can be used by proxy developers to accommodate protocols that
	protocols that are not mentioned herein.		are not mentioned herein.
	Draft ND Proxy October 2005
	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 multicast packets, the link-layer address substituted		For multicast packets, the link-layer address substituted
	within the payload will be different for each outgoing		within the payload will be different for each outgoing
	interface.		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,
	[DHCPv6] is in this category.		[DHCPv6] is in this category.
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		This document defines a new bit in the RA flags (the P bit). There
			is currently no registration procedure for such bits, so IANA should
			not take any action.
	9. Security Considerations		9. Security Considerations
	Unsecured Neighbor Discovery has a number of security issues which		Unsecured Neighbor Discovery has a number of security issues, which
	are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines		are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security
	security mechanisms that can protect Neighbor Discovery.		mechanisms that can protect Neighbor Discovery.
	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. These issues		plague hosts using unsecured Neighbor Discovery. These issues
	include hijacking traffic and denial-of-service within the subnet.		include hijacking traffic and denial-of-service within the subnet.
	Malicious nodes within the subnet can take advantage of this		Malicious nodes within the subnet can take advantage of this
	property, and hijack traffic. In addition, a Neighbor Discovery		property, and hijack traffic. In addition, a Neighbor Discovery
	proxy is essentially a legitimate man-in-the-middle, which implies		proxy is essentially a legitimate man-in-the-middle, which implies
	that there is a need to distinguish proxies from unwanted man-in-		that there is a need to distinguish proxies from unwanted man-in-
	the-middle attackers.		the-middle attackers.
	This document does not introduce any new mechanisms for the		This document does not introduce any new mechanisms for the
	protection of proxy neighbor discovery. That is, it does not		protection of proxy Neighbor Discovery. That is, it does not provide
	provide a mechanism from authorizing certain devices to act as		a mechanism from authorizing certain devices to act as proxies, and
	proxies, and it does not provide extensions to SEND to make it		it does not provide extensions to SEND to make it possible to use
	possible to use both SEND and proxies at the same time. We note		both SEND and proxies at the same time. We note that RFC 2461 [ND]
	that RFC 2461 [ND] already defines the ability to proxy Neighbor		already defines the ability to proxy Neighbor Advertisements, and
	Advertisements, and extensions to SEND are already needed to cover		extensions to SEND are already needed to cover that case, independent
			of this document.
	Draft ND Proxy October 2005
	that case, independent of this document.
	Note also that the use of proxy Neighbor Discovery may render it		Note also that the use of proxy Neighbor Discovery may render it
	impossible to use SEND both on the leaf subnet and on the external		impossible to use SEND both on the leaf subnet and on the external
	subnet. This because the modifications performed by the proxy		subnet. This is because the modifications performed by the proxy
	will invalidate the RSA Signature Option in a secured Neighbor		will invalidate the RSA Signature Option in a secured Neighbor
	Discovery message, and cause SEND-capable nodes to either discard		Discovery message, and cause SEND-capable nodes to either discard the
	the messages or treat them as unsecured. The latter is the		messages or treat them as unsecured. The latter is the desired
	desired operation when SEND is used together with this		operation when SEND is used together with this specification, and it
	specification, and ensures that SEND nodes within this environment		ensures that SEND nodes within this environment can selectively
	can selectively downgrade themselves to unsecure Neighbor		downgrade themselves to unsecure Neighbor Discovery when proxies are
	Discovery when proxies are present.		present.
	In the following we outline some potential paths to follow when		In the following, we outline some potential paths to follow when
	defining a secure proxy mechanism.		defining a secure proxy mechanism.
	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
	relationship with the proxy, and accept ND packets from either the		relationship with the proxy and to accept ND packets either from the
	owner of a specific address (normal SEND), or which it can verify		owner of a specific address (normal SEND) or from a trusted proxy
	are from a trusted proxy (see below).		that it can verify (see below).
	For nodes on the external subnet, there is a tradeoff between		For nodes on the external subnet, there is a trade-off between
	security (where all nodes have a secure relationship with the		security (where all nodes have a secure relationship with the proxy)
	proxy) and privacy (where no nodes are aware that the proxy is a		and privacy (where no nodes are aware that the proxy is a proxy). In
	proxy). In the case of a point-to-point external link (Scenario		the case of a point-to-point external link (Scenario 2), however,
	2) however, SEND may not be a requirement on that link.		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
	extension to the SEND protocol and is left for future work [SPND],		extension to the SEND protocol and is left for future work [SPND],
	but is similar to the problem of securing Router Advertisements		but is similar to the problem of securing Router Advertisements that
	which is supported today. For example, a rogue node can send a		is supported today. For example, a rogue node can send a Router
	Router Advertisement to cause a proxy to disable its proxy		Advertisement to cause a proxy to disable its proxy behavior, and
	behavior, and hence cause denial-of-service to other nodes; this		hence cause denial-of-service to other nodes; this threat is covered
	threat is covered in section 4.2.1 of [PSREQ].		in Section 4.2.1 of [PSREQ].
	Alternative designs might involve schemes where the right for		Alternative designs might involve schemes where the right for
	representing a particular host is delegated to the proxy, or where		representing a particular host is delegated to the proxy, or where
	multiple nodes can make statements on behalf of one address		multiple nodes can make statements on behalf of one address
	[RINGSIG].		[RINGSIG].
	10. Appendix A: Comparison with Naive RA Proxy		10. Acknowledgements
	It has been suggested that a simple Router Advertisement (RA)
	proxy would be sufficient, where the subnet prefix in an RA is
	Draft ND Proxy October 2005
	"stolen" by the proxy and applied to a downstream link instead of		The authors wish to thank Jari Arkko for contributing portions of the
	an upstream link. Other ND messages are not proxied.		Security Considerations text.
	There are many problems with this approach. First, it requires		11. Normative References
	cooperation from all nodes on the upstream link. No node
	(including the router sending the RA) can have an address in the
	subnet or it will not have connectivity with nodes on the
	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
	on the upstream link, it will never discover the neighbor on the
	upstream link. Similarly, if messages are not proxied during DAD,
	conflicts can occur.
	Second, if the proxy assumes that no nodes on the upstream link		[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges",
	have addresses in the prefix, such a proxy could not be safely		ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/
	deployed without cooperation from the network administrator since		getieee802/download/802.1D-2004.pdf.
	it introduces a requirement that the router itself not have an
	address in the prefix. This rules out use in situations where
	bridges and Network Address Translators (NATs) are used today,
	which is the problem this document is directly addressing.
	Instead, where a prefix is desired for use on one or more
	downstream links in cooperation with the network administrator,
	Prefix Delegation [PD] should be used instead.
	11. Acknowledgements		[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
			Protocol (ICMPv6) for the Internet Protocol Version 6
			(IPv6) Specification", RFC 2463, December 1998.
	The authors wish to thank Jari Arkko for contributing portions of		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	the Security Considerations text.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	12. Authors' Addresses		[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
			Discovery for IP Version 6 (IPv6)", RFC 2461, December
			1998.
	Dave Thaler		[NODEREQ] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,
	Microsoft Corporation		April 2006.
	One Microsoft Way
	Redmond, WA 98052-6399
	Phone: +1 425 703 8835
	EMail: dthaler@microsoft.com
	Mohit Talwar		12. Informative References
	Microsoft Corporation
	One Microsoft Way
	Redmond, WA 98052-6399
	Phone: +1 425 705 3131
	Draft ND Proxy October 2005		[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
			via IPv4 Clouds", RFC 3056, February 2001.
	EMail: mohitt@microsoft.com		[BCP] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point
			Protocol (PPP) Bridging Control Protocol (BCP)", RFC
			3518, April 2003.
	Chirayu Patel		[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	All Play, No Work		C., and M. Carney, "Dynamic Host Configuration Protocol
	Bangalore, Karnataka 560038		for IPv6 (DHCPv6)", RFC 3315, July 2003.
	Phone: +91-98452-88078
	EMail: chirayu@chirayu.org
	13. Normative References		[NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network
			Address Translator (Traditional NAT)", RFC 3022, January
			2001.
	[BRIDGE]		[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	T. Jeffree, editor, "Media Access Control (MAC) Bridges",		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	ANSI/IEEE Std 802.1D, 2004,		December 2003.
	http://standards.ieee.org/getieee802/download/802.1D-2004.pdf.
	[ICMPv6]		[PSREQ] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
	Conta, A. and S. Deering, "Internet Control Message Protocol		Discovery (ND) Trust Models and Threats", RFC 3756, May
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)		2004.
	Specification", RFC 2463, December 1998.
	[KEYWORDS]		[RINGSIG] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying
	S. Bradner, "Key words for use in RFCs to Indicate		using Multi-Key Cryptographically Generated Addresses
	Requirement Levels", BCP 14, RFC 2119, March, 1997.		(MCGAs)", Work in Progress, August 2005.
	[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery		[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[NODEREQ]		[SPND] Daley, G., "Securing Proxy Neighbour Discovery Problem
	J. Loughney, "IPv6 Node Requirements", Work in progress,		Statement", Work in Progress, February 2005.
	draft-ietf-ipv6-node-requirements-11.txt, August 2004.
	14. Informative References		Appendix A: Comparison with Naive RA Proxy
	[6TO4]		It has been suggested that a simple Router Advertisement (RA) proxy
	Carpenter, B. and K. Moore, "Connection of IPv6 Domains via		would be sufficient, where the subnet prefix in an RA is "stolen" by
	IPv4 Clouds", RFC 3056, February 2001.		the proxy and applied to a downstream link instead of an upstream
			link. Other ND messages are not proxied.
	Draft ND Proxy October 2005		There are many problems with this approach. First, it requires
			cooperation from all nodes on the upstream link. No node (including
			the router sending the RA) can have an address in the subnet or it
			will not have connectivity with nodes on the 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 on the upstream link,
			it will never discover the neighbor on the upstream link. Similarly,
			if messages are not proxied during Duplicate Address Detection (DAD),
			conflicts can occur.
	[BCP]		Second, if the proxy assumes that no nodes on the upstream link have
	Baker, F. and R. Bowen, "PPP Bridging Control Protocol		addresses in the prefix, such a proxy could not be safely deployed
	(BCP)", RFC 1638, June 1994.		without cooperation from the network administrator since it
			introduces a requirement that the router itself not have an address
			in the prefix. This rules out use in situations where bridges and
			Network Address Translators (NATs) are used today, which is the
			problem this document is directly addressing. Instead, where a
			prefix is desired for use on one or more downstream links in
			cooperation with the network administrator, Prefix Delegation [PD]
			should be used instead.
	[DHCPv6]		Authors' Addresses
	Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C.
	and M. Carney, "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.
	[NAT]		Dave Thaler
	Srisuresh, P. and K. Egevang, "Traditional IP Network Address		Microsoft Corporation
	Translator (Traditional NAT)", RFC 3022, January 2001.		One Microsoft Way
			Redmond, WA 98052-6399
	[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host		Phone: +1 425 703 8835
	Configuration Protocol (DHCP) version 6", RFC 3633, December		EMail: dthaler@microsoft.com
	2003.
	[PSREQ]		Mohit Talwar
	Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor		Microsoft Corporation
	Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.		One Microsoft Way
			Redmond, WA 98052-6399
	[RINGSIG]		Phone: +1 425 705 3131
	Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying using		EMail: mohitt@microsoft.com
	Multi-Key Cryptographically Generated Addresses (MCGAs)",
	Work in progress, draft-kempf-mobopts-ringsig-ndproxy-02.txt,
	August, 2005.
	[SEND]		Chirayu Patel
	Arkko, J., Ed., Kempf, J., Zill, B. and P. Nikander, "SEcure		All Play, No Work
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Bangalore, Karnataka 560038
	[SPND]		Phone: +91-98452-88078
	Daley, G., "Securing Proxy Neighbour Discovery Problem		EMail: chirayu@chirayu.org
	Statement", Work in progress, draft-daley-send-spnd-
	prob-01.txt, February 2005.
	Draft ND Proxy October 2005		Full Copyright Statement
	15. Full Copyright Statement		Copyright (C) The Internet Society (2006).
	Copyright (C) The Internet Society (2005). This document is		This document is subject to the rights, licenses and restrictions
	subject to the rights, licenses and restrictions contained in BCP		contained in BCP 78, and except as set forth therein, the authors
	78, and except as set forth therein, the authors retain all their		retain all their rights.
	rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on an
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	PARTICULAR PURPOSE.
	16. Intellectual Property		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
	to pertain to the implementation or use of the technology		pertain to the implementation or use of the technology described in
	described in this document or the extent to which any license		this document or the extent to which any license under such rights
	under such rights might or might not be available; nor does it		might or might not be available; nor does it represent that it has
	represent that it has made any independent effort to identify any		made any independent effort to identify any such rights. Information
	such rights. Information on the procedures with respect to rights		on the procedures with respect to rights in RFC documents can be
	in RFC documents can be found in BCP 78 and BCP 79.		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
	of such proprietary rights by implementers or users of this		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
	at http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention
	any copyrights, patents or patent applications, or other
	proprietary rights that may cover technology that may be required
	to implement this standard. Please address the information to the
	IETF at ietf-ipr@ietf.org.
	Draft ND Proxy October 2005		The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	Table of Contents		Acknowledgement
	1: Introduction ............................................. 2		Funding for the RFC Editor function is provided by the IETF
	1.1: SCENARIO 1: Wireless upstream .......................... 3		Administrative Support Activity (IASA).
	1.2: SCENARIO 2: PPP upstream ............................... 4
	1.3: Inapplicable Scenarios ................................. 4
	2: Terminology .............................................. 4
	3: Requirements ............................................. 5
	3.1: Non-requirements ....................................... 6
	4: Proxy Behavior ........................................... 6
	4.1: Forwarding Packets ..................................... 7
	4.1.1: Sending Packet Too Big Messages ...................... 8
	4.1.2: Proxying Packets With Link-Layer Addresses ........... 8
	4.1.3: IPv6 ND Proxying ..................................... 9
	4.1.3.1: ICMPv6 Neighbor Solicitations ...................... 9
	4.1.3.2: ICMPv6 Neighbor Advertisements ..................... 9
	4.1.3.3: ICMPv6 Router Advertisements ....................... 9
	4.1.3.4: ICMPv6 Redirects ................................... 10
	4.2: Originating Packets .................................... 10
	5: Example .................................................. 11
	6: Loop Prevention .......................................... 12
	7: Guidelines to proxy developers ........................... 12
	8: IANA Considerations ...................................... 13
	9: Security Considerations .................................. 13
	10: Appendix A: Comparison with Naive RA Proxy .............. 14
	11: Acknowledgements ........................................ 15
	12: Authors' Addresses ...................................... 15
	13: Normative References .................................... 16
	14: Informative References .................................. 16
	15: Full Copyright Statement ................................ 18
	16: Intellectual Property ................................... 18
End of changes. 112 change blocks.
	464 lines changed or deleted		421 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/