2 .\" $Id: radvd.conf.5.man,v 1.41 2011/05/10 21:55:10 reubenhwk Exp $
5 .\" Lars Fenneberg <lf@elemental.net>
6 .\" Marko Myllynen <myllynen@lut.fi>
8 .\" This software is Copyright 1996-2000 by the above mentioned author(s),
9 .\" All Rights Reserved.
11 .\" The license which is distributed with this software in the file COPYRIGHT
12 .\" applies to this software. If your distribution is missing this file, you
13 .\" may request it from <pekkas@netcore.fi>.
17 .TH RADVD.CONF 5 "4 Jan 2011" "radvd @VERSION@" ""
19 radvd.conf \- configuration file of the router advertisement daemon
22 This file describes the information which is included in the router
23 advertisement (RA) of a specific interface.
25 The file contains one or more interface definitions of the form:
28 .BR "interface " "name " {
29 list of interface specific options
30 list of prefix definitions
31 list of clients (IPv6 addresses) to advertise to
32 list of route definitions
33 list of RDNSS definitions
34 list of DNSSL definitions
38 All the possible interface specific options are detailed below. Each
39 option has to be terminated by a semicolon.
41 Prefix definitions are of the form:
44 .BR "prefix " prefix / "length " {
45 list of prefix specific options
49 Prefix can be network prefix or the address of the inferface.
50 The address of interface should be used when using Mobile IPv6
53 Special prefix "::/64" is also supported on systems that implement getifaddrs()
54 (on other systems, configuration activation fails and radvd exits).
55 When configured, radvd
56 picks all non-link-local prefix assigned to the interface and starts advertising
57 it. This may be applicable in non-6to4 scenarios where the upstream prefix might
58 change. This option is incompatible with Base6to4Interface option.
59 AdvRouterAddr option is always enabled when this configuration is used.
61 All the possible prefix specific options are described below. Each
62 option has to be terminated by a semicolon.
64 Decimal values are allowed only for MinDelayBetweenRAs,
65 MaxRtrAdvInterval and MinRtrAdvInterval. Decimal values should
66 be used only when using Mobile IPv6 extensions.
68 Route definitions are of the form:
71 .BR "route " prefix / "length " {
72 list of route specific options
76 The prefix of a route definition should be network prefix; it can be used to
77 advertise more specific routes to the hosts.
79 RDNSS (Recursive DNS server) definitions are of the form:
82 .BR "RDNSS " "ip [ip] [ip] " {
83 list of rdnss specific options
87 DNSSL (DNS Search List) definitions are of the form:
90 .BR "DNSSL " "suffix [suffix] [suffix] [...] " {
91 list of dnssl specific options
95 By default radvd will send route advertisements so that every node on the link can use them.
96 The list of clients (IPv6 address) to advertise to, and accept route solicitations from can be configured.
97 If done, radvd does not send send messages to the multicast addresses but
98 to the configured unicast addresses only. Solicitations from other addresses are refused.
99 This is similar to UnicastOnly but includes periodic messages and incoming client access
100 configuration. See examples section for a use case of this.
102 The definitions are of the form:
106 list of IPv6 addresses
110 .SH INTERFACE SPECIFIC OPTIONS
113 .BR IgnoreIfMissing " " on | off
115 A flag indicating whether or not the interface is ignored
116 if it does not exist at start-up. By default, radvd exits.
118 This is useful for dynamic interfaces which are not active when radvd
119 starts or which are dynamically disabled and re-enabled during the time
122 Current versions of radvd automatically try to re-enable interfaces.
124 Enabling IgnoreIfMissing also quenches certain warnings in log messages
125 relating to missing interfaces.
130 .BR AdvSendAdvert " " on | off
132 A flag indicating whether or not the router sends
133 periodic router advertisements and responds to
134 router solicitations.
136 This option no longer has to be specified first, but it
139 to enable advertisement on this interface.
144 .BR UnicastOnly " " on | off
146 Indicates that the interface link type only supports unicast.
147 This will prevent unsolicited advertisements from being sent, and
148 will cause solicited advertisements to be unicast to the
149 soliciting node. This option is necessary for non-broadcast,
150 multiple-access links, such as ISATAP.
155 .BR "MaxRtrAdvInterval " seconds
157 The maximum time allowed between sending unsolicited multicast
158 router advertisements from the interface, in seconds.
160 Must be no less than 4 seconds and no greater than 1800 seconds.
162 Minimum when using Mobile IPv6 extensions: 0.07.
164 For values less than 0.2 seconds, 0.02 seconds is added to account for
165 scheduling granularities as specified in RFC3775.
170 .BR "MinRtrAdvInterval " seconds
172 The minimum time allowed between sending unsolicited multicast
173 router advertisements from the interface, in seconds.
175 Must be no less than 3 seconds and no greater than 0.75 *
178 Minimum when using Mobile IPv6 extensions: 0.03.
180 Default: 0.33 * MaxRtrAdvInterval
183 .BR "MinDelayBetweenRAs " seconds
185 The minimum time allowed between sending multicast
186 router advertisements from the interface, in seconds.
188 This applies to solicited multicast RAs.
189 This is defined as the protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861.
190 MIPv6 redefines this parameter to have a minimum of 0.03 seconds.
192 Minimum when using Mobile IPv6 extensions: 0.03.
197 .BR AdvManagedFlag " " on | off
199 When set, hosts use the administered (stateful) protocol for address
200 autoconfiguration in addition to any addresses autoconfigured using
201 stateless address autoconfiguration. The use of this flag is
202 described in RFC 4862.
207 .BR AdvOtherConfigFlag " " on | off
209 When set, hosts use the administered (stateful) protocol for
210 autoconfiguration of other (non-address) information. The use of
211 this flag is described in RFC 4862.
216 .BR "AdvLinkMTU " integer
218 The MTU option is used in router advertisement messages to insure
219 that all nodes on a link use the same MTU value in those cases where
220 the link MTU is not well known.
222 If specified, i.e. not 0, must not be smaller than 1280 and not greater
223 than the maximum MTU allowed for this link (e.g. ethernet has
224 a maximum MTU of 1500. See RFC 4864).
229 .BR "AdvReachableTime " milliseconds
231 The time, in milliseconds, that a node assumes a neighbor is
232 reachable after having received a reachability confirmation. Used
233 by the Neighbor Unreachability Detection algorithm (see Section
234 7.3 of RFC 4861). A value of zero means unspecified (by this router).
236 Must be no greater than 3,600,000 milliseconds (1 hour).
241 .BR "AdvRetransTimer " milliseconds
243 The time, in milliseconds, between retransmitted Neighbor
244 Solicitation messages. Used by address resolution and the Neighbor
245 Unreachability Detection algorithm (see Sections 7.2 and 7.3 of RFC 4861).
246 A value of zero means unspecified (by this router).
251 .BR "AdvCurHopLimit " integer
253 The default value that should be placed in the Hop Count field of
254 the IP header for outgoing (unicast) IP packets. The value should
255 be set to the current diameter of the Internet. The value zero
256 means unspecified (by this router).
261 .BR "AdvDefaultLifetime " seconds
263 The lifetime associated with the default router in units of seconds.
264 The maximum value corresponds to 18.2 hours. A lifetime of 0
265 indicates that the router is not a default router and should not
266 appear on the default router list. The router lifetime applies only
267 to the router's usefulness as a default router; it does not apply to
268 information contained in other message fields or options. Options
269 that need time limits for their information include their own
272 Must be either zero or between MaxRtrAdvInterval and 9000 seconds.
274 Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
277 .BR AdvDefaultPreference " " low | medium | high
279 The preference associated with the default router, as either "low",
285 .BR AdvSourceLLAddress " " on | off
287 When set, the link-layer address of the outgoing interface is
293 .BR AdvHomeAgentFlag " " on | off
295 When set, indicates that sending router is able to serve as Mobile
296 IPv6 Home Agent. When set, minimum limits specified by Mobile IPv6
297 are used for MinRtrAdvInterval and MaxRtrAdvInterval.
302 .BR AdvHomeAgentInfo " " on | off
304 When set, Home Agent Information Option (specified by Mobile IPv6)
305 is included in Router Advertisements. AdvHomeAgentFlag must also
306 be set when using this option.
311 .BR "HomeAgentLifetime " seconds
313 The length of time in seconds (relative to the time the packet is
314 sent) that the router is offering Mobile IPv6 Home Agent services.
315 A value 0 must not be used. The maximum lifetime is 65520 seconds
316 (18.2 hours). This option is ignored, if AdvHomeAgentInfo is not
319 If both HomeAgentLifetime and HomeAgentPreference are set to their
320 default values, Home Agent Information Option will not be sent.
322 Default: AdvDefaultLifetime
325 .BR "HomeAgentPreference " integer
327 The preference for the Home Agent sending this Router Advertisement.
328 Values greater than 0 indicate more preferable Home Agent, values
329 less than 0 indicate less preferable Home Agent. This option is
330 ignored, if AdvHomeAgentInfo is not set.
332 If both HomeAgentLifetime and HomeAgentPreference are set to their
333 default values, Home Agent Information Option will not be sent.
338 .BR AdvMobRtrSupportFlag " " on | off
340 When set, the Home Agent signals it supports Mobile Router
341 registrations (specified by NEMO Basic). AdvHomeAgentInfo must also
342 be set when using this option.
347 .BR AdvIntervalOpt " " on | off
349 When set, Advertisement Interval Option (specified by Mobile IPv6)
350 is included in Router Advertisements. When set, minimum limits
351 specified by Mobile IPv6 are used for MinRtrAdvInterval and
354 The advertisement interval is based on the configured MaxRtrAdvInterval
355 parameter except where this is less than 200ms. In this case,
356 the advertised interval is ( MaxRtrAdvInterval + 20ms ).
360 .SH PREFIX SPECIFIC OPTIONS
363 .BR AdvOnLink " " on | off
365 When set, indicates that this prefix can be used for on-link
366 determination. When not set the advertisement makes no statement
367 about on-link or off-link properties of the prefix. For instance,
368 the prefix might be used for address configuration with some of the
369 addresses belonging to the prefix being on-link and others being
375 .BR AdvAutonomous " " on | off
377 When set, indicates that this prefix can be used for autonomous
378 address configuration as specified in RFC 4862.
383 .BR AdvRouterAddr " " on | off
385 When set, indicates that the address of interface is sent instead of
386 network prefix, as is required by Mobile IPv6. When set, minimum
387 limits specified by Mobile IPv6 are used for MinRtrAdvInterval and
393 .BR "AdvValidLifetime " seconds "" | infinity
395 The length of time in seconds (relative to the time the packet is
396 sent) that the prefix is valid for the purpose of on-link
397 determination. The symbolic value
399 represents infinity (i.e. a value of all one bits (0xffffffff)).
400 The valid lifetime is also used by RFC 4862.
402 Note that clients will ignore AdvValidLifetime of an existing prefix
403 if the lifetime is below two hours, as required in RFC 4862 Section 5.5.3
406 Note: RFC4861's suggested default value is significantly longer: 30 days.
408 Default: 86400 seconds (1 day)
411 .BR "AdvPreferredLifetime " seconds "" | infinity
413 The length of time in seconds (relative to the time the packet is
414 sent) that addresses generated from the prefix via stateless address
415 autoconfiguration remain preferred.
418 represents infinity (i.e. a value of all one bits (0xffffffff)).
421 Note: RFC4861's suggested default value is significantly longer: 7 days.
423 Default: 14400 seconds (4 hours)
426 .BR DeprecatePrefix " " on | off
428 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.
430 See RFC4862, section 5.5.3., "Router Advertisement Processing", part (e).
435 .BR DecrementLifetimes " " on | off
437 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.
439 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.
441 See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6".
446 .BR "Base6Interface " name
448 If this options is specified, this prefix will be combined with the
449 IPv6 address of the interface specified by
451 The resulting prefix length will be 64.
454 .BR "Base6to4Interface " name
456 If this option is specified, this prefix will be combined with the
457 IPv4 address of interface
459 to produce a valid 6to4 prefix. The first 16 bits of this prefix
462 and the next 32 bits of this prefix will be replaced by the IPv4
463 address assigned to interface
465 at configuration time. The remaining 80 bits of the prefix (including
466 the SLA ID) will be advertised as specified in the configuration file.
467 See the next section for an example.
471 is not available at configuration time, a warning will be written to
472 the log and this prefix will be disabled until radvd is reconfigured.
474 This option enables systems with dynamic IPv4 addresses to update their
475 advertised 6to4 prefixes simply by restarting radvd or sending a SIGHUP
476 signal to cause radvd to reconfigure itself.
478 Note that 6to4 prefixes derived from dynamically-assigned IPv4 addresses
479 should be advertised with a significantly shorter lifetime (see the
482 .B AdvPreferredLifetime
485 For more information on 6to4, see RFC 3056.
487 Default: 6to4 is not used
489 .SH ROUTE SPECIFIC OPTIONS
492 .BR "AdvRouteLifetime " seconds "" | infinity
494 The lifetime associated with the route in units of seconds.
497 represents infinity (i.e. a value of all one bits (0xffffffff)).
499 Default: 3 * MaxRtrAdvInterval
502 .BR AdvRoutePreference " " low | medium | high
504 The preference associated with the default router, as either "low",
510 .BR RemoveRoute " " on | off
512 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.
516 .SH RDNSS SPECIFIC OPTIONS
519 .BR "AdvRDNSSLifetime " seconds | infinity
520 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.
522 Default: 2*MaxRtrAdvInterval
525 .BR FlushRDNSS " " on | off
527 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.
531 .SH DNSSL SPECIFIC OPTIONS
534 .BR "AdvDNSSLLifetime " seconds | infinity;
535 The maximum duration how long the DNSSL entries are used for name resolution.
536 A value of 0 means the suffix should no longer be used.
537 The value, if not 0, must be at least MaxRtrAdvInterval. To ensure stale
538 DNSSL info gets removed in a timely fashion, this should not be greater than
541 Default: 2*MaxRtrAdvInterval
544 .BR FlushDNSSL " " on | off
546 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.
556 prefix 2001:db8:0:1::/64
564 It says that router advertisement daemon should advertise
565 (AdvSendAdvert on;) the prefix 2001:db8:0:1:: which has a lenght of 64
566 on the interface eth0. Also the prefix should be marked as autonomous
567 (AdvAutonomous on;) and as on-link (AdvOnLink on;). All the other
568 options are left on their default values.
570 To support movement detection of Mobile IPv6 Mobile Nodes, the
571 address of interface should be used instead of network prefix:
577 prefix 2001:db8:0:1::4/64
586 For 6to4 support, include the
588 option in each prefix section. When using a dynamic IPv4 address, set
589 small prefix lifetimes to prevent hosts from retaining unreachable
590 prefixes after a new IPv4 address has been assigned. When advertising to on
591 a dynamic interface (e.g., Bluetooth), skip the interface if it is not
600 # Advertise at least every 30 seconds
601 MaxRtrAdvInterval 30;
603 prefix 0:0:0:5678::/64
607 Base6to4Interface ppp0;
609 # Very short lifetimes for dynamic addresses
610 AdvValidLifetime 300;
611 AdvPreferredLifetime 120;
616 Since 6to4 is enabled, the prefix will be advertised as
617 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of
618 ppp0 at configuration time. (IPv6 addresses are written in hexadecimal
619 whereas IPv4 addresses are written in decimal, so the IPv4 address
620 WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)
622 In this specific case, the configuration scripts may send HUP signal to
623 radvd when taking bnep0 up or down to notify about the status; in the
624 current radvd releases, sending HUP is no longer mandatory when the link
631 prefix 2001:db8:0:1::/64
638 fe80::21f:16ff:fe06:3aab;
639 fe80::21d:72ff:fe96:aaff;
644 This configuration would only announce the prefix to fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff.
645 Furthermore, all RA requests of other clients are denied.
647 This may come in handy if you want to roll out IPv6 only partially because
648 some clients are broken or untested.
661 The description of the different flags and variables is in large
662 parts taken from RFC 4861.
665 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP
666 Version 6 (IPv6)", RFC 4861, September 2007.
668 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfiguration",
669 RFC 4862, September 2007.
671 Deering, S., and R. Hinden, "IP Version 6 Addressing
672 Architecture", RFC 4291, February 2006.
674 Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol (ICMPv6)
675 for the Internet Protocol Version 6 (IPv6)", RFC 4443, March 2006.
677 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
678 RFC 2464, December 1998.
680 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
681 RFC 3056, February 2001. (6to4 specification)
683 Draves, R., D. Thaler, "Default Router Preferences and More-Specific Routes",
684 RFC 4191, November 2005.
686 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6",
689 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network Mobility (NEMO) Basic Support Protocol",
690 RFC 3963, January 2005.
692 J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration",
693 RFC 6106, November 2010.
701 radvd does not support splitting up RAs to multiple packets (RFC4861 6.2.3 last paragraph).
702 In practise this limits advertising to ~45 prefixes on a link, but there is no reason to