draft-ietf-ipv6-ndproxy-02.txt		draft-ietf-ipv6-ndproxy-03.txt
	IPv6 Working Group D. Thaler		IPv6 Working Group D. Thaler
	INTERNET-DRAFT M. Talwar		INTERNET-DRAFT M. Talwar
	May 5, 2005 Microsoft		July 14, 2005 Microsoft
	Expires November 2005 C. Patel		Expires January 2006 C. Patel
	All Play, No Work		All Play, No Work
	Bridge-like Neighbor Discovery Proxies (ND Proxy)		Neighbor Discovery Proxies (ND Proxy)
	<draft-ietf-ipv6-ndproxy-02.txt>		<draft-ietf-ipv6-ndproxy-03.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		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
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	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 May 2005		Draft ND Proxy July 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 2, line 31		skipping to change at page 2, line 31
	concentrates on describing similar behavior for IPv6.		concentrates on describing similar behavior for IPv6.
	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 with the network service provider. Since NATs modify		coordination with the network service provider. Since NATs modify
	IP addresses in packets, they are problematic for many IP		IP addresses in packets, they are problematic for many IP
	applications. As a result, it is desirable to address the problem		applications. As a result, it is desirable to address the problem
	(for both IPv4 and IPv6) without the need for NATs.		(for both IPv4 and IPv6) without the need for NATs, while still
			maintaining the property that no explicit cooperation from the
			router is needed.
	Another common solution is IEEE 802 bridging, as specified in		Another common solution is IEEE 802 bridging, as specified in
	[BRIDGE]. It is expected that whenever possible links will be		[BRIDGE]. It is expected that whenever possible links will be
	bridged at the link layer using classic bridge technology [BRIDGE]		bridged at the link layer using classic bridge technology [BRIDGE]
	as opposed to using the mechanisms herein. However, classic		as opposed to using the mechanisms herein. However, classic
	bridging at the data-link layer has the following limitations		bridging at the data-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, 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.
	Draft ND Proxy May 2005		Draft ND Proxy July 2005
			these two scenarios.
	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 49		skipping to change at page 4, line 4
	multiple variants have emerged in different implementations over		multiple variants have emerged in different implementations over
	time. In this document, we describe one such variant, and enable		time. In this document, we describe one such variant, and enable
	equivalent functionality for IPv6 to remove this incentive to		equivalent functionality for IPv6 to remove this incentive to
	deploy NATs in IPv6.		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
			Draft ND Proxy July 2005
	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.
	skipping to change at page 4, line 49		skipping to change at page 5, line 5
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	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.
			Draft ND Proxy July 2005
	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.
	3. Requirements		3. Requirements
	Bridge-like proxy behavior is designed with the following		Proxy behavior is designed with the following requirements in
	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 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
	media for IPv4.		media for IPv4.
	o Support both IPv6 and IPv4 for 802 media.		o Support both IPv6 and IPv4 for 802 media.
	o Do not require any changes to existing routers. That is, any		o Do not require any changes to existing routers. That is, any
	routers on the subnet should be unaware that the subnet is		routers on the subnet should be unaware that the subnet is
	being bridged.		being 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) which have addresses in the subnet prefix,
	adding a bridge-like proxy must allow bridged nodes to have		adding a proxy must allow bridged nodes to have full
	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.
	Draft ND Proxy May 2005		Draft ND Proxy July 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:
	o Show up as a hop in a traceroute.		o Show up as a hop in a traceroute.
	skipping to change at page 7, line 5		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		Draft ND Proxy July 2005
	4. Bridge-Like Proxy Behavior		4. 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.
	skipping to change at page 7, line 42		skipping to change at page 7, line 42
	When any IP or ARP packet is received on a proxy interface, it		When any IP or ARP packet is received on a proxy interface, it
	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 is received on a
	IPv6 Link-scoped RSTP Multicast Group) is received on a proxy		proxy interface, in addition to any normal IP behavior such as
	interface, in addition to any normal IP behavior such as being		being delivered locally, it is forwarded unchanged (other than
	delivered locally, it is forwarded unchanged (other than using a		using a new link-layer header) out all other proxy interfaces on
	new link-layer header) out all other proxy interfaces on the same		the same link. (As specified in [BRIDGE], the proxy may instead
	link. (As specified in [BRIDGE], the proxy may instead support		support multicast learning and filtering but this is OPTIONAL.)
	multicast learning and filtering but this is OPTIONAL.) In		In particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and
	particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and no		no ICMP errors (except as noted in Section 4.1.1 below) are sent
	ICMP errors (except as noted in Section 4.1.1 below) are sent as a		as a result of attempting this forwarding.
	Draft ND Proxy May 2005
	result of attempting this forwarding.		Draft ND Proxy July 2005
	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
	skipping to change at page 9, line 4		skipping to change at page 8, line 49
	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
			Draft ND Proxy July 2005
	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
	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
	skipping to change at page 10, line 4		skipping to change at page 9, line 46
	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.
			Draft ND Proxy July 2005
	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
	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.
	skipping to change at page 11, line 5		skipping to change at page 10, line 44
	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
			Draft ND Proxy July 2005
	described above.		described above.
	4.1.4.3. ICMPv6 Router Advertisements		4.1.4.3. ICMPv6 Router Advertisements
	Unless RSTP is implemented as described in section 6, the		The following special processing is done for IPv6 Router
	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.
	skipping to change at page 11, line 45		skipping to change at page 11, line 39
	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
			Draft ND Proxy July 2005
	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.
	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
	skipping to change at page 12, line 42		skipping to change at page 12, line 31
	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-
	specific fashion, and the packet will then be forwarded out other		specific fashion, and the packet will then be forwarded out other
	proxy interfaces on the same link as described in Section 4.1		proxy interfaces on the same link as described in Section 4.1
	above.		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 segments which are connected by a bridge-like proxy P:		separate 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
	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
			Draft ND Proxy July 2005
	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
	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
	skipping to change at page 14, line 5		skipping to change at page 13, line 39
	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 by using
	either:		the P bit in RA's as follows. The proxy determines an "upstream"
			proxy interface, typically through a physical choice dictated by
	a) by using the P bit in RA's as described below, or		the scenario (see Scenarios 1 and 2 above), or through manual
			configuration. As described in Section 4.1.3.3, only the upstream
	b) by running the Rapid Spanning Tree Protocol (RSTP) defined in		interface is allowed to receive RAs, and never from other proxies.
	[BRIDGE] on all proxy interfaces as described below.		Proxy functionality is disabled on an interface otherwise.
			Finally, a proxy MUST wait until it has sent two P bit RAs on a
	Loop prevention using RSTP would typically be done by devices that		given "downstream" interface before it enables forwarding on that
	already implement this protocol as a result of supporting normal		interface.
	briding functionality, and is done here as follows. IEEE 802
	interfaces use the protocol exactly as specified in [BRIDGE].
	Operation of RSTP over other types of link layers is done by
	encapsulating the RSTP frame in an IPv6 header. The Next Header
	field is set to [TBA by IANA], indicating that an RSTP header
	follows. The Destination Address field is set to the Link-scoped
	RSTP Multicast Group [TBA by IANA]. All proxies operating on non-
	IEEE 802 media join this group so they will receive RSTP packets.
	RSTP packets are never forwarded or proxied.
	Loop avoidance using the P bit in RAs is done as follows. The
	proxy determines an "upstream" proxy interface, typically through
	a physical choice dictated by the scenario (see Scenarios 1 and 2
	above), or through manual configuration. As described in Section
	4.1.3.3, only the upstream interface is allowed to receive RAs,
	and never from other proxies. Proxy functionality is disabled on
	an interface otherwise. Finally, a proxy MUST wait until it has
	sent two P bit RAs on a given "downstream" interface before it
	enables forwarding on that interface.
	Note that it is possible that a site has a mixture of P bit		Draft ND Proxy July 2005
	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,
	skipping to change at page 15, line 31		skipping to change at page 14, line 35
	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,
	[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:		This document has no actions for IANA.
	1) a Protocol Number for RSTP, and
	2) an IPv6 Link-Local Scope multicast address for All-RSTP-
	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.
			Draft ND Proxy July 2005
	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
	relationship with the proxy, and accept ND packets from either the		relationship with the proxy, and accept ND packets from either the
	owner of a specific address (normal SEND), or which it can verify		owner of a specific address (normal SEND), or which it can verify
	skipping to change at page 17, line 4		skipping to change at page 15, line 49
	(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
			Draft ND Proxy July 2005
	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
	skipping to change at page 18, line 5		skipping to change at page 17, line 5
	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]		[ARPPROXY]
	J. Postel, "Multi-LAN address resolution", RFC 925, October		J. Postel, "Multi-LAN address resolution", RFC 925, October
	1984.		1984.
	Draft ND Proxy May 2005		Draft ND Proxy July 2005
	[BRIDGE]		[BRIDGE]
	T. Jeffree, editor, "Media Access Control (MAC) Bridges",		T. Jeffree, editor, "Media Access Control (MAC) Bridges",
	ANSI/IEEE Std 802.1D, 2004,		ANSI/IEEE Std 802.1D, 2004,
	http://standards.ieee.org/getieee802/download/802.1D-2004.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.
	skipping to change at page 19, line 5		skipping to change at page 18, line 5
	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		Draft ND Proxy July 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
	skipping to change at page 20, line 5		skipping to change at page 19, line 5
	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		Draft ND Proxy July 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
	any copyrights, patents or patent applications, or other		any copyrights, patents or patent applications, or other
	proprietary rights that may cover technology that may be required		proprietary rights that may cover technology that may be required
	to implement this standard. Please address the information to the		to implement this standard. Please address the information to the
	IETF at ietf-ipr@ietf.org.		IETF at ietf-ipr@ietf.org.
			Draft ND Proxy July 2005
			Table of Contents
			1: Introduction ............................................. 2
			1.1: SCENARIO 1: Wireless upstream .......................... 3
			1.2: SCENARIO 2: PPP upstream ............................... 4
			2: Terminology .............................................. 4
			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 ........... 9
			4.1.3: IPv4 ARP Proxying .................................... 9
			4.1.3.1: ARP REQUEST Packets ................................ 9
			4.1.3.2: ARP REPLY Packets .................................. 9
			4.1.3.3: DHCPv4 Packets ..................................... 10
			4.1.4: IPv6 ND Proxying ..................................... 10
			4.1.4.1: ICMPv6 Neighbor Solicitations ...................... 10
			4.1.4.2: ICMPv6 Neighbor Advertisements ..................... 10
			4.1.4.3: ICMPv6 Router Advertisements ....................... 11
			4.1.4.4: ICMPv6 Redirects ................................... 11
			4.2: Originating Packets .................................... 12
			5: Example .................................................. 12
			6: Loop Prevention .......................................... 13
			7: Guidelines to proxy developers ........................... 14
			8: IANA Considerations ...................................... 14
			9: Security Considerations .................................. 14
			10: Appendix A: Comparison with Naive RA Proxy .............. 15
			11: Authors' Addresses ...................................... 16
			12: Normative References .................................... 16
			13: Informative References .................................. 17
			14: Full Copyright Statement ................................ 18
			15: Intellectual Property ................................... 18
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/