release/src/router/radvd/radvd.conf.5.man

   1 .\"
   2 .\"   $Id: radvd.conf.5.man,v 1.41 2011/05/10 21:55:10 reubenhwk Exp $
   3 .\"
   4 .\"   Authors:
   5 .\"    Lars Fenneberg           <lf@elemental.net>
   6 .\"    Marko Myllynen           <myllynen@lut.fi>
   7 .\"
   8 .\"   This software is Copyright 1996-2000 by the above mentioned author(s),
   9 .\"   All Rights Reserved.
  10 .\"
  11 .\"   The license which is distributed with this software in the file COPYRIGHT
  12 .\"   applies to this software. If your distribution is missing this file, you
  13 .\"   may request it from <pekkas@netcore.fi>.
  14 .\"
  15 .\"
  16 .\"
  17 .TH RADVD.CONF 5 "4 Jan 2011" "radvd @VERSION@" ""
  18 .SH NAME
  19 radvd.conf \- configuration file of the router advertisement daemon
  20 .B radvd
  21 .SH DESCRIPTION
  22 This file describes the information which is included in the router
  23 advertisement (RA) of a specific interface.
  24 .P
  25 The file contains one or more interface definitions of the form:
  26
  27 .nf
  28 .BR "interface " "name " {
  29         list of interface specific options
  30         list of prefix definitions
  31         list of clients (IPv6 addresses) to advertise to
  32         list of route definitions
  33         list of RDNSS definitions
  34         list of DNSSL definitions
  35 .B };
  36 .fi
  37
  38 All the possible interface specific options are detailed below.  Each
  39 option has to be terminated by a semicolon.
  40
  41 Prefix definitions are of the form:
  42
  43 .nf
  44 .BR "prefix " prefix / "length " {
  45         list of prefix specific options
  46 .B };
  47 .fi
  48
  49 Prefix can be network prefix or the address of the inferface.
  50 The address of interface should be used when using Mobile IPv6
  51 extensions.
  52
  53 Special prefix "::/64" is also supported on systems that implement getifaddrs()
  54 (on other systems, configuration activation fails and radvd exits).
  55 When configured, radvd
  56 picks all non-link-local prefix assigned to the interface and starts advertising
  57 it.  This may be applicable in non-6to4 scenarios where the upstream prefix might
  58 change.  This option is incompatible with Base6to4Interface option.
  59 AdvRouterAddr option is always enabled when this configuration is used.
  60
  61 All the possible prefix specific options are described below.  Each
  62 option has to be terminated by a semicolon.
  63
  64 Decimal values are allowed only for MinDelayBetweenRAs,
  65 MaxRtrAdvInterval and MinRtrAdvInterval.  Decimal values should
  66 be used only when using Mobile IPv6 extensions.
  67
  68 Route definitions are of the form:
  69
  70 .nf
  71 .BR "route " prefix / "length " {
  72         list of route specific options
  73 .B };
  74 .fi
  75
  76 The prefix of a route definition should be network prefix; it can be used to
  77 advertise more specific routes to the hosts.
  78
  79 RDNSS (Recursive DNS server) definitions are of the form:
  80
  81 .nf
  82 .BR "RDNSS " "ip [ip] [ip] " {
  83         list of rdnss specific options
  84 .B };
  85 .fi
  86
  87 DNSSL (DNS Search List) definitions are of the form:
  88
  89 .nf
  90 .BR "DNSSL " "suffix [suffix] [suffix] [...] " {
  91         list of dnssl specific options
  92 .B };
  93 .fi
  94
  95 By default radvd will send route advertisements so that every node on the link can use them.
  96 The list of clients (IPv6 address) to advertise to, and accept route solicitations from can be configured.
  97 If done, radvd does not send send messages to the multicast addresses but
  98 to the configured unicast addresses only.  Solicitations from other addresses are refused.
  99 This is similar to UnicastOnly but includes periodic messages and incoming client access
 100 configuration.  See examples section for a use case of this.
 101
 102 The definitions are of the form:
 103
 104 .nf
 105 .BR "clients " {
 106         list of IPv6 addresses
 107 .B };
 108 .fi
 109
 110 .SH INTERFACE SPECIFIC OPTIONS
 111
 112 .TP
 113 .BR IgnoreIfMissing " " on | off
 114
 115 A flag indicating whether or not the interface is ignored
 116 if it does not exist at start-up.  By default, radvd exits.
 117
 118 This is useful for dynamic interfaces which are not active when radvd
 119 starts or which are dynamically disabled and re-enabled during the time
 120 radvd runs.
 121
 122 Current versions of radvd automatically try to re-enable interfaces.
 123
 124 Enabling IgnoreIfMissing also quenches certain warnings in log messages
 125 relating to missing interfaces.
 126
 127 Default: on
 128
 129 .TP
 130 .BR AdvSendAdvert " " on | off
 131
 132 A flag indicating whether or not the router sends
 133 periodic router advertisements and responds to
 134 router solicitations.
 135
 136 This option no longer has to be specified first, but it
 137 needs to be
 138 .B on
 139 to enable advertisement on this interface.
 140
 141 Default: off
 142
 143 .TP
 144 .BR UnicastOnly " " on | off
 145
 146 Indicates that the interface link type only supports unicast.
 147 This will prevent unsolicited advertisements from being sent, and
 148 will cause solicited advertisements to be unicast to the
 149 soliciting node.  This option is necessary for non-broadcast,
 150 multiple-access links, such as ISATAP.
 151
 152 Default: off
 153
 154 .TP
 155 .BR "MaxRtrAdvInterval " seconds
 156
 157 The maximum time allowed between sending unsolicited multicast
 158 router advertisements from the interface, in seconds.
 159
 160 Must be no less than 4 seconds and no greater than 1800 seconds.
 161
 162 Minimum when using Mobile IPv6 extensions: 0.07.
 163
 164 For values less than 0.2 seconds, 0.02 seconds is added to account for
 165 scheduling granularities as specified in RFC3775.
 166
 167 Default: 600 seconds
 168
 169 .TP
 170 .BR "MinRtrAdvInterval " seconds
 171
 172 The minimum time allowed between sending unsolicited multicast
 173 router advertisements from the interface, in seconds.
 174
 175 Must be no less than 3 seconds and no greater than 0.75 *
 176 MaxRtrAdvInterval.
 177
 178 Minimum when using Mobile IPv6 extensions: 0.03.
 179
 180 Default: 0.33 * MaxRtrAdvInterval
 181
 182 .TP
 183 .BR "MinDelayBetweenRAs " seconds
 184
 185 The minimum time allowed between sending multicast
 186 router advertisements from the interface, in seconds.
 187
 188 This applies to solicited multicast RAs.
 189 This is defined as the protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861.
 190 MIPv6 redefines this parameter to have a minimum of 0.03 seconds.
 191
 192 Minimum when using Mobile IPv6 extensions: 0.03.
 193
 194 Default: 3
 195
 196 .TP
 197 .BR AdvManagedFlag " " on | off
 198
 199 When set, hosts use the administered (stateful) protocol for address
 200 autoconfiguration in addition to any addresses autoconfigured using
 201 stateless address autoconfiguration.  The use of this flag is
 202 described in RFC 4862.
 203
 204 Default: off
 205
 206 .TP
 207 .BR AdvOtherConfigFlag " " on | off
 208
 209 When set, hosts use the administered (stateful) protocol for
 210 autoconfiguration of other (non-address) information.  The use of
 211 this flag is described in RFC 4862.
 212
 213 Default: off
 214
 215 .TP
 216 .BR "AdvLinkMTU " integer
 217
 218 The MTU option is used in  router advertisement messages to insure
 219 that all nodes on a link use the same MTU value in those cases where
 220 the link MTU is not well known.
 221
 222 If specified, i.e. not 0, must not be smaller than 1280 and not greater
 223 than the maximum MTU allowed for this link (e.g. ethernet has
 224 a maximum MTU of 1500. See RFC 4864).
 225
 226 Default: 0
 227
 228 .TP
 229 .BR "AdvReachableTime " milliseconds
 230
 231 The time, in milliseconds, that a node assumes a neighbor is
 232 reachable after having received a reachability confirmation.  Used
 233 by the Neighbor Unreachability Detection algorithm (see Section
 234 7.3 of RFC 4861).  A value of zero means unspecified (by this router).
 235
 236 Must be no greater than 3,600,000 milliseconds (1 hour).
 237
 238 Default: 0
 239
 240 .TP
 241 .BR "AdvRetransTimer " milliseconds
 242
 243 The time, in milliseconds, between retransmitted Neighbor
 244 Solicitation messages.  Used by address resolution and the Neighbor
 245 Unreachability Detection algorithm (see Sections 7.2 and 7.3 of RFC 4861).
 246 A value of zero means unspecified (by this router).
 247
 248 Default: 0
 249
 250 .TP
 251 .BR "AdvCurHopLimit " integer
 252
 253 The default value that should be placed in the Hop Count field of
 254 the IP header for outgoing (unicast) IP packets.  The value should
 255 be set to the current diameter of the Internet.  The value zero
 256 means unspecified (by this router).
 257
 258 Default: 64
 259
 260 .TP
 261 .BR "AdvDefaultLifetime " seconds
 262
 263 The lifetime associated with the default router in units of seconds.
 264 The maximum value corresponds to 18.2 hours.  A lifetime of 0
 265 indicates that the router is not a default router and should not
 266 appear on the default router list.  The router lifetime applies only
 267 to the router's usefulness as a default router; it does not apply to
 268 information contained in other message fields or options.  Options
 269 that need time limits for their information include their own
 270 lifetime fields.
 271
 272 Must be either zero or between MaxRtrAdvInterval and 9000 seconds.
 273
 274 Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
 275
 276 .TP
 277 .BR AdvDefaultPreference " " low | medium | high
 278
 279 The preference associated with the default router, as either "low",
 280 "medium", or "high".
 281
 282 Default: medium
 283
 284 .TP
 285 .BR AdvSourceLLAddress " " on | off
 286
 287 When set, the link-layer address of the outgoing interface is
 288 included in the RA.
 289
 290 Default: on
 291
 292 .TP
 293 .BR AdvHomeAgentFlag " " on | off
 294
 295 When set, indicates that sending router is able to serve as Mobile
 296 IPv6 Home Agent.  When set, minimum limits specified by Mobile IPv6
 297 are used for MinRtrAdvInterval and MaxRtrAdvInterval.
 298
 299 Default: off
 300
 301 .TP
 302 .BR AdvHomeAgentInfo " " on | off
 303
 304 When set, Home Agent Information Option (specified by Mobile IPv6)
 305 is included in Router Advertisements.  AdvHomeAgentFlag must also
 306 be set when using this option.
 307
 308 Default: off
 309
 310 .TP
 311 .BR "HomeAgentLifetime " seconds
 312
 313 The length of time in seconds (relative to the time the packet is
 314 sent) that the router is offering Mobile IPv6 Home Agent services.
 315 A value 0 must not be used.  The maximum lifetime is 65520 seconds
 316 (18.2 hours).  This option is ignored, if AdvHomeAgentInfo is not
 317 set.
 318
 319 If both HomeAgentLifetime and HomeAgentPreference are set to their
 320 default values, Home Agent Information Option will not be sent.
 321
 322 Default: AdvDefaultLifetime
 323
 324 .TP
 325 .BR "HomeAgentPreference " integer
 326
 327 The preference for the Home Agent sending this Router Advertisement.
 328 Values greater than 0 indicate more preferable Home Agent, values
 329 less than 0 indicate less preferable Home Agent.  This option is
 330 ignored, if AdvHomeAgentInfo is not set.
 331
 332 If both HomeAgentLifetime and HomeAgentPreference are set to their
 333 default values, Home Agent Information Option will not be sent.
 334
 335 Default: 0
 336
 337 .TP
 338 .BR AdvMobRtrSupportFlag " " on | off
 339
 340 When set, the Home Agent signals it supports Mobile Router
 341 registrations (specified by NEMO Basic).  AdvHomeAgentInfo must also
 342 be set when using this option.
 343
 344 Default: off
 345
 346 .TP
 347 .BR AdvIntervalOpt " " on | off
 348
 349 When set, Advertisement Interval Option (specified by Mobile IPv6)
 350 is included in Router Advertisements.  When set, minimum limits
 351 specified by Mobile IPv6 are used for MinRtrAdvInterval and
 352 MaxRtrAdvInterval.
 353
 354 The advertisement interval is based on the configured MaxRtrAdvInterval
 355 parameter except where this is less than 200ms.  In this case,
 356 the advertised interval is ( MaxRtrAdvInterval + 20ms ).
 357
 358 Default: off
 359
 360 .SH PREFIX SPECIFIC OPTIONS
 361
 362 .TP
 363 .BR AdvOnLink " " on | off
 364
 365 When set, indicates that this prefix can be used for on-link
 366 determination.  When not set the advertisement makes no statement
 367 about on-link or off-link properties of the prefix.  For instance,
 368 the prefix might be used for address configuration with some of the
 369 addresses belonging to the prefix being on-link and others being
 370 off-link.
 371
 372 Default: on
 373
 374 .TP
 375 .BR AdvAutonomous " " on | off
 376
 377 When set, indicates that this prefix can be used for autonomous
 378 address configuration as specified in RFC 4862.
 379
 380 Default: on
 381
 382 .TP
 383 .BR AdvRouterAddr " " on | off
 384
 385 When set, indicates that the address of interface is sent instead of
 386 network prefix, as is required by Mobile IPv6.  When set, minimum
 387 limits specified by Mobile IPv6 are used for MinRtrAdvInterval and
 388 MaxRtrAdvInterval.
 389
 390 Default: off
 391
 392 .TP
 393 .BR "AdvValidLifetime " seconds "" | infinity
 394
 395 The length of time in seconds (relative to the time the packet is
 396 sent) that the prefix is valid for the purpose of on-link
 397 determination.  The symbolic value
 398 .B infinity
 399 represents infinity (i.e. a value of all one bits (0xffffffff)).
 400 The valid lifetime is also used by RFC 4862.
 401
 402 Note that clients will ignore AdvValidLifetime of an existing prefix
 403 if the lifetime is below two hours, as required in RFC 4862 Section 5.5.3
 404 point e).
 405
 406 Note: RFC4861's suggested default value is significantly longer: 30 days.
 407
 408 Default: 86400 seconds (1 day)
 409
 410 .TP
 411 .BR "AdvPreferredLifetime " seconds "" | infinity
 412
 413 The length of time in seconds (relative to the time the packet is
 414 sent) that addresses generated from the prefix via stateless address
 415 autoconfiguration remain preferred.
 416 The symbolic value
 417 .B infinity
 418 represents infinity (i.e. a value of all one bits (0xffffffff)).
 419 See RFC 4862.
 420
 421 Note: RFC4861's suggested default value is significantly longer: 7 days.
 422
 423 Default: 14400 seconds (4 hours)
 424
 425 .TP
 426 .BR DeprecatePrefix " " on | off
 427
 428 Upon shutdown, this option will cause radvd to deprecate the prefix by announcing it in the radvd shutdown RA with a zero preferred lifetime and a valid lifetime slightly greater than 2 hours. This will encourage end-nodes using this prefix to deprecate any associated addresses immediately. Note that this option should only be used when only one router is announcing the prefix onto the link, otherwise end-nodes will deprecate associated addresses despite the prefix still being valid for preferred use.
 429
 430 See RFC4862, section 5.5.3., "Router Advertisement Processing", part (e).
 431
 432 Default: off
 433
 434 .TP
 435 .BR DecrementLifetimes " " on | off
 436
 437 This option causes radvd to decrement the values of the preferred and valid lifetimes for the prefix over time. The lifetimes are decremented by the number of seconds since the last RA. If radvd receives a SIGUSR1 signal, it will reset the values of the preferred and valid lifetimes back to the initial values used by radvd when it started. If radvd never receives a SIGUSR1 signal, it will continue to decrement the lifetimes until the preferred lifetime reaches zero. After a final RA with a zero value preferred lifetime, radvd will cease to announce the prefix. If a SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then re-appear in the RAs.
 438
 439 This option is intended to be used in conjunction with a DHCPv6 client that is using the Identity Association for Prefix Delegation (IA_PD) option to acquire a prefix from a Delegating Router for use by a Requesting Router. In this scenario, the prefix(es) from within the delegated prefix that are announced by radvd would age in parallel with and at the same rate as the delegated prefix, and expire at approximately the same time, if the delegated prefix's life isn't extended.
 440
 441 See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6".
 442
 443 Default: off
 444
 445 .TP
 446 .BR "Base6Interface " name
 447
 448 If this options is specified, this prefix will be combined with the
 449 IPv6 address of the interface specified by
 450 .B name.
 451 The resulting prefix length will be 64.
 452
 453 .TP
 454 .BR "Base6to4Interface " name
 455
 456 If this option is specified, this prefix will be combined with the
 457 IPv4 address of interface
 458 .B name
 459 to produce a valid 6to4 prefix. The first 16 bits of this prefix
 460 will be replaced by
 461 .B 2002
 462 and the next 32 bits of this prefix will be replaced by the IPv4
 463 address assigned to interface
 464 .B name
 465 at configuration time. The remaining 80 bits of the prefix (including
 466 the SLA ID) will be advertised as specified in the configuration file.
 467 See the next section for an example.
 468
 469 If interface
 470 .B name
 471 is not available at configuration time, a warning will be written to
 472 the log and this prefix will be disabled until radvd is reconfigured.
 473
 474 This option enables systems with dynamic IPv4 addresses to update their
 475 advertised 6to4 prefixes simply by restarting radvd or sending a SIGHUP
 476 signal to cause radvd to reconfigure itself.
 477
 478 Note that 6to4 prefixes derived from dynamically-assigned IPv4 addresses
 479 should be advertised with a significantly shorter lifetime (see the
 480 .B AdvValidLifetime
 481 and
 482 .B AdvPreferredLifetime
 483 options).
 484
 485 For more information on 6to4, see RFC 3056.
 486
 487 Default: 6to4 is not used
 488
 489 .SH ROUTE SPECIFIC OPTIONS
 490
 491 .TP
 492 .BR "AdvRouteLifetime " seconds "" | infinity
 493
 494 The lifetime associated with the route in units of seconds.
 495 The symbolic value
 496 .B infinity
 497 represents infinity (i.e. a value of all one bits (0xffffffff)).
 498
 499 Default: 3 * MaxRtrAdvInterval
 500
 501 .TP
 502 .BR AdvRoutePreference " " low | medium | high
 503
 504 The preference associated with the default router, as either "low",
 505 "medium", or "high".
 506
 507 Default: medium
 508
 509 .TP
 510 .BR RemoveRoute " " on | off
 511
 512 Upon shutdown, announce this route with a zero second lifetime. This should cause the route to be immediately removed from the receiving end-nodes' route table.
 513
 514 Default: on
 515
 516 .SH RDNSS SPECIFIC OPTIONS
 517
 518 .TP
 519 .BR "AdvRDNSSLifetime " seconds | infinity
 520 The maximum duration how long the RDNSS entries are used for name resolution. A value of 0 means the nameserver must no longer be used. The value, if not 0, must be at least MaxRtrAdvInterval.  To ensure stale RDNSS info gets removed in a timely fashion, this should not be greater than 2*MaxRtrAdvInterval.
 521
 522 Default: 2*MaxRtrAdvInterval
 523
 524 .TP
 525 .BR FlushRDNSS " " on | off
 526
 527 Upon shutdown, announce the RDNSS entries with a zero second lifetime. This should cause the RDNSS addresses to be immediately removed from the end-nodes' list of Recursive DNS Servers.
 528
 529 Default: on
 530
 531 .SH DNSSL SPECIFIC OPTIONS
 532
 533 .TP
 534 .BR "AdvDNSSLLifetime " seconds | infinity;
 535 The maximum duration how long the DNSSL entries are used for name resolution.
 536 A value of 0 means the suffix should no longer be used.
 537 The value, if not 0, must be at least MaxRtrAdvInterval.  To ensure stale
 538 DNSSL info gets removed in a timely fashion, this should not be greater than
 539 2*MaxRtrAdvInterval.
 540
 541 Default: 2*MaxRtrAdvInterval
 542
 543 .TP
 544 .BR FlushDNSSL " " on | off
 545
 546 Upon shutdown, announce the DNSSL entries with a zero second lifetime. This should cause the DNSSL entries to be immediately removed from the end-nodes' DNS search list.
 547
 548 Default: on
 549
 550 .SH EXAMPLES
 551
 552 .nf
 553 interface eth0
 554 {
 555         AdvSendAdvert on;
 556         prefix 2001:db8:0:1::/64
 557         {
 558                 AdvOnLink on;
 559                 AdvAutonomous on;
 560         };
 561 };
 562 .fi
 563
 564 It says that router advertisement daemon should advertise
 565 (AdvSendAdvert on;) the prefix 2001:db8:0:1:: which has a lenght of 64
 566 on the interface eth0.  Also the prefix should be marked as autonomous
 567 (AdvAutonomous on;) and as on-link (AdvOnLink on;).  All the other
 568 options are left on their default values.
 569
 570 To support movement detection of Mobile IPv6 Mobile Nodes, the
 571 address of interface should be used instead of network prefix:
 572
 573 .nf
 574 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 .fi
 585
 586 For 6to4 support, include the
 587 .B Base6to4Interface
 588 option in each prefix section. When using a dynamic IPv4 address, set
 589 small prefix lifetimes to prevent hosts from retaining unreachable
 590 prefixes after a new IPv4 address has been assigned.  When advertising to on
 591 a dynamic interface (e.g., Bluetooth), skip the interface if it is not
 592 active yet.
 593
 594 .nf
 595 interface bnep0
 596 {
 597         IgnoreIfMissing on;
 598         AdvSendAdvert on;
 599
 600         # Advertise at least every 30 seconds
 601         MaxRtrAdvInterval 30;
 602
 603         prefix 0:0:0:5678::/64
 604         {
 605                 AdvOnLink on;
 606                 AdvAutonomous on;
 607                 Base6to4Interface ppp0;
 608
 609                 # Very short lifetimes for dynamic addresses
 610                 AdvValidLifetime 300;
 611                 AdvPreferredLifetime 120;
 612         };
 613 };
 614 .fi
 615
 616 Since 6to4 is enabled, the prefix will be advertised as
 617 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of
 618 ppp0 at configuration time. (IPv6 addresses are written in hexadecimal
 619 whereas IPv4 addresses are written in decimal, so the IPv4 address
 620 WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)
 621
 622 In this specific case, the configuration scripts may send HUP signal to
 623 radvd when taking bnep0 up or down to notify about the status; in the
 624 current radvd releases, sending HUP is no longer mandatory when the link
 625 comes back up.
 626
 627 .nf
 628 interface eth0
 629 {
 630         AdvSendAdvert on;
 631         prefix 2001:db8:0:1::/64
 632         {
 633                 AdvOnLink on;
 634                 AdvAutonomous on;
 635         };
 636         clients
 637         {
 638                 fe80::21f:16ff:fe06:3aab;
 639                 fe80::21d:72ff:fe96:aaff;
 640         };
 641 };
 642 .fi
 643
 644 This configuration would only announce the prefix to fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff.
 645 Furthermore, all RA requests of other clients are denied.
 646
 647 This may come in handy if you want to roll out IPv6 only partially because
 648 some clients are broken or untested.
 649
 650
 651 .SH FILES
 652
 653 .nf
 654 @sbindir@/radvd
 655 @PATH_RADVD_CONF@
 656 @PATH_RADVD_PID@
 657 @PATH_RADVD_LOG@
 658 .fi
 659
 660 .SH CREDIT
 661 The description of the different flags and variables is in large
 662 parts taken from RFC 4861.
 663
 664 .SH RFCS
 665 Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP
 666 Version 6 (IPv6)", RFC 4861, September 2007.
 667 .PP
 668 Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfiguration",
 669 RFC 4862, September 2007.
 670 .PP
 671 Deering, S., and R. Hinden, "IP Version 6 Addressing
 672 Architecture", RFC 4291, February 2006.
 673 .PP
 674 Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol (ICMPv6)
 675 for the Internet Protocol Version 6 (IPv6)", RFC 4443, March 2006.
 676 .PP
 677 Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks",
 678 RFC 2464, December 1998.
 679 .PP
 680 Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
 681 RFC 3056, February 2001. (6to4 specification)
 682 .PP
 683 Draves, R., D. Thaler, "Default Router Preferences and More-Specific Routes",
 684 RFC 4191, November 2005.
 685 .PP
 686 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6",
 687 RFC 3775, June 2004.
 688 .PP
 689 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network Mobility (NEMO) Basic Support Protocol",
 690 RFC 3963, January 2005.
 691 .PP
 692 J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration",
 693 RFC 6106, November 2010.
 694
 695 .SH "SEE ALSO"
 696
 697 .BR radvd (8),
 698 .BR radvdump (8)
 699
 700 .SH BUGS
 701 radvd does not support splitting up RAs to multiple packets (RFC4861 6.2.3 last paragraph).
 702 In practise this limits advertising to ~45 prefixes on a link, but there is no reason to
 703 be able to so.
 704