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

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