preferences and/or more specific routes in Routing Advertisements
typically does not know which kind of nodes (Type A, B, and/or C)
will be connected to its links. This requires that the administrator
configure the settings that will work in an optimal fashion
regardless of which kinds of nodes will be attached. Two examples of
how to do so follow.
5. Examples
5.1. Best Router for ::/0 vs Router Least Likely to Redirect
The best router for the default route is the router with the best
route toward the wider Internet. The router least likely to redirect
traffic depends on the actual traffic usage. The two concepts can be
different when the majority of communication actually needs to go
through some other router.
For example, consider a situation in which you have a link with two
routers, X and Y. Router X is the best for 2002::/16. (It’s your
6to4 site gateway.) Router Y is the best for ::/0. (It connects to
the native IPv6 Internet.) Router X forwards native IPv6 traffic to
router Y; router Y forwards 6to4 traffic to router X. If most
traffic from this site is sent to 2002:/16 destinations, then router
X is the one least likely to redirect.
To make type A hosts work well, both routers should advertise
themselves as default routers. In particular, if router Y goes down,
type A hosts should send traffic to router X to maintain 6to4
connectivity, so router X and router Y need to be default routers.
To make type B hosts work well, router X should advertise itself with
a High default router preference. This will cause type B hosts to
prefer router X, minimizing the number of redirects.
To make type C hosts work well, router X should in addition advertise
the ::/0 route with a Low preference and the 2002::/16 route with a
Medium preference. A type C host will end up with three routes in
its routing table: ::/0 -> router X (Low), ::/0 -> router Y (Medium),
2002::/16 -> router X (Medium). It will send 6to4 traffic to router
X and other traffic to router Y. Type C hosts will not cause any
redirects.
Note that when type C hosts process the Router Advertisement from
router X, the Low preference for ::/0 overrides the High default
router preference. If the ::/0 specific route were not present, then
a type C host would apply the High default router preference to its
::/0 route to router X.
5.2. Multi-Homed Host and Isolated Network
In another scenario, a multi-homed host is connected to the Internet
via router X on one link and to an isolated network via router Y on
another link. The multi-homed host might have a tunnel into a
firewalled corporate network, or it might be directly connected to an
isolated test network.
In this situation, a type A multi-homed host (which has no default
router preferences or more-specific routes) will have no way to
intelligently choose between routers X and Y on its Default Router
List. Users of the host will see unpredictable connectivity
failures, depending on the destination address and the choice of
router.
If the routers are configured appropriately, a multi-homed type B
host in this same situation would have stable Internet connectivity,
but would have no connectivity to the isolated test network.
If the routers are configured appropriately, a multi-homed type C
host in this same situation can correctly choose between routers X
and Y. For example, router Y on the isolated network should
advertise a Route Information Option for the isolated network prefix.
It might not advertise itself as a default router at all (zero Router
Lifetime), or it might advertise itself as a default router with a
Low preference. Router X should advertise itself as a default router
with a Medium preference.
6. Security Considerations
A malicious node could send Router Advertisement messages, specifying
a High Default Router Preference or carrying specific routes, with
the effect of pulling traffic away from legitimate routers. However,
a malicious node could easily achieve this same effect in other ways.
For example, it could fabricate Router Advertisement messages with a
zero Router Lifetime from the other routers, causing hosts to stop
using the other routes. By advertising a specific prefix, this
attack could be carried out in a less noticeable way. However, this
attack has no significant incremental impact on Internet
infrastructure security.
A malicious node could also include an infinite lifetime in a Route
Information Option causing the route to linger indefinitely. A
similar attack already exists with Prefix Information Options in RFC
2461, where a malicious node causes a prefix to appear as on-link
indefinitely, resulting in a lack of connectivity if it is not. In
contrast, an infinite lifetime in a Route Information Option will
cause router reachability probing to continue indefinitely, but will
not result in a lack of connectivity.
Similarly, a malicious node could also try to overload hosts with a
large number of routes in Route Information Options, or with very
frequent Route Advertisements. Again, this same attack already
exists with Prefix Information Options.
[RFC3756] provides more details on the trust models, and there is
work in progress in the SEND WG on securing router discovery messages
that will address these problems.
7. IANA Considerations
Section 2.3 defines a new Neighbor Discovery [RFC2461] option, the
Route Information Option, which has been assigned the value 24 within
the numbering space for IPv6 Neighbor Discovery Option Formats.
8. Acknowledgements
The authors would like to acknowledge the contributions of Balash
Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian
Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir
Segaric, and Brian Zill. The packet diagrams are derived from
Neighbor Discovery [RFC2461].
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
10. Informative References
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May
2004.
Authors’ Addresses
Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 2268
EMail: richdr@microsoft.com
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.