1RADVD.CONF(5) RADVD.CONF(5)
2
6 radvd.conf - configuration file of the router advertisement daemon
7 radvd
8
10 This file describes the information which is included in the router ad‐
11 vertisement (RA) of a specific interface.
12 The file contains one or more interface definitions of the form:
14 interface name {
16 list of interface specific options
17 list of prefix definitions
18 list of clients (IPv6 addresses) to advertise to
19 list of route definitions
20 list of RDNSS definitions
21 list of DNSSL definitions
22 list of ABRO definitions
23 list of acceptable RA source addresses
24 };
25 All the possible interface specific options are detailed below. Each
27 option has to be terminated by a semicolon.
28 Prefix definitions are of the form:
30 prefix prefix/length {
32 list of prefix specific options
33 };
34 Prefix can be network prefix or the address of the interface. The ad‐
36 dress of interface should be used when using Mobile IPv6 extensions.
37 Special prefix "::/64" is also supported on systems that implement
39 getifaddrs() (on other systems, configuration activation fails and
40 radvd exits). When configured, radvd picks all non-link-local prefix
41 assigned to the interface and starts advertising it. This may be ap‐
42 plicable in non-6to4 scenarios where the upstream prefix might change.
43 This option is incompatible with Base6to4Interface option. AdvRouter‐
44 Addr option is always enabled when this configuration is used.
45 All the possible prefix specific options are described below. Each op‐
47 tion has to be terminated by a semicolon.
48 Decimal values are allowed only for MinDelayBetweenRAs, MaxRtrAdvInter‐
50 val and MinRtrAdvInterval. Decimal values should be used only when us‐
51 ing Mobile IPv6 extensions.
52 Route definitions are of the form:
54 route prefix/length {
56 list of route specific options
57 };
58 The prefix of a route definition should be network prefix; it can be
60 used to advertise more specific routes to the hosts.
61 RDNSS (Recursive DNS server) definitions are of the form:
63 RDNSS ip [ip] [ip] {
65 list of rdnss specific options
66 };
67 DNSSL (DNS Search List) definitions are of the form:
69 DNSSL suffix [suffix] [suffix] [...] {
71 list of dnssl specific options
72 };
73 By default radvd will send multicast route advertisements so that every
75 node on the link can use them. The list of clients (IPv6 address) to
76 advertise to, and accept route solicitations from can be configured.
77 If done, radvd does not send send messages to the multicast addresses
78 but to the configured unicast addresses only. Solicitations from other
79 addresses are refused. This is similar to UnicastOnly but includes pe‐
80 riodic messages and incoming client access configuration. See examples
81 section for a use case of this.
82 The definitions are of the form:
84 clients {
86 list of IPv6 addresses
87 };
88 By default radvd will use the first link-local address for the inter‐
90 face as the source address for route advertisements. This can be over‐
91 written by manually setting the list of acceptable source addresses. If
92 done, radvd will use the first address from the interface that is
93 present in the configured source addresses only. This functionality
94 will NOT spoof the source address, but may be useful in combination
95 with VRRP or other functionality that
96 AdvRASrcAddress {
98 list of IPv6 addresses
99 };
100 ABRO (Authoritative Border Router Option) definitions are of the form:
102 abro IPv6-address {
104 list of abro specific options
105 };
106
109 IgnoreIfMissing on|off
110 A flag indicating whether or not the interface is ignored if it
112 does not exist at start-up.
113 This is useful for dynamic interfaces which are not active when
115 radvd starts or which are dynamically disabled and re-enabled
116 during the time radvd runs.
117 Current versions of radvd automatically try to re-enable inter‐
119 faces.
120 Enabling IgnoreIfMissing also quenches certain warnings in log
122 messages relating to missing interfaces.
123 Default: on
125 AdvSendAdvert on|off
128 A flag indicating whether or not the router sends periodic
130 router advertisements and responds to router solicitations.
131 This option no longer has to be specified first, but it needs to
133 be on to enable advertisement on this interface.
134 Default: off
136 UnicastOnly on|off
139 Indicates that the interface link type only supports unicast.
141 This will prevent unsolicited advertisements from being sent,
142 and will cause solicited advertisements to be unicast to the so‐
143 liciting node. This option is necessary for non-broadcast, mul‐
144 tiple-access links, such as ISATAP.
145 Default: off
147 AdvRASolicitedUnicast on|off
150 Indicates that router solicitations will be responded to with
152 unicast router advertisements, as recommended by RFC7772. Large
153 networks with a high concentration of mobile devices might expe‐
154 rience like battery depletion, when solicited Router Advertise‐
155 ment messages are multicast.
156 This corresponds to the Cisco IOS option ipv6 nd ra solicited
158 unicast
159 Default: on
161 MaxRtrAdvInterval seconds
164 The maximum time allowed between sending unsolicited multicast
166 router advertisements from the interface, in seconds.
167 Must be no less than 4 seconds and no greater than 1800 seconds.
169 Minimum when using Mobile IPv6 extensions: 0.07.
171 For values less than 0.2 seconds, 0.02 seconds is added to ac‐
173 count for scheduling granularities as specified in RFC3775.
174 Default: 600 seconds
176 MinRtrAdvInterval seconds
179 The minimum time allowed between sending unsolicited multicast
181 router advertisements from the interface, in seconds.
182 Must be no less than 3 seconds and no greater than 0.75 * MaxR‐
184 trAdvInterval.
185 Minimum when using Mobile IPv6 extensions: 0.03.
187 Default: 0.33 * MaxRtrAdvInterval
189 MinDelayBetweenRAs seconds
192 The minimum time allowed between sending multicast router adver‐
194 tisements from the interface, in seconds.
195 This applies to solicited multicast RAs. This is defined as the
197 protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861. MIPv6 rede‐
198 fines this parameter to have a minimum of 0.03 seconds.
199 Minimum when using Mobile IPv6 extensions: 0.03.
201 Default: 3
203 AdvManagedFlag on|off
206 When set, hosts use the administered (stateful) protocol for ad‐
208 dress autoconfiguration in addition to any addresses autoconfig‐
209 ured using stateless address autoconfiguration. The use of this
210 flag is described in RFC 4862.
211 Default: off
213 AdvOtherConfigFlag on|off
216 When set, hosts use the administered (stateful) protocol for au‐
218 toconfiguration of other (non-address) information. The use of
219 this flag is described in RFC 4862.
220 Default: off
222 AdvLinkMTU integer
225 The MTU option is used in router advertisement messages to in‐
227 sure that all nodes on a link use the same MTU value in those
228 cases where the link MTU is not well known.
229 If specified, i.e. not 0, must not be smaller than 1280 and not
231 greater than the maximum MTU allowed for this link (e.g. ether‐
232 net has a maximum MTU of 1500. See RFC 4864).
233 Default: 0
235 AdvReachableTime milliseconds
238 The time, in milliseconds, that a node assumes a neighbor is
240 reachable after having received a reachability confirmation.
241 Used by the Neighbor Unreachability Detection algorithm (see
242 Section 7.3 of RFC 4861). A value of zero means unspecified (by
243 this router).
244 Must be no greater than 3,600,000 milliseconds (1 hour).
246 Default: 0
248 AdvRetransTimer milliseconds
251 The time, in milliseconds, between retransmitted Neighbor Solic‐
253 itation messages. Used by address resolution and the Neighbor
254 Unreachability Detection algorithm (see Sections 7.2 and 7.3 of
255 RFC 4861). A value of zero means unspecified (by this router).
256 Default: 0
258 AdvCurHopLimit integer
261 The default value that should be placed in the Hop Count field
263 of the IP header for outgoing (unicast) IP packets. The value
264 should be set to the current diameter of the Internet. The
265 value zero means unspecified (by this router).
266 Default: 64
268 AdvDefaultLifetime seconds
271 The lifetime associated with the default router in units of sec‐
273 onds. The maximum value corresponds to 18.2 hours. A lifetime
274 of 0 indicates that the router is not a default router and
275 should not appear on the default router list. The router life‐
276 time applies only to the router's usefulness as a default
277 router; it does not apply to information contained in other mes‐
278 sage fields or options. Options that need time limits for their
279 information include their own lifetime fields.
280 Must be either zero or between MaxRtrAdvInterval and 9000 sec‐
282 onds.
283 Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
285 AdvDefaultPreference low|medium|high
288 The preference associated with the default router, as either
290 "low", "medium", or "high".
291 Default: medium
293 AdvSourceLLAddress on|off
296 When set, the link-layer address of the outgoing interface is
298 included in the RA.
299 Default: on
301 AdvHomeAgentFlag on|off
304 When set, indicates that sending router is able to serve as Mo‐
306 bile IPv6 Home Agent. When set, minimum limits specified by Mo‐
307 bile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInterval.
308 Default: off
310 AdvHomeAgentInfo on|off
313 When set, Home Agent Information Option (specified by Mobile
315 IPv6) is included in Router Advertisements. AdvHomeAgentFlag
316 must also be set when using this option.
317 Default: off
319 HomeAgentLifetime seconds
322 The length of time in seconds (relative to the time the packet
324 is sent) that the router is offering Mobile IPv6 Home Agent ser‐
325 vices. A value 0 must not be used. The maximum lifetime is
326 65520 seconds (18.2 hours). This option is ignored, if AdvHome‐
327 AgentInfo is not set.
328 If both HomeAgentLifetime and HomeAgentPreference are set to
330 their default values, Home Agent Information Option will not be
331 sent.
332 Default: AdvDefaultLifetime
334 HomeAgentPreference integer
337 The preference for the Home Agent sending this Router Advertise‐
339 ment. Values greater than 0 indicate more preferable Home
340 Agent, values less than 0 indicate less preferable Home Agent.
341 This option is ignored, if AdvHomeAgentInfo is not set.
342 If both HomeAgentLifetime and HomeAgentPreference are set to
344 their default values, Home Agent Information Option will not be
345 sent.
346 Default: 0
348 AdvMobRtrSupportFlag on|off
351 When set, the Home Agent signals it supports Mobile Router reg‐
353 istrations (specified by NEMO Basic). AdvHomeAgentInfo must
354 also be set when using this option.
355 Default: off
357 AdvIntervalOpt on|off
360 When set, Advertisement Interval Option (specified by Mobile
362 IPv6) is included in Router Advertisements. When set, minimum
363 limits specified by Mobile IPv6 are used for MinRtrAdvInterval
364 and MaxRtrAdvInterval.
365 The advertisement interval is based on the configured MaxRtrAdv‐
367 Interval parameter except where this is less than 200ms. In
368 this case, the advertised interval is ( MaxRtrAdvInterval + 20ms
369 ).
370 Default: off
372
375 AdvOnLink on|off
376 When set, indicates that this prefix can be used for on-link de‐
378 termination. When not set the advertisement makes no statement
379 about on-link or off-link properties of the prefix. For in‐
380 stance, the prefix might be used for address configuration with
381 some of the addresses belonging to the prefix being on-link and
382 others being off-link.
383 Default: on
385 AdvAutonomous on|off
388 When set, indicates that this prefix can be used for autonomous
390 address configuration as specified in RFC 4862.
391 Default: on
393 AdvRouterAddr on|off
396 When set, indicates that the address of interface is sent in‐
398 stead of network prefix, as is required by Mobile IPv6. When
399 set, minimum limits specified by Mobile IPv6 are used for MinR‐
400 trAdvInterval and MaxRtrAdvInterval.
401 Default: off
403 AdvValidLifetime seconds|infinity
406 The length of time in seconds (relative to the time the packet
408 is sent) that the prefix is valid for the purpose of on-link de‐
409 termination. The symbolic value infinity represents infinity
410 (i.e. a value of all one bits (0xffffffff)). The valid lifetime
411 is also used by RFC 4862.
412 Note that clients will ignore AdvValidLifetime of an existing
414 prefix if the lifetime is below two hours, as required in RFC
415 4862 Section 5.5.3 point e).
416 Note: RFC4861's suggested default value is significantly longer:
418 30 days.
419 Default: 86400 seconds (1 day)
421 AdvPreferredLifetime seconds|infinity
424 The length of time in seconds (relative to the time the packet
426 is sent) that addresses generated from the prefix via stateless
427 address autoconfiguration remain preferred. The symbolic value
428 infinity represents infinity (i.e. a value of all one bits
429 (0xffffffff)). See RFC 4862.
430 Note: RFC4861's suggested default value is significantly longer:
432 7 days.
433 Default: 14400 seconds (4 hours)
435 DeprecatePrefix on|off
438 Upon shutdown, this option will cause radvd to deprecate the
440 prefix by announcing it in the radvd shutdown RA with a zero
441 preferred lifetime and a valid lifetime slightly greater than 2
442 hours. This will encourage end-nodes using this prefix to depre‐
443 cate any associated addresses immediately. Note that this option
444 should only be used when only one router is announcing the pre‐
445 fix onto the link, otherwise end-nodes will deprecate associated
446 addresses despite the prefix still being valid for preferred
447 use.
448 See RFC4862, section 5.5.3., "Router Advertisement Processing",
450 part (e).
451 Default: off
453 DecrementLifetimes on|off
456 This option causes radvd to decrement the values of the pre‐
458 ferred and valid lifetimes for the prefix over time. The life‐
459 times are decremented by the number of seconds since the last
460 RA. If radvd receives a SIGUSR1 signal, it will reset the values
461 of the preferred and valid lifetimes back to the initial values
462 used by radvd when it started. If radvd never receives a SIGUSR1
463 signal, it will continue to decrement the lifetimes until the
464 preferred lifetime reaches zero. After a final RA with a zero
465 value preferred lifetime, radvd will cease to announce the pre‐
466 fix. If a SIGUSR1 signal then causes the lifetimes to be reset,
467 the prefix will then re-appear in the RAs.
468 This option is intended to be used in conjunction with a DHCPv6
470 client that is using the Identity Association for Prefix Delega‐
471 tion (IA_PD) option to acquire a prefix from a Delegating Router
472 for use by a Requesting Router. In this scenario, the prefix(es)
473 from within the delegated prefix that are announced by radvd
474 would age in parallel with and at the same rate as the delegated
475 prefix, and expire at approximately the same time, if the dele‐
476 gated prefix's life isn't extended.
477 See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration
479 Protocol (DHCP) version 6".
480 Default: off
482 Base6Interface name
485 If this options is specified, this prefix will be combined with
487 the IPv6 address of the interface specified by name. The re‐
488 sulting prefix length will be 64.
489 Base6to4Interface name
492 If this option is specified, this prefix will be combined with
494 the IPv4 address of interface name to produce a valid 6to4 pre‐
495 fix. The first 16 bits of this prefix will be replaced by 2002
496 and the next 32 bits of this prefix will be replaced by the IPv4
497 address assigned to interface name at configuration time. The
498 remaining 80 bits of the prefix (including the SLA ID) will be
499 advertised as specified in the configuration file. See the next
500 section for an example.
501 If interface name is not available at configuration time, a
503 warning will be written to the log and this prefix will be dis‐
504 abled until radvd is reconfigured.
505 This option enables systems with dynamic IPv4 addresses to up‐
507 date their advertised 6to4 prefixes simply by restarting radvd
508 or sending a SIGHUP signal to cause radvd to reconfigure itself.
509 Note that 6to4 prefixes derived from dynamically-assigned IPv4
511 addresses should be advertised with a significantly shorter
512 lifetime (see the AdvValidLifetime and AdvPreferredLifetime op‐
513 tions).
514 For more information on 6to4, see RFC 3056.
516 Default: 6to4 is not used
518
521 AdvRouteLifetime seconds|infinity
522 The lifetime associated with the route in units of seconds. The
524 symbolic value infinity represents infinity (i.e. a value of all
525 one bits (0xffffffff)).
526 Default: 3 * MaxRtrAdvInterval
528 AdvRoutePreference low|medium|high
531 The preference associated with the default router, as either
533 "low", "medium", or "high".
534 Default: medium
536 RemoveRoute on|off
539 Upon shutdown, announce this route with a zero second lifetime.
541 This should cause the route to be immediately removed from the
542 receiving end-nodes' route table.
543 Default: on
545
548 AdvRDNSSLifetime seconds|infinity
549 The maximum duration how long the RDNSS entries are used for
550 name resolution. A value of 0 means the nameserver must no
551 longer be used. The value, if not 0, must be at least MaxRtrAdv‐
552 Interval. To ensure stale RDNSS info gets removed in a timely
553 fashion, this should not be greater than 2*MaxRtrAdvInterval.
554 Default: 2*MaxRtrAdvInterval
556 FlushRDNSS on|off
559 Upon shutdown, announce the RDNSS entries with a zero second
561 lifetime. This should cause the RDNSS addresses to be immedi‐
562 ately removed from the end-nodes' list of Recursive DNS Servers.
563 Default: on
565
568 AdvDNSSLLifetime seconds|infinity;
569 The maximum duration how long the DNSSL entries are used for
570 name resolution. A value of 0 means the suffix should no longer
571 be used. The value, if not 0, must be at least MaxRtrAdvInter‐
572 val. To ensure stale DNSSL info gets removed in a timely fash‐
573 ion, this should not be greater than 2*MaxRtrAdvInterval.
574 Default: 2*MaxRtrAdvInterval
576 FlushDNSSL on|off
579 Upon shutdown, announce the DNSSL entries with a zero second
581 lifetime. This should cause the DNSSL entries to be immediately
582 removed from the end-nodes' DNS search list.
583 Default: on
585
588 AdvValidLifeTime seconds
589 The time in units of that the set of border router information
590 is valid. A value of all zero bits assumes a default value of
591 10,000(~one week).
592 AdvVersionLow, AdvVersionHigh unsignedinteger
595 Both forms 32-bit unsigned version number corresponding to the
596 set of information contained in RA message.
597
600 interface eth0
601 {
602 AdvSendAdvert on;
603 prefix 2001:db8:0:1::/64
604 {
605 AdvOnLink on;
606 AdvAutonomous on;
607 };
608 };
609 It says that router advertisement daemon should advertise (AdvSendAd‐
611 vert on;) the prefix 2001:db8:0:1:: which has a length of 64 on the in‐
612 terface eth0. Also the prefix should be marked as autonomous (AdvAu‐
613 tonomous on;) and as on-link (AdvOnLink on;). All the other options
614 are left on their default values.
615 To support movement detection of Mobile IPv6 Mobile Nodes, the address
617 of interface should be used instead of network prefix:
618 interface eth0
620 {
621 AdvSendAdvert on;
622 prefix 2001:db8:0:1::4/64
623 {
624 AdvOnLink on;
625 AdvAutonomous on;
626 AdvRouterAddr on;
627 };
628 };
629 For 6to4 support, include the Base6to4Interface option in each prefix
631 section. When using a dynamic IPv4 address, set small prefix lifetimes
632 to prevent hosts from retaining unreachable prefixes after a new IPv4
633 address has been assigned. When advertising to on a dynamic interface
634 (e.g., Bluetooth), skip the interface if it is not active yet.
635 interface bnep0
637 {
638 IgnoreIfMissing on;
639 AdvSendAdvert on;
640 # Advertise at least every 30 seconds
642 MaxRtrAdvInterval 30;
643 prefix 0:0:0:5678::/64
645 {
646 AdvOnLink on;
647 AdvAutonomous on;
648 Base6to4Interface ppp0;
649 # Very short lifetimes for dynamic addresses
651 AdvValidLifetime 300;
652 AdvPreferredLifetime 120;
653 };
654 };
655 Since 6to4 is enabled, the prefix will be advertised as
657 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of ppp0
658 at configuration time. (IPv6 addresses are written in hexadecimal
659 whereas IPv4 addresses are written in decimal, so the IPv4 address
660 WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)
661 In this specific case, the configuration scripts may send HUP signal to
663 radvd when taking bnep0 up or down to notify about the status; in the
664 current radvd releases, sending HUP is no longer mandatory when the
665 link comes back up.
666 interface eth0
668 {
669 AdvSendAdvert on;
670 prefix 2001:db8:0:1::/64
671 {
672 AdvOnLink on;
673 AdvAutonomous on;
674 };
675 clients
676 {
677 fe80::21f:16ff:fe06:3aab;
678 fe80::21d:72ff:fe96:aaff;
679 };
680 };
681 This configuration would only announce the prefix to
683 fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. Furthermore,
684 all RA requests of other clients are denied.
685 This may come in handy if you want to roll out IPv6 only partially be‐
687 cause some clients are broken or untested.
688 For ABRO support
690 interface lowpan0
691 {
692 AdvSendAdvert on;
693 UnicastOnly on;
694 AdvCurHopLimit 255;
695 prefix 2001:0db8:0100:f101::/64 {
696 AdvOnLink on;
697 AdvAutonomous on;
698 AdvRouterAddr on;
699 };
700 abro fe80::a200:0:0:1/64 {
701 AdvVersionLow 10;
702 AdvVersionHigh 2;
703 AdvValidLifeTime 2;
704 };
705 };
706
709 /usr/sbin/radvd
710 /etc/radvd.conf
711 /run/radvd/radvd.pid
712 /var/log/radvd.log
713
716 The description of the different flags and variables is in large parts
717 taken from RFC 4861.
718
721 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Dis‐
722 covery for IP Version 6 (IPv6)", RFC 4861, September 2007.
723 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig‐
725 uration", RFC 4862, September 2007.
726 Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
728 4291, February 2006.
729 Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol
731 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 4443, March
732 2006.
733 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
735 RFC 2464, December 1998.
736 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
738 RFC 3056, February 2001. (6to4 specification)
739 Draves, R., D. Thaler, "Default Router Preferences and More-Specific
741 Routes", RFC 4191, November 2005.
742 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
744 3775, June 2004.
745 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network
747 Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
748 J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Adver‐
750 tisement Options for DNS Configuration", RFC 6106, November 2010.
751 Z. Shelby, S. Chakrabarti, E. Nordmark and C. Bormann " Neighbor Dis‐
753 covery Optimization for IPv6 over Low-Power Wireless Personal Area Net‐
754 works (6LoWPANs)", RFC 6775, November 2012.
755 Gont, F. "Security Implications of IPv6 Fragmentation with IPv6 Neigh‐
757 bor Discovery", RFC 6980, August 2013.
758 Yourtchenko, A. and Colitti, L. "Reducing Energy Consumption of Router
760 Advertisements", RFC 7772, February 2016.
761
764 radvd(8), radvdump(8)
765radvd 2.19 4 Jan 2011 RADVD.CONF(5)