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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/