Almost this entire page may be a large result of various copy-and-paste from internal notes made earlier. Much of this may still need a decent amount of verification to be considered useful/reliable.

(Perhaps some phrases to Router Advertisements should be changed to the more generalized term of Router Discovery Messages.)

Automatic Addressing for IPv6

Overview of key technologies used for IPv6 automatic addressing

With IPv6, there are multiple terms. The recommended setups are usually to use either:

  • router advertisements and NDP and SLAAC including DAD
  • router advertisements and NDP and DHCPv6.

So, things are a bit more complex than the typical DHCP/IPv4 setup. Understanding the roles of the protocols are recommended, so the first bit of recommended reading is the overview of router advertisements, NDP, SLAAC, DAD, and DHCPv6. Since most guides involve deploying multiple of these terms at once, reading the guide is recommended to be able to correctly keep things striaght.

[#nodvshst]: Some basic IPv6 terminology

Many documents that discuss IPv6, including RFC documents, may use the terms “node” and “host”. These are two different terms and they do mean two different things, using definitions provided by RFC 2460 (IPv6 specification) section 2 (section called “Terminology”).

Further discussion on the terms “node” and “host”

(Here are some further observations about the terms “node” and “host”. These observations complicate things and add little value, but are being provided anyway for the sake of completeness. Don't worry about these details if they seem unclear and the goal is just to get a basic grasp of general concepts. These details may be useful for people who are trying to create new software or design hardware.)

RFC 2460 (IPv6 specification) section 2 (section called “Terminology”) provides a “Note” (on RFC 2460 page 4, just before the start of section 3) about a machine that servers as a router for some nodes (a.k.a. devices/computers), but may appear as a “host” (that is, a non-routing device) to other nodes on the network. RFC 4861: NDP for IPv6: section 2: Terminology: Subsection 2.1: “General” Terminology provides mostly similar terms, although it does not have that note about devices that act like both a router and a “host” (a.k.a. non-router).

RFC 4861 has a fairly similar terminology section , with some differences. Perhaps most strikingly, RFC 4861's terms tend to use the phrase IP rather than IPv6 (even though IPv6 is generally what is actually being referred to), and “MTU link” is slightly different, and it lacks an entry for “path MTU”. Oh, and RFC 4861 also has additional terms.)

Getting that terminology straight is likely to be a requirement for correctly understanding some of this documentation related to automatic addressing. Know the difference between the terms “node” and “host”.

[#rtadvrol]: Network design: which systems perform which roles

Only routers should perform the role of handing out “router advertisements”.

This does differ from a common IPv4 setup, where automatic addressing (via DHCP for IPv4) was often run on one server, while routing was on a different server. Despite working fine, and being common with IPv4 setups, trying to do the same thing with automatic IPv6 routing is likely to cause issues.

For the curious, a discussion about those issues is covered by a section dedicated to router advertisements and device roles.

Overview of protocol(s) and some standardized behavior

(This is simply documenting some information that has been moved, to prevent link rot if anyone hyperlinked to the old links.)

[#ndpovw]: Information has been moved: in the Differences between NDP and SLAAC section is in the NDP overview (contrasting to SLAAC) section.

[#slaacovw]: Information has been moved: in the Differences between NDP and SLAAC section is the SLAAC overview (contrasting to NDP) section.

Subnet size

When using automatic addressing (with SLAAC?), using a subnet size of /64 may be most compatible with IPv6 implementations. (If thinking of trying to use a different subnet size, then expect that compatibility problems are likely.) For documentation about this limit, see the section about SLAAC's prefix size of /64.

If not immedidately using SLAAC, it may still be wise to use a /64 if convenient, so that later the network could easily start using SLAAC if desired. If a different subnet size is used, things may break horribly when starting to try using SLAAC, and fixing the problem may not be any simpler than needing to start using a /64 subnet.

[#ip6adrsv]: Server-side implementations

(On the surface, this section may look fairly sparse/short. That is primarily because there are simply hyperlinks to some larger sections.)

Router advertisement implementations
Overview information
[#ndpmoflg]: The configuring flags
This information has moved: see IPv6 router advertisers: the configuring flags.

Other information is now in the more specific section that is dedicted to IPv6 router advertisers.

[#dhcpipv6]: DHCP for IPv6 (DHCPv6, a.k.a. DHCP6)

Information has been moved to: DHCPv6 servers.

Solidifying changes

After running the srever software, see if the program is running. If not, check out the end of the text file named /var/log/messages and see if a problem was reported. (Details on viewing a (text) file's contents.) After addressing any such problem, note the time (simply run the Unix date command). Then, if errors happen again when trying again to run the server, manually ignore any messages in the log file that are earlier than the time that was shown when the date command ran.

It may make sense to ensure that the relevant client software is working before trying to solidify changes.

Once it is clear that the server is providing useful information to the clients, it is likely that this sort of configuration will be useful in the future. Make sure that any changed files are backed up. (Relevant details are available in the sections about backing up (by copying files).) Make sure that any other configuration changes are saved. (For instance, if the kernel configuration was altered using BSD “sysctl values”, back up the configuration file that is automatically used when the system starts. Then alter that file, as described by the section about sysctl values. If any programs are currently running, make sure they get started during the computer's startup process. (Details may be in the section about system startup: automatically started files.)

If there are multiple services running (e.g. one for router advertisements, and one for DHCPv6, then make sure both services are taken care of (by having any configurations backed up, and by making sure they will automatically start).

[#ip6adrcl]: Client-side implementation details for automatic addressing
[#ndp]: Neighbor Discovery Protocol (“NPD”)

There is an ndp command. It is useful for verifying what computers can see each other. However, it is mostly about using neighbor solicitations, which performs the same sort of role that ARP did in IPv4. Although techncially the router solicitations are part of the NDP (RFC) specification documents, using tools more specialized to router advertisements will likely be useful when dealing with router advertisements.

More overview

See: NDP Overview.

A key related section is the IPv6 Stateless Autoconfiguration, which uses this transmitted information to assign an address to an interface. (So see that section for further details, as information in that section may also apply to this section.)

RFC 4861 (which updated RFC 2461).

NDP uses ICMPv6. Specifically, ICMPv6 supports various “types” of messages, and IANA's ICMPv6 Type Numbers shows that ICMPv6 types 133 through 137 are reserved by the RFC about NDP. These five types are, in order, called Router Solicititation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, and Redirect Message.

[#rtadvspc]: Supporting router advertisements
[#rtadvknc]: Kernel configuration

This isn't about adjusting a kernel's default behaviors before compiling the kernel. This is simply telling the kernel to accept certain types of NDP traffic. This may be needed if the NDP support is built into the kernel.

BSD kernels

The following is verified from OpenBSD 5.0.

Performing the documented adjustments to the kernel configuration includes turning off IPv6 traffic forwarding. That may not be something that is desirable for a firewall/routing computer to do. (The intended way to deal with that limitation is to not use the automatic addressing client software on those computers. This is discussed in the section about “Network Design: which systems perform which roles”. In fact, routers may want to do about the opposite configuration. The expected configuration for routers may be shown by Configuring routers to use the “IPv6 support” code for compatability with router advertisements, instead of this example that is meant for client systems.)

echo Showing the current values...
sysctl net.inet6.ip6.accept_rtadv
sysctl net.inet6.icmp6.rediraccept
sysctl net.inet6.ip6.forwarding
echo Change the values if they are not set to the desired values
sudo sysctl net.inet6.ip6.accept_rtadv=1
sudo sysctl net.inet6.icmp6.rediraccept=1
sudo sysctl net.inet6.ip6.forwarding=0

When things are working well, making long-term changes to the sysctl values will be worth saving.

grep -i net.inet6.ip6.accept_rtadv /etc/sysctl.conf
grep -i net.inet6.icmp6.rediraccept /etc/sysctl.conf
grep -i net.inet6.ip6.forwarding /etc/sysctl.conf

echo net.inet6.ip6.accept_rtadv=1 | sudo -n tee -a /etc/sysctl.conf
echo net.inet6.icmp6.rediraccept=1 | sudo -n tee -a /etc/sysctl.conf
echo net.inet6.ip6.forwarding=0 | sudo -n tee -a /etc/sysctl.conf
Enabling NDP on the interface

Perhaps this is done by default. The following was found from OpenBSD's manual page for the NDP command.

ndp -i if0

One of the lines of output may start with the word “Flags: ”. If it shows the accept_rtadv flag, then all is okay. (That is probably the case.) Otherwise, add it:

sudo ndp -i if0 accept_rtadv

(To turn off this support, the syntax would be to use “ -accept_rtadv ”.)

In addition to accepting router advertisements, which will allow the host (a.k.a. “client”) to configure itself the next time that a router advertisement is sent out by a router, it can also be useful to have a host/client send out a “Router Solicitation”. A “Router Solicitation” is basically a request only meant for a router, sent in the hopes that a router will see the solicitation and respond by quickly providing a “Router Advertisement”.

Monitoring software

A program which might not come with the operating system, and which won't set network settings, but which can be nice to know about, is radvdump. If there is question about whether a server is failing or whether there may be a malfunctioning client that is seeing information from the server, this program can help to determine what information is coming from the server.

The program might need to be installed. e.g., in Debian, try running “ aptitude install radvd ”. (This will not only install the radvdump command, but will also install server software.)

Once the program is installed, it may be run by using the command line “radvdump -d 4”.

Doing this may show some output like:

[ 448.756968] NET: Registered protocol family 10
[ 448.766953] lo: Disabled Privacy Extensions

These errors may be drawn to the screen, not the terminal, so changing screen windows may cause these messages to disappear. The messages may simply be ignorable.


OpenBSD's manual page for rtsold states, “Upon receipt of signal SIGUSR1, rtsold will dump the current internal state into /var/run/rtsold.dump.” (At the time of this writing, it is not currently clear whether this is quite useful...) To do this, run “ pgrep rtsol ” to get the PID(s), and then use “ kill -HUP # ” (customizing by replacing # with a PID).

Wikipedia's article on NDPMon describes some software that may be able to detect some configuration problems.
netsh for Microsoft Windows

This doesn't specifically show the traffic, but this may show some more results of the traffic (beyond just what is shown by some of the other software that reveals the resulting IPv6 address information that gets used).

First, figure out the identifier (name or index) of the network interface.

netsh int ipv6 show interface "Local Area Connection"

The quotation marks are not needed if using an Interface Index as the identifier.

netsh int ipv6 show interface 10

This can help to determine what configuration settings are being provided. For example, the line stating “Managed Address Configuration” will help to indicate whether a DHCPv6 server will be getting contacted.

rtsol and rtsold

(Note: this section was initially meant to be about using the software as a monitor. There is another section about how to use this software to configure the interface: NDP client-side software implementations. However, this section may have had some further details/instructions added, reducing difference between these instructions and the instructions on NDP client-side software implementations.)

[#rtsoltro]: Introduction to this software

rtsol is part of KAME, which is used by (and often built into) BSD operating systems. This software may be bundled in with BSD operating systems.

The behaviors of the rtsol and rtsold commands are fairly similar to each other. In fact, OpenBSD manual page for rtsol says, “rtsol behaves as ``rtsold -f1 interface ...''.” Those parameters cause the program to run in the foreground, and to exit after each NIC has received at least one valid “Router Advertisement” packet. The rtsold command, without those parameters, keeps running and will automatically send another “Router Solicitation” when certain conditions are meant.

Both rtsold, and the rtsol “wrapper” style command, are meant for “hosts”. To use a some more generic terms: this software is meant for clients, or end user systems. The “d” in the filename likely does refer to the term “daemon”, and refers to the programs ability to operate in the background. This does NOT mean that the program is meant to be a server. (The rtadvd software is the corresponding software meant to serve “Router Advertisements”.)

Before trying to run this client software, make sure the relevant sysctl values are set appropriately. (This is discussed in the section about kernel support.)

For a simple test, try just running:

sudo rtsol -F if0

OpenBSD manual page for rtsold (and rtsol) says, “Note that some network cards and drivers do not allow the extraction of link state. In such cases, rtsold cannot detect the change of the interface status.” (One would hope that is fairly rare.) For all other systems, if the results seem good now, it may be worthwhile to run rtsold in the background. This will cause rtsold to be “periodically probing to see if the status of the interface is active or not.” If a temporary interface failure is detected, then after the interface is brought back up, rtsold will send out another “Router Solicitation”. To start making this good thing happen, run:

sudo rtsold -F if0
Enabling support for the longer term

If any changes needed to be made to support router advertisements, such as configuring kernel options to enable such support, make sure those changes are long-term so they will be effective when the system reboots. For example, in a BSD operating system, see the section about using sysctl configurations.

Further information about running the clients automatically (when the system is restarted) is intentionally not being covered yet. In case there is also a desire to have stateful configuration, this guide first covers using DHCPv6. Then this documentation covers using both router advertisements and also DHCPv6. Then details may be found about setting things up for the long term. (The alternative is setting something up, only to need to make additional changes anyway.) However, if this system reboots before such long term changes are made to cause the Router Solicitations to be automatically sent, then realize that a client may need to be manually re-run in order for Router Solicitations to be getting sent again.

(There may also be some information at tutorial on setting up the operating systems: automatically setting IP addresses.)

[#ndpclisw]: Specific client software implementing NDP

rtsol is part of KAME, which is used by BSD software, and so this may be bundled in with BSD operating systems. (See introduction to rtsol/rtsold for some further details.)

First, check the sysctl values. (The -F parameter to rtsol, which is different than the -f parameter, may override these?)

sysctl net.inet6.ip6.accept_rtadv ; echo should be 1
sysctl net.inet6.ip6.forwarding ; echo should be 0

If either of these aren't set right, an immediate change may be made with:

sudo sysctl net.inet6.ip6.accept_rtadv=1
sudo sysctl net.inet6.ip6.forwarding=0

To make changes long term, make sure the desired values are appropriately placed in /etc/sysctl.conf file. If the cpytobak program is available, then something like the following may be useful:

cpytobak /etc/sysctl.conf
echo ${VISUAL}
[ "X${VISUAL}" = "X" ] && ${VISUAL} /etc/sysctl.conf

Simply run rtsol with one parameter, which is the name of the interface. (See: available interfaces.) Or, if the system has only one NIC that will be getting used, then using “ rtsol -a ” may be an option. In OpenBSD, one option would be to put the following in the correct /etc/hostname.* file.

# Lines starting with # are comments
!rtsol -a
# Should only be on single-NIC host.  Otherwise, for other hosts, # the line should say: !rtsol $if

(If desired, see man page for /etc/hostname.*).

Then run ifconfig (followed by -A and -a and then the interface name, although with newer versions all of these parameters may be optional).

On a technical level, rtsol may do nothing other than act exactly like rtsold with certain parameters.

If there seem to be troubles, see: Some troubleshooting steps for NDP client software.

Supporting DHCPv6
Some introduction

The OpenBSD's manual page for rtsol/rtsold indicates this can be supported by utilizing a script file. This is incompatible with using the -a parameter to rtsol/rtsold (according to the syntax of the manual page).

The manual page may seem to indicate that the only configuration flag supported is the “Other” configuration flag. However, this should also get run when the “Managed” configuration flag is used, since RFC 2462 page 12 states, “when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well.” (Further details on these flags are available in the section called Configuration flags in rtadvd.conf and especially its referenced resource, Router advertisement configuring flags.) So what this basically menas is that the script file ends up being run whenever the client is supposed to run DHCPv6 client software.

Actions to take

First, it simply makes sense to get DHCPv6 working (manually) before trying to get rtsol/rtsold to use this.

In the /etc/hostname.* file(s), locate any line that just says:


Replace that line with the following contents:

!rtsold -O /etc/rtdhc$if0 $if

Make sure that script file works as expected. (This means creating the script. The script file's name may include the interface name, which can be referenced using a $if variable in the /etc/hostname.* file. The script file will receive the interface name, and may refer to it using ${1} (or ${1}).)

Make sure that has the permissions documented by rtsol's man page. OpenBSD's manual page for rtsol/rtsold notes that “the file itself should be a regular file and owned by the same user running rtsold” (or the user account that ends up running rtsol). (See: Overview of Unix ownership/permissions metadata, Interacting with ownership (in filesystems) in Unix. Also make sure that permissions are sufficient.)

Make sure the script file works as expected (and did not break from changing any permissions change).

If there are any old copies of rtsold running, and if they should be stopped (which is likely), stop them. (see if the program is running, adjusting what software is running

Try running the rtsol/rtsold command. (The best way to do this may be to run “ ${SHELL} /etc/netstart if0 ”, as that may be fairly thorough and similar to what happens when the computer reboots.)


This is essentially the same program as rtsol, and may in fact be the same executable. This runs on the hosts (clients), and the remote end, the “router” (SLAAC server) may/will not notice any difference from rtsol. This may communicate with rtadvd on remote BSD systems. Other remote systems might use a different program name like radvd.

Essentially what this program does is looks for certain events, such as a wireless card becoming active after hibernation, and responds to certain events by automatically sending traffic which may/will be the same sort of traffic that would be sent if rtsol were manually run. Therefore, this may be nicer than rtsol for a long term solution. However, for initial setup/troubleshooting, rtsol is probably the better bet.

The Linux kernel

For this example, Debian Lenny will be used. (Note that at the time of writing this Debian information, Debian Lenny's successor of Squeeze had not yet been released as a “stable” release. Debian IPv6 page said “Fully IPv6 support is a ReleaseGoals for Squeeze.” [apparent grammer error is noted.] The “Full IPv6 support” web page was referenced by the Debian Release Goals page.) An advantage to documenting Lenny is that some things may be less automatic so the process can be seen.

An optional step is to install radvd package and use the radvdump program for troubleshooting.

As root:
sysctl net.ipv6.conf.all.forwarding
Note that this could be done with sudo, but there's a fair amount here to be done as root, so using “ sudo sh ” (or a better option like “ sudo bash ” or, more generally, “ sudo ${SHELL} ”) may be preferred.

If that responds with:
error: "net.ipv6.conf.all.forwarding" is an unknown key
then IPv6 likely isn't active.

[#lnxnoip6]: No IPv6 active in Linux
  • sysctl net.ipv6.conf.all.forwarding shows: error: "net.ipv6.conf.all.forwarding" is an unknown key
    (For that matter, maybe net.ipv6 will be unknown?)
  • lsmod | grep ipv6
    (shows nothing)
  • grep ipv6 /etc/modules (will probably shows nothing)
  • ls -ld /proc/sys/net/ipv? (doesn't show ipv6 (but may show ipv4)
  • Running “/etc/init.d/radvd start” says: IPv6 support must be enabled in the kernel for radvd to work.


  • modprobe ipv6
  • For long term, one may wish to put ipv6 into /etc/modules

This likely won't need to be done, but checking for blacklisting may also be worthwhile if that is problematic: See Debian guide: turning off IPv6 for more info.

Once IPv6 is working, the sysctl described above should work.

Setting the sysctl values

Check if ipv6 is enabled. Details are in the section of setting up the server. If not, fix that. The following values were used:

sysctl net.ipv6.conf.default.forwarding
sysctl net.ipv6.conf.default.forwarding = 0

sysctl net.ipv6.conf.default.autoconf
sysctl net.ipv6.conf.default.autoconf = 1
sysctl net.ipv6.conf.default | grep accept_ra
sysctl net.ipv6.conf.default.accept_ra = 1
sysctl net.ipv6.conf.default.accept_ra_defrtr = 1
sysctl net.ipv6.conf.default.accept_ra_pinfo = 1
sysctl net.ipv6.conf.default.accept_ra_rtr_pref = 1
sysctl net.ipv6.conf.default.accept_ra_rt_info_max_plen = 0 (redirector to madduck's pages) / madduck's pages had a slightly different list: For server, used autoconf, accept_ra, accept_ra_defrtr, accept_ra_rtr_perf, accept_ra_pinfo, accept_source_route, accept_redirections, and forwarding, all under both net.ipv6.conf.default. and net.ipv6.conf.all., set to zero for the router and noted accept_ra* values should be 1 for autoconfiguration. It also had information about using pre-up in an iface file.

Check that the interface is up

If the Ethernet interface being used is called eth0, use:

ifconfig eth0 up

To find the Ethernet interface, use “ ifconfig -a ” or “dmesg | grep eth” and review the output.

Initiating a router solicitation
One option is to bring the interface down and back up. (Unknown: Can changing the sysctl, to disable and re-enable, also do this? Is there a better/easier way?)
[#ndpclfix]: Some troubleshooting steps

If NDP client software seems probematic, here are some steps. Note that these steps may alter data (such as causing a computer to forget cached details about a neighbor), and some of these might or might not be a good idea. They were documented based on discovering some ideas that might be helpful. No statement is being made regarding whether or not these ideas really are actually useful in practice.

If the software is not working as expected, check the kernel configuration (e.g. sysctl values) and then ensure that the server is working. Check that the router advertisements are providing a /64 prefix length (as an overly broad generalization, but this might really be required when SLAAC is expected to be used).

Using monitoring software (mentioned in the section on supporting router advertisements) may be helpful.

If that doesn't seem to resolve the situation, there are some ndp commands that may help provide some useful information. (These are documented by OpenBSD's manual page for ndp.) Try using: ndp -c ; this clears ndp entries which may be good to do first, just for troubleshooting
ndp -P This also clears some info so old info from previous attempts are not seen
rtsol -dDF interface (e.g. rtsol -dDF ne3)
Then, in another window, perhaps one of more of:
ndp -a
ndp -p
echo show prefix list, may show even if invalid prefix length was received from server
ndp -I
ndp -I delete
perhaps ndp -i ne3
ndp -H

[#slaac]: IPv6 Stateless Address Autoconfiguration (“SLAAC”) / Network Discovery Protocol (“NDP”)

(See also: SLAAC overview, RFC 4862: IPv6 Stateless Address Autoconfiguration.)

SLAAC may commonly be automatically enabled, ready to take effect when the right condition(s) occur(s). Namely, SLAAC may be used when NDP router advertisements are successfully received, and when those router advertisements include a /64 subnet, and when those router advertisements have the “Managed” (a.k.a. “M”) configuration flag flag cleared to a value of zero. There may be really nothing needed for client-side configuration, other than whatever is needed to be having the NDP configuration being processed. (See the details about client-side implementations for NDP.)

The data in NDP packets may specify the M and O flags, as noted in section 4.2 of the RFC documents related to the NDP protocol. The SLAAC specification section 5.2 states that (software implementing support for) the interfaces on hosts will have “flags”. (A flag is basically a boolean variable; a variable that store a binary value.) Those flags on the interfaces will be set according to the data specified in the NDP packets. These flags will determine whether or not to use the stateful method. RFC 4861 (“Neighbor Discovery for IP version 6 (IPv6)”) specifies that the stateful method is DHCPv6. SLAAC also provides a stateless method of determining addresses to automatically assign. That information is used if stateful (DHCPv6) isn't being used. (Otherwise, even if DHCPv6 is being used, the older SLAAC RFC 2461 indicates that addressing info from NDP is used “in addition to” the addresses specified with the stateful protocol being used.)

Uses NDP. Specifies DAD.

Multi-homed: RFC 2462 section 5 says, in part, “Autoconfiguration is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface.” The “Bugs” section of OpenBSD's “man page” (“manual page”) for rtsold (and rtsol) says “The IPv6 autoconfiguration specification assumes a single-interface host. You may see kernel error messages if you try to autoconfigure a host with multiple interfaces.”

OpenBSD's rtsol has requirements for some sysctl values. See rtsol.

RFC 4862 says "If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required."

[#slaacprf]: Restrictions of prefix size in stateless autoconf

There are a number of implementations and documents that suggest that the prefix length/size of the subnet used with autoconfiguration must be a /64.

RFC references regarding the limitation

The simple answer is that a prefix length of 64 bits is clearly mentioned in the last sentence of RFC 2464: Transmission of IPv6 Packets over Ethernet Networks, section 4 (a.k.a. page 3): Stateless Autoconfiguration, which says “An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits.”. Note that this exact statement does not say “at least” 64 bits or “at most” 64 bits, so a size of precisely 64 bits is needed. The “[ACONF]” quoted above references the “IPv6 Stateless Address Autoconfiguration” RFC (specifically RFC 2464: Transmission of IPv6 Packets over Ethernet Networks, which obsoleted RFC 1971 and has been obsoleted by RFC 4862).

There's not necessarily a technical reason why RFC 2464 needed to specify the precise exact value of /64. This RFC 2464 (about Transmission of IPv6/Ethernet), with the clear statement above, updates the older RFC 1971 (which was also about Transmission of IPv6/Ethernet), which had made this different clear statement: “An IPv6 address prefix used for stateless autoconfiguration of an ethernet interface must be 80 bits in length.” Another RFC, RFC 4941 (page 3), specifically says “Note that an IPv6 identifier does not necessarily have to be 64 bits in length”.

A fair number of documents describing the 64-bit prefix length have cited the “IPv6 Stateless Address Autoconfiguration” RFC (4862) as a reference for that limitation. However, RFC 4862 does not directly mention a 64-bit length and specifically notes that it “described the relationship with the prefix length advertised in Router Advertisements, and avoided using a particular length hard-coded in this document.” If the documents referenced by the Autoconf documents were obsoleted, a different prefix length could be used without violating any of the Autoconf documents (other than a possible update regarding which documents are being referred to).

RFC 2462, which is the earlier SLAAC document before RFC 4862, is also sometimes cited as an authoritative reference for this limit. For instance, RFC 2529 page 4 notes “An IPv6 address prefix used for stateless autoconfiguration [CONF] of an IPv4 interface MUST have a length of 64 bits except for” (multicast). (“[CONF]” in this case refers to RFC 2462.)

The closest thing that either RFC 4862 or 2462 do to referencing this limit is to make references in the description of “interface identifier” at the bottom of the terminology section that ends at the bottom of page 6 of RFC 2462: IPv6 Stateless Addr Autoconf and near the bottom of page 6 of RFC 4281: IPv6 Stateless Addr Autoconf. Both of these documents do make references to the RFC 2464 described above. (RFC 2462 calls it “IPv6-ETHER” and identifies it in section 7 of the document, while RFC 4862 references RFC 2462 directly.) That evidence is more conclusive than the other documents referenced earlier in the “interface identifier” descriptions of these Autoconf RFCs.

The earlier RFC 2462 references ADDR-ARCH (RFC 2373, obsoleted by 3513 which was obsoleted by 4291) and may refer to the first paragraph on page 7 of RFC 2373. The newer RFC 4862 references RFC 4291 which updated RFC 2373: The first paragraph of page 8 of RFC 4291 essentially says the same thing as page 7 of 2373.

RFC 3627: “Use of /127 Prefix Length Between Routers Considered Harmful”, Section 1: “Introduction” says “having prefix length longer than 64 is forbidden by” (RFC 2373 section 2.4). (That RFC has had its status updated, as noted by RFC 6547.)

However, this isn't quite conclusive: It is rather implied by the requirement of 64-bit interface addresses that a subnet size might not have a prefix length longer than 64 (allowing 64 remaining bits for the interface identifier), but a shorter prefix length would also allow at least 64 bits at the end to be used for an interface identifier. The ADDR-ARCH documents don't specifically state that the prefix length needs to be exactly 64 bits.

(Note that the /64 subnet size does not seem to be required for IPv6 in general, and is mentioned here as a limit to be aware of when working with stateless autoconfiguration. For example, another document RFC 3627 discusses issues with a /127 prefix length: draft--kohno--ipv6--prefixlen--p2p--00.txt is a newer document that counters that RFC, and in section 2 mentions other prefixes between /111 and /127.)

RFC 3177 refers to the limit when discussing “requirements for IPv6 agreed to in 1993”, referring to some considerations that were being taken into consideration.

Other documentation/implementations of the prefix limit

Although there may be a lot of documentation citing an incorrect RFC regarding what the prefix length requirement is, there's less ambiguity regarding what is the actual value for the prefix length: Many implementations use a limit of 64 bits. Examples follow:

NetBSD IPv6 Networking documentation/FAQ says “The prefix length for an IPv6 subnet will always be /64; no more, no less.” A page that was once at the URL has stated, “The subnet prefix always contains 64 bits. These bits include 48 bits for the site prefix, in addition to 16 bits for the subnet ID.” Wikipedia's web page about Subnet: section about “Subnetting in IPv6 networks” says: “stateless address autoconfiguration of network interfaces (RFC 4862) requires a /64 address.” (Hyperlink may have been added to that quoted text.) Documentation about RouterOS says “Note that the prefix length must be equal to 64 for host autoconfiguration to work.” IPv6Deployment Guide: page about Cisco IOS says: “However, for stateless autoconfiguration to work properly, the advertised prefix length in router advertisement messages must always be 64 bits.” IPv6 article (about OpenBSD 3.3 router and FreeBSD hosts) notes: “Supplemental: After a reboot this did not work anymore. The problem was that rtadvd can not advertise IPv6 ips with a prefixlen op 48. Setting it to 64 using only a part of my IPv6 space solves this problem.”

IPv6 autoconf
When booting, OpenBSD may say:
WARNING: inconsistent config - check /etc/sysctl.conf for IPv6 autoconf

This seems to be nothing more than SLAAC working with NDP.

The referenced file may state,

net.inet6.ip6.accept_rtadv=1 # 1=Permit IPv6 autoconf (forwarding must be 0)

That is simply saying that net.inet6.ip6.forwarding must be set to zero if inet6.ip6.accept_rtadv is set to 1. This warning could also occur if a NIC's configuration script specifies to use the default rtsol configuration, but having inet6.ip6.accept_rtadv still set to zero.

The OpenBSD manual page for “autoconf” has nothing to do with IPv6 autoconf.

Other operating systems may also use the term: e.g. TLDP section about /proc/sys/net/ipv6/conf/interface/autoconf.

[#dhcp6cli]: DHCPv6 clients

Information is in the section about DHCPv6 clients.

[#wdhcp6c]: WIDE-DHCPv6 dhcp6c

Information has been moved to: DHCPv6 clients: WIDE-DHCPv6 dhcp6c

Microsoft Windows
Information has been moved to: DHCPv6 clients.
Chaining DHCPv6 to NDP
Adjusting NDP configuration
Make sure the M or O bit is set, depending on preference. Basically, setting the M bit also causes the effects of the O bit, and so may be more noticeable. (The section about NDP configuring flags (in the section about DHCPv6 servers) discusses the impact in more detail. Directions for changing this may be in the section about the specific software: see information about DHCPv6 server software for more specific details.)
Having client support both router advertisements and DHCPv6
Using rtsold (and rtsol)

This example shows quite a few references to the name of the interface. To simplify copying and pasting from an electronic version of this text, a variable is being set for this example text. Run the following:


Make a Unix script file that runs the DHCP client with all needed parameters. The script may expect to receive one parameter which is the name of the interface to be configuring.

sudo dhcp6c -p /var/run/dhc6$ $1 2>&1 | tee -a ~/dhc6$1.log

OpenBSD's manual page for rtsold (and rtsol) states, “the file itself should be a regular file and owned by the same user running rtsold.” The file may/may not be an executable file. Change the file's ownership (using techniques described by the section about file attributes ) if needed: the following might pull this off sufficiently. In OpenBSD, one may run:

sudo chown $(whoami):$( id -gn $(whoami)) ~/dhc6${CURRNIC}

For other operating systems, if the group name isn't necessarily likely to match the username, then leave off the reference to changing the group. (It was shown for demonstration purposes, but is really unnecessary.) So, just run:

sudo chown $( sudo whoami ) ~/dhc6${CURRNIC}

If desired, go ahead and give that script a test run:

. ./dhc6${CURRNIC} ${CURRNIC}

Finally, run the client software. Add “ -O /home/$(whoami)/dhc6${CURRNIC} ” before the name of the NIC. e.g., perhaps the entire command line looks like the following:

sudo rtsold -DdFf1 -O /home/$(whoami)/dhc6${CURRNIC} ${CURRNIC}
Update: It appears the script should start with a reference to the shell path (e.g. #!/bin/sh), and then it runs in the background (not showing any output to the terminal). However, it can run tee effectively.

Note: At this time, the output “script "/path/file" terminated” is appearing. When this initially happened, some other error messages occurred; upon rectifying those, this message still shows. The solution has not yet been identified at the time of this writing; the workaround being used is to simply run the script file separately. That does seem to have the intended effect.

If that seemed to work, try making sure: quit any running copies of rtsold and any running copies of dhcp6c and then remove the IPv6 address from the interface.

sudo ifconfig ${CURRNIC} -inet6

Note that with all IPv6 addresses removed, DHCPv6 may not end up completing smoothly. That shouldn't be a problem, because running rtsold should assign a link-local address before DHCPv6 ends up getting called. (So that situation should not occur, unless running DHCPv6 manually before running rtsold. So, simply don't manually cause that situation.)

Then try again and see if the desired address gets assigned. If the desired address is a reserved address, then statistically that would indicate that the address is correctly getting assigned by the DHCPv6 configuration. (The chances of SLAAC picking the address at random are quite miniscule.)

If this is working, then get the client to run automatically:

cpytobak /etc/hostname.${CURRNIC}
echo !sudo rtsold -DdFf1 -O /home/$(whoami)/dhc6\$if \$if | sudo tee -a /etc/hostname.${CURRNIC}
echo !sudo /home/$(whoami)/dhc6\$if \$if | sudo tee -a /etc/hostname.${CURRNIC}
sudo ifconfig ${CURRNIC} -inet6
ifconfig ${CURRNIC}
sudo $SHELL -c ". /etc/netstart ${CURRNIC}"
ifconfig ${CURRNIC}

Note: There should be no need to run dhcp6c from the text file, as rtsold should do that automatically. However, if that is not happening, a note was made to run some software as a work-around to a current issue.

When done with this example/documentation, clean up by removing the custom variable.

Other settings

The earlier parts of the guide, which shows how to get the automatic addressing software running, covers some of the basic network settings: subnet prefix info, and assignment of a device's IPv6 addresses. However, there may be some more addresses worth mentioning.

Name resolution

DNS settings may be sent with router advertisements. (This may be a newer option, so perhaps may not be supported by some older software.) IPv6 Router Advertisement Options for DNS Configuration

Perhaps more commonly supported, at least by older software, is DHCPv6 supporting DNS.

Routing info by using router advertisements
Using rtadvd

With rtadvd, the plus side is that there may not be much that needs to be configured, as noted by rtadvd design details: dynamic routes. (On the perhaps less nice side, this program might not be quite so configurable, so automated ease comes at the cost of inflexibility.)

Routing info by DHCP
See: commentary.
Other options

There may be other options (both “manual” options, and more automated options) described by the traffic routing section.


(These were some old notes. At least part of these have been merged into the main section. Some pieces that remain may simply have not been merged, yet.)

RFC 2461: IPv6 Neighbor Discovery, RFC 2461: Stateless Address Autoconfiguration, VuXML: FreeBSD IPv6 Neighbor Discovery Protocol routing vulnerability says “IPv6 router administrators are encouraged to read RFC 3756 for further discussion of Neighbor Discovery security implications.”

(Following are... some misc notes?) PRE TAG

rtadvd: Meant for a 
“router”, this may have some more
	specific configurations.  The clients receive rtadv's.
	KAME/BSD: rtadvd.  Linux: radvd.
	net.ipv6.conf.all.forwarding on Linux or 
net.inet6.ip6.forwarding on BSD.
		(quoting )

sysctl: net.inet6.ip6.accept_rtadv
	Maybe this responds to advertisements, including unsolicited 

rtsol: Send a soliciation.  Meant to be fully automatic, accepting
	configurations from other devices that run rtsol or rtadvd.
	Regarding resending traffic, see RFC 6.3.7 (which references 
	protocol constant values defined in
	RFC 4861 section 10 (under Host constants).

rtsold: Listens for rtsol requests (over time).  Upon receiving an rtsol
	request, this sends info identical to rtsol. says
	"If a node (re)attaches to a link"..., to understand that, 
consider a
	specific example: if a NIC re-attaches to an Ethernet cord.
	Basically, it acts as rtsol and watches the NIC.  If the NIC 
goes down,
	it will rtsol once the NIC is back up.

site-local: link-local: global: routable:

This may be nicer: With OpenBSD, it may require less configuration.

In OpenBSD
Example: echo show values
sysctl net.inet6.ip6.accept_rtadv
sysctl net.inet6.ip6.forwarding
echo change values if they aren't set to the values described in the next echo couple of lines.
sysctl net.inet6.ip6.accept_rtadv=0
sysctl net.inet6.ip6.forwarding=1
echo may wish to change /etc/sysctl.conf
cp /etc/sysctl.conf /etc/sysctl_conf_no_rtadv

Following examples assume ne3. ls -l /etc/rtadvd_conf_ne3 nano # The man page for rtadvd.conf notes that # is the comment character

Note: The fd99... part is a private address, and can be set to any fd??:*.
rtadvd -dc /etc/rtadvd_conf_ne3 ne3
Further study and testing may be in order to determine what all those default settings refer to.
Linux IPv6 Router Advertisement Daemon (radvd): says “Both Linux and BSD are supported.” To clarify, it seems this may be available for FreeBSD and NetBSD.

Those who know that there is some client software named rtsol and some software named rtsold might naturally expect that rtsold is discussed in this section about server software. However, in reality, rtsold is for the clients (not the “rtouer advertisement” servers, a.k.a. routers). So check out the client-side software for details about this program.


Note the SLAAC prefix length limitation may affect some of these solutions. (Although it is set by the server, radvdump can show a different prefix length, so it seems that it is the client software that is causing the limitation on what works. However, the clients do not have options to override this limit. The standard method of dealing with these limits is to adjust the server configuration, if needed, so that the server is using what the clients will accept.)

Misc notes (not necessarily client-specific nor server-specific)

RFC 2462 section 6 discusses that spoofing neighbor discovery messages may “be addressed by requiring that Neighbor Discovery packets be authenticated”, referencing RFC 2402 which was titled “IP Authentication Header”.

An OpenBSD-specific resource: IPv6 Samurai: Todd T Fries's Technical Quickstart for IPv6. IPv6-enabled home network with OpenBSD.

DHCP for IPv6 (DHCPv6, a.k.a. DHCP6)
Info moved

The following information may need some clean-up before being merged into the main part of the article...

This should likely to into another (routing?) section, but here is info about routing:

For tunnel providers, check out one or more of: Wikipedia's list of IPv6 tunnel brokers Hurricane Electric Aarnet Freenet6 Singnet SixXS Debian: sudo bash aptitude search freenet6 tspc / Freenet6 / username-password/etc. SixXS: aptitude show aiccu Hexago: aptitude show tspc Freenet 6 in Debian: aptitude install freenet6 Use in Debian: aptitude show tspc aptitude install tspc Note: The old package freenet6 no longer is part of Debian: Info on bug 311734: Freenet6 removed Note: it appears by running aptitude install tspc, /etc/init.d/tspc start-stop-daemon --start --quiet --exec $TSPC may run. Stop the daemon after it runs: /etc/init.d/tspc stop cp /etc/tsp/tspc.conf /etc/tsp/tspc_org_backup.conf nano /etc/tsp/tspc.conf

To use an anonymous account
userid=anonymous (this is the default)
passwd= (leave it blank if userid=anonymous) (a good default only if trying to use the anonymous service)
Error 303

Upon running “/etc/init.d/etc/tspc start”, the following is seen:
“Setting up IPv6 tunnel: Status error 303 in tunnel negociation: 303 Unsupported unnel mode

Error is 303: 303 is not definted as a client error, might be a TSP error?
TSP session done

Perhaps NAT is interfering. Try editing /etc/tsp/tspc.conf (after backing it up, naturally), and changing “tunnel_mode=” to “v6udpv4” instead of its default (“v6anyv4”).

“Error is 1: TSP_ERROR”

“Setting up IPv6 tunnel: Requested tunnel mode not supported on server

Error is 1: TSP_ERROR
TSP session done

prefix length
tspc --configure

TechNet Blog: Team DHCP: Handling of DHCPv6 by Windows Vista describes that the prefix may not be requested by Windows Vista, by default, unless there is a reason for Vista to request the prefix. For instance, if Vista is acting like a router due to using the Internet Connection Sharing (“ICS”) feature of the operating system, then the operating system has a reason to be requesting a prefix.