draft-ietf-ipv6-ndproxy-02.txt | draft-ietf-ipv6-ndproxy-03.txt | |||
---|---|---|---|---|
IPv6 Working Group D. Thaler | IPv6 Working Group D. Thaler | |||
INTERNET-DRAFT M. Talwar | INTERNET-DRAFT M. Talwar | |||
May 5, 2005 Microsoft | July 14, 2005 Microsoft | |||
Expires November 2005 C. Patel | Expires January 2006 C. Patel | |||
All Play, No Work | All Play, No Work | |||
Bridge-like Neighbor Discovery Proxies (ND Proxy) | Neighbor Discovery Proxies (ND Proxy) | |||
<draft-ietf-ipv6-ndproxy-02.txt> | <draft-ietf-ipv6-ndproxy-03.txt> | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 2, line 5 | skipping to change at page 2, line 5 | |||
progress." | progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright Notice | Copyright Notice | |||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
Copyright (C) The Internet Society (2005). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
Abstract | Abstract | |||
Bridging multiple links into a single entity has several | Bridging multiple links into a single entity has several | |||
operational advantages. A single subnet prefix is sufficient to | operational advantages. A single subnet prefix is sufficient to | |||
support multiple physical links. There is no need to allocate | support multiple physical links. There is no need to allocate | |||
subnet numbers to the different networks, simplifying management. | subnet numbers to the different networks, simplifying management. | |||
Bridging some types of media requires network-layer support, | Bridging some types of media requires network-layer support, | |||
skipping to change at page 2, line 31 | skipping to change at page 2, line 31 | |||
concentrates on describing similar behavior for IPv6. | concentrates on describing similar behavior for IPv6. | |||
1. Introduction | 1. Introduction | |||
In the IPv4 Internet today, it is common for Network Address | In the IPv4 Internet today, it is common for Network Address | |||
Translators (NATs) [NAT] to be used to easily connect one or more | Translators (NATs) [NAT] to be used to easily connect one or more | |||
leaf links to an existing network without requiring any | leaf links to an existing network without requiring any | |||
coordination with the network service provider. Since NATs modify | coordination with the network service provider. Since NATs modify | |||
IP addresses in packets, they are problematic for many IP | IP addresses in packets, they are problematic for many IP | |||
applications. As a result, it is desirable to address the problem | applications. As a result, it is desirable to address the problem | |||
(for both IPv4 and IPv6) without the need for NATs. | (for both IPv4 and IPv6) without the need for NATs, while still | |||
maintaining the property that no explicit cooperation from the | ||||
router is needed. | ||||
Another common solution is IEEE 802 bridging, as specified in | Another common solution is IEEE 802 bridging, as specified in | |||
[BRIDGE]. It is expected that whenever possible links will be | [BRIDGE]. It is expected that whenever possible links will be | |||
bridged at the link layer using classic bridge technology [BRIDGE] | bridged at the link layer using classic bridge technology [BRIDGE] | |||
as opposed to using the mechanisms herein. However, classic | as opposed to using the mechanisms herein. However, classic | |||
bridging at the data-link layer has the following limitations | bridging at the data-link layer has the following limitations | |||
(among others): | (among others): | |||
o It requires the ports to support promiscuous mode. | o It requires the ports to support promiscuous mode. | |||
o It requires all ports to support the same type of link-layer | o It requires all ports to support the same type of link-layer | |||
addressing (in particular, IEEE 802 addressing). | addressing (in particular, IEEE 802 addressing). | |||
As a result, two common scenarios, described below, are not | As a result, two common scenarios, described below, are not | |||
solved, and it is these two scenarios we specifically target in | solved, and it is these two scenarios we specifically target in | |||
this document. While the mechanism described herein may apply to | this document. While the mechanism described herein may apply to | |||
other scenarios as well, we will concentrate our discussion on | other scenarios as well, we will concentrate our discussion on | |||
these two scenarios. | ||||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
these two scenarios. | ||||
1.1. SCENARIO 1: Wireless upstream | 1.1. SCENARIO 1: Wireless upstream | |||
The following figure illustrates a likely example: | The following figure illustrates a likely example: | |||
| +-------+ +--------+ | | +-------+ +--------+ | |||
local |Ethernet | | Wireless | Access | | local |Ethernet | | Wireless | Access | | |||
+---------+ A +-))) (((-+ +--> rest of network | +---------+ A +-))) (((-+ +--> rest of network | |||
hosts | | | link | Point | | hosts | | | link | Point | | |||
| +-------+ +--------+ | | +-------+ +--------+ | |||
skipping to change at page 3, line 49 | skipping to change at page 4, line 4 | |||
multiple variants have emerged in different implementations over | multiple variants have emerged in different implementations over | |||
time. In this document, we describe one such variant, and enable | time. In this document, we describe one such variant, and enable | |||
equivalent functionality for IPv6 to remove this incentive to | equivalent functionality for IPv6 to remove this incentive to | |||
deploy NATs in IPv6. | deploy NATs in IPv6. | |||
We also note that Prefix Delegation [PD] could also be used to | We also note that Prefix Delegation [PD] could also be used to | |||
solve this scenario. There are, however, two disadvantages to | solve this scenario. There are, however, two disadvantages to | |||
this. First, if an implementation already supports IPv4 ARP | this. First, if an implementation already supports IPv4 ARP | |||
proxying (which is indeed supported in a number of implementations | proxying (which is indeed supported in a number of implementations | |||
today), then IPv6 Prefix Delegation would result in separate IPv6 | today), then IPv6 Prefix Delegation would result in separate IPv6 | |||
Draft ND Proxy July 2005 | ||||
subnets on either side of the device, while a single IPv4 subnet | subnets on either side of the device, while a single IPv4 subnet | |||
would span both segments. This topological discrepancy can | would span both segments. This topological discrepancy can | |||
complicate applications and protocols which use the concept of a | complicate applications and protocols which use the concept of a | |||
Draft ND Proxy May 2005 | ||||
local subnet. Secondly, the extent to which Prefix Delegation is | local subnet. Secondly, the extent to which Prefix Delegation is | |||
supported, and supported without additional charge, is up to the | supported, and supported without additional charge, is up to the | |||
service provider. Hence, there is no guarantee that Prefix | service provider. Hence, there is no guarantee that Prefix | |||
Delegation will work without explicit configuration or additional | Delegation will work without explicit configuration or additional | |||
charge. Bridging, on the other hand, allows the device to work | charge. Bridging, on the other hand, allows the device to work | |||
with zero configuration, regardless of the service provider's | with zero configuration, regardless of the service provider's | |||
policies, just as a NAT does. Hence bridging avoids the incentive | policies, just as a NAT does. Hence bridging avoids the incentive | |||
to NAT IPv6 just to avoid paying for, or requiring configuration | to NAT IPv6 just to avoid paying for, or requiring configuration | |||
to get, another prefix. | to get, another prefix. | |||
skipping to change at page 4, line 49 | skipping to change at page 5, line 5 | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" | |||
in this document are to be interpreted as described in BCP 14, RFC | in this document are to be interpreted as described in BCP 14, RFC | |||
2119 [KEYWORDS]. | 2119 [KEYWORDS]. | |||
The term "proxy interface" will be used to refer to an interface | The term "proxy interface" will be used to refer to an interface | |||
(which could itself be a bridge interface) over which network | (which could itself be a bridge interface) over which network | |||
layer proxying is done as defined herein. | layer proxying is done as defined herein. | |||
Draft ND Proxy July 2005 | ||||
In this document we make no distinction between a "link" (in the | In this document we make no distinction between a "link" (in the | |||
classic IPv6 sense) and a "subnet". We use the term "segment" to | classic IPv6 sense) and a "subnet". We use the term "segment" to | |||
Draft ND Proxy May 2005 | ||||
apply to a bridged component of the link. | apply to a bridged component of the link. | |||
Finally, while it is possible that functionality equivalent to | Finally, while it is possible that functionality equivalent to | |||
that described herein may be achieved by nodes which do not | that described herein may be achieved by nodes which do not | |||
fulfill all the requirements in [NODEREQ], in the remainder of | fulfill all the requirements in [NODEREQ], in the remainder of | |||
this document we will describe behavior in terms of an IPv6 node | this document we will describe behavior in terms of an IPv6 node | |||
as defined in that document. | as defined in that document. | |||
3. Requirements | 3. Requirements | |||
Bridge-like proxy behavior is designed with the following | Proxy behavior is designed with the following requirements in | |||
requirements in mind: | mind: | |||
o Support connecting multiple segments with a single subnet | o Support connecting multiple segments with a single subnet | |||
prefix. | prefix. | |||
o Support media which cannot be bridged at the link-layer. | o Support media which cannot be bridged at the link-layer. | |||
Note, this document does not support bridging of non-802 | Note, this document does not support bridging of non-802 | |||
media for IPv4. | media for IPv4. | |||
o Support both IPv6 and IPv4 for 802 media. | o Support both IPv6 and IPv4 for 802 media. | |||
o Do not require any changes to existing routers. That is, any | o Do not require any changes to existing routers. That is, any | |||
routers on the subnet should be unaware that the subnet is | routers on the subnet should be unaware that the subnet is | |||
being bridged. | being bridged. | |||
o Provide full connectivity between all nodes in the subnet. | o Provide full connectivity between all nodes in the subnet. | |||
For example, if there are existing nodes (such as any routers | For example, if there are existing nodes (such as any routers | |||
on the subnet) which have addresses in the subnet prefix, | on the subnet) which have addresses in the subnet prefix, | |||
adding a bridge-like proxy must allow bridged nodes to have | adding a proxy must allow bridged nodes to have full | |||
full connectivity with existing nodes on the subnet. | connectivity with existing nodes on the subnet. | |||
o Prevent loops. | o Prevent loops. | |||
o Also work in the absence of any routers. | o Also work in the absence of any routers. | |||
o Support nodes moving between segments. For example, a node | o Support nodes moving between segments. For example, a node | |||
should be able to keep its address without seeing its address | should be able to keep its address without seeing its address | |||
as a duplicate due to any cache maintained at the proxy. | as a duplicate due to any cache maintained at the proxy. | |||
o Allow dynamic addition of a proxy without adversely | o Allow dynamic addition of a proxy without adversely | |||
disrupting the network. | disrupting the network. | |||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
o The proxy behavior should not break any existing classic | o The proxy behavior should not break any existing classic | |||
bridges in use on a network segment. | bridges in use on a network segment. | |||
3.1. Non-requirements | 3.1. Non-requirements | |||
The following items are not considered requirements, as they are | The following items are not considered requirements, as they are | |||
not met by classic bridges: | not met by classic bridges: | |||
o Show up as a hop in a traceroute. | o Show up as a hop in a traceroute. | |||
skipping to change at page 7, line 5 | skipping to change at page 7, line 5 | |||
for securing these protocols do not use IPsec so this is | for securing these protocols do not use IPsec so this is | |||
considered acceptable. | considered acceptable. | |||
o Support Redirects for off-subnet destinations that point to a | o Support Redirects for off-subnet destinations that point to a | |||
router on a different segment from the redirected host. | router on a different segment from the redirected host. | |||
While this scenario may be desirable, no solution is | While this scenario may be desirable, no solution is | |||
currently known which does not have undesirable side effects | currently known which does not have undesirable side effects | |||
outside the subnet. As a result, this scenario is outside | outside the subnet. As a result, this scenario is outside | |||
the scope of this document. | the scope of this document. | |||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
4. Bridge-Like Proxy Behavior | 4. Proxy Behavior | |||
Network layer support for proxying between multiple interfaces | Network layer support for proxying between multiple interfaces | |||
SHOULD be used only when classic bridging is not possible. | SHOULD be used only when classic bridging is not possible. | |||
When a proxy interface comes up, the node puts it in "all- | When a proxy interface comes up, the node puts it in "all- | |||
multicast" mode so that it will receive all multicast packets. It | multicast" mode so that it will receive all multicast packets. It | |||
is common for interfaces to not support full promiscuous mode | is common for interfaces to not support full promiscuous mode | |||
(e.g., on a wireless client), but all-multicast mode is generally | (e.g., on a wireless client), but all-multicast mode is generally | |||
still supported. | still supported. | |||
skipping to change at page 7, line 42 | skipping to change at page 7, line 42 | |||
When any IP or ARP packet is received on a proxy interface, it | When any IP or ARP packet is received on a proxy interface, it | |||
must be parsed to see whether it is known to be of a type that | must be parsed to see whether it is known to be of a type that | |||
negotiates link-layer addresses. This document covers the | negotiates link-layer addresses. This document covers the | |||
following types: ARP, IPv6 Neighbor Discovery, IPv6 Router | following types: ARP, IPv6 Neighbor Discovery, IPv6 Router | |||
Discovery, IPv6 Redirects, and DHCPv4. These packets are ones | Discovery, IPv6 Redirects, and DHCPv4. These packets are ones | |||
that can carry link-layer addresses, and hence must be proxied (as | that can carry link-layer addresses, and hence must be proxied (as | |||
described below) so that packets between nodes on different | described below) so that packets between nodes on different | |||
segments can be received by the proxy and have the correct link- | segments can be received by the proxy and have the correct link- | |||
layer address type on each segment. | layer address type on each segment. | |||
When any other IP broadcast or multicast packet (other than to the | When any other IP broadcast or multicast packet is received on a | |||
IPv6 Link-scoped RSTP Multicast Group) is received on a proxy | proxy interface, in addition to any normal IP behavior such as | |||
interface, in addition to any normal IP behavior such as being | being delivered locally, it is forwarded unchanged (other than | |||
delivered locally, it is forwarded unchanged (other than using a | using a new link-layer header) out all other proxy interfaces on | |||
new link-layer header) out all other proxy interfaces on the same | the same link. (As specified in [BRIDGE], the proxy may instead | |||
link. (As specified in [BRIDGE], the proxy may instead support | support multicast learning and filtering but this is OPTIONAL.) | |||
multicast learning and filtering but this is OPTIONAL.) In | In particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and | |||
particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and no | no ICMP errors (except as noted in Section 4.1.1 below) are sent | |||
ICMP errors (except as noted in Section 4.1.1 below) are sent as a | as a result of attempting this forwarding. | |||
Draft ND Proxy May 2005 | ||||
result of attempting this forwarding. | Draft ND Proxy July 2005 | |||
When any other IP unicast packet is received on a proxy interface, | When any other IP unicast packet is received on a proxy interface, | |||
if it is not locally destined then it is forwarded unchanged | if it is not locally destined then it is forwarded unchanged | |||
(other than using a new link-layer header) to the proxy interface | (other than using a new link-layer header) to the proxy interface | |||
for which the next hop address appears in the neighbor cache. | for which the next hop address appears in the neighbor cache. | |||
Again the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP | Again the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP | |||
errors (except as noted in Section 4.1.1 below) are sent as a | errors (except as noted in Section 4.1.1 below) are sent as a | |||
result of attempting this forwarding. To choose a proxy interface | result of attempting this forwarding. To choose a proxy interface | |||
to forward to, the neighbor cache is consulted, and the interface | to forward to, the neighbor cache is consulted, and the interface | |||
with the neighbor entry in the "best" state is used. In order of | with the neighbor entry in the "best" state is used. In order of | |||
skipping to change at page 9, line 4 | skipping to change at page 8, line 49 | |||
the address of the outgoing interface. | the address of the outgoing interface. | |||
4.1.1. Sending Packet Too Big Messages | 4.1.1. Sending Packet Too Big Messages | |||
Whenever any IPv4 packet is to be forwarded out an interface whose | Whenever any IPv4 packet is to be forwarded out an interface whose | |||
MTU is smaller than the size of the packet, and the Dont Fragment | MTU is smaller than the size of the packet, and the Dont Fragment | |||
bit is set, the ARP proxy drops the packet and sends a | bit is set, the ARP proxy drops the packet and sends a | |||
Fragmentation Needed message back to the source. | Fragmentation Needed message back to the source. | |||
Similarly, whenever any IPv6 packet is to be forwarded out an | Similarly, whenever any IPv6 packet is to be forwarded out an | |||
Draft ND Proxy May 2005 | ||||
interface whose MTU is smaller than the size of the packet, the ND | interface whose MTU is smaller than the size of the packet, the ND | |||
proxy drops the packet and sends a Packet Too Big message back to | proxy drops the packet and sends a Packet Too Big message back to | |||
Draft ND Proxy July 2005 | ||||
the source, as described in [ICMPv6]. | the source, as described in [ICMPv6]. | |||
4.1.2. Proxying Packets With Link-Layer Addresses | 4.1.2. Proxying Packets With Link-Layer Addresses | |||
Once it is determined that the packet is either | Once it is determined that the packet is either | |||
multicast/broadcast or else is not locally destined (if unicast), | multicast/broadcast or else is not locally destined (if unicast), | |||
the special types enumerated above (ARP, etc.) that carry link- | the special types enumerated above (ARP, etc.) that carry link- | |||
layer addresses are handled by generating a proxy packet that | layer addresses are handled by generating a proxy packet that | |||
contains the proxy's link-layer address on the outgoing interface | contains the proxy's link-layer address on the outgoing interface | |||
instead. Section 7, "Guidelines to proxy developers", describes | instead. Section 7, "Guidelines to proxy developers", describes | |||
skipping to change at page 10, line 4 | skipping to change at page 9, line 46 | |||
locally but no ARP REPLY is generated immediately. Instead, the | locally but no ARP REPLY is generated immediately. Instead, the | |||
ARP REQUEST is proxied (as described above) and the ARP REPLY will | ARP REQUEST is proxied (as described above) and the ARP REPLY will | |||
be proxied when it is received. This ensures that the proxy does | be proxied when it is received. This ensures that the proxy does | |||
not interfere with hosts moving from one segment to another since | not interfere with hosts moving from one segment to another since | |||
it never responds to an ARP REQUEST based on its own cache. | it never responds to an ARP REQUEST based on its own cache. | |||
4.1.3.2. ARP REPLY Packets | 4.1.3.2. ARP REPLY Packets | |||
If the received packet is an ARP REPLY, the neighbor cache on the | If the received packet is an ARP REPLY, the neighbor cache on the | |||
receiving interface is first updated as if the ARP REPLY were | receiving interface is first updated as if the ARP REPLY were | |||
Draft ND Proxy May 2005 | ||||
locally destined, and then the ARP REPLY is proxied as described | locally destined, and then the ARP REPLY is proxied as described | |||
above. | above. | |||
Draft ND Proxy July 2005 | ||||
4.1.3.3. DHCPv4 Packets | 4.1.3.3. DHCPv4 Packets | |||
If the received packet is a DHCPv4 DISCOVER or REQUEST message, | If the received packet is a DHCPv4 DISCOVER or REQUEST message, | |||
then instead of changing the client's hardware address in the | then instead of changing the client's hardware address in the | |||
payload, the BROADCAST (B) flag is set in the proxied packet. | payload, the BROADCAST (B) flag is set in the proxied packet. | |||
This ensures that the proxy will be able to receive and proxy the | This ensures that the proxy will be able to receive and proxy the | |||
response since the response will be broadcast rather than unicast | response since the response will be broadcast rather than unicast | |||
to that hardware address. The hardware address is thus used only | to that hardware address. The hardware address is thus used only | |||
as a unique identifier and hence need not be a link-layer address | as a unique identifier and hence need not be a link-layer address | |||
on the same segment. | on the same segment. | |||
skipping to change at page 11, line 5 | skipping to change at page 10, line 44 | |||
4.1.4.1. ICMPv6 Neighbor Solicitations | 4.1.4.1. ICMPv6 Neighbor Solicitations | |||
If the received packet is an ICMPv6 Neighbor Solicitation, the NS | If the received packet is an ICMPv6 Neighbor Solicitation, the NS | |||
is processed locally as described in section 7.2.3 of [ND] but no | is processed locally as described in section 7.2.3 of [ND] but no | |||
NA is generated immediately. Instead the NS is proxied as | NA is generated immediately. Instead the NS is proxied as | |||
described above and the NA will be proxied when it is received. | described above and the NA will be proxied when it is received. | |||
This ensures that the proxy does not interfere with hosts moving | This ensures that the proxy does not interfere with hosts moving | |||
from one segment to another since it never responds to an NS based | from one segment to another since it never responds to an NS based | |||
on its own cache. | on its own cache. | |||
Draft ND Proxy May 2005 | ||||
4.1.4.2. ICMPv6 Neighbor Advertisements | 4.1.4.2. ICMPv6 Neighbor Advertisements | |||
If the received packet is an ICMPv6 Neighbor Advertisement, the | If the received packet is an ICMPv6 Neighbor Advertisement, the | |||
neighbor cache on the receiving interface is first updated as if | neighbor cache on the receiving interface is first updated as if | |||
the NA were locally destined, and then the NA is proxied as | the NA were locally destined, and then the NA is proxied as | |||
Draft ND Proxy July 2005 | ||||
described above. | described above. | |||
4.1.4.3. ICMPv6 Router Advertisements | 4.1.4.3. ICMPv6 Router Advertisements | |||
Unless RSTP is implemented as described in section 6, the | The following special processing is done for IPv6 Router | |||
following special processing is done for IPv6 Router | ||||
Advertisements (RAs). | Advertisements (RAs). | |||
A new "Proxy" bit is defined in the existing Router Advertisement | A new "Proxy" bit is defined in the existing Router Advertisement | |||
flags field as follows: | flags field as follows: | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|M|O|H|Prf|P|Rsv| | |M|O|H|Prf|P|Rsv| | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
where "P" indicates the location of the Proxy bit, and "Rsv | where "P" indicates the location of the Proxy bit, and "Rsv | |||
indicates the remaining reserved bits. | indicates the remaining reserved bits. | |||
skipping to change at page 11, line 45 | skipping to change at page 11, line 39 | |||
If an RA with the P bit set has arrived on a given interface | If an RA with the P bit set has arrived on a given interface | |||
(including the upstream interface) within the last 60 minutes, | (including the upstream interface) within the last 60 minutes, | |||
that interface MUST NOT be used as a proxy interface; i.e., proxy | that interface MUST NOT be used as a proxy interface; i.e., proxy | |||
functionality is disabled on that interface. | functionality is disabled on that interface. | |||
Furthermore, if any RA (regardless of the value of the P bit) has | Furthermore, if any RA (regardless of the value of the P bit) has | |||
arrived on a "downstream" proxy interface within the last 60 | arrived on a "downstream" proxy interface within the last 60 | |||
minutes, that interface MUST NOT be used as a proxy interface. | minutes, that interface MUST NOT be used as a proxy interface. | |||
If, on the other hand, RSTP is implemented as described in section | ||||
6, no special processing is done for RAs. That is, the P bit is | ||||
ignored, and the P bit is unmodified in RAs proxied to other | ||||
interfaces. | ||||
Draft ND Proxy May 2005 | ||||
4.1.4.4. ICMPv6 Redirects | 4.1.4.4. ICMPv6 Redirects | |||
If the received packet is an ICMPv6 Redirect message, then the | If the received packet is an ICMPv6 Redirect message, then the | |||
proxied packet should be modified as follows. If the proxy has a | proxied packet should be modified as follows. If the proxy has a | |||
valid (i.e., not INCOMPLETE) neighbor entry for the target address | valid (i.e., not INCOMPLETE) neighbor entry for the target address | |||
on the same interface as the redirected host, then the TLLA option | on the same interface as the redirected host, then the TLLA option | |||
in the proxied Redirect simply contains the link-layer address of | in the proxied Redirect simply contains the link-layer address of | |||
the target as found in the proxy's neighbor entry, since the | the target as found in the proxy's neighbor entry, since the | |||
redirected host may reach the target address directly. Otherwise, | redirected host may reach the target address directly. Otherwise, | |||
if the proxy has a valid neighbor entry for the target address on | if the proxy has a valid neighbor entry for the target address on | |||
some other interface, then the TLLA option in the proxied packet | some other interface, then the TLLA option in the proxied packet | |||
Draft ND Proxy July 2005 | ||||
contains the link-layer address of the proxy on the sending | contains the link-layer address of the proxy on the sending | |||
interface, since the redirected host must reach the target address | interface, since the redirected host must reach the target address | |||
through the proxy. Otherwise, the proxy has no valid neighbor | through the proxy. Otherwise, the proxy has no valid neighbor | |||
entry for the target address, and the proxied packet contains no | entry for the target address, and the proxied packet contains no | |||
TLLA option, which will cause the redirected host to perform | TLLA option, which will cause the redirected host to perform | |||
neighbor discovery for the target address. | neighbor discovery for the target address. | |||
4.2. Originating Packets | 4.2. Originating Packets | |||
Locally originated packets that are sent on a proxy interface also | Locally originated packets that are sent on a proxy interface also | |||
skipping to change at page 12, line 42 | skipping to change at page 12, line 31 | |||
interface will be discovered and the packet will be sent on that | interface will be discovered and the packet will be sent on that | |||
interface. When a multicast or broadcast packet is to be locally | interface. When a multicast or broadcast packet is to be locally | |||
originated, an interface can be chosen in any implementation- | originated, an interface can be chosen in any implementation- | |||
specific fashion, and the packet will then be forwarded out other | specific fashion, and the packet will then be forwarded out other | |||
proxy interfaces on the same link as described in Section 4.1 | proxy interfaces on the same link as described in Section 4.1 | |||
above. | above. | |||
5. Example | 5. Example | |||
Consider the following topology, where A and B are nodes on | Consider the following topology, where A and B are nodes on | |||
separate segments which are connected by a bridge-like proxy P: | separate segments which are connected by a proxy P: | |||
A---|---P---|---B | A---|---P---|---B | |||
a p1 p2 b | a p1 p2 b | |||
A and B have link-layer addresses a and b, respectively. P has | A and B have link-layer addresses a and b, respectively. P has | |||
link-layer addresses p1 and p2 on the two segments. We now walk | link-layer addresses p1 and p2 on the two segments. We now walk | |||
through the actions that happen when A attempts to send an initial | through the actions that happen when A attempts to send an initial | |||
Draft ND Proxy May 2005 | ||||
IPv6 packet to B. | IPv6 packet to B. | |||
A first does a route lookup on the destination address B. This | A first does a route lookup on the destination address B. This | |||
matches the on-link subnet prefix, and a destination cache entry | matches the on-link subnet prefix, and a destination cache entry | |||
is created as well as a neighbor cache entry in the INCOMPLETE | is created as well as a neighbor cache entry in the INCOMPLETE | |||
state. Before the packet can be sent, A needs to resolve B's | state. Before the packet can be sent, A needs to resolve B's | |||
link-layer address and sends a Neighbor Solicitation (NS) to the | link-layer address and sends a Neighbor Solicitation (NS) to the | |||
solicited-node multicast address for B. The SLLA option in the | solicited-node multicast address for B. The SLLA option in the | |||
solicitation contains A's link-layer address. | solicitation contains A's link-layer address. | |||
P receives the solicitation (since it is receiving all link-layer | P receives the solicitation (since it is receiving all link-layer | |||
Draft ND Proxy July 2005 | ||||
multicast packets) and processes it as it would any multicast | multicast packets) and processes it as it would any multicast | |||
packet by forwarding it out to other segments on the link. | packet by forwarding it out to other segments on the link. | |||
However, before actually sending the packet, it determines if the | However, before actually sending the packet, it determines if the | |||
packet being sent is one which requires proxying. Since it is an | packet being sent is one which requires proxying. Since it is an | |||
NS, it creates a neighbor entry for A on interface 1 and records | NS, it creates a neighbor entry for A on interface 1 and records | |||
its link-layer address. It also creates a neighbor entry for B | its link-layer address. It also creates a neighbor entry for B | |||
(on an arbitrary proxy interface) in the INCOMPLETE state. Since | (on an arbitrary proxy interface) in the INCOMPLETE state. Since | |||
the packet is multicast, P then needs to proxy the NS out all | the packet is multicast, P then needs to proxy the NS out all | |||
other proxy interfaces on the subnet. Before sending the packet | other proxy interfaces on the subnet. Before sending the packet | |||
out interface 2, it replaces the link-layer address in the SLLA | out interface 2, it replaces the link-layer address in the SLLA | |||
skipping to change at page 14, line 5 | skipping to change at page 13, line 39 | |||
which requires proxying. Since it is an NA, it updates its | which requires proxying. Since it is an NA, it updates its | |||
neighbor entry for B to be REACHABLE and records the link-layer | neighbor entry for B to be REACHABLE and records the link-layer | |||
address b. P then replaces the link-layer address in the TLLA | address b. P then replaces the link-layer address in the TLLA | |||
option with its own link-layer address on the outgoing interface, | option with its own link-layer address on the outgoing interface, | |||
p1. The packet is then sent out interface 1. | p1. The packet is then sent out interface 1. | |||
A receives this NA, processing it as usual. Hence it creates a | A receives this NA, processing it as usual. Hence it creates a | |||
neighbor entry for B on interface 2 in the REACHABLE state and | neighbor entry for B on interface 2 in the REACHABLE state and | |||
records the link-layer address p1. | records the link-layer address p1. | |||
Draft ND Proxy May 2005 | ||||
6. Loop Prevention | 6. Loop Prevention | |||
An implementation MUST ensure that loops are prevented, via | An implementation MUST ensure that loops are prevented by using | |||
either: | the P bit in RA's as follows. The proxy determines an "upstream" | |||
proxy interface, typically through a physical choice dictated by | ||||
a) by using the P bit in RA's as described below, or | the scenario (see Scenarios 1 and 2 above), or through manual | |||
configuration. As described in Section 4.1.3.3, only the upstream | ||||
b) by running the Rapid Spanning Tree Protocol (RSTP) defined in | interface is allowed to receive RAs, and never from other proxies. | |||
[BRIDGE] on all proxy interfaces as described below. | Proxy functionality is disabled on an interface otherwise. | |||
Finally, a proxy MUST wait until it has sent two P bit RAs on a | ||||
Loop prevention using RSTP would typically be done by devices that | given "downstream" interface before it enables forwarding on that | |||
already implement this protocol as a result of supporting normal | interface. | |||
briding functionality, and is done here as follows. IEEE 802 | ||||
interfaces use the protocol exactly as specified in [BRIDGE]. | ||||
Operation of RSTP over other types of link layers is done by | ||||
encapsulating the RSTP frame in an IPv6 header. The Next Header | ||||
field is set to [TBA by IANA], indicating that an RSTP header | ||||
follows. The Destination Address field is set to the Link-scoped | ||||
RSTP Multicast Group [TBA by IANA]. All proxies operating on non- | ||||
IEEE 802 media join this group so they will receive RSTP packets. | ||||
RSTP packets are never forwarded or proxied. | ||||
Loop avoidance using the P bit in RAs is done as follows. The | ||||
proxy determines an "upstream" proxy interface, typically through | ||||
a physical choice dictated by the scenario (see Scenarios 1 and 2 | ||||
above), or through manual configuration. As described in Section | ||||
4.1.3.3, only the upstream interface is allowed to receive RAs, | ||||
and never from other proxies. Proxy functionality is disabled on | ||||
an interface otherwise. Finally, a proxy MUST wait until it has | ||||
sent two P bit RAs on a given "downstream" interface before it | ||||
enables forwarding on that interface. | ||||
Note that it is possible that a site has a mixture of P bit | Draft ND Proxy July 2005 | |||
proxies and RSTP-capable proxies. To understand how this works, | ||||
consider the case where only P bit proxies are present. However, | ||||
within each link, there may be classic IEEE 802 bridges. Those | ||||
classic bridges are responsible for ensuring that that link is | ||||
loop-free. To P bit proxies, proxies which run RSTP are the same | ||||
in this respect as classic IEEE 802 bridges. | ||||
7. Guidelines to proxy developers | 7. Guidelines to proxy developers | |||
Proxy developers will have to accomodate protocols or protocol | Proxy developers will have to accomodate protocols or protocol | |||
options (for example, new ICMP messages) that are developed in the | options (for example, new ICMP messages) that are developed in the | |||
Draft ND Proxy May 2005 | ||||
future, or protocols that are not mentioned in this document (for | future, or protocols that are not mentioned in this document (for | |||
example, proprietary protocols). This section prescribes | example, proprietary protocols). This section prescribes | |||
guidelines that can be used by proxy developers to accomodate | guidelines that can be used by proxy developers to accomodate | |||
protocols that are not mentioned herein. | protocols that are not mentioned herein. | |||
1) If a link-layer address carried in the payload of the | 1) If a link-layer address carried in the payload of the | |||
protocol can be used in the link-layer header of future | protocol can be used in the link-layer header of future | |||
messages, then the proxy should substitute it with its own | messages, then the proxy should substitute it with its own | |||
address. For example the link-layer address in NA messages is | address. For example the link-layer address in NA messages is | |||
used in the link-layer header for future messages, and, | used in the link-layer header for future messages, and, | |||
skipping to change at page 15, line 31 | skipping to change at page 14, line 35 | |||
outgoing interface. | outgoing interface. | |||
2) If the link-layer address in the payload of the protocol will | 2) If the link-layer address in the payload of the protocol will | |||
never be used in any link-layer header, then the proxy should | never be used in any link-layer header, then the proxy should | |||
not substitute it with its own address. No special actions | not substitute it with its own address. No special actions | |||
are required for supporting these protocols. For example, | are required for supporting these protocols. For example, | |||
[DHCPv6] is in this category. | [DHCPv6] is in this category. | |||
8. IANA Considerations | 8. IANA Considerations | |||
To support loop prevention over non-802 media, IANA should assign: | This document has no actions for IANA. | |||
1) a Protocol Number for RSTP, and | ||||
2) an IPv6 Link-Local Scope multicast address for All-RSTP- | ||||
Speakers. | ||||
9. Security Considerations | 9. Security Considerations | |||
Proxies are susceptible to the same kind of security issues that | Proxies are susceptible to the same kind of security issues that | |||
plague hosts using unsecured Neighbor Discovery or ARP. Even if | plague hosts using unsecured Neighbor Discovery or ARP. Even if | |||
these protocols are secured, the proxies may process unsecured | these protocols are secured, the proxies may process unsecured | |||
messages, and update the neighbor cache. Malicious nodes within | messages, and update the neighbor cache. Malicious nodes within | |||
the subnet can take advantage of this property, and hijack | the subnet can take advantage of this property, and hijack | |||
traffic. The threats are discussed in detail in [PSREQ]. | traffic. The threats are discussed in detail in [PSREQ]. | |||
As a result, securing Neighbor Discovery or ARP must take into | As a result, securing Neighbor Discovery or ARP must take into | |||
account the ability to proxy messages. This document does not | account the ability to proxy messages. This document does not | |||
Draft ND Proxy May 2005 | ||||
introduce any new requirements in this regard. | introduce any new requirements in this regard. | |||
Draft ND Proxy July 2005 | ||||
From an IPv6 perspective, RFC 2461 [ND] already defines the | From an IPv6 perspective, RFC 2461 [ND] already defines the | |||
ability to proxy Neighbor Advertisements. Since the ND packets | ability to proxy Neighbor Advertisements. Since the ND packets | |||
must be modified whenever the link-layer address formats are | must be modified whenever the link-layer address formats are | |||
different (as with PPP) or promiscuous reception is not possible | different (as with PPP) or promiscuous reception is not possible | |||
(as with 802.11), securing any solution in this space requires | (as with 802.11), securing any solution in this space requires | |||
that hosts have a secure relationship with the proxy. | that hosts have a secure relationship with the proxy. | |||
It is reasonable for nodes on the leaf subnet to have a secure | It is reasonable for nodes on the leaf subnet to have a secure | |||
relationship with the proxy, and accept ND packets from either the | relationship with the proxy, and accept ND packets from either the | |||
owner of a specific address (normal SEND), or which it can verify | owner of a specific address (normal SEND), or which it can verify | |||
skipping to change at page 17, line 4 | skipping to change at page 15, line 49 | |||
(including the router sending the RA) can have an address in the | (including the router sending the RA) can have an address in the | |||
subnet or it will not have connectivity with nodes on the | subnet or it will not have connectivity with nodes on the | |||
downstream link. This is because when a node on a downstream link | downstream link. This is because when a node on a downstream link | |||
tries to do Neighbor Discovery, and the proxy does not send the NS | tries to do Neighbor Discovery, and the proxy does not send the NS | |||
on the upstream link, it will never discover the neighbor on the | on the upstream link, it will never discover the neighbor on the | |||
upstream link. Similarly, if messages are not proxied during DAD, | upstream link. Similarly, if messages are not proxied during DAD, | |||
conflicts can occur. | conflicts can occur. | |||
Second, if the proxy assumes that no nodes on the upstream link | Second, if the proxy assumes that no nodes on the upstream link | |||
have addresses in the prefix, such a proxy could not be safely | have addresses in the prefix, such a proxy could not be safely | |||
Draft ND Proxy May 2005 | ||||
deployed without cooperation from the network administrator since | deployed without cooperation from the network administrator since | |||
it introduces a requirement that the router itself not have an | it introduces a requirement that the router itself not have an | |||
Draft ND Proxy July 2005 | ||||
address in the prefix. This rules out use in situations where | address in the prefix. This rules out use in situations where | |||
bridges and Network Address Translators (NATs) are used today, | bridges and Network Address Translators (NATs) are used today, | |||
which is the problem this document is directly addressing. | which is the problem this document is directly addressing. | |||
Instead, where a prefix is desired for use on one or more | Instead, where a prefix is desired for use on one or more | |||
downstream links in cooperation with the network administrator, | downstream links in cooperation with the network administrator, | |||
Prefix Delegation [PD] should be used instead. | Prefix Delegation [PD] should be used instead. | |||
11. Authors' Addresses | 11. Authors' Addresses | |||
Dave Thaler | Dave Thaler | |||
skipping to change at page 18, line 5 | skipping to change at page 17, line 5 | |||
12. Normative References | 12. Normative References | |||
[ARP] | [ARP] | |||
D. Plummer, "An Ethernet Address Resolution Protocol", STD | D. Plummer, "An Ethernet Address Resolution Protocol", STD | |||
37, RFC 826, November 1982. | 37, RFC 826, November 1982. | |||
[ARPPROXY] | [ARPPROXY] | |||
J. Postel, "Multi-LAN address resolution", RFC 925, October | J. Postel, "Multi-LAN address resolution", RFC 925, October | |||
1984. | 1984. | |||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
[BRIDGE] | [BRIDGE] | |||
T. Jeffree, editor, "Media Access Control (MAC) Bridges", | T. Jeffree, editor, "Media Access Control (MAC) Bridges", | |||
ANSI/IEEE Std 802.1D, 2004, | ANSI/IEEE Std 802.1D, 2004, | |||
http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. | http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. | |||
[DHCPv4] | [DHCPv4] | |||
R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, | R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, | |||
March 1997. | March 1997. | |||
skipping to change at page 19, line 5 | skipping to change at page 18, line 5 | |||
Carpenter, B. and K. Moore, "Connection of IPv6 Domains via | Carpenter, B. and K. Moore, "Connection of IPv6 Domains via | |||
IPv4 Clouds", RFC 3056, February 2001. | IPv4 Clouds", RFC 3056, February 2001. | |||
[DHCPAUTH] | [DHCPAUTH] | |||
Droms, R. and W. Arbaugh, Eds., "Autentication for DHCP | Droms, R. and W. Arbaugh, Eds., "Autentication for DHCP | |||
Messages", RFC 3118, June 2001. | Messages", RFC 3118, June 2001. | |||
[DHCPv6] | [DHCPv6] | |||
Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. | Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. | |||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
and M. Carney, "Dynamic Host Configuration Protocol for IPv6 | and M. Carney, "Dynamic Host Configuration Protocol for IPv6 | |||
(DHCPv6)", RFC 3315, July 2003. | (DHCPv6)", RFC 3315, July 2003. | |||
[NAT] | [NAT] | |||
Srisuresh, P. and K. Egevang, "Traditional IP Network Address | Srisuresh, P. and K. Egevang, "Traditional IP Network Address | |||
Translator (Traditional NAT)", RFC 3022, January 2001. | Translator (Traditional NAT)", RFC 3022, January 2001. | |||
[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host | [PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host | |||
Configuration Protocol (DHCP) version 6", RFC 3633, December | Configuration Protocol (DHCP) version 6", RFC 3633, December | |||
skipping to change at page 20, line 5 | skipping to change at page 19, line 5 | |||
15. Intellectual Property | 15. Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
to pertain to the implementation or use of the technology | to pertain to the implementation or use of the technology | |||
described in this document or the extent to which any license | described in this document or the extent to which any license | |||
under such rights might or might not be available; nor does it | under such rights might or might not be available; nor does it | |||
represent that it has made any independent effort to identify any | represent that it has made any independent effort to identify any | |||
such rights. Information on the procedures with respect to rights | such rights. Information on the procedures with respect to rights | |||
Draft ND Proxy May 2005 | Draft ND Proxy July 2005 | |||
in RFC documents can be found in BCP 78 and BCP 79. | in RFC documents can be found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use | attempt made to obtain a general license or permission for the use | |||
of such proprietary rights by implementers or users of this | of such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository | specification can be obtained from the IETF on-line IPR repository | |||
at http://www.ietf.org/ipr. | at http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention | The IETF invites any interested party to bring to its attention | |||
any copyrights, patents or patent applications, or other | any copyrights, patents or patent applications, or other | |||
proprietary rights that may cover technology that may be required | proprietary rights that may cover technology that may be required | |||
to implement this standard. Please address the information to the | to implement this standard. Please address the information to the | |||
IETF at ietf-ipr@ietf.org. | IETF at ietf-ipr@ietf.org. | |||
Draft ND Proxy July 2005 | ||||
Table of Contents | ||||
1: Introduction ............................................. 2 | ||||
1.1: SCENARIO 1: Wireless upstream .......................... 3 | ||||
1.2: SCENARIO 2: PPP upstream ............................... 4 | ||||
2: Terminology .............................................. 4 | ||||
3: Requirements ............................................. 5 | ||||
3.1: Non-requirements ....................................... 6 | ||||
4: Proxy Behavior ........................................... 7 | ||||
4.1: Forwarding Packets ..................................... 7 | ||||
4.1.1: Sending Packet Too Big Messages ...................... 8 | ||||
4.1.2: Proxying Packets With Link-Layer Addresses ........... 9 | ||||
4.1.3: IPv4 ARP Proxying .................................... 9 | ||||
4.1.3.1: ARP REQUEST Packets ................................ 9 | ||||
4.1.3.2: ARP REPLY Packets .................................. 9 | ||||
4.1.3.3: DHCPv4 Packets ..................................... 10 | ||||
4.1.4: IPv6 ND Proxying ..................................... 10 | ||||
4.1.4.1: ICMPv6 Neighbor Solicitations ...................... 10 | ||||
4.1.4.2: ICMPv6 Neighbor Advertisements ..................... 10 | ||||
4.1.4.3: ICMPv6 Router Advertisements ....................... 11 | ||||
4.1.4.4: ICMPv6 Redirects ................................... 11 | ||||
4.2: Originating Packets .................................... 12 | ||||
5: Example .................................................. 12 | ||||
6: Loop Prevention .......................................... 13 | ||||
7: Guidelines to proxy developers ........................... 14 | ||||
8: IANA Considerations ...................................... 14 | ||||
9: Security Considerations .................................. 14 | ||||
10: Appendix A: Comparison with Naive RA Proxy .............. 15 | ||||
11: Authors' Addresses ...................................... 16 | ||||
12: Normative References .................................... 16 | ||||
13: Informative References .................................. 17 | ||||
14: Full Copyright Statement ................................ 18 | ||||
15: Intellectual Property ................................... 18 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |