1RADVD.CONF(5) RADVD.CONF(5)
2
3
4
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
13 The file contains one or more interface definitions of the form:
14
15 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
23 All the possible interface specific options are detailed below. Each
24 option has to be terminated by a semicolon.
25
26 Prefix definitions are of the form:
27
28 prefix prefix/length {
29 list of prefix specific options
30 };
31
32 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
35 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
43 All the possible prefix specific options are described below. Each
44 option has to be terminated by a semicolon.
45
46 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
50 Route definitions are of the form:
51
52 route prefix/length {
53 list of route specific options
54 };
55
56 The prefix of a route definition should be network prefix; it can be
57 used to advertise more specific routes to the hosts.
58
59 RDNSS (Recursive DNS server) definitions are of the form:
60
61 RDNSS ip [ip] [ip] {
62 list of rdnss specific options
63 };
64
65 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
74 The definitions are of the form:
75
76 clients {
77 list of IPv6 addresses
78 };
79
80
82 IgnoreIfMissing on|off
83
84 A flag indicating whether or not the interface is ignored if it
85 does not exist at start-up. By default, radvd exits.
86
87 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
91 Current versions of radvd automatically try to re-enable inter‐
92 faces.
93
94 Enabling IgnoreIfMissing also quenches certain warnings in log
95 messages relating to missing interfaces.
96
97 Default: off
98
99
100 AdvSendAdvert on|off
101
102 A flag indicating whether or not the router sends periodic
103 router advertisements and responds to router solicitations.
104
105 This option no longer has to be specified first, but it needs to
106 be on to enable advertisement on this interface.
107
108 Default: off
109
110
111 UnicastOnly on|off
112
113 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
119 Default: off
120
121
122 MaxRtrAdvInterval seconds
123
124 The maximum time allowed between sending unsolicited multicast
125 router advertisements from the interface, in seconds.
126
127 Must be no less than 4 seconds and no greater than 1800 seconds.
128
129 Minimum when using Mobile IPv6 extensions: 0.07.
130
131 For values less than 0.2 seconds, 0.02 seconds is added to
132 account for scheduling granularities as specified in RFC3775.
133
134 Default: 600 seconds
135
136
137 MinRtrAdvInterval seconds
138
139 The minimum time allowed between sending unsolicited multicast
140 router advertisements from the interface, in seconds.
141
142 Must be no less than 3 seconds and no greater than 0.75 * MaxR‐
143 trAdvInterval.
144
145 Minimum when using Mobile IPv6 extensions: 0.03.
146
147 Default: 0.33 * MaxRtrAdvInterval
148
149
150 MinDelayBetweenRAs seconds
151
152 The minimum time allowed between sending multicast router adver‐
153 tisements from the interface, in seconds.
154
155 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
159 Minimum when using Mobile IPv6 extensions: 0.03.
160
161 Default: 3
162
163
164 AdvManagedFlag on|off
165
166 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
171 Default: off
172
173
174 AdvOtherConfigFlag on|off
175
176 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
180 Default: off
181
182
183 AdvLinkMTU integer
184
185 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
189 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
193 Default: 0
194
195
196 AdvReachableTime milliseconds
197
198 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
204 Must be no greater than 3,600,000 milliseconds (1 hour).
205
206 Default: 0
207
208
209 AdvRetransTimer milliseconds
210
211 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
216 Default: 0
217
218
219 AdvCurHopLimit integer
220
221 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
226 Default: 64
227
228
229 AdvDefaultLifetime seconds
230
231 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
240 Must be either zero or between MaxRtrAdvInterval and 9000 sec‐
241 onds.
242
243 Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
244
245
246 AdvDefaultPreference low|medium|high
247
248 The preference associated with the default router, as either
249 "low", "medium", or "high".
250
251 Default: medium
252
253
254 AdvSourceLLAddress on|off
255
256 When set, the link-layer address of the outgoing interface is
257 included in the RA.
258
259 Default: on
260
261
262 AdvHomeAgentFlag on|off
263
264 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
269 Default: off
270
271
272 AdvHomeAgentInfo on|off
273
274 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
278 Default: off
279
280
281 HomeAgentLifetime seconds
282
283 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
289 If both HomeAgentLifetime and HomeAgentPreference are set to
290 their default values, Home Agent Information Option will not be
291 sent.
292
293 Default: AdvDefaultLifetime
294
295
296 HomeAgentPreference integer
297
298 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
303 If both HomeAgentLifetime and HomeAgentPreference are set to
304 their default values, Home Agent Information Option will not be
305 sent.
306
307 Default: 0
308
309
310 AdvMobRtrSupportFlag on|off
311
312 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
316 Default: off
317
318
319 AdvIntervalOpt on|off
320
321 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
326 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
331 Default: off
332
333
335 AdvOnLink on|off
336
337 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
344 Default: on
345
346
347 AdvAutonomous on|off
348
349 When set, indicates that this prefix can be used for autonomous
350 address configuration as specified in RFC 4862.
351
352 Default: on
353
354
355 AdvRouterAddr on|off
356
357 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
362 Default: off
363
364
365 AdvValidLifetime seconds|infinity
366
367 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
373 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
377 Note: RFC4861's suggested default value is significantly longer:
378 30 days.
379
380 Default: 86400 seconds (1 day)
381
382
383 AdvPreferredLifetime seconds|infinity
384
385 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
391 Note: RFC4861's suggested default value is significantly longer:
392 7 days.
393
394 Default: 14400 seconds (4 hours)
395
396
397 Base6to4Interface name
398
399 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
408 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
412 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
416 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
421 For more information on 6to4, see RFC 3056.
422
423 Default: 6to4 is not used
424
425
427 AdvRouteLifetime seconds|infinity
428
429 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
433 Default: 3 * MaxRtrAdvInterval
434
435
436 AdvRoutePreference low|medium|high
437
438 The preference associated with the default router, as either
439 "low", "medium", or "high".
440
441 Default: medium
442
443
445 AdvRDNSSPreference integer;
446
447 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
452 NOTE: This feature was removed from the final RFC but can still
453 be used for experimental purposes.
454
455 Default: 8
456
457
458 AdvRDNSSOpen on|off;
459
460 "Service Open" flag. When set, indicates that RDNSS continues to
461 be available to hosts even if they moved to a different subnet.
462
463 NOTE: This feature was removed from the final RFC but can still
464 be used for experimental purposes.
465
466 Default: off
467
468
469 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
479 Default: 2*MaxRtrAdvInterval
480
481
483 interface eth0
484 {
485 AdvSendAdvert on;
486 prefix 2001:db8:0:1::/64
487 {
488 AdvOnLink on;
489 AdvAutonomous on;
490 };
491 };
492
493 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
499 To support movement detection of Mobile IPv6 Mobile Nodes, the address
500 of interface should be used instead of network prefix:
501
502 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
513 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
519 interface bnep0
520 {
521 IgnoreIfMissing on;
522 AdvSendAdvert on;
523
524 # Advertise at least every 30 seconds
525 MaxRtrAdvInterval 30;
526
527 prefix 0:0:0:5678::/64
528 {
529 AdvOnLink on;
530 AdvAutonomous on;
531 Base6to4Interface ppp0;
532
533 # Very short lifetimes for dynamic addresses
534 AdvValidLifetime 300;
535 AdvPreferredLifetime 120;
536 };
537 };
538
539 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
545 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
550 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
565 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
569 This may come in handy if you want to roll out IPv6 only partially
570 because some clients are broken or untested.
571
572
573
575 /usr/sbin/radvd
576 /etc/radvd.conf
577 /var/run/radvd/radvd.pid
578 /var/log/radvd.log
579
580
582 The description of the different flags and variables is in large parts
583 taken from RFC 4861.
584
585
587 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Dis‐
588 covery for IP Version 6 (IPv6)", RFC 4861, September 2007.
589
590 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig‐
591 uration", RFC 4862, September 2007.
592
593 Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
594 4291, February 2006.
595
596 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
600 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
601 RFC 2464, December 1998.
602
603 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
604 RFC 3056, February 2001. (6to4 specification)
605
606 Draves, R., D. Thaler, "Default Router Preferences and More-Specific
607 Routes", RFC 4191, November 2005.
608
609 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
610 3775, June 2004.
611
612 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network
613 Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
614
615 J. Jeong, L. Beloeil, and S. Madanapalli, "IPv6 Router Advertisement
616 Option for DNS Configuration", RFC 5006, September 2007.
617
618
620 radvd(8), radvdump(8)
621
622
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.
627
628
629
630
631radvd 1.6 19 Jun 2009 RADVD.CONF(5)