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/ |