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 };
22 All the possible interface specific options are detailed below. Each
24 option has to be terminated by a semicolon.
25 Prefix definitions are of the form:
27 prefix prefix/length {
29 list of prefix specific options
30 };
31 Prefix can be network prefix or the address of the inferface. The
33 address of interface should be used when using Mobile IPv6 extensions.
34 Special prefix "::/64" is also supported on systems that implement
36 getifaddrs() (on other systems, configuration activation fails and
37 radvd exits). When configured, radvd picks one non-link-local prefix
38 assigned to the interface and starts advertising it. This may be
39 applicable in non-6to4 scenarios where the upstream prefix might
40 change. This option is incompatible with Base6to4Interface option.
41 AdvRouterAddr option is always enabled when this configuration is used.
42 All the possible prefix specific options are described below. Each
44 option has to be terminated by a semicolon.
45 Decimal values are allowed only for MinDelayBetweenRAs, MaxRtrAdvInter‐
47 val and MinRtrAdvInterval. Decimal values should be used only when
48 using Mobile IPv6 extensions.
49 Route definitions are of the form:
51 route prefix/length {
53 list of route specific options
54 };
55 The prefix of a route definition should be network prefix; it can be
57 used to advertise more specific routes to the hosts.
58 RDNSS (Recursive DNS server) definitions are of the form:
60 RDNSS ip [ip] [ip] {
62 list of rdnss specific options
63 };
64 By default radvd will send route advertisements so that every node on
66 the link can use them. The list of clients (IPv6 address) to advertise
67 to, and accept route solicitations from can be configured. If done,
68 radvd does not send send messages to the multicast addresses but to the
69 configured unicast addresses only. Solicitations from other addresses
70 are refused. This is similar to UnicastOnly but includes periodic mes‐
71 sages and incoming client access configuration. See examples section
72 for a use case of this.
73 The definitions are of the form:
75 clients {
77 list of IPv6 addresses
78 };
79
82 IgnoreIfMissing on|off
83 A flag indicating whether or not the interface is ignored if it
85 does not exist at start-up. By default, radvd exits.
86 This is useful for dynamic interfaces which are not active when
88 radvd starts or which are dynamically disabled and re-enabled
89 during the time radvd runs.
90 Current versions of radvd automatically try to re-enable inter‐
92 faces.
93 Enabling IgnoreIfMissing also quenches certain warnings in log
95 messages relating to missing interfaces.
96 Default: off
98 AdvSendAdvert on|off
101 A flag indicating whether or not the router sends periodic
103 router advertisements and responds to router solicitations.
104 This option no longer has to be specified first, but it needs to
106 be on to enable advertisement on this interface.
107 Default: off
109 UnicastOnly on|off
112 Indicates that the interface link type only supports unicast.
114 This will prevent unsolicited advertisements from being sent,
115 and will cause solicited advertisements to be unicast to the
116 soliciting node. This option is necessary for non-broadcast,
117 multiple-access links, such as ISATAP.
118 Default: off
120 MaxRtrAdvInterval seconds
123 The maximum time allowed between sending unsolicited multicast
125 router advertisements from the interface, in seconds.
126 Must be no less than 4 seconds and no greater than 1800 seconds.
128 Minimum when using Mobile IPv6 extensions: 0.07.
130 For values less than 0.2 seconds, 0.02 seconds is added to
132 account for scheduling granularities as specified in RFC3775.
133 Default: 600 seconds
135 MinRtrAdvInterval seconds
138 The minimum time allowed between sending unsolicited multicast
140 router advertisements from the interface, in seconds.
141 Must be no less than 3 seconds and no greater than 0.75 * MaxR‐
143 trAdvInterval.
144 Minimum when using Mobile IPv6 extensions: 0.03.
146 Default: 0.33 * MaxRtrAdvInterval
148 MinDelayBetweenRAs seconds
151 The minimum time allowed between sending multicast router adver‐
153 tisements from the interface, in seconds.
154 This applies to solicited multicast RAs. This is defined as the
156 protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861. MIPv6 rede‐
157 fines this parameter to have a minimum of 0.03 seconds.
158 Minimum when using Mobile IPv6 extensions: 0.03.
160 Default: 3
162 AdvManagedFlag on|off
165 When set, hosts use the administered (stateful) protocol for
167 address autoconfiguration in addition to any addresses autocon‐
168 figured using stateless address autoconfiguration. The use of
169 this flag is described in RFC 4862.
170 Default: off
172 AdvOtherConfigFlag on|off
175 When set, hosts use the administered (stateful) protocol for
177 autoconfiguration of other (non-address) information. The use
178 of this flag is described in RFC 4862.
179 Default: off
181 AdvLinkMTU integer
184 The MTU option is used in router advertisement messages to
186 insure that all nodes on a link use the same MTU value in those
187 cases where the link MTU is not well known.
188 If specified, i.e. not 0, must not be smaller than 1280 and not
190 greater than the maximum MTU allowed for this link (e.g. ether‐
191 net has a maximum MTU of 1500. See RFC 4864).
192 Default: 0
194 AdvReachableTime milliseconds
197 The time, in milliseconds, that a node assumes a neighbor is
199 reachable after having received a reachability confirmation.
200 Used by the Neighbor Unreachability Detection algorithm (see
201 Section 7.3 of RFC 4861). A value of zero means unspecified (by
202 this router).
203 Must be no greater than 3,600,000 milliseconds (1 hour).
205 Default: 0
207 AdvRetransTimer milliseconds
210 The time, in milliseconds, between retransmitted Neighbor Solic‐
212 itation messages. Used by address resolution and the Neighbor
213 Unreachability Detection algorithm (see Sections 7.2 and 7.3 of
214 RFC 4861). A value of zero means unspecified (by this router).
215 Default: 0
217 AdvCurHopLimit integer
220 The default value that should be placed in the Hop Count field
222 of the IP header for outgoing (unicast) IP packets. The value
223 should be set to the current diameter of the Internet. The
224 value zero means unspecified (by this router).
225 Default: 64
227 AdvDefaultLifetime seconds
230 The lifetime associated with the default router in units of sec‐
232 onds. The maximum value corresponds to 18.2 hours. A lifetime
233 of 0 indicates that the router is not a default router and
234 should not appear on the default router list. The router life‐
235 time applies only to the router's usefulness as a default
236 router; it does not apply to information contained in other mes‐
237 sage fields or options. Options that need time limits for their
238 information include their own lifetime fields.
239 Must be either zero or between MaxRtrAdvInterval and 9000 sec‐
241 onds.
242 Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
244 AdvDefaultPreference low|medium|high
247 The preference associated with the default router, as either
249 "low", "medium", or "high".
250 Default: medium
252 AdvSourceLLAddress on|off
255 When set, the link-layer address of the outgoing interface is
257 included in the RA.
258 Default: on
260 AdvHomeAgentFlag on|off
263 When set, indicates that sending router is able to serve as
265 Mobile IPv6 Home Agent. When set, minimum limits specified by
266 Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInter‐
267 val.
268 Default: off
270 AdvHomeAgentInfo on|off
273 When set, Home Agent Information Option (specified by Mobile
275 IPv6) is included in Router Advertisements. AdvHomeAgentFlag
276 must also be set when using this option.
277 Default: off
279 HomeAgentLifetime seconds
282 The length of time in seconds (relative to the time the packet
284 is sent) that the router is offering Mobile IPv6 Home Agent ser‐
285 vices. A value 0 must not be used. The maximum lifetime is
286 65520 seconds (18.2 hours). This option is ignored, if AdvHome‐
287 AgentInfo is not set.
288 If both HomeAgentLifetime and HomeAgentPreference are set to
290 their default values, Home Agent Information Option will not be
291 sent.
292 Default: AdvDefaultLifetime
294 HomeAgentPreference integer
297 The preference for the Home Agent sending this Router Advertise‐
299 ment. Values greater than 0 indicate more preferable Home
300 Agent, values less than 0 indicate less preferable Home Agent.
301 This option is ignored, if AdvHomeAgentInfo is not set.
302 If both HomeAgentLifetime and HomeAgentPreference are set to
304 their default values, Home Agent Information Option will not be
305 sent.
306 Default: 0
308 AdvMobRtrSupportFlag on|off
311 When set, the Home Agent signals it supports Mobile Router reg‐
313 istrations (specified by NEMO Basic). AdvHomeAgentInfo must
314 also be set when using this option.
315 Default: off
317 AdvIntervalOpt on|off
320 When set, Advertisement Interval Option (specified by Mobile
322 IPv6) is included in Router Advertisements. When set, minimum
323 limits specified by Mobile IPv6 are used for MinRtrAdvInterval
324 and MaxRtrAdvInterval.
325 The advertisement interval is based on the configured MaxRtrAdv‐
327 Interval parameter except where this is less than 200ms. In
328 this case, the advertised interval is ( MaxRtrAdvInterval + 20ms
329 ).
330 Default: off
332
335 AdvOnLink on|off
336 When set, indicates that this prefix can be used for on-link
338 determination. When not set the advertisement makes no state‐
339 ment about on-link or off-link properties of the prefix. For
340 instance, the prefix might be used for address configuration
341 with some of the addresses belonging to the prefix being on-link
342 and others being off-link.
343 Default: on
345 AdvAutonomous on|off
348 When set, indicates that this prefix can be used for autonomous
350 address configuration as specified in RFC 4862.
351 Default: on
353 AdvRouterAddr on|off
356 When set, indicates that the address of interface is sent
358 instead of network prefix, as is required by Mobile IPv6. When
359 set, minimum limits specified by Mobile IPv6 are used for MinR‐
360 trAdvInterval and MaxRtrAdvInterval.
361 Default: off
363 AdvValidLifetime seconds|infinity
366 The length of time in seconds (relative to the time the packet
368 is sent) that the prefix is valid for the purpose of on-link
369 determination. The symbolic value infinity represents infinity
370 (i.e. a value of all one bits (0xffffffff)). The valid lifetime
371 is also used by RFC 4862.
372 Note that clients will ignore AdvValidLifetime of an existing
374 prefix if the lifetime is below two hours, as required in RFC
375 4862 Section 5.5.3 point e).
376 Note: RFC4861's suggested default value is significantly longer:
378 30 days.
379 Default: 86400 seconds (1 day)
381 AdvPreferredLifetime seconds|infinity
384 The length of time in seconds (relative to the time the packet
386 is sent) that addresses generated from the prefix via stateless
387 address autoconfiguration remain preferred. The symbolic value
388 infinity represents infinity (i.e. a value of all one bits
389 (0xffffffff)). See RFC 4862.
390 Note: RFC4861's suggested default value is significantly longer:
392 7 days.
393 Default: 14400 seconds (4 hours)
395 Base6to4Interface name
398 If this option is specified, this prefix will be combined with
400 the IPv4 address of interface name to produce a valid 6to4 pre‐
401 fix. The first 16 bits of this prefix will be replaced by 2002
402 and the next 32 bits of this prefix will be replaced by the IPv4
403 address assigned to interface name at configuration time. The
404 remaining 80 bits of the prefix (including the SLA ID) will be
405 advertised as specified in the configuration file. See the next
406 section for an example.
407 If interface name is not available at configuration time, a
409 warning will be written to the log and this prefix will be dis‐
410 abled until radvd is reconfigured.
411 This option enables systems with dynamic IPv4 addresses to
413 update their advertised 6to4 prefixes simply by restarting radvd
414 or sending a SIGHUP signal to cause radvd to reconfigure itself.
415 Note that 6to4 prefixes derived from dynamically-assigned IPv4
417 addresses should be advertised with a significantly shorter
418 lifetime (see the AdvValidLifetime and AdvPreferredLifetime
419 options).
420 For more information on 6to4, see RFC 3056.
422 Default: 6to4 is not used
424
427 AdvRouteLifetime seconds|infinity
428 The lifetime associated with the route in units of seconds. The
430 symbolic value infinity represents infinity (i.e. a value of all
431 one bits (0xffffffff)).
432 Default: 3 * MaxRtrAdvInterval
434 AdvRoutePreference low|medium|high
437 The preference associated with the default router, as either
439 "low", "medium", or "high".
440 Default: medium
442
445 AdvRDNSSPreference integer;
446 The preference of the DNS server, compared to other DNS servers
448 advertised and used. 0 to 7 means less important than manually
449 configured nameservers in resolv.conf, while 12 to 15 means more
450 important.
451 NOTE: This feature was removed from the final RFC but can still
453 be used for experimental purposes.
454 Default: 8
456 AdvRDNSSOpen on|off;
459 "Service Open" flag. When set, indicates that RDNSS continues to
461 be available to hosts even if they moved to a different subnet.
462 NOTE: This feature was removed from the final RFC but can still
464 be used for experimental purposes.
465 Default: off
467 AdvRDNSSLifetime seconds|infinity;
470 The maximum duration how long the RDNSS entries are used for
471 name resolution. A value of 0 means the nameserver should no
472 longer be used. The maximum duration how long the RDNSS entries
473 are used for name resolution. A value of 0 means the nameserver
474 should no longer be used. The value, if not 0, must be at least
475 MaxRtrAdvInterval. To ensure stale RDNSS info gets removed in a
476 timely fashion, this should not be greater than 2*MaxRtrAdvIn‐
477 terval.
478 Default: 2*MaxRtrAdvInterval
480
483 interface eth0
484 {
485 AdvSendAdvert on;
486 prefix 2001:db8:0:1::/64
487 {
488 AdvOnLink on;
489 AdvAutonomous on;
490 };
491 };
492 It says that router advertisement daemon should advertise (AdvSendAd‐
494 vert on;) the prefix 2001:db8:0:1:: which has a lenght of 64 on the
495 interface eth0. Also the prefix should be marked as autonomous (AdvAu‐
496 tonomous on;) and as on-link (AdvOnLink on;). All the other options
497 are left on their default values.
498 To support movement detection of Mobile IPv6 Mobile Nodes, the address
500 of interface should be used instead of network prefix:
501 interface eth0
503 {
504 AdvSendAdvert on;
505 prefix 2001:db8:0:1::4/64
506 {
507 AdvOnLink on;
508 AdvAutonomous on;
509 AdvRouterAddr on;
510 };
511 };
512 For 6to4 support, include the Base6to4Interface option in each prefix
514 section. When using a dynamic IPv4 address, set small prefix lifetimes
515 to prevent hosts from retaining unreachable prefixes after a new IPv4
516 address has been assigned. When advertising to on a dynamic interface
517 (e.g., Bluetooth), skip the interface if it is not active yet.
518 interface bnep0
520 {
521 IgnoreIfMissing on;
522 AdvSendAdvert on;
523 # Advertise at least every 30 seconds
525 MaxRtrAdvInterval 30;
526 prefix 0:0:0:5678::/64
528 {
529 AdvOnLink on;
530 AdvAutonomous on;
531 Base6to4Interface ppp0;
532 # Very short lifetimes for dynamic addresses
534 AdvValidLifetime 300;
535 AdvPreferredLifetime 120;
536 };
537 };
538 Since 6to4 is enabled, the prefix will be advertised as
540 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of ppp0
541 at configuration time. (IPv6 addresses are written in hexadecimal
542 whereas IPv4 addresses are written in decimal, so the IPv4 address
543 WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)
544 In this specific case, the configuration scripts may send HUP signal to
546 radvd when taking bnep0 up or down to notify about the status; in the
547 current radvd releases, sending HUP is no longer mandatory when the
548 link comes back up.
549 interface eth0
551 {
552 AdvSendAdvert on;
553 prefix 2001:db8:0:1::/64
554 {
555 AdvOnLink on;
556 AdvAutonomous on;
557 };
558 clients
559 {
560 fe80::21f:16ff:fe06:3aab;
561 fe80::21d:72ff:fe96:aaff;
562 };
563 };
564 This configuration would only announce the prefix to
566 fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. Furthermore,
567 all RA requests of other clients are denied.
568 This may come in handy if you want to roll out IPv6 only partially
570 because some clients are broken or untested.
571
575 /usr/sbin/radvd
576 /etc/radvd.conf
577 /var/run/radvd/radvd.pid
578 /var/log/radvd.log
579
582 The description of the different flags and variables is in large parts
583 taken from RFC 4861.
584
587 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Dis‐
588 covery for IP Version 6 (IPv6)", RFC 4861, September 2007.
589 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig‐
591 uration", RFC 4862, September 2007.
592 Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
594 4291, February 2006.
595 Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol
597 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 4443, March
598 2006.
599 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
601 RFC 2464, December 1998.
602 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
604 RFC 3056, February 2001. (6to4 specification)
605 Draves, R., D. Thaler, "Default Router Preferences and More-Specific
607 Routes", RFC 4191, November 2005.
608 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
610 3775, June 2004.
611 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network
613 Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
614 J. Jeong, L. Beloeil, and S. Madanapalli, "IPv6 Router Advertisement
616 Option for DNS Configuration", RFC 5006, September 2007.
617
620 radvd(8), radvdump(8)
621
624 radvd does not support splitting up RAs to multiple packets (RFC4861
625 6.2.3 last paragraph). In practise this limits advertising to ~45 pre‐
626 fixes on a link, but there is no reason to be able to so.
627radvd 1.6 19 Jun 2009 RADVD.CONF(5)