Provided by: radvd_2.16-3_amd64 bug

NAME

       radvd.conf - configuration file of the router advertisement daemon radvd

DESCRIPTION

       This  file describes the information which is included in the router advertisement (RA) of
       a specific interface.

       The file contains one or more interface definitions of the form:

       interface name {
            list of interface specific options
            list of prefix definitions
            list of clients (IPv6 addresses) to advertise to
            list of route definitions
            list of RDNSS definitions
            list of DNSSL definitions
            list of ABRO definitions
            list of acceptable RA source addresses
       };

       All the possible interface specific options are detailed below.  Each  option  has  to  be
       terminated by a semicolon.

       Prefix definitions are of the form:

       prefix prefix/length {
            list of prefix specific options
       };

       Prefix  can  be  network prefix or the address of the interface.  The address of interface
       should be used when using Mobile IPv6 extensions.

       Special prefix "::/64" is also supported on systems that implement getifaddrs() (on  other
       systems,  configuration  activation  fails and radvd exits).  When configured, radvd picks
       all non-link-local prefix assigned to the interface and starts advertising it.   This  may
       be  applicable  in non-6to4 scenarios where the upstream prefix might change.  This option
       is incompatible with Base6to4Interface option.  AdvRouterAddr  option  is  always  enabled
       when this configuration is used.

       All  the  possible  prefix  specific  options  are described below.  Each option has to be
       terminated by a semicolon.

       Decimal  values  are  allowed   only   for   MinDelayBetweenRAs,   MaxRtrAdvInterval   and
       MinRtrAdvInterval.  Decimal values should be used only when using Mobile IPv6 extensions.

       Route definitions are of the form:

       route prefix/length {
            list of route specific options
       };

       The  prefix  of  a  route definition should be network prefix; it can be used to advertise
       more specific routes to the hosts.

       RDNSS (Recursive DNS server) definitions are of the form:

       RDNSS ip [ip] [ip] {
            list of rdnss specific options
       };

       DNSSL (DNS Search List) definitions are of the form:

       DNSSL suffix [suffix] [suffix] [...] {
            list of dnssl specific options
       };

       By default radvd will send route advertisements so that every node on  the  link  can  use
       them.   The list of clients (IPv6 address) to advertise to, and accept route solicitations
       from can be configured.  If done, radvd does not  send  send  messages  to  the  multicast
       addresses  but  to  the  configured  unicast  addresses  only.   Solicitations  from other
       addresses are refused.  This is similar to UnicastOnly but includes periodic messages  and
       incoming client access configuration.  See examples section for a use case of this.

       The definitions are of the form:

       clients {
               list of IPv6 addresses
       };

       By  default  radvd  will  use the first link-local address for the interface as the source
       address for route advertisements. This can be overwritten by manually setting the list  of
       acceptable  source addresses. If done, radvd will use the first address from the interface
       that is present in the configured source addresses only. This functionality will NOT spoof
       the source address, but may be useful in combination with VRRP or other functionality that

       AdvRASrcAddress {
               list of IPv6 addresses
       };

       ABRO (Authoritative Border Router Option) definitions are of the form:

       abro IPv6-address {
               list of abro specific options
       };

INTERFACE SPECIFIC OPTIONS

       IgnoreIfMissing on|off

              A  flag  indicating whether or not the interface is ignored if it does not exist at
              start-up.  By default, radvd exits.

              This is useful for dynamic interfaces which are not active  when  radvd  starts  or
              which are dynamically disabled and re-enabled during the time radvd runs.

              Current versions of radvd automatically try to re-enable interfaces.

              Enabling IgnoreIfMissing also quenches certain warnings in log messages relating to
              missing interfaces.

              Default: on

       AdvSendAdvert on|off

              A flag indicating whether or not the router sends  periodic  router  advertisements
              and responds to router solicitations.

              This  option  no  longer has to be specified first, but it needs to be on to enable
              advertisement on this interface.

              Default: off

       UnicastOnly on|off

              Indicates that the interface link type only supports unicast.   This  will  prevent
              unsolicited advertisements from being sent, and will cause solicited advertisements
              to be unicast to the soliciting node.  This option is necessary for  non-broadcast,
              multiple-access links, such as ISATAP.

              Default: off

       MaxRtrAdvInterval seconds

              The   maximum   time   allowed   between   sending   unsolicited  multicast  router
              advertisements from the interface, in seconds.

              Must be no less than 4 seconds and no greater than 1800 seconds.

              Minimum when using Mobile IPv6 extensions: 0.07.

              For values less than 0.2 seconds, 0.02 seconds is added to account  for  scheduling
              granularities as specified in RFC3775.

              Default: 600 seconds

       MinRtrAdvInterval seconds

              The   minimum   time   allowed   between   sending   unsolicited  multicast  router
              advertisements from the interface, in seconds.

              Must be no less than 3 seconds and no greater than 0.75 * MaxRtrAdvInterval.

              Minimum when using Mobile IPv6 extensions: 0.03.

              Default: 0.33 * MaxRtrAdvInterval

       MinDelayBetweenRAs seconds

              The minimum time allowed between sending multicast router advertisements  from  the
              interface, in seconds.

              This  applies to solicited multicast RAs.  This is defined as the protocol constant
              MIN_DELAY_BETWEEN_RAS in RFC4861.  MIPv6 redefines this parameter to have a minimum
              of 0.03 seconds.

              Minimum when using Mobile IPv6 extensions: 0.03.

              Default: 3

       AdvManagedFlag on|off

              When   set,   hosts   use   the   administered   (stateful)  protocol  for  address
              autoconfiguration in addition  to  any  addresses  autoconfigured  using  stateless
              address autoconfiguration.  The use of this flag is described in RFC 4862.

              Default: off

       AdvOtherConfigFlag on|off

              When  set,  hosts use the administered (stateful) protocol for autoconfiguration of
              other (non-address) information.  The use of this flag is described in RFC 4862.

              Default: off

       AdvLinkMTU integer

              The MTU option is used in  router advertisement messages to insure that  all  nodes
              on  a  link  use  the  same MTU value in those cases where the link MTU is not well
              known.

              If specified, i.e. not 0, must not be smaller than 1280 and not  greater  than  the
              maximum MTU allowed for this link (e.g. ethernet has a maximum MTU of 1500. See RFC
              4864).

              Default: 0

       AdvReachableTime milliseconds

              The time, in milliseconds, that a node assumes a neighbor is reachable after having
              received   a  reachability  confirmation.   Used  by  the  Neighbor  Unreachability
              Detection algorithm (see  Section  7.3  of  RFC  4861).   A  value  of  zero  means
              unspecified (by this router).

              Must be no greater than 3,600,000 milliseconds (1 hour).

              Default: 0

       AdvRetransTimer milliseconds

              The  time,  in  milliseconds, between retransmitted Neighbor Solicitation messages.
              Used by address resolution and the Neighbor Unreachability Detection algorithm (see
              Sections  7.2  and  7.3  of  RFC 4861).  A value of zero means unspecified (by this
              router).

              Default: 0

       AdvCurHopLimit integer

              The default value that should be placed in the Hop Count field of the IP header for
              outgoing  (unicast) IP packets.  The value should be set to the current diameter of
              the Internet.  The value zero means unspecified (by this router).

              Default: 64

       AdvDefaultLifetime seconds

              The lifetime associated with the default router in units of seconds.   The  maximum
              value  corresponds to 18.2 hours.  A lifetime of 0 indicates that the router is not
              a default router and should not appear on the  default  router  list.   The  router
              lifetime  applies  only to the router's usefulness as a default router; it does not
              apply to information contained in other message fields or  options.   Options  that
              need time limits for their information include their own lifetime fields.

              Must be either zero or between MaxRtrAdvInterval and 9000 seconds.

              Default: 3 * MaxRtrAdvInterval (Minimum 1 second).

       AdvDefaultPreference low|medium|high

              The  preference  associated  with the default router, as either "low", "medium", or
              "high".

              Default: medium

       AdvSourceLLAddress on|off

              When set, the link-layer address of the outgoing interface is included in the RA.

              Default: on

       AdvHomeAgentFlag on|off

              When set, indicates that sending router is able to serve as Mobile IPv6 Home Agent.
              When  set,  minimum  limits specified by Mobile IPv6 are used for MinRtrAdvInterval
              and MaxRtrAdvInterval.

              Default: off

       AdvHomeAgentInfo on|off

              When set, Home Agent Information Option (specified by Mobile IPv6) is  included  in
              Router Advertisements.  AdvHomeAgentFlag must also be set when using this option.

              Default: off

       HomeAgentLifetime seconds

              The  length  of  time in seconds (relative to the time the packet is sent) that the
              router is offering Mobile IPv6 Home Agent services.  A value 0 must  not  be  used.
              The  maximum  lifetime  is  65520 seconds (18.2 hours).  This option is ignored, if
              AdvHomeAgentInfo is not set.

              If both HomeAgentLifetime and HomeAgentPreference are set to their default  values,
              Home Agent Information Option will not be sent.

              Default: AdvDefaultLifetime

       HomeAgentPreference integer

              The  preference  for  the  Home  Agent  sending  this Router Advertisement.  Values
              greater than 0 indicate more preferable Home Agent, values  less  than  0  indicate
              less  preferable  Home  Agent.   This option is ignored, if AdvHomeAgentInfo is not
              set.

              If both HomeAgentLifetime and HomeAgentPreference are set to their default  values,
              Home Agent Information Option will not be sent.

              Default: 0

       AdvMobRtrSupportFlag on|off

              When set, the Home Agent signals it supports Mobile Router registrations (specified
              by NEMO Basic).  AdvHomeAgentInfo must also be set when using this option.

              Default: off

       AdvIntervalOpt on|off

              When set, Advertisement Interval Option (specified by Mobile IPv6) is  included  in
              Router  Advertisements.  When set, minimum limits specified by Mobile IPv6 are used
              for MinRtrAdvInterval and MaxRtrAdvInterval.

              The advertisement interval is based on the configured  MaxRtrAdvInterval  parameter
              except  where  this is less than 200ms.  In this case, the advertised interval is (
              MaxRtrAdvInterval + 20ms ).

              Default: off

PREFIX SPECIFIC OPTIONS

       AdvOnLink on|off

              When set, indicates that this prefix can be used for on-link  determination.   When
              not  set  the advertisement makes no statement about on-link or off-link properties
              of the prefix.  For instance, the prefix might be used  for  address  configuration
              with  some  of the addresses belonging to the prefix being on-link and others being
              off-link.

              Default: on

       AdvAutonomous on|off

              When  set,  indicates  that  this  prefix  can  be  used  for  autonomous   address
              configuration as specified in RFC 4862.

              Default: on

       AdvRouterAddr on|off

              When  set,  indicates  that  the  address  of  interface is sent instead of network
              prefix, as is required by Mobile IPv6.   When  set,  minimum  limits  specified  by
              Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInterval.

              Default: off

       AdvValidLifetime seconds|infinity

              The  length  of  time in seconds (relative to the time the packet is sent) that the
              prefix is valid for the purpose  of  on-link  determination.   The  symbolic  value
              infinity  represents  infinity  (i.e.  a  value of all one bits (0xffffffff)).  The
              valid lifetime is also used by RFC 4862.

              Note that clients will  ignore  AdvValidLifetime  of  an  existing  prefix  if  the
              lifetime is below two hours, as required in RFC 4862 Section 5.5.3 point e).

              Note: RFC4861's suggested default value is significantly longer: 30 days.

              Default: 86400 seconds (1 day)

       AdvPreferredLifetime seconds|infinity

              The  length  of  time  in  seconds  (relative  to the time the packet is sent) that
              addresses generated from the prefix via stateless address autoconfiguration  remain
              preferred.   The  symbolic  value infinity represents infinity (i.e. a value of all
              one bits (0xffffffff)).  See RFC 4862.

              Note: RFC4861's suggested default value is significantly longer: 7 days.

              Default: 14400 seconds (4 hours)

       DeprecatePrefix on|off

              Upon shutdown, this option will cause radvd to deprecate the prefix  by  announcing
              it  in  the  radvd  shutdown RA with a zero preferred lifetime and a valid lifetime
              slightly greater than 2 hours. This will encourage end-nodes using this  prefix  to
              deprecate  any  associated addresses immediately. Note that this option should only
              be used when only one router is announcing the prefix onto the link, otherwise end-
              nodes  will deprecate associated addresses despite the prefix still being valid for
              preferred use.

              See RFC4862, section 5.5.3., "Router Advertisement Processing", part (e).

              Default: off

       DecrementLifetimes on|off

              This option causes radvd to  decrement  the  values  of  the  preferred  and  valid
              lifetimes  for the prefix over time. The lifetimes are decremented by the number of
              seconds since the last RA. If radvd receives a SIGUSR1 signal, it  will  reset  the
              values  of  the  preferred  and  valid lifetimes back to the initial values used by
              radvd when it started. If radvd never receives a SIGUSR1 signal, it  will  continue
              to decrement the lifetimes until the preferred lifetime reaches zero. After a final
              RA with a zero value preferred lifetime, radvd will cease to announce  the  prefix.
              If a SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then re-
              appear in the RAs.

              This option is intended to be used in conjunction with  a  DHCPv6  client  that  is
              using  the  Identity  Association for Prefix Delegation (IA_PD) option to acquire a
              prefix from a Delegating Router for use by a Requesting Router. In  this  scenario,
              the  prefix(es)  from within the delegated prefix that are announced by radvd would
              age in parallel with and at the same rate as the delegated prefix,  and  expire  at
              approximately the same time, if the delegated prefix's life isn't extended.

              See  RFC3633,  "IPv6  Prefix Options for Dynamic Host Configuration Protocol (DHCP)
              version 6".

              Default: off

       Base6Interface name

              If this options is specified, this prefix will be combined with the IPv6 address of
              the interface specified by name.  The resulting prefix length will be 64.

       Base6to4Interface name

              If  this option is specified, this prefix will be combined with the IPv4 address of
              interface name to produce a valid 6to4 prefix. The first 16  bits  of  this  prefix
              will  be  replaced  by 2002 and the next 32 bits of this prefix will be replaced by
              the IPv4 address assigned to interface name at configuration time. The remaining 80
              bits  of  the  prefix (including the SLA ID) will be advertised as specified in the
              configuration file.  See the next section for an example.

              If interface name is not available at configuration time, a warning will be written
              to the log and this prefix will be disabled until radvd is reconfigured.

              This  option enables systems with dynamic IPv4 addresses to update their advertised
              6to4 prefixes simply by restarting radvd or sending a SIGHUP signal to cause  radvd
              to reconfigure itself.

              Note  that 6to4 prefixes derived from dynamically-assigned IPv4 addresses should be
              advertised with a significantly shorter  lifetime  (see  the  AdvValidLifetime  and
              AdvPreferredLifetime options).

              For more information on 6to4, see RFC 3056.

              Default: 6to4 is not used

ROUTE SPECIFIC OPTIONS

       AdvRouteLifetime seconds|infinity

              The  lifetime  associated  with  the route in units of seconds.  The symbolic value
              infinity represents infinity (i.e. a value of all one bits (0xffffffff)).

              Default: 3 * MaxRtrAdvInterval

       AdvRoutePreference low|medium|high

              The preference associated with the default router, as either  "low",  "medium",  or
              "high".

              Default: medium

       RemoveRoute on|off

              Upon  shutdown,  announce this route with a zero second lifetime. This should cause
              the route to be immediately removed from the receiving end-nodes' route table.

              Default: on

RDNSS SPECIFIC OPTIONS

       AdvRDNSSLifetime seconds|infinity
              The maximum duration how long the RDNSS entries are used  for  name  resolution.  A
              value  of  0 means the nameserver must no longer be used. The value, if not 0, must
              be at least MaxRtrAdvInterval.  To ensure stale RDNSS info gets removed in a timely
              fashion, this should not be greater than 2*MaxRtrAdvInterval.

              Default: 2*MaxRtrAdvInterval

       FlushRDNSS on|off

              Upon  shutdown, announce the RDNSS entries with a zero second lifetime. This should
              cause the RDNSS addresses to be immediately removed from  the  end-nodes'  list  of
              Recursive DNS Servers.

              Default: on

DNSSL SPECIFIC OPTIONS

       AdvDNSSLLifetime seconds|infinity;
              The  maximum  duration  how long the DNSSL entries are used for name resolution.  A
              value of 0 means the suffix should no longer be used.  The value, if not 0, must be
              at  least  MaxRtrAdvInterval.   To ensure stale DNSSL info gets removed in a timely
              fashion, this should not be greater than 2*MaxRtrAdvInterval.

              Default: 2*MaxRtrAdvInterval

       FlushDNSSL on|off

              Upon shutdown, announce the DNSSL entries with a zero second lifetime. This  should
              cause  the  DNSSL  entries to be immediately removed from the end-nodes' DNS search
              list.

              Default: on

ABRO SPECIFIC OPTIONS

       AdvValidLifeTime seconds
              The time in units of that the set of border router information is valid.   A  value
              of all zero bits assumes a default value of 10,000(~one week).

       AdvVersionLow, AdvVersionHigh unsignedinteger
              Both  forms  32-bit unsigned version number corresponding to the set of information
              contained in RA message.

EXAMPLES

       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
               };
       };

       It says that router advertisement daemon should advertise (AdvSendAdvert on;)  the  prefix
       2001:db8:0:1::  which has a length of 64 on the interface eth0.  Also the prefix should be
       marked as autonomous (AdvAutonomous on;) and as on-link (AdvOnLink on;).   All  the  other
       options are left on their default values.

       To support movement detection of Mobile IPv6 Mobile Nodes, the address of interface should
       be used instead of network prefix:

       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::4/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
                       AdvRouterAddr on;
               };
       };

       For 6to4 support, include the Base6to4Interface option in each prefix section. When  using
       a  dynamic  IPv4  address,  set  small  prefix  lifetimes  to prevent hosts from retaining
       unreachable prefixes after a new IPv4 address has been assigned.  When advertising to on a
       dynamic interface (e.g., Bluetooth), skip the interface if it is not active yet.

       interface bnep0
       {
               IgnoreIfMissing on;
               AdvSendAdvert on;

               # Advertise at least every 30 seconds
               MaxRtrAdvInterval 30;

               prefix 0:0:0:5678::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
                       Base6to4Interface ppp0;

                       # Very short lifetimes for dynamic addresses
                       AdvValidLifetime 300;
                       AdvPreferredLifetime 120;
               };
       };

       Since  6to4  is  enabled, the prefix will be advertised as 2002:WWXX:YYZZ:5678::/64, where
       WW.XX.YY.ZZ is the IPv4 address of ppp0 at configuration time. (IPv6 addresses are written
       in  hexadecimal  whereas  IPv4  addresses  are  written  in  decimal,  so the IPv4 address
       WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)

       In this specific case, the configuration scripts may send HUP signal to radvd when  taking
       bnep0 up or down to notify about the status; in the current radvd releases, sending HUP is
       no longer mandatory when the link comes back up.

       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
               };
               clients
               {
                       fe80::21f:16ff:fe06:3aab;
                       fe80::21d:72ff:fe96:aaff;
               };
       };

       This  configuration  would  only  announce  the  prefix  to  fe80::21f:16ff:fe06:3aab  and
       fe80::21d:72ff:fe96:aaff.  Furthermore, all RA requests of other clients are denied.

       This  may  come  in handy if you want to roll out IPv6 only partially because some clients
       are broken or untested.

       For ABRO support
       interface lowpan0
       {
            AdvSendAdvert on;
            UnicastOnly on;
            AdvCurHopLimit 255;
            prefix 2001:0db8:0100:f101::/64 {
                 AdvOnLink on;
                 AdvAutonomous on;
                 AdvRouterAddr on;
            };
            abro fe80::a200:0:0:1/64 {
                 AdvVersionLow 10;
                 AdvVersionHigh 2;
                 AdvValidLifeTime 2;
            };
       };

FILES

       /usr/sbin/radvd
       /etc/radvd.conf
       /var/run/radvd.pid
       /var/log/radvd.log

CREDIT

       The description of the different flags and variables is in  large  parts  taken  from  RFC
       4861.

RFCS

       Narten,  T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version
       6 (IPv6)", RFC 4861, September 2007.

       Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC  4862,
       September 2007.

       Deering,  S.,  and  R.  Hinden, "IP Version 6 Addressing Architecture", RFC 4291, February
       2006.

       Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol (ICMPv6)  for  the
       Internet Protocol Version 6 (IPv6)", RFC 4443, March 2006.

       Crawford,  M.,  "Transmission  of IPv6 Packets over Ethernet Networks", RFC 2464, December
       1998.

       Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC  3056,  February
       2001. (6to4 specification)

       Draves,  R.,  D.  Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191,
       November 2005.

       Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

       Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network Mobility (NEMO) Basic
       Support Protocol", RFC 3963, January 2005.

       J.  Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Advertisement Options for
       DNS Configuration", RFC 6106, November 2010.

       Z. Shelby, S. Chakrabarti, E. Nordmark and  C. Bormann " Neighbor  Discovery  Optimization
       for  IPv6  over  Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November
       2012.

       Gont, F. "Security Implications of IPv6 Fragmentation with IPv6 Neighbor  Discovery",  RFC
       6980, August 2013.

       Yourtchenko,  A.  and  Colitti, L. "Reducing Energy Consumption of Router Advertisements",
       RFC 7772, February 2016.

SEE ALSO

       radvd(8), radvdump(8)