Default Router Preferences and More-Specific Routes
RFC 4191

 
Document Type RFC - Proposed Standard (November 2005; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4191 (Proposed Standard)
Telechat date
Responsible AD Margaret Wasserman
Send notices to <bob.hinden@nokia.com>, <margaret@thingmagic.com>
Network Working Group                                          R. Draves
Request for Comments: 4191                                     D. Thaler
Category: Standards Track                                      Microsoft
                                                           November 2005

          Default Router Preferences and More-Specific Routes

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes an optional extension to Router Advertisement
   messages for communicating default router preferences and more-
   specific routes from routers to hosts.  This improves the ability of
   hosts to pick an appropriate router, especially when the host is
   multi-homed and the routers are on different links.  The preference
   values and specific routes advertised to hosts require administrative
   configuration; they are not automatically derived from routing
   tables.

1.  Introduction

   Neighbor Discovery [RFC2461] specifies a conceptual model for hosts
   that includes a Default Router List and a Prefix List.  Hosts send
   Router Solicitation messages and receive Router Advertisement
   messages from routers.  Hosts populate their Default Router List and
   Prefix List based on information in the Router Advertisement
   messages.  A conceptual sending algorithm uses the Prefix List to
   determine if a destination address is on-link and uses the Default
   Router List to select a router for off-link destinations.

   In some network topologies where the host has multiple routers on its
   Default Router List, the choice of router for an off-link destination
   is important.  In some situations, one router may provide much better
   performance than another for a destination.  In other situations,
   choosing the wrong router may result in a failure to communicate.
   (Section 5 gives specific examples of these scenarios.)

Draves & Thaler             Standards Track                     [Page 1]
RFC 4191      Router Preferences and More-Specific Routes  November 2005

   This document describes an optional extension to Neighbor Discovery
   Router Advertisement messages for communicating default router
   preferences and more-specific routes from routers to hosts.  This
   improves the ability of hosts to pick an appropriate router for an
   off-link destination.

   Note that since these procedures are applicable to hosts only, the
   forwarding algorithm used by the routers (including hosts with
   enabled IP forwarding) is not affected.

   Neighbor Discovery provides a Redirect message that routers can use
   to correct a host's choice of router.  A router can send a Redirect
   message to a host, telling it to use a different router for a
   specific destination.  However, the Redirect functionality is limited
   to a single link.  A router on one link cannot redirect a host to a
   router on another link.  Hence, Redirect messages do not help multi-
   homed (through multiple interfaces) hosts select an appropriate
   router.

   Multi-homed hosts are an increasingly important scenario, especially
   with IPv6.  In addition to a wired network connection, like Ethernet,
   hosts may have one or more wireless connections, like 802.11 or
   Bluetooth.  In addition to physical network connections, hosts may
   have virtual or tunnel network connections.  For example, in addition
   to a direct connection to the public Internet, a host may have a
   tunnel into a private corporate network.  Some IPv6 transition
   scenarios can add additional tunnels.  For example, hosts may have
   6to4 [RFC3056] or configured tunnel [RFC2893] network connections.

   This document requires that the preference values and specific routes
   advertised to hosts require explicit administrative configuration.
   They are not automatically derived from routing tables.  In
   particular, the preference values are not routing metrics and it is
   not recommended that routers "dump out" their entire routing tables
   to hosts.

   We use Router Advertisement messages, instead of some other protocol
   like RIP [RFC2080], because Router Advertisements are an existing
   standard, stable protocol for router-to-host communication.
   Piggybacking this information on existing message traffic from
   routers to hosts reduces network overhead.  Neighbor Discovery shares
   with Multicast Listener Discovery the property that they both define
Show full document text