January 13, 2000 (Check here for the latest version.)
See our 6bone and 6to4 documentation for specific examples of configuring MSR 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.
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
net start tcpip6
This section documents the ipv6.exe command. With the exception of IPsec, all MSR 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#]
ipv6 ifc if# [forwards] [advertises] [-forwards] [-advertises] [mtu #bytes] [site site-identifier]
forwards
may be abbreviated as forw
.
advertises
may be abbreviated as adv
.
ipv6 if
) and greater than or equal to the minimum IPv6 MTU (1280 bytes).
sin6_scope_id
field
with site-local addresses.
ipv6 ifd if#
ipv6 nc [if# [address]]
ipv6 ncf [if# [address]]
ipv6 rc [if# address]
ipv6 rcf [if# [address]]
ipv6 bc
ipv6 adu if#/address [lifetime VL[/PL]] [anycast] [unicast]
anycast
is specified.
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
.
ipv6 spt
ipv6 spu prefix if# [lifetime L]
ipv6 rt
ipv6 rtu prefix if#[/nexthop] [lifetime L] [preference P]
[publish] [age] [spl site-prefix-length]
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
.
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.
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
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 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
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.
When sending to a multicast destination address, MSR 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 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.
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.