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.
7. Guidelines to Proxy Developers
Proxy developers will have to accommodate protocols or protocol
options (for example, new ICMP messages) that are developed in the
future, or protocols that are not mentioned in this document (for
example, proprietary protocols). This section prescribes guidelines
that can be used by proxy developers to accommodate protocols that
are not mentioned herein.
1) If a link-layer address carried in the payload of the
protocol can be used in the link-layer header of future
messages, then the proxy should substitute it with its own
address. For example, the link-layer address in NA messages is
used in the link-layer header for future messages, and,
hence, the proxy substitutes it with its own address.
For multicast packets, the link-layer address substituted
within the payload will be different for each outgoing
interface.
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
not substitute it with its own address. No special actions
are required for supporting these protocols. For example,
[DHCPv6] is in this category.
8. IANA Considerations
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
Unsecured Neighbor Discovery has a number of security issues, which
are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security
mechanisms that can protect Neighbor Discovery.
Proxies are susceptible to the same kind of security issues that
plague hosts using unsecured Neighbor Discovery. These issues
include hijacking traffic and denial-of-service within the subnet.
Malicious nodes within the subnet can take advantage of this
property, and hijack traffic. In addition, a Neighbor Discovery
proxy is essentially a legitimate man-in-the-middle, which implies
that there is a need to distinguish proxies from unwanted man-in-
the-middle attackers.
This document does not introduce any new mechanisms for the
protection of proxy Neighbor Discovery. That is, it does not provide
a mechanism from authorizing certain devices to act as proxies, and
it does not provide extensions to SEND to make it possible to use
both SEND and proxies at the same time. We note that RFC 2461 [ND]
already defines the ability to proxy Neighbor Advertisements, and
extensions to SEND are already needed to cover that case, independent
of this document.
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
subnet. This is because the modifications performed by the proxy
will invalidate the RSA Signature Option in a secured Neighbor
Discovery message, and cause SEND-capable nodes to either discard the
messages or treat them as unsecured. The latter is the desired
operation when SEND is used together with this specification, and it
ensures that SEND nodes within this environment can selectively
downgrade themselves to unsecure Neighbor Discovery when proxies are
present.
In the following, we outline some potential paths to follow when
defining a secure proxy mechanism.
It is reasonable for nodes on the leaf subnet to have a secure
relationship with the proxy and to accept ND packets either from the
owner of a specific address (normal SEND) or from a trusted proxy
that it can verify (see below).
For nodes on the external subnet, there is a trade-off between
security (where all nodes have a secure relationship with the proxy)
and privacy (where no nodes are aware that the proxy is a proxy). In
the case of a point-to-point external link (Scenario 2), however,
SEND may not be a requirement on that link.
Verifying that ND packets come from a trusted proxy requires an
extension to the SEND protocol and is left for future work [SPND],
but is similar to the problem of securing Router Advertisements that
is supported today. For example, a rogue node can send a Router
Advertisement to cause a proxy to disable its proxy behavior, and
hence cause denial-of-service to other nodes; this threat is covered
in Section 4.2.1 of [PSREQ].
Alternative designs might involve schemes where the right for
representing a particular host is delegated to the proxy, or where
multiple nodes can make statements on behalf of one address
[RINGSIG].
10. Acknowledgements
The authors wish to thank Jari Arkko for contributing portions of the
Security Considerations text.
11. Normative References
[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges",
ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/
getieee802/download/802.1D-2004.pdf.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[NODEREQ] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,
April 2006.
12. Informative References
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[BCP] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point
Protocol (PPP) Bridging Control Protocol (BCP)", RFC
3518, April 2003.
[DHCPv6] 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] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[PSREQ] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May
2004.
[RINGSIG] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying
using Multi-Key Cryptographically Generated Addresses
(MCGAs)", Work in Progress, August 2005.
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[SPND] Daley, G., "Securing Proxy Neighbour Discovery Problem
Statement", Work in Progress, February 2005.
Appendix A: Comparison with Naive RA Proxy
It has been suggested that a simple Router Advertisement (RA) proxy
would be sufficient, where the subnet prefix in an RA is "stolen" by
the proxy and applied to a downstream link instead of an upstream
link. Other ND messages are not proxied.
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.
Second, if the proxy assumes that no nodes on the upstream link have
addresses in the prefix, such a proxy could not be safely deployed
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.
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
Chirayu Patel
All Play, No Work
Bangalore, Karnataka 560038
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).