Configuring Microsoft Research IPv6

March 16, 2001 (Check here for the latest version.)

See our 6bone and 6to4 documentation for specific examples of configuring Microsoft Research IPv6.

Configuration changes are not permanent. They are lost if you reboot or restart the IPv6 stack. To work around this, put your configuration changes in a command script (.cmd file) that you can run after boot.

net.exe

The net.exe command can be used to stop and start the IPv6 stack. Restarting the IPv6 stack causes it to reinitialize exactly as if the machine were rebooting. Note that interface numbers may change when the stack reinitializes.

The net.exe command has numerous subcommands. Each subcommand has its own set of arguments and options. Only a few are directly relevant to IPv6.

net stop tcpip6
Stops the IPv6 stack and unloads it (removes it from memory). This will fail if there are any open IPv6 sockets.
net start tcpip6
Starts the IPv6 stack if it was stopped. If a new tcpip6.sys driver file is present in the %windir%\system32\drivers directory, the new driver file gets used.

ipv6.exe

This section documents the ipv6.exe command. With the exception of IPsec, all Microsoft Research IPv6 configuration is done via the ipv6.exe command. Among other things, it is used for querying and configuring interfaces, addresses, and routes.

The ipv6.exe command has numerous subcommands. Each subcommand has its own set of arguments and options.

ipv6 if [if#]
Displays information about interfaces. If an interface number is specified, displays information only about that interface. Otherwise displays information about all interfaces. The output includes the interface's link-layer address and the list of IPv6 addresses assigned to the interface. It includes the interface's current MTU and the "true" or maximum MTU that the interface can support.
Interface #1 is a pseudo-interface used for loopback. Interface #2 is a pseudo-interface used for configured tunneling, automatic tunneling, and 6to4 tunneling. Other interfaces are numbered sequentially in the order in which they are created. This order will vary from machine to machine.
If the link-layer address is of the form aa-bb-cc-dd-ee-ff, then it is an Ethernet or FDDI interface. If the link-layer address is of the form a.b.c.d, then it is a Carpenter/Jung 6-over-4 interface.
The two pseudo-interfaces do not use any aspect of Neighbor Discovery.
ipv6 ifc if# [forwards] [advertises] [-forwards] [-advertises] [mtu #bytes] [site site-identifier]
Control attributes of the interface. Interfaces may be forwarding, in which case they forward packets whose destination address is not assigned to the interface. Interfaces may be advertising, in which case they send Router Advertisements. These are independently controllable attributes. An interface either sends Router Solicitations and receives Router Advertisements, or receives Router Solicitations and sends Router Advertisements.
Because the two pseudo-interfaces do not use Neighbor Discovery, they can not be configured to send Router Advertisements.
forwards may be abbreviated as forw.
advertises may be abbreviated as adv.
Can also set the MTU for the interface. The new MTU must be less than or equal to the link's maximum or "true" MTU (as reported by ipv6 if) and greater than or equal to the minimum IPv6 MTU (1280 bytes).
Can also change the site-identifier for an interface. Site identifiers are used in the sin6_scope_id field with site-local addresses.
ipv6 ifd if#
Deletes an interface. The loopback and tunnel pseudo-interfaces can not be deleted.
ipv6 nc [if# [address]]
Displays the contents of the Neighbor Cache. If an interface number is specified, displays only the contents of that interface's cache. Otherwise displays the contents of all interface's caches. If an interface is specified, one may further specify an IPv6 address and then only that one Neighbor Cache Entry is displayed.
For each Neighbor Cache Entry, displays the interface, the IPv6 address, the link-layer address, and the reachability state.
ipv6 ncf [if# [address]]
Flushes the specified Neighbor Cache Entries. Only Neighbor Cache Entries without references will be purged. Because Route Cache Entries hold references to Neighbor Cache Entries, it works best to flush the route cache first. Routing table entries can also hold references to Neighbor Cache Entries.
ipv6 rc [if# address]
Displays the contents of the Route Cache. The Route Cache is the MSR IPv6 implementation's name for the Destination Cache. If an interface and address is specified, displays the Route Cache Entry for the reaching the address via the interface. Otherwise displays all Route Cache Entries.
For each Route Cache Entry, displays the IPv6 address and the current next-hop interface and neighbor address. Also displays the preferred source address for use with this destination, the current path MTU for reaching this destination via the interface, and whether this is an "interface-specific" Route Cache Entry. Also displays if there is a Care-Of Address (for mobility) for this destination address.
A destination address can have multiple Route Cache Entries, up to one for each outgoing interface. However, a destination address can have at most one Route Cache Entry that is not "interface-specific". An "interface-specific" Route Cache Entry is only used if the application explicitly specifies that outgoing interface.
ipv6 rcf [if# [address]]
Flushes the specified Route Cache Entries.
ipv6 bc
Displays the contents of the Binding Cache. The Binding Cache holds bindings between Home Addresses and Care-Of Addresses for Mobile IPv6.
For each binding, displays the home address, the care-of address, and the binding sequence number and lifetime.
ipv6 adu if#/address [lifetime VL[/PL]] [anycast] [unicast]
Adds or removes a unicast or anycast address assignment on an interface. Defaults to unicast unless anycast is specified.
If the lifetime is not specified, it is infinite. If only a valid lifetime is specified, then the preferred lifetime is equal to the valid lifetime. A lifetime of infinite may be specified, or a value in seconds. The preferred lifetime must be less than or equal to the valid lifetime. Specifying a lifetime of zero causes the address to be removed.
lifetime may be abbreviated as life.
For anycast addresses, the only valid lifetime values are zero and infinite.
ipv6 spt
Displays the current contents of the site prefix table.
For each site prefix, displays the prefix, the interface to which the site prefix applies, and the prefix lifetime in seconds.
Site prefixes are normally auto-configured from Router Advertisements. They are used in getaddrinfo and getipnodebyname to filter out inappropriate site-local addresses.
ipv6 spu prefix if# [lifetime L]
Adds, removes, or updates a prefix in the site prefix table.
The prefix and interface number are not optional. The site prefix prefix lifetime (specified in seconds) defaults to infinite if not specified. Specifying a lifetime of zero causes the site prefix to be deleted.
Not needed for normal configuration of hosts or routers.
ipv6 rt
Displays the current contents of the routing table.
For each routing table entry, displays the route prefix, either an on-link interface or a next-hop neighbor on an interface, a preference value (smaller is more preferred), and a lifetime in seconds.
Routing table entries may also have publish and aging attributes. The default is for them to age (meaning the lifetime actually counts down, instead of remaining constant) and to not be published (meaning they are not used in constructing Router Advertisements).
On hosts, routing table entries are normally auto-configured from Router Advertisements.
ipv6 rtu prefix if#[/nexthop] [lifetime L] [preference P] [publish] [age] [spl site-prefix-length]
Adds or removes a route in the routing table. The route prefix is not optional. The prefix can either be on-link to a specified interface or it can have next-hop, specified with a neighbor address on an interface. The route can have a lifetime in seconds (defaults to infinite) and a preference (defaults to zero, or most preferred). Specifying a lifetime of zero causes the route to be deleted.
If the route is specified as published (meaning it will be used in constructing Router Advertisements), then by default it does not age. The route's lifetime does not count down, so it is effectively infinite, but the value does get used in Router Advertisements. Optionally, a route can specified as a published route that also ages. A non-published route by default always ages.
The optional spl suboption can be used to specify a site prefix length associated with the route. The site prefix length is used only when sending Router Advertisements.
lifetime may be abbreviated as life.
preference may be abbreviated as pref.
publish may be abbreviated as pub.

Discussion

Router Advertisements

The content of Router Advertisements is automatically derived from the published routes in the routing table. Non-published routes are used for routing but are completely ignored when constructing Router Advertisments.

Router Advertisements always contain a Source Link-Layer Address option and an MTU option. The value for the MTU option is taken from the sending interface's current link MTU. This value can be changed with the ipv6 ifc mtu command.

The Router Advertisement will have a non-zero Router Lifetime only if there is a published default route. A default route is a route for the zero-length prefix.

Published on-link routes result in Prefix Information Options in Router Advertisements. If the on-link prefix has 64 bits, then the Prefix Information option has both the L and A bits set, so hosts receiving it will auto-configure addresses.

An interface that sends Router Advertisements will also autoconfigure addresses for itself based on the Prefix Information Options that it sends.

It is normally best to have a finite non-aging lifetime on all published routes, like 30 minutes. Then if you decide to retract a route, just change the route to have an aging lifetime. The route will age over the course of a few Router Advertisements and then disappear from both the router and any hosts receiving the Router Advertisements.

Routes that hosts learn from Router Advertisements are not published and do age. Similarly, addresses autoconfigured from Router Advertisements do age.

Site Prefixes

The ipv6 rtu command allows published on-link prefixes to also be configured with a site prefix length. If specified, the site prefix length is put into a Prefix Information option in Router Advertisements. For example,

ipv6 rtu 2002:836b:4179:2::/64 4 pub life 1800 spl 48 specifies a prefix that is on-link to interface #4. The prefix is published, meaning that it is included in Router Advertisements if interface #4 is an advertising interface. The lifetime in the Prefix Information option is 1800 seconds or 30 minutes. The Site Prefix Length in the Prefix Information option is 48.

The receipt of a Prefix Information Option that specifies a site prefix causes an entry to be created in the Site Prefix Table. The ipv6 spt command displays the Site Prefix Table. The Site Prefix Table is used to remove inappropriate site-local addresses from the addresses returned by the getaddrinfo and getipnodebyname APIs.

See the Internet Draft Site prefixes in Neighbor Discovery for more information about site prefixes and site-local addressing.

Link-Local and Site-Local Addresses

Link-local and site-local addresses are called scoped addresses. The API supports the sin6_scope_id field in struct sockaddr_in6 for use with scoped addresses.

For link-local addresses (fe80::/10 prefix), the sin6_scope_id field in the socket address is an interface number.

For site-local addresses (fec0::/10 prefix), the sin6_scope_id field in the socket address is a site identifier. The ipv6 ifc site command will change the site identifier associated with an interface. By default, interfaces are associated with site identifier 1.

For all other addresses, the sin6_scope_id field must be zero.

If you are sending or connecting to a scoped address, then sin6_scope_id may be left unspecified (zero). If you are binding to a scoped address, then sin6_scope_id must be non-zero and specify a valid interface number or site identifier.

If you are sending or connecting to a scoped address and have not specified sin6_scope_id, then the scoped address is ambiguous. To resolve the ambiguity, the IPv6 stack first checks if you've bound the socket to a source address. If so, the bound source address resolves the ambiguity by supplying an interface number or site identifier.

If you are sending or connecting to a scoped address and have not specified sin6_scope_id and not bound a source address, then the IPv6 stack looks in the routing table. For example,

ipv6 rtu fe80::/10 3 specifies that link-local addresses by default be treated as on-link to interface #3.

If you have not specified sin6_scope_id, you have not bound a source address, and you have not specified a route for link-local addresses, then as a last resort the IPv6 stack will try Neighbor Discovery to resolve a link-local address via each of your interfaces in turn until it finds a neighboring node that has the link-local address. When Neighbor Discovery times out (this takes several seconds), it will move on to the next interface for the next packet that you send.

Multicast Destination Addresses

When sending to a multicast destination address, Microsoft Research IPv6 normally requires that the application have specified an outgoing interface. It can do this with the IPV6_MULTICAST_IF socket option.

It is also possible and often convenient to specify a default interface for a specific multicast address, an entire multicast address scope, or all multicast addresses. This is done with a route that makes the multicast prefix be on-link to the desired outgoing interface. For example,

ipv6 rtu ff02::5/128 3
ipv6 rtu ff0e::/16 3
ipv6 rtu ff00::/8 3

Automatic Tunneling and 6to4

Automatic tunneling with v4-compatible addresses and 6to4 both work the same way, via a route for a prefix that is on-link to interface #2. The 32 bits following the prefix are extracted and used as a v4 destination address for the encapsulated packet.

Automatic tunneling uses the ::/96 prefix. It is enabled by default. It can be disabled by removing the route for ::/96.

6to4 uses the 2002::/16 prefix. It is not enabled by default.

Forwarding Tunneled Packets

There is a limitation in the code that receives encapsulated (tunneled) packets and demultiplexes them to a specific interface. If you want to forward tunneled packets received via a configured tunnel, then it is necessary to enable forwarding on any 6-over-4 interfaces as well as interface #2. Just enabling forwarding on interface #2 will not work. Of course, normally when configuring a router you would in any case enable forwarding on all interfaces except loopback.