bionic (5) radvd.conf.5.gz

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)