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
11 advertisement (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
36 address 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
42 applicable in non-6to4 scenarios where the upstream prefix might
43 change. This option is incompatible with Base6to4Interface option.
44 AdvRouterAddr option is always enabled when this configuration is used.
45 All the possible prefix specific options are described below. Each
47 option 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
51 using 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
80 periodic messages and incoming client access configuration. See exam‐
81 ples 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. By default, radvd exits.
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
143 soliciting node. This option is necessary for non-broadcast,
144 multiple-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
173 account 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
208 address autoconfiguration in addition to any addresses autocon‐
209 figured using stateless address autoconfiguration. The use of
210 this flag is described in RFC 4862.
211 Default: off
213 AdvOtherConfigFlag on|off
216 When set, hosts use the administered (stateful) protocol for
218 autoconfiguration of other (non-address) information. The use
219 of this flag is described in RFC 4862.
220 Default: off
222 AdvLinkMTU integer
225 The MTU option is used in router advertisement messages to
227 insure 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
306 Mobile IPv6 Home Agent. When set, minimum limits specified by
307 Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInter‐
308 val.
309 Default: off
311 AdvHomeAgentInfo on|off
314 When set, Home Agent Information Option (specified by Mobile
316 IPv6) is included in Router Advertisements. AdvHomeAgentFlag
317 must also be set when using this option.
318 Default: off
320 HomeAgentLifetime seconds
323 The length of time in seconds (relative to the time the packet
325 is sent) that the router is offering Mobile IPv6 Home Agent ser‐
326 vices. A value 0 must not be used. The maximum lifetime is
327 65520 seconds (18.2 hours). This option is ignored, if AdvHome‐
328 AgentInfo is not set.
329 If both HomeAgentLifetime and HomeAgentPreference are set to
331 their default values, Home Agent Information Option will not be
332 sent.
333 Default: AdvDefaultLifetime
335 HomeAgentPreference integer
338 The preference for the Home Agent sending this Router Advertise‐
340 ment. Values greater than 0 indicate more preferable Home
341 Agent, values less than 0 indicate less preferable Home Agent.
342 This option is ignored, if AdvHomeAgentInfo is not set.
343 If both HomeAgentLifetime and HomeAgentPreference are set to
345 their default values, Home Agent Information Option will not be
346 sent.
347 Default: 0
349 AdvMobRtrSupportFlag on|off
352 When set, the Home Agent signals it supports Mobile Router reg‐
354 istrations (specified by NEMO Basic). AdvHomeAgentInfo must
355 also be set when using this option.
356 Default: off
358 AdvIntervalOpt on|off
361 When set, Advertisement Interval Option (specified by Mobile
363 IPv6) is included in Router Advertisements. When set, minimum
364 limits specified by Mobile IPv6 are used for MinRtrAdvInterval
365 and MaxRtrAdvInterval.
366 The advertisement interval is based on the configured MaxRtrAdv‐
368 Interval parameter except where this is less than 200ms. In
369 this case, the advertised interval is ( MaxRtrAdvInterval + 20ms
370 ).
371 Default: off
373
376 AdvOnLink on|off
377 When set, indicates that this prefix can be used for on-link
379 determination. When not set the advertisement makes no state‐
380 ment about on-link or off-link properties of the prefix. For
381 instance, the prefix might be used for address configuration
382 with some of the addresses belonging to the prefix being on-link
383 and others being off-link.
384 Default: on
386 AdvAutonomous on|off
389 When set, indicates that this prefix can be used for autonomous
391 address configuration as specified in RFC 4862.
392 Default: on
394 AdvRouterAddr on|off
397 When set, indicates that the address of interface is sent
399 instead of network prefix, as is required by Mobile IPv6. When
400 set, minimum limits specified by Mobile IPv6 are used for MinR‐
401 trAdvInterval and MaxRtrAdvInterval.
402 Default: off
404 AdvValidLifetime seconds|infinity
407 The length of time in seconds (relative to the time the packet
409 is sent) that the prefix is valid for the purpose of on-link
410 determination. The symbolic value infinity represents infinity
411 (i.e. a value of all one bits (0xffffffff)). The valid lifetime
412 is also used by RFC 4862.
413 Note that clients will ignore AdvValidLifetime of an existing
415 prefix if the lifetime is below two hours, as required in RFC
416 4862 Section 5.5.3 point e).
417 Note: RFC4861's suggested default value is significantly longer:
419 30 days.
420 Default: 86400 seconds (1 day)
422 AdvPreferredLifetime seconds|infinity
425 The length of time in seconds (relative to the time the packet
427 is sent) that addresses generated from the prefix via stateless
428 address autoconfiguration remain preferred. The symbolic value
429 infinity represents infinity (i.e. a value of all one bits
430 (0xffffffff)). See RFC 4862.
431 Note: RFC4861's suggested default value is significantly longer:
433 7 days.
434 Default: 14400 seconds (4 hours)
436 DeprecatePrefix on|off
439 Upon shutdown, this option will cause radvd to deprecate the
441 prefix by announcing it in the radvd shutdown RA with a zero
442 preferred lifetime and a valid lifetime slightly greater than 2
443 hours. This will encourage end-nodes using this prefix to depre‐
444 cate any associated addresses immediately. Note that this option
445 should only be used when only one router is announcing the pre‐
446 fix onto the link, otherwise end-nodes will deprecate associated
447 addresses despite the prefix still being valid for preferred
448 use.
449 See RFC4862, section 5.5.3., "Router Advertisement Processing",
451 part (e).
452 Default: off
454 DecrementLifetimes on|off
457 This option causes radvd to decrement the values of the pre‐
459 ferred and valid lifetimes for the prefix over time. The life‐
460 times are decremented by the number of seconds since the last
461 RA. If radvd receives a SIGUSR1 signal, it will reset the values
462 of the preferred and valid lifetimes back to the initial values
463 used by radvd when it started. If radvd never receives a SIGUSR1
464 signal, it will continue to decrement the lifetimes until the
465 preferred lifetime reaches zero. After a final RA with a zero
466 value preferred lifetime, radvd will cease to announce the pre‐
467 fix. If a SIGUSR1 signal then causes the lifetimes to be reset,
468 the prefix will then re-appear in the RAs.
469 This option is intended to be used in conjunction with a DHCPv6
471 client that is using the Identity Association for Prefix Delega‐
472 tion (IA_PD) option to acquire a prefix from a Delegating Router
473 for use by a Requesting Router. In this scenario, the prefix(es)
474 from within the delegated prefix that are announced by radvd
475 would age in parallel with and at the same rate as the delegated
476 prefix, and expire at approximately the same time, if the dele‐
477 gated prefix's life isn't extended.
478 See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration
480 Protocol (DHCP) version 6".
481 Default: off
483 Base6Interface name
486 If this options is specified, this prefix will be combined with
488 the IPv6 address of the interface specified by name. The
489 resulting prefix length will be 64.
490 Base6to4Interface name
493 If this option is specified, this prefix will be combined with
495 the IPv4 address of interface name to produce a valid 6to4 pre‐
496 fix. The first 16 bits of this prefix will be replaced by 2002
497 and the next 32 bits of this prefix will be replaced by the IPv4
498 address assigned to interface name at configuration time. The
499 remaining 80 bits of the prefix (including the SLA ID) will be
500 advertised as specified in the configuration file. See the next
501 section for an example.
502 If interface name is not available at configuration time, a
504 warning will be written to the log and this prefix will be dis‐
505 abled until radvd is reconfigured.
506 This option enables systems with dynamic IPv4 addresses to
508 update their advertised 6to4 prefixes simply by restarting radvd
509 or sending a SIGHUP signal to cause radvd to reconfigure itself.
510 Note that 6to4 prefixes derived from dynamically-assigned IPv4
512 addresses should be advertised with a significantly shorter
513 lifetime (see the AdvValidLifetime and AdvPreferredLifetime
514 options).
515 For more information on 6to4, see RFC 3056.
517 Default: 6to4 is not used
519
522 AdvRouteLifetime seconds|infinity
523 The lifetime associated with the route in units of seconds. The
525 symbolic value infinity represents infinity (i.e. a value of all
526 one bits (0xffffffff)).
527 Default: 3 * MaxRtrAdvInterval
529 AdvRoutePreference low|medium|high
532 The preference associated with the default router, as either
534 "low", "medium", or "high".
535 Default: medium
537 RemoveRoute on|off
540 Upon shutdown, announce this route with a zero second lifetime.
542 This should cause the route to be immediately removed from the
543 receiving end-nodes' route table.
544 Default: on
546
549 AdvRDNSSLifetime seconds|infinity
550 The maximum duration how long the RDNSS entries are used for
551 name resolution. A value of 0 means the nameserver must no
552 longer be used. The value, if not 0, must be at least MaxRtrAdv‐
553 Interval. To ensure stale RDNSS info gets removed in a timely
554 fashion, this should not be greater than 2*MaxRtrAdvInterval.
555 Default: 2*MaxRtrAdvInterval
557 FlushRDNSS on|off
560 Upon shutdown, announce the RDNSS entries with a zero second
562 lifetime. This should cause the RDNSS addresses to be immedi‐
563 ately removed from the end-nodes' list of Recursive DNS Servers.
564 Default: on
566
569 AdvDNSSLLifetime seconds|infinity;
570 The maximum duration how long the DNSSL entries are used for
571 name resolution. A value of 0 means the suffix should no longer
572 be used. The value, if not 0, must be at least MaxRtrAdvInter‐
573 val. To ensure stale DNSSL info gets removed in a timely fash‐
574 ion, this should not be greater than 2*MaxRtrAdvInterval.
575 Default: 2*MaxRtrAdvInterval
577 FlushDNSSL on|off
580 Upon shutdown, announce the DNSSL entries with a zero second
582 lifetime. This should cause the DNSSL entries to be immediately
583 removed from the end-nodes' DNS search list.
584 Default: on
586
589 AdvValidLifeTime seconds
590 The time in units of that the set of border router information
591 is valid. A value of all zero bits assumes a default value of
592 10,000(~one week).
593 AdvVersionLow, AdvVersionHigh unsignedinteger
596 Both forms 32-bit unsigned version number corresponding to the
597 set of information contained in RA message.
598
601 interface eth0
602 {
603 AdvSendAdvert on;
604 prefix 2001:db8:0:1::/64
605 {
606 AdvOnLink on;
607 AdvAutonomous on;
608 };
609 };
610 It says that router advertisement daemon should advertise (AdvSendAd‐
612 vert on;) the prefix 2001:db8:0:1:: which has a length of 64 on the
613 interface eth0. Also the prefix should be marked as autonomous (AdvAu‐
614 tonomous on;) and as on-link (AdvOnLink on;). All the other options
615 are left on their default values.
616 To support movement detection of Mobile IPv6 Mobile Nodes, the address
618 of interface should be used instead of network prefix:
619 interface eth0
621 {
622 AdvSendAdvert on;
623 prefix 2001:db8:0:1::4/64
624 {
625 AdvOnLink on;
626 AdvAutonomous on;
627 AdvRouterAddr on;
628 };
629 };
630 For 6to4 support, include the Base6to4Interface option in each prefix
632 section. When using a dynamic IPv4 address, set small prefix lifetimes
633 to prevent hosts from retaining unreachable prefixes after a new IPv4
634 address has been assigned. When advertising to on a dynamic interface
635 (e.g., Bluetooth), skip the interface if it is not active yet.
636 interface bnep0
638 {
639 IgnoreIfMissing on;
640 AdvSendAdvert on;
641 # Advertise at least every 30 seconds
643 MaxRtrAdvInterval 30;
644 prefix 0:0:0:5678::/64
646 {
647 AdvOnLink on;
648 AdvAutonomous on;
649 Base6to4Interface ppp0;
650 # Very short lifetimes for dynamic addresses
652 AdvValidLifetime 300;
653 AdvPreferredLifetime 120;
654 };
655 };
656 Since 6to4 is enabled, the prefix will be advertised as
658 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of ppp0
659 at configuration time. (IPv6 addresses are written in hexadecimal
660 whereas IPv4 addresses are written in decimal, so the IPv4 address
661 WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)
662 In this specific case, the configuration scripts may send HUP signal to
664 radvd when taking bnep0 up or down to notify about the status; in the
665 current radvd releases, sending HUP is no longer mandatory when the
666 link comes back up.
667 interface eth0
669 {
670 AdvSendAdvert on;
671 prefix 2001:db8:0:1::/64
672 {
673 AdvOnLink on;
674 AdvAutonomous on;
675 };
676 clients
677 {
678 fe80::21f:16ff:fe06:3aab;
679 fe80::21d:72ff:fe96:aaff;
680 };
681 };
682 This configuration would only announce the prefix to
684 fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. Furthermore,
685 all RA requests of other clients are denied.
686 This may come in handy if you want to roll out IPv6 only partially
688 because some clients are broken or untested.
689 For ABRO support
691 interface lowpan0
692 {
693 AdvSendAdvert on;
694 UnicastOnly on;
695 AdvCurHopLimit 255;
696 prefix 2001:0db8:0100:f101::/64 {
697 AdvOnLink on;
698 AdvAutonomous on;
699 AdvRouterAddr on;
700 };
701 abro fe80::a200:0:0:1/64 {
702 AdvVersionLow 10;
703 AdvVersionHigh 2;
704 AdvValidLifeTime 2;
705 };
706 };
707
710 /usr/sbin/radvd
711 /etc/radvd.conf
712 /var/run/radvd/radvd.pid
713 /var/log/radvd.log
714
717 The description of the different flags and variables is in large parts
718 taken from RFC 4861.
719
722 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Dis‐
723 covery for IP Version 6 (IPv6)", RFC 4861, September 2007.
724 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig‐
726 uration", RFC 4862, September 2007.
727 Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
729 4291, February 2006.
730 Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol
732 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 4443, March
733 2006.
734 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
736 RFC 2464, December 1998.
737 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
739 RFC 3056, February 2001. (6to4 specification)
740 Draves, R., D. Thaler, "Default Router Preferences and More-Specific
742 Routes", RFC 4191, November 2005.
743 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
745 3775, June 2004.
746 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network
748 Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
749 J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Adver‐
751 tisement Options for DNS Configuration", RFC 6106, November 2010.
752 Z. Shelby, S. Chakrabarti, E. Nordmark and C. Bormann " Neighbor Dis‐
754 covery Optimization for IPv6 over Low-Power Wireless Personal Area Net‐
755 works (6LoWPANs)", RFC 6775, November 2012.
756 Gont, F. "Security Implications of IPv6 Fragmentation with IPv6 Neigh‐
758 bor Discovery", RFC 6980, August 2013.
759 Yourtchenko, A. and Colitti, L. "Reducing Energy Consumption of Router
761 Advertisements", RFC 7772, February 2016.
762
765 radvd(8), radvdump(8)
766radvd 2.17 4 Jan 2011 RADVD.CONF(5)