1RADVD.CONF(5)                                                    RADVD.CONF(5)
2
3
4

NAME

6       radvd.conf  -  configuration  file  of  the router advertisement daemon
7       radvd
8

DESCRIPTION

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            list of DNSSL definitions
22            list of ABRO definitions
23            list of acceptable RA source addresses
24       };
25
26       All  the  possible interface specific options are detailed below.  Each
27       option has to be terminated by a semicolon.
28
29       Prefix definitions are of the form:
30
31       prefix prefix/length {
32            list of prefix specific options
33       };
34
35       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
38       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
46       All  the  possible  prefix  specific options are described below.  Each
47       option has to be terminated by a semicolon.
48
49       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
53       Route definitions are of the form:
54
55       route prefix/length {
56            list of route specific options
57       };
58
59       The prefix of a route definition should be network prefix;  it  can  be
60       used to advertise more specific routes to the hosts.
61
62       RDNSS (Recursive DNS server) definitions are of the form:
63
64       RDNSS ip [ip] [ip] {
65            list of rdnss specific options
66       };
67
68       DNSSL (DNS Search List) definitions are of the form:
69
70       DNSSL suffix [suffix] [suffix] [...] {
71            list of dnssl specific options
72       };
73
74       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
83       The definitions are of the form:
84
85       clients {
86               list of IPv6 addresses
87       };
88
89       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
97       AdvRASrcAddress {
98               list of IPv6 addresses
99       };
100
101       ABRO (Authoritative Border Router Option) definitions are of the form:
102
103       abro IPv6-address {
104               list of abro specific options
105       };
106
107

INTERFACE SPECIFIC OPTIONS

109       IgnoreIfMissing on|off
110
111              A flag indicating whether or not the interface is ignored if  it
112              does not exist at start-up.  By default, radvd exits.
113
114              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
118              Current  versions of radvd automatically try to re-enable inter‐
119              faces.
120
121              Enabling IgnoreIfMissing also quenches certain warnings  in  log
122              messages relating to missing interfaces.
123
124              Default: on
125
126
127       AdvSendAdvert on|off
128
129              A  flag  indicating  whether  or  not  the router sends periodic
130              router advertisements and responds to router solicitations.
131
132              This option no longer has to be specified first, but it needs to
133              be on to enable advertisement on this interface.
134
135              Default: off
136
137
138       UnicastOnly on|off
139
140              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
146              Default: off
147
148
149       AdvRASolicitedUnicast on|off
150
151              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
157              This  corresponds  to  the Cisco IOS option ipv6 nd ra solicited
158              unicast
159
160              Default: on
161
162
163       MaxRtrAdvInterval seconds
164
165              The maximum time allowed between sending  unsolicited  multicast
166              router advertisements from the interface, in seconds.
167
168              Must be no less than 4 seconds and no greater than 1800 seconds.
169
170              Minimum when using Mobile IPv6 extensions: 0.07.
171
172              For  values  less  than  0.2  seconds,  0.02 seconds is added to
173              account for scheduling granularities as specified in RFC3775.
174
175              Default: 600 seconds
176
177
178       MinRtrAdvInterval seconds
179
180              The minimum time allowed between sending  unsolicited  multicast
181              router advertisements from the interface, in seconds.
182
183              Must  be no less than 3 seconds and no greater than 0.75 * MaxR‐
184              trAdvInterval.
185
186              Minimum when using Mobile IPv6 extensions: 0.03.
187
188              Default: 0.33 * MaxRtrAdvInterval
189
190
191       MinDelayBetweenRAs seconds
192
193              The minimum time allowed between sending multicast router adver‐
194              tisements from the interface, in seconds.
195
196              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
200              Minimum when using Mobile IPv6 extensions: 0.03.
201
202              Default: 3
203
204
205       AdvManagedFlag on|off
206
207              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
212              Default: off
213
214
215       AdvOtherConfigFlag on|off
216
217              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
221              Default: off
222
223
224       AdvLinkMTU integer
225
226              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
230              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
234              Default: 0
235
236
237       AdvReachableTime milliseconds
238
239              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
245              Must be no greater than 3,600,000 milliseconds (1 hour).
246
247              Default: 0
248
249
250       AdvRetransTimer milliseconds
251
252              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
257              Default: 0
258
259
260       AdvCurHopLimit integer
261
262              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
267              Default: 64
268
269
270       AdvDefaultLifetime seconds
271
272              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
281              Must  be  either zero or between MaxRtrAdvInterval and 9000 sec‐
282              onds.
283
284              Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
285
286
287       AdvDefaultPreference low|medium|high
288
289              The preference associated with the  default  router,  as  either
290              "low", "medium", or "high".
291
292              Default: medium
293
294
295       AdvSourceLLAddress on|off
296
297              When  set,  the  link-layer address of the outgoing interface is
298              included in the RA.
299
300              Default: on
301
302
303       AdvHomeAgentFlag on|off
304
305              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
310              Default: off
311
312
313       AdvHomeAgentInfo on|off
314
315              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
319              Default: off
320
321
322       HomeAgentLifetime seconds
323
324              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
330              If  both  HomeAgentLifetime  and  HomeAgentPreference are set to
331              their default values, Home Agent Information Option will not  be
332              sent.
333
334              Default: AdvDefaultLifetime
335
336
337       HomeAgentPreference integer
338
339              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
344              If both HomeAgentLifetime and  HomeAgentPreference  are  set  to
345              their  default values, Home Agent Information Option will not be
346              sent.
347
348              Default: 0
349
350
351       AdvMobRtrSupportFlag on|off
352
353              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
357              Default: off
358
359
360       AdvIntervalOpt on|off
361
362              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
367              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
372              Default: off
373
374

PREFIX SPECIFIC OPTIONS

376       AdvOnLink on|off
377
378              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
385              Default: on
386
387
388       AdvAutonomous on|off
389
390              When  set, indicates that this prefix can be used for autonomous
391              address configuration as specified in RFC 4862.
392
393              Default: on
394
395
396       AdvRouterAddr on|off
397
398              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
403              Default: off
404
405
406       AdvValidLifetime seconds|infinity
407
408              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
414              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
418              Note: RFC4861's suggested default value is significantly longer:
419              30 days.
420
421              Default: 86400 seconds (1 day)
422
423
424       AdvPreferredLifetime seconds|infinity
425
426              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
432              Note: RFC4861's suggested default value is significantly longer:
433              7 days.
434
435              Default: 14400 seconds (4 hours)
436
437
438       DeprecatePrefix on|off
439
440              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
450              See  RFC4862, section 5.5.3., "Router Advertisement Processing",
451              part (e).
452
453              Default: off
454
455
456       DecrementLifetimes on|off
457
458              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
470              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
479              See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration
480              Protocol (DHCP) version 6".
481
482              Default: off
483
484
485       Base6Interface name
486
487              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
491
492       Base6to4Interface name
493
494              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
503              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
507              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
511              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
516              For more information on 6to4, see RFC 3056.
517
518              Default: 6to4 is not used
519
520

ROUTE SPECIFIC OPTIONS

522       AdvRouteLifetime seconds|infinity
523
524              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
528              Default: 3 * MaxRtrAdvInterval
529
530
531       AdvRoutePreference low|medium|high
532
533              The preference associated with the  default  router,  as  either
534              "low", "medium", or "high".
535
536              Default: medium
537
538
539       RemoveRoute on|off
540
541              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
545              Default: on
546
547

RDNSS SPECIFIC OPTIONS

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
556              Default: 2*MaxRtrAdvInterval
557
558
559       FlushRDNSS on|off
560
561              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
565              Default: on
566
567

DNSSL SPECIFIC OPTIONS

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
576              Default: 2*MaxRtrAdvInterval
577
578
579       FlushDNSSL on|off
580
581              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
585              Default: on
586
587

ABRO SPECIFIC OPTIONS

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
594
595       AdvVersionLow, AdvVersionHigh unsignedinteger
596              Both  forms  32-bit unsigned version number corresponding to the
597              set of information contained in RA message.
598
599

EXAMPLES

601       interface eth0
602       {
603               AdvSendAdvert on;
604               prefix 2001:db8:0:1::/64
605               {
606                       AdvOnLink on;
607                       AdvAutonomous on;
608               };
609       };
610
611       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
617       To support movement detection of Mobile IPv6 Mobile Nodes, the  address
618       of interface should be used instead of network prefix:
619
620       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
631       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
637       interface bnep0
638       {
639               IgnoreIfMissing on;
640               AdvSendAdvert on;
641
642               # Advertise at least every 30 seconds
643               MaxRtrAdvInterval 30;
644
645               prefix 0:0:0:5678::/64
646               {
647                       AdvOnLink on;
648                       AdvAutonomous on;
649                       Base6to4Interface ppp0;
650
651                       # Very short lifetimes for dynamic addresses
652                       AdvValidLifetime 300;
653                       AdvPreferredLifetime 120;
654               };
655       };
656
657       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
663       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
668       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
683       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
687       This may come in handy if you want to  roll  out  IPv6  only  partially
688       because some clients are broken or untested.
689
690       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
708

FILES

710       /usr/sbin/radvd
711       /etc/radvd.conf
712       /run/radvd/radvd.pid
713       /var/log/radvd.log
714
715

CREDIT

717       The  description of the different flags and variables is in large parts
718       taken from RFC 4861.
719
720

RFCS

722       Narten, T., Nordmark, E., Simpson, W., and H. Soliman,  "Neighbor  Dis‐
723       covery for IP Version 6 (IPv6)", RFC 4861, September 2007.
724
725       Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig‐
726       uration", RFC 4862, September 2007.
727
728       Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
729       4291, February 2006.
730
731       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
735       Crawford,  M.,  "Transmission  of IPv6 Packets over Ethernet Networks",
736       RFC 2464, December 1998.
737
738       Carpenter B., K. Moore, "Connection of IPv6 Domains via  IPv4  Clouds",
739       RFC 3056, February 2001. (6to4 specification)
740
741       Draves,  R.,  D.  Thaler, "Default Router Preferences and More-Specific
742       Routes", RFC 4191, November 2005.
743
744       Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
745       3775, June 2004.
746
747       Devarapalli,  V.,  Wakikawa,  R., Petrescu, A., and P. Thubert "Network
748       Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
749
750       J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router  Adver‐
751       tisement Options for DNS Configuration", RFC 6106, November 2010.
752
753       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
757       Gont,  F. "Security Implications of IPv6 Fragmentation with IPv6 Neigh‐
758       bor Discovery", RFC 6980, August 2013.
759
760       Yourtchenko, A. and Colitti, L. "Reducing Energy Consumption of  Router
761       Advertisements", RFC 7772, February 2016.
762
763

SEE ALSO

765       radvd(8), radvdump(8)
766
767
768
769radvd 2.18                        4 Jan 2011                     RADVD.CONF(5)
Impressum