One document matched: draft-thaler-ipv6-ndproxy-00.txt
IPv6 Working Group D. Thaler
INTERNET-DRAFT M. Talwar
Expires December 2003 Microsoft
June 9, 2003
Bridge-like Neighbor Discovery Proxies (ND Proxy)
<draft-thaler-ipv6-ndproxy-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Expires December 2003 [Page 1]
Draft ND Proxy March 2003
Bridging multiple links into a single entity has several
operational advantages. A single subnet prefix is sufficient to
support multiple physical links. There is no need to allocate
subnet numbers to the different networks, simplifying management.
Bridging some types of media requires network-layer support,
however. This document describes these cases and specifies the
IP-layer support that enables bridging under these circumstances.
1. Introduction
IEEE 802 bridging, specified in [BRIDGE] is in widespread usage
today. However, classic bridging at the data-link layer has the
following limitations (among others):
o It requires the ports to support promiscuous mode. As a
result, an 802.11 segment cannot be bridged except at the
access point.
o It requires all ports to support the same type of link-layer
addressing (in particular, IEEE 802 addressing). For
example, an Ethernet segment and a PPP segment cannot be
bridged.
Under such conditions, multiple segments can still be bridged by
detecting and proxying specific messages at the network layer, and
forwarding all others. In the document, we specify the behavior
for such a proxy for IPv6 as well as IPv4, which is
indistinguishable (as much as possible) from a classic bridge. It
is expected that links will be bridged at the link layer using
classic bridge technology whenever possible and a single "bridge"
interface will be exposed to the IP layer, and that network layer
support for proxying between multiple interfaces is used only when
this is not possible. In the remainder of this document, a "proxy
interface" will be used to refer to an interface (which could
itself be a bridge interface) over which network layer proxying is
done as defined herein.
In contrast to [MLSR], in this document we make no distinction
between a "link" (in the classic IPv6 sense) and a "subnet". We
use the term "segment" to apply to a bridged component of the
link.
It has been suggested that a simple Router Advertisement (RA)
proxy would be sufficient, where the subnet prefix in an RA is
Expires December 2003 [Page 2]
Draft ND Proxy March 2003
"stolen" by the proxy and applied to a downstream link _instead
of_ an upstream link. 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. Second, as a result, such a proxy could
not be used without cooperation from the network administrator,
ruling out use in situations where bridges and Network Address
Translators (NATs) are used today. Instead, where a prefix is
desired for use on one or more downstream links in cooperation
with the network administrator, Prefix Delegation should be used
instead.
We now discuss requirements for the bridge-like proxy mechanism.
1.1. Requirements
Bridge-like proxy behavior is designed with the following
requirements in mind:
o Support connecting multiple segments with a single subnet
prefix.
o Support media which cannot be bridged at the link-layer.
o Do not require any changes to existing routers. That is, any
routers on the subnet should be unaware that the subnet is
being bridged. It should appear as if one host uses multiple
addresses.
o Provide full connectivity. For example, if there are
existing nodes (such as any routers on the subnet) which have
addresses in the subnet prefix, adding a bridge-like proxy
must allow bridged nodes to have full connectivity with
existing nodes on the subnet. If, on the other hand,
neighbor discovery messages were not proxied on the segment
containing a router or other node with an existing address,
then confusion, duplicate addresses, and lack of connectivity
could result.
o Prevent loops.
o Also work in the absense of any routers.
Expires December 2003 [Page 3]
Draft ND Proxy March 2003
o Support secure IPv6 neighbor discovery. This is discussed in
the Security Considerations section.
o Support both IPv6 and IPv4.
o Support nodes moving between segments. For example, a node
should be able to keep its address without seeing its address
as a duplicate due to any cache maintained at the proxy.
1.2. Non-requirements
The following items are not considered requirements, as they are
not met by classic bridges:
o Show up in a traceroute.
o Use the shortest path between two nodes on different
segments.
o Be able to use all available interfaces simultaneously.
Instead, bridging technology relies on disabling redundant
interfaces to prevent loops.
o Support differing MTUs in use on different segments. That
is, all segments on a bridged link must use the smallest MTU
of any segment. Note that the result of this is that in the
absence of cooperation of the network administrator (who can
configure routers with a smaller MTU to advertise in Router
Advertisements) a bridge-like IPv6 proxy can only connect
links with equal MTU, or where all routers are on segments
with the smallest MTU.
o Support connecting media on which Neighbor Discovery is not
possible. For example, some technologies such as 6to4 use an
algorithmic mapping from IPv6 address to the underlying link-
layer (IPv4 in this case) address, and hence cannot support
bridging arbitrary IP addresses.
The following additional items are not considered requirements for
this document:
o Support network-layer protocols other than IPv4 and IPv6. We
do not preclude such support, but it is not specified in this
document.
Expires December 2003 [Page 4]
Draft ND Proxy March 2003
o Support Neighbor Discovery, Router Discovery, or DHCPv4
packets using encryption with an ESP header. We also note
that the current methods for securing these protocols do not
use an ESP header. Where encryption is required, link-layer
encryption can be used on each segment.
o Support Redirects for off-subnet destinations that point to a
router on a different segment from the redirected host.
While this scenario would be desirable, no solution is
currently known which does not have undesirable side effects
outside the subnet. As a result, this feature is left as an
opportunity for future work.
2. Bridge-Like Proxy Behavior
In general, the proxy attempts to emulate a bridge as much as
possible, and augments this with IP-specific behavior for cases
which could not otherwise be handled.
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.
Loop prevention is done by having the proxy implement the Spanning
Tree Algorithm and Protocol as defined in [BRIDGE] on all proxy
interfaces.
As with all other interfaces, IPv4 and IPv6 maintain a neighbor
cache for each proxy interface, which will be used as described
below.
When any IP or ARP packet is received on a proxy interface, it
must be parsed to see whether it is known to be one of the
following types: ARP, IPv6 Neighbor Discovery, IPv6 Router
Discovery, IPv6 Redirects, or DHCPv4. These packets are ones that
can carry link-layer addresses, and hence must be proxied (as
described below) so that packets between nodes on different
segments can be received by the proxy and have the correct link-
layer address type on each segment.
When any other IP broadcast or multicast packet is received on a
proxy interface, in addition to any normal IP behavior such as
Expires December 2003 [Page 5]
Draft ND Proxy March 2003
being delivered locally, it is forwarded unchanged out all other
proxy interfaces on the same link. (As specified in [BRIDGE], the
proxy may instead support multicast learning and filtering but
this is optional.) In particular, the IPv4 TTL or IPv6 Hop Limit
is not updated, and no ICMP errors are sent as a result of
attempting this forwarding.
When any other IP unicast packet is received on a proxy interface,
if it is not locally destined then it is forwarded unchanged to
the proxy interface 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 errors 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.
Locally originated packets that are sent on a proxy interface also
follow the same rules as packets received on a proxy interface.
If no neighbor entry exists when a packet is to be locally
originated, an interface can be chosen in any implementation-
specific fashion. Once the neighbor is resolved, the actual
interface will be discovered and the packet will be sent on that
interface.
The special types enumerated above (ARP, etc.) that carry link-
layer addresses are handled, once it is determined that the packet
is either multicast/broadcast or else is not locally destined (if
unicast), by generating a proxy packet that contains the proxy's
link-layer address instead. As with all forwarded packets, the
link-layer header is also new. Any Authentication Header would
also be removed, and a new one may be added as discussed below
under Security Considerations.
In addition, 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 NA is generated immediately. Instead the NS
is proxied and the NA will be proxied when it is received. This
ensures that the proxy does not interfere with hosts moving from
one segment to another since it never responds to an NS based on
its own cache.
Expires December 2003 [Page 6]
Draft ND Proxy March 2003
If the received packet is an ICMPv6 Neighbor Advertisement, the
neighbor cache on the receiving interface is first updated as if
the NA were locally destined, and then the Override bit is cleared
in the proxied packet.
For IPv4, ARP packets are similarly proxied (except that no
Override bit exists to clear).
If the received packet is a DHCPv4 DISCOVER or REQUEST message,
then instead of changing the client's hardware address in the
payload, the BROADCAST (B) flag is set in the proxied packet.
This ensures that the proxy will be able to receive and proxy the
response.
If the received packet is an ICMPv6 Redirect message, then the
proxied packet should be modified as follows. If the proxy has a
valid (i.e., not INCOMPLETE) neighbor entry for the target address
on the same interface as the redirected host, then the TLLA option
in the proxied Redirect simply contains the link-layer address of
the target as found in the proxy's neighbor entry, since the
redirected host may reach the target address directly. Otherwise,
if the proxy has a valid neighbor entry for the target address on
some other interface, then the TLLA option in the proxied packet
contains the link-layer address of the proxy on the sending
interface, since the redirected host must reach the target address
through the proxy. Otherwise, the proxy has no valid neighbor
entry for the target address, and the proxied packet contains no
TLLA option, which will cause the redirected host to perform
neighbor discovery for the target address.
2.1. Example
Consider the following topology, where A and B are nodes on
separate segments which are connected by a bridge-like proxy P:
A---|---P---|---B
a p1 p2 b
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
through the actions that happen when A attempts to send an initial
IPv6 packet to B.
A first does a route lookup on the destination address B. This
Expires December 2003 [Page 7]
Draft ND Proxy March 2003
matches the on-link subnet prefix, and a destination cache entry
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
link-layer address and sends a Neighbor Solicitation (NS) to the
solicited-node multicast address for B. The SLLA option in the
solicitation contains A's link-layer address.
P receives the solicitation (since it is receiving all link-layer
multicast packets) and processes it as it would any multicast
packet by forwarding it out to other segments on the link.
However, before actually sending the packet, it determines if the
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
its link-layer address. It also creates a neighbor entry for B
(on an arbitrary proxy interface) in the INCOMPLETE state. Since
the packet is multicast, P then needs to proxy the NS out all
other proxy interfaces on the subnet. Before sending the packet
out interface 2, it replaces the link-layer address in the SLLA
option with its own link-layer address, p2.
B receives this NS, processing it as usual. Hence it creates a
neighbor entry for A mapping it to the link-layer address p2. It
responds with a Neighbor Advertisement (NA) sent to A containing
B's link-layer address b. The NA is sent using A's neighbor
entry, i.e. to the link-layer address p2.
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
the neighbor cache. However, before actually sending the packet
out, it inspects it to determine if the packet being sent is one
which requires proxying. Since it is an NA, it updates its
neighbor entry for B to be REACHABLE and records the link-layer
address b. P then replaces the link-layer address in the TLLA
option with its own link-layer address on the outgoing interface,
p1. It also clears the Override bit, since the NA is being
proxied. The packet is then sent out interface 1.
A receives this NA, processing it as usual. Hence it creates a
neighbor entry for B on interface 2 in the REACHABLE state and
records the link-layer address p1.
Expires December 2003 [Page 8]
Draft ND Proxy March 2003
3. Security Considerations
Securing neighbor discovery must take into account the ability to
proxy messages. This document does not introduce any new
requirements in this regard, since RFC 2461 [ND] already defines
the ability to proxy Neighbor Advertisements, specifying that the
Override bit is always clear in a proxied advertisement. When a
receiver sees that the Override bit is clear, however, it
typically cannot tell whether the advertisement was for an anycast
address, or whether the advertisement was proxied, or both. As a
result, secure neighbor discovery must take this into account.
The threats are discussed in detail in [PSREQ]. The requirements
for securing proxied Neighbor Advertisements are similar to those
for securing Router Advertisements, since the receiver must verify
that the advertisement came from a valid router/proxy, rather than
from the owner of a specific address.
4. Authors' Addresses
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Mohit Talwar
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
5. Normative References
[ARP]
D. Plummer, "An Ethernet Address Resolution Protocol", STD
37, RFC 826, November 1982.
[BRIDGE]
T. Jeffree, editor, "Media Access Control (MAC) Bridges",
ANSI/IEEE Std 802.1D, 1998,
Expires December 2003 [Page 9]
Draft ND Proxy March 2003
http://standards.ieee.org/getieee802/download/802.1D-1998.pdf.
[DHCPv4]
R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
6. Informative References
[MLSR]
Thaler, D., and C. Huitema, "Multi-link Subnet Support in
IPv6", Work in progress, draft-ietf-ipv6-multilink-
subnets-00.txt, June 2002.
[PSREQ]
Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery trust models and threats", Work in progress, draft-
ietf-send-psreq-03.txt, April 2003.
7. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
Expires December 2003 [Page 10]
Draft ND Proxy March 2003
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires December 2003 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:24 |