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 };
23 All the possible interface specific options are detailed below. Each
25 option has to be terminated by a semicolon.
26 Prefix definitions are of the form:
28 prefix prefix/length {
30 list of prefix specific options
31 };
32 Prefix can be network prefix or the address of the inferface. The
34 address of interface should be used when using Mobile IPv6 extensions.
35 Special prefix "::/64" is also supported on systems that implement
37 getifaddrs() (on other systems, configuration activation fails and
38 radvd exits). When configured, radvd picks all non-link-local prefix
39 assigned to the interface and starts advertising it. This may be
40 applicable in non-6to4 scenarios where the upstream prefix might
41 change. This option is incompatible with Base6to4Interface option.
42 AdvRouterAddr option is always enabled when this configuration is used.
43 All the possible prefix specific options are described below. Each
45 option has to be terminated by a semicolon.
46 Decimal values are allowed only for MinDelayBetweenRAs, MaxRtrAdvInter‐
48 val and MinRtrAdvInterval. Decimal values should be used only when
49 using Mobile IPv6 extensions.
50 Route definitions are of the form:
52 route prefix/length {
54 list of route specific options
55 };
56 The prefix of a route definition should be network prefix; it can be
58 used to advertise more specific routes to the hosts.
59 RDNSS (Recursive DNS server) definitions are of the form:
61 RDNSS ip [ip] [ip] {
63 list of rdnss specific options
64 };
65 DNSSL (DNS Search List) definitions are of the form:
67 DNSSL suffix [suffix] [suffix] [...] {
69 list of dnssl specific options
70 };
71 By default radvd will send route advertisements so that every node on
73 the link can use them. The list of clients (IPv6 address) to advertise
74 to, and accept route solicitations from can be configured. If done,
75 radvd does not send send messages to the multicast addresses but to the
76 configured unicast addresses only. Solicitations from other addresses
77 are refused. This is similar to UnicastOnly but includes periodic mes‐
78 sages and incoming client access configuration. See examples section
79 for a use case of this.
80 The definitions are of the form:
82 clients {
84 list of IPv6 addresses
85 };
86
89 IgnoreIfMissing on|off
90 A flag indicating whether or not the interface is ignored if it
92 does not exist at start-up. By default, radvd exits.
93 This is useful for dynamic interfaces which are not active when
95 radvd starts or which are dynamically disabled and re-enabled
96 during the time radvd runs.
97 Current versions of radvd automatically try to re-enable inter‐
99 faces.
100 Enabling IgnoreIfMissing also quenches certain warnings in log
102 messages relating to missing interfaces.
103 Default: on
105 AdvSendAdvert on|off
108 A flag indicating whether or not the router sends periodic
110 router advertisements and responds to router solicitations.
111 This option no longer has to be specified first, but it needs to
113 be on to enable advertisement on this interface.
114 Default: off
116 UnicastOnly on|off
119 Indicates that the interface link type only supports unicast.
121 This will prevent unsolicited advertisements from being sent,
122 and will cause solicited advertisements to be unicast to the
123 soliciting node. This option is necessary for non-broadcast,
124 multiple-access links, such as ISATAP.
125 Default: off
127 MaxRtrAdvInterval seconds
130 The maximum time allowed between sending unsolicited multicast
132 router advertisements from the interface, in seconds.
133 Must be no less than 4 seconds and no greater than 1800 seconds.
135 Minimum when using Mobile IPv6 extensions: 0.07.
137 For values less than 0.2 seconds, 0.02 seconds is added to
139 account for scheduling granularities as specified in RFC3775.
140 Default: 600 seconds
142 MinRtrAdvInterval seconds
145 The minimum time allowed between sending unsolicited multicast
147 router advertisements from the interface, in seconds.
148 Must be no less than 3 seconds and no greater than 0.75 * MaxR‐
150 trAdvInterval.
151 Minimum when using Mobile IPv6 extensions: 0.03.
153 Default: 0.33 * MaxRtrAdvInterval
155 MinDelayBetweenRAs seconds
158 The minimum time allowed between sending multicast router adver‐
160 tisements from the interface, in seconds.
161 This applies to solicited multicast RAs. This is defined as the
163 protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861. MIPv6 rede‐
164 fines this parameter to have a minimum of 0.03 seconds.
165 Minimum when using Mobile IPv6 extensions: 0.03.
167 Default: 3
169 AdvManagedFlag on|off
172 When set, hosts use the administered (stateful) protocol for
174 address autoconfiguration in addition to any addresses autocon‐
175 figured using stateless address autoconfiguration. The use of
176 this flag is described in RFC 4862.
177 Default: off
179 AdvOtherConfigFlag on|off
182 When set, hosts use the administered (stateful) protocol for
184 autoconfiguration of other (non-address) information. The use
185 of this flag is described in RFC 4862.
186 Default: off
188 AdvLinkMTU integer
191 The MTU option is used in router advertisement messages to
193 insure that all nodes on a link use the same MTU value in those
194 cases where the link MTU is not well known.
195 If specified, i.e. not 0, must not be smaller than 1280 and not
197 greater than the maximum MTU allowed for this link (e.g. ether‐
198 net has a maximum MTU of 1500. See RFC 4864).
199 Default: 0
201 AdvReachableTime milliseconds
204 The time, in milliseconds, that a node assumes a neighbor is
206 reachable after having received a reachability confirmation.
207 Used by the Neighbor Unreachability Detection algorithm (see
208 Section 7.3 of RFC 4861). A value of zero means unspecified (by
209 this router).
210 Must be no greater than 3,600,000 milliseconds (1 hour).
212 Default: 0
214 AdvRetransTimer milliseconds
217 The time, in milliseconds, between retransmitted Neighbor Solic‐
219 itation messages. Used by address resolution and the Neighbor
220 Unreachability Detection algorithm (see Sections 7.2 and 7.3 of
221 RFC 4861). A value of zero means unspecified (by this router).
222 Default: 0
224 AdvCurHopLimit integer
227 The default value that should be placed in the Hop Count field
229 of the IP header for outgoing (unicast) IP packets. The value
230 should be set to the current diameter of the Internet. The
231 value zero means unspecified (by this router).
232 Default: 64
234 AdvDefaultLifetime seconds
237 The lifetime associated with the default router in units of sec‐
239 onds. The maximum value corresponds to 18.2 hours. A lifetime
240 of 0 indicates that the router is not a default router and
241 should not appear on the default router list. The router life‐
242 time applies only to the router's usefulness as a default
243 router; it does not apply to information contained in other mes‐
244 sage fields or options. Options that need time limits for their
245 information include their own lifetime fields.
246 Must be either zero or between MaxRtrAdvInterval and 9000 sec‐
248 onds.
249 Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
251 AdvDefaultPreference low|medium|high
254 The preference associated with the default router, as either
256 "low", "medium", or "high".
257 Default: medium
259 AdvSourceLLAddress on|off
262 When set, the link-layer address of the outgoing interface is
264 included in the RA.
265 Default: on
267 AdvHomeAgentFlag on|off
270 When set, indicates that sending router is able to serve as
272 Mobile IPv6 Home Agent. When set, minimum limits specified by
273 Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInter‐
274 val.
275 Default: off
277 AdvHomeAgentInfo on|off
280 When set, Home Agent Information Option (specified by Mobile
282 IPv6) is included in Router Advertisements. AdvHomeAgentFlag
283 must also be set when using this option.
284 Default: off
286 HomeAgentLifetime seconds
289 The length of time in seconds (relative to the time the packet
291 is sent) that the router is offering Mobile IPv6 Home Agent ser‐
292 vices. A value 0 must not be used. The maximum lifetime is
293 65520 seconds (18.2 hours). This option is ignored, if AdvHome‐
294 AgentInfo is not set.
295 If both HomeAgentLifetime and HomeAgentPreference are set to
297 their default values, Home Agent Information Option will not be
298 sent.
299 Default: AdvDefaultLifetime
301 HomeAgentPreference integer
304 The preference for the Home Agent sending this Router Advertise‐
306 ment. Values greater than 0 indicate more preferable Home
307 Agent, values less than 0 indicate less preferable Home Agent.
308 This option is ignored, if AdvHomeAgentInfo is not set.
309 If both HomeAgentLifetime and HomeAgentPreference are set to
311 their default values, Home Agent Information Option will not be
312 sent.
313 Default: 0
315 AdvMobRtrSupportFlag on|off
318 When set, the Home Agent signals it supports Mobile Router reg‐
320 istrations (specified by NEMO Basic). AdvHomeAgentInfo must
321 also be set when using this option.
322 Default: off
324 AdvIntervalOpt on|off
327 When set, Advertisement Interval Option (specified by Mobile
329 IPv6) is included in Router Advertisements. When set, minimum
330 limits specified by Mobile IPv6 are used for MinRtrAdvInterval
331 and MaxRtrAdvInterval.
332 The advertisement interval is based on the configured MaxRtrAdv‐
334 Interval parameter except where this is less than 200ms. In
335 this case, the advertised interval is ( MaxRtrAdvInterval + 20ms
336 ).
337 Default: off
339
342 AdvOnLink on|off
343 When set, indicates that this prefix can be used for on-link
345 determination. When not set the advertisement makes no state‐
346 ment about on-link or off-link properties of the prefix. For
347 instance, the prefix might be used for address configuration
348 with some of the addresses belonging to the prefix being on-link
349 and others being off-link.
350 Default: on
352 AdvAutonomous on|off
355 When set, indicates that this prefix can be used for autonomous
357 address configuration as specified in RFC 4862.
358 Default: on
360 AdvRouterAddr on|off
363 When set, indicates that the address of interface is sent
365 instead of network prefix, as is required by Mobile IPv6. When
366 set, minimum limits specified by Mobile IPv6 are used for MinR‐
367 trAdvInterval and MaxRtrAdvInterval.
368 Default: off
370 AdvValidLifetime seconds|infinity
373 The length of time in seconds (relative to the time the packet
375 is sent) that the prefix is valid for the purpose of on-link
376 determination. The symbolic value infinity represents infinity
377 (i.e. a value of all one bits (0xffffffff)). The valid lifetime
378 is also used by RFC 4862.
379 Note that clients will ignore AdvValidLifetime of an existing
381 prefix if the lifetime is below two hours, as required in RFC
382 4862 Section 5.5.3 point e).
383 Note: RFC4861's suggested default value is significantly longer:
385 30 days.
386 Default: 86400 seconds (1 day)
388 AdvPreferredLifetime seconds|infinity
391 The length of time in seconds (relative to the time the packet
393 is sent) that addresses generated from the prefix via stateless
394 address autoconfiguration remain preferred. The symbolic value
395 infinity represents infinity (i.e. a value of all one bits
396 (0xffffffff)). See RFC 4862.
397 Note: RFC4861's suggested default value is significantly longer:
399 7 days.
400 Default: 14400 seconds (4 hours)
402 DeprecatePrefix on|off
405 Upon shutdown, this option will cause radvd to deprecate the
407 prefix by announcing it in the radvd shutdown RA with a zero
408 preferred lifetime and a valid lifetime slightly greater than 2
409 hours. This will encourage end-nodes using this prefix to depre‐
410 cate any associated addresses immediately. Note that this option
411 should only be used when only one router is announcing the pre‐
412 fix onto the link, otherwise end-nodes will deprecate associated
413 addresses despite the prefix still being valid for preferred
414 use.
415 See RFC4862, section 5.5.3., "Router Advertisement Processing",
417 part (e).
418 Default: off
420 DecrementLifetimes on|off
423 This option causes radvd to decrement the values of the pre‐
425 ferred and valid lifetimes for the prefix over time. The life‐
426 times are decremented by the number of seconds since the last
427 RA. If radvd receives a SIGUSR1 signal, it will reset the values
428 of the preferred and valid lifetimes back to the initial values
429 used by radvd when it started. If radvd never receives a SIGUSR1
430 signal, it will continue to decrement the lifetimes until the
431 preferred lifetime reaches zero. After a final RA with a zero
432 value preferred lifetime, radvd will cease to announce the pre‐
433 fix. If a SIGUSR1 signal then causes the lifetimes to be reset,
434 the prefix will then re-appear in the RAs.
435 This option is intended to be used in conjunction with a DHCPv6
437 client that is using the Identity Association for Prefix Delega‐
438 tion (IA_PD) option to acquire a prefix from a Delegating Router
439 for use by a Requesting Router. In this scenario, the prefix(es)
440 from within the delegated prefix that are announced by radvd
441 would age in parallel with and at the same rate as the delegated
442 prefix, and expire at approximately the same time, if the dele‐
443 gated prefix's life isn't extended.
444 See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration
446 Protocol (DHCP) version 6".
447 Default: off
449 Base6Interface name
452 If this options is specified, this prefix will be combined with
454 the IPv6 address of the interface specified by name. The
455 resulting prefix length will be 64.
456 Base6to4Interface name
459 If this option is specified, this prefix will be combined with
461 the IPv4 address of interface name to produce a valid 6to4 pre‐
462 fix. The first 16 bits of this prefix will be replaced by 2002
463 and the next 32 bits of this prefix will be replaced by the IPv4
464 address assigned to interface name at configuration time. The
465 remaining 80 bits of the prefix (including the SLA ID) will be
466 advertised as specified in the configuration file. See the next
467 section for an example.
468 If interface name is not available at configuration time, a
470 warning will be written to the log and this prefix will be dis‐
471 abled until radvd is reconfigured.
472 This option enables systems with dynamic IPv4 addresses to
474 update their advertised 6to4 prefixes simply by restarting radvd
475 or sending a SIGHUP signal to cause radvd to reconfigure itself.
476 Note that 6to4 prefixes derived from dynamically-assigned IPv4
478 addresses should be advertised with a significantly shorter
479 lifetime (see the AdvValidLifetime and AdvPreferredLifetime
480 options).
481 For more information on 6to4, see RFC 3056.
483 Default: 6to4 is not used
485
488 AdvRouteLifetime seconds|infinity
489 The lifetime associated with the route in units of seconds. The
491 symbolic value infinity represents infinity (i.e. a value of all
492 one bits (0xffffffff)).
493 Default: 3 * MaxRtrAdvInterval
495 AdvRoutePreference low|medium|high
498 The preference associated with the default router, as either
500 "low", "medium", or "high".
501 Default: medium
503 RemoveRoute on|off
506 Upon shutdown, announce this route with a zero second lifetime.
508 This should cause the route to be immediately removed from the
509 receiving end-nodes' route table.
510 Default: on
512
515 AdvRDNSSLifetime seconds|infinity
516 The maximum duration how long the RDNSS entries are used for
517 name resolution. A value of 0 means the nameserver must no
518 longer be used. The value, if not 0, must be at least MaxRtrAdv‐
519 Interval. To ensure stale RDNSS info gets removed in a timely
520 fashion, this should not be greater than 2*MaxRtrAdvInterval.
521 Default: 2*MaxRtrAdvInterval
523 FlushRDNSS on|off
526 Upon shutdown, announce the RDNSS entries with a zero second
528 lifetime. This should cause the RDNSS addresses to be immedi‐
529 ately removed from the end-nodes' list of Recursive DNS Servers.
530 Default: on
532
535 AdvDNSSLLifetime seconds|infinity;
536 The maximum duration how long the DNSSL entries are used for
537 name resolution. A value of 0 means the suffix should no longer
538 be used. The value, if not 0, must be at least MaxRtrAdvInter‐
539 val. To ensure stale DNSSL info gets removed in a timely fash‐
540 ion, this should not be greater than 2*MaxRtrAdvInterval.
541 Default: 2*MaxRtrAdvInterval
543 FlushDNSSL on|off
546 Upon shutdown, announce the DNSSL entries with a zero second
548 lifetime. This should cause the DNSSL entries to be immediately
549 removed from the end-nodes' DNS search list.
550 Default: on
552
555 interface eth0
556 {
557 AdvSendAdvert on;
558 prefix 2001:db8:0:1::/64
559 {
560 AdvOnLink on;
561 AdvAutonomous on;
562 };
563 };
564 It says that router advertisement daemon should advertise (AdvSendAd‐
566 vert on;) the prefix 2001:db8:0:1:: which has a lenght of 64 on the
567 interface eth0. Also the prefix should be marked as autonomous (AdvAu‐
568 tonomous on;) and as on-link (AdvOnLink on;). All the other options
569 are left on their default values.
570 To support movement detection of Mobile IPv6 Mobile Nodes, the address
572 of interface should be used instead of network prefix:
573 interface eth0
575 {
576 AdvSendAdvert on;
577 prefix 2001:db8:0:1::4/64
578 {
579 AdvOnLink on;
580 AdvAutonomous on;
581 AdvRouterAddr on;
582 };
583 };
584 For 6to4 support, include the Base6to4Interface option in each prefix
586 section. When using a dynamic IPv4 address, set small prefix lifetimes
587 to prevent hosts from retaining unreachable prefixes after a new IPv4
588 address has been assigned. When advertising to on a dynamic interface
589 (e.g., Bluetooth), skip the interface if it is not active yet.
590 interface bnep0
592 {
593 IgnoreIfMissing on;
594 AdvSendAdvert on;
595 # Advertise at least every 30 seconds
597 MaxRtrAdvInterval 30;
598 prefix 0:0:0:5678::/64
600 {
601 AdvOnLink on;
602 AdvAutonomous on;
603 Base6to4Interface ppp0;
604 # Very short lifetimes for dynamic addresses
606 AdvValidLifetime 300;
607 AdvPreferredLifetime 120;
608 };
609 };
610 Since 6to4 is enabled, the prefix will be advertised as
612 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of ppp0
613 at configuration time. (IPv6 addresses are written in hexadecimal
614 whereas IPv4 addresses are written in decimal, so the IPv4 address
615 WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)
616 In this specific case, the configuration scripts may send HUP signal to
618 radvd when taking bnep0 up or down to notify about the status; in the
619 current radvd releases, sending HUP is no longer mandatory when the
620 link comes back up.
621 interface eth0
623 {
624 AdvSendAdvert on;
625 prefix 2001:db8:0:1::/64
626 {
627 AdvOnLink on;
628 AdvAutonomous on;
629 };
630 clients
631 {
632 fe80::21f:16ff:fe06:3aab;
633 fe80::21d:72ff:fe96:aaff;
634 };
635 };
636 This configuration would only announce the prefix to
638 fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. Furthermore,
639 all RA requests of other clients are denied.
640 This may come in handy if you want to roll out IPv6 only partially
642 because some clients are broken or untested.
643
647 /usr/sbin/radvd
648 /etc/radvd.conf
649 /var/run/radvd/radvd.pid
650 /var/log/radvd.log
651
654 The description of the different flags and variables is in large parts
655 taken from RFC 4861.
656
659 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Dis‐
660 covery for IP Version 6 (IPv6)", RFC 4861, September 2007.
661 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig‐
663 uration", RFC 4862, September 2007.
664 Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
666 4291, February 2006.
667 Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol
669 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 4443, March
670 2006.
671 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
673 RFC 2464, December 1998.
674 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
676 RFC 3056, February 2001. (6to4 specification)
677 Draves, R., D. Thaler, "Default Router Preferences and More-Specific
679 Routes", RFC 4191, November 2005.
680 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
682 3775, June 2004.
683 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network
685 Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
686 J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Adver‐
688 tisement Options for DNS Configuration", RFC 6106, November 2010.
689
692 radvd(8), radvdump(8)
693
696 radvd does not support splitting up RAs to multiple packets (RFC4861
697 6.2.3 last paragraph). In practise this limits advertising to ~45 pre‐
698 fixes on a link, but there is no reason to be able to so.
699radvd 1.8.2 4 Jan 2011 RADVD.CONF(5)