IPv6 Networking FAQ
This page is being developed, and we welcome any comments or suggestions.
IPv6 code was merged into NetBSD in June 1999, and is part of NetBSD. IPv6 configuration is mostly the same as IPv4 configuration, so you may want to check the documentation for IPv4 networking.
The GENERIC kernel configuration enables IPv6 support by default for most of the architectures (ports). Userland code includes IPv6 support where possible, by default, so no rebuild of userland is necessary even if you switch between an IPv4-only kernel and an IPv4/v6 kernel.
Around 1992, the IETF became aware of a global shortage of IPv4 addresses, and technical obstacles in deploying new protocols due to limitations imposed by IPv4. An IPng (IP next generation) effort was started to solve these issues. The discussion is outlined in a bunch of RFCs, starting from RFC1550. After a large amount of discussion, around 1995, IPv6 (IP version 6) was picked as the final IPng proposal. The IPv6 base specification is specified in RFC2460.
In a single sentence, IPv6 is a re-engineering effort against IP technology. Key features are listed below:
- Larger IP address space. IPv4 uses only 32 bits for IP address space, which allows only 4 billion nodes to be identified on the Internet. 4 billion may look like a large number; however, it is less than the human population on the earth! IPv6 allows 128 bits for IP address space, allowing 340282366920938463463374607431768211456 (three hundred forty undecillion) nodes to be uniquely identified on the Internet. A larger address space allows true end to end communication, without NAT or other short term workarounds against the IPv4 address shortage. (These days NAT is a headache for new protocol deployment and has scalability issues; we really need to decommission NAT networks for the Internet to grow further).
Deploy more recent technologies.
After IPv4 was specified 20 years ago,
we saw many technical improvements in networking.
IPv6 includes a number of those improvements in its base specification,
allowing people to assume these features are available everywhere, anytime.
"Recent technologies" include, but are not limited to, the following:
- Autoconfiguration. With IPv4, DHCP exists but is optional. A novice user can get into trouble if they visit another site without a DHCP server. With IPv6, a "stateless host autoconfiguration" mechanism is mandatory. This is much simpler to use and manage than IPv4 DHCP. RFC4862 has the specification for it.
- Security. With IPv4, IPsec is optional and you need to ask the peer if it supports IPsec. With IPv6, IPsec support is recommended. By recommending IPsec, we can assume that you should be able to secure your IP communication whenever you talk to IPv6 devices.
- Friendly to traffic engineering technologies. IPv6 was designed to allow better support for traffic engineering like diffserv or intserv (RSVP). We do not have a single standard for traffic engineering yet, so the IPv6 base specification reserves a 24-bit space in the header field for those technologies and is able to adapt to coming standards better than IPv4.
- Multicast. Multicast is mandatory in IPv6, which was optional in IPv4. The IPv6 base specifications themselves extensively use multicast.
- Better support for ad-hoc networking. Scoped addresses allow better support for ad-hoc (or "zeroconf") networking. IPv6 supports anycast addresses, which can also contribute to service discoveries.
- and more.
- A cure to routing table growth. The IPv4 backbone routing table size has been a big headache to ISPs and backbone operators. The IPv6 addressing specification restricts the number of backbone routing entries by advocating route aggregation. With the current IPv6 addressing specification, we will see only 8192 routes on the default-free zone.
- Simplified header structures. IPv6 has simpler packet header structures than IPv4. It will allow future vendors to implement hardware acceleration for IPv6 routers easier.
- Allows flexible protocol extensions. IPv6 allows more flexible protocol extensions than IPv4 does, by introducing a protocol header chain. Even though IPv6 allows flexible protocol extensions, IPv6 does not impose overhead to intermediate routers. It is achieved by splitting headers into two flavors: the headers intermediate routers need to examine, and the headers the end nodes will examine. This also eases hardware acceleration for IPv6 routers.
- Smooth transition from IPv4. There were a number of transition considerations made during the IPv6 discussions. Also, there are a large number of transition mechanisms available. You can pick the most suitable one for your site.
- Follows the key design principles of IPv4. IPv4 was a very successful design, as proven by the ultra large-scale global deployment. IPv6 is "new version of IP", and it follows many of the design features that made IPv4 very successful. This will also allow smooth transition from IPv4 to IPv6.
- and more.
There are number of good books available on IPv6. Be sure to check these if you are interested.
The network configuration is defined in a set of text configuration files. Note that you do not need to edit some of those if you are configuring a host (not a router), by using autoconfiguration.
/etc/rc.conf- rc.conf(5) specifies system services, including the network services, to be automatically started at system initialization.
/etc/hosts- hosts(5) can include mappings between FQDN names and IPv6 numeric addresses.
/etc/rc.conf- you can include IPv6 network setup, using ifconfig(8), into here.
In IPv6, routers and hosts are clearly separated. Nodes that forward packets for others are called routers. Nodes that do not are called hosts. Routers need to be configured manually. Routers will advertise information about subnet using rtadvd(8) daemon. Hosts usually have only one external network interface (some parts of this document assume this), and will be autoconfigured using the advertised subnet information.
There are two separate mechanisms defined for IPv6 host autoconfiguration. One is called stateless address autoconfiguration, and is specified in RFC4862. The other is called DHCPv6, and is specified in RFC3315. DHCPv6 is discussed in the IETF dhc working group. NetBSD currently implements RFC2462, the predecessor of RFC4862, and DHCPv6.
Stateless address configuration basically works as follows. We have two parties here: a host (which is to be autoconfigured) and a router (which emits necessary information to the host).
- The host configures a link-local address to its network interface.
A link-local IPv6 address starts with "fe80", and has a value in
the lower-most 64 bits.
The lower-most 64 bits are called the interface ID.
For Ethernet and some other interfaces, the MAC address is used as
the source for interface ID.
% ifconfig ne2 ne2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet manual inet6 fe80::a00:5aff:fe38:6f86%ne2 prefixlen 64 scopeid 0x1
- By running rtadvd(8) on the router, the router periodically advertises
information about the link (like Ethernet segment)
to all nodes on the link.
The information is carried by ICMPv6 "router advertisement" packet.
The attached example advertises the following information:
- IPv6 subnet prefix is 2001:218:420::/64
- Default router is on fe80::240:5ff:fea0:8e08
- And couple of more parameters, like IPv6 link MTU, default hoplimit, and router lifetime.
14:18:20.812850 fe80::240:5ff:fea0:8e08 > ff02::1: icmp6: router advertisement\ (chlim=64, router_ltime=1800, reachable_time=30000, retrans_time=1000)(src\ lladdr: 0:40:5:a0:8e:8)(mtu: mtu=1500)(prefix info: LA valid_ltime=2592000,\ preffered_ltime=604800, prefix=2001:218:420::/64) 6000 0000 00a0 3aff fe80 0000 0000 0000 0240 05ff fea0 8e08 ff02 0000 0000 0000 0000 0000 0000 0001 8600 d38d 4000 0708 0000 7530 0000 03e8 0101 0040 05a0 8e08 0501 0000 0000 05dc 0304 40c0 0027 8d00 0009 3a80 0000 0000 2001 0218 0420 0000 0000 0000 0000 0000
- The host catches the advertisement, and configures the global IPv6
address and the default router.
By running ndp(8) on the host, we can see more detail about
the most recent router advertisement.
% ifconfig ne2 ne2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet manual inet6 fe80::a00:5aff:fe38:6f86%ne2 prefixlen 64 scopeid 0x1 inet6 2001:218:420:0:a00:5aff:fe38:6f86 prefixlen 64
- Optionally, the host can ask for an advertisement from the router
by sending an ICMPv6 "router solicitation" packet.
rtsol(8) transmits the router solicitation packet.
If you are running a mobile node, you may want to run rtsold(8) and
transmit router solicitations periodically.
The packet will be like this:
14:18:20.300501 fe80::a00:5aff:fe38:6f86 > ff02::2: icmp6: router solicitation\ (src lladdr: 8:0:5a:38:6f:86) (len 16, hlim 255) 6000 0000 0010 3aff fe80 0000 0000 0000 0a00 5aff fe38 6f86 ff02 0000 0000 0000 0000 0000 0000 0002 8500 d7b0 0000 0000 0101 0800 5a38 6f86
We call it stateless address autoconfiguration, since we do not need to manage state in the router side. It is a very simple, robust and effective autoconfiguration mechanism.
Note that we cannot autoconfigure routers. Routers really need to be configured manually.
First, you may want to get an IPv6 global address from upstream provider. If you have one, you'll need to perform the following steps.
- Add manual configuration for network interfaces, into
/etc/netstart.local. See the following section for details.
- Configure the following lines in rc.conf(5).
rtadvd_flags="sm1 ne2" # set interfaces to advertise
- You may want to edit
/etc/rtadvd.conf(rtadvd.conf(5)) for fine-tuning the router advertisement timers.
- If you would like to announce routes by using RIPng, configure rc.conf(5) to run route6d(8).
- Perform a reboot.
If you have an IPv6 router on the network, all you have to do is as follows. After the reboot, the host will be autoconfigured by using Router Advertisements from the rtadvd(8) on the adjacent router.
- Configure the following lines in rc.conf(5).
rtsol_flags="sm1" # set your interface here
up !rtsol $int
- Perform a reboot.
If you do not have an IPv6 router on the network, you'll need to manually configure your system. See the following section for details.
Also, due to restrictions in the IPv6 specification, it is not recommended to autoconfigure a host with multiple external interfaces (like 2 ethernet interfaces). Please perform manual configuration in this case. See the following section for details.
One of the key value-adds of IPv6 is the ubiquitous availability of autoconfiguration. Since IPv6 addresses are 128 bits, there's a higher chance for mistakes in manual configuration. We strongly recommend that you avoid manual configuration whenever possible. For example:
If you think it is easier to do manual configuration, it's not. Manual configuration will impose future maintenance labor upon you.
If you really need a manual configuration, read on.
If you need to configure a node manually, add manual configuration for network interfaces into rc.conf(5).
You will first need to declare the type of the node (host or router)
ip6mode as per below.
ip6mode="router" # forward packets for others ip6mode="host" # do not forward packets for others
Then, add interface configuration into rc.conf(5), or
other files sourced by
/etc/rc.d/network such as
/etc/ifconfig.xxN. You can have multiple lines in
inet 10.1.1.1 netmask 0xffffff00 inet6 2001:db8:1234::1 prefixlen 64 alias
"alias" at the end of the line. As there
are multiple interface addresses with IPv6, the keyword is
If your configuration is not covered by rc.conf(5),
configuration can be added into
You will need to use the following programs:
A string hostname will be resolved to IPv6 numeric
addresses by using
(hosts(5)), and/or DNS. This is much like the same as IPv4
case. yp(8) may be used, however, the author has no
experience using yp(8) with IPv6 addresses.
/etc/hosts(hosts(5)): For small networks of a few nodes, the hostname/IP maps can be manually duplicated in the /etc/hosts files of each node.
2001:db8:1234::a:b:c:d host2.example.net host2
DNS: The hostname maps can be centralized into zone-files which are accessed by the name-server, named(8).
Forward zone file entry
host2 IN AAAA 2001:db8:1234::a:b:c:d
Reverse zone file entry
d.0.0.0.c.0.0.0.b.0.0.0.a.0.0.0.0.0.0.0.4.188.8.131.52.b.d.0.1.0.0.2.ip6.arpa. IN PTR host2.example.net
Note: If you have heard about A6 records and bitstring labels for DNS – A6 and bitstrings are now in historic status, so you don't need to worry about them. AAAA is to be used for production service and works fine.
Also note that the reverse DNS table has moved from
ip6.arpa; 6Bone (3ffe) addresses are no longer used. Production addresses should be announced under ip6.arpa.
Please note that the following addresses MUST NOT appear in the global DNS cloud:
- link-local addresses (matches fe80::/10, like fe80::1)
This one is not globally reachable.
- unique-local addresses (matches fc00::/7, like fd00::1)
This one is not globally reachable either. This one is somewhat like a private address, so you can put it into your intranet DNS cloud.
- v4 mapped addresses (matches ::ffff:0.0.0.0/96, like ::ffff:10.1.1.1)
This address is only for internal use in a node. Do not put this into DNS database directly.
It is not recommended to put these addresses onto DNS cloud:
- multicast addresses (matches ff00::/8, like ff05::1)
For the NetBSD/KAME IPv6 code, putting the following address does not make sense due to lack of support:
- v4 compatible address (matches ::0.0.0.0/96, like ::10.1.1.1)
NetBSD/KAME does not support RFC2893 auto tunnel.
There are couple of differences between IPv6 and IPv4 address allocation.
The prefix length for an IPv6 subnet will always be /64; no more, no less. It allows you to place as many IPv6 devices as the underlying network medium allows.
With IPv4, prefix length varies between subnets to subnets, and it caused painful costs when renumbering subnets (for example, imagine when you renumber an IPv4 subnet from /28 to /29 or vice versa).
An ordinary leaf site will always get /48 of address space. It will make site renumbering easier, and allows you to switch ISP more easily.
With IPv4, the allocation varies by the size of the site, and made it very painful when you migrated from one ISP to another, for example.
Depending on the ISP situation around you, you may be able to get native IPv6 connectivity (just like you do for IPv4), or you may be able to get tunnelled connectivity (IPv6 packets encapsulated into IPv4 packets). The section talks about the latter case.
You can hook your machine up to Hurricane Electric's IPv6 Tunnel Broker. You will need to talk with the nearest tunnel server to get your IPv6 address. They provide a web interface to update the IPv4 address of your tunnel if it changes.
If you do not have a fixed IPv4 global address (if you are using dialup ISP connection), don't panic. You can hook yourself up to Freenet6. They provide a web interface to hook up your home network whenever you reconnect to the Internet.
In both cases, you will need to set up an IPv6-over-IPv4 tunneling interface onto your router. Consult gif(4) for details. Hurricane Electric provides instructions for setting up tunnels on NetBSD.
Setting up gif tunnel: create
/etc/ifconfig.gif0with the following content. The first argument (
x.x.x.x) is your IPv4 address, and the second one (
y.y.y.y) is the IPv4 address of the other endpoint.
create (only needed on post-1.5) tunnel x.x.x.x y.y.y.y
Or, add the following lines into
# ifconfig gif0 create (only needed on post-1.5) # ifconfig gif0 tunnel x.x.x.x y.y.y.y
See if the tunnel is working correctly: First try invoking the following command:
# ping6 -n ff02::1%gif0
If you see two packets, one from your local node and another from the remote node, the tunnel is working fine. If you have an IPv4 reachability problem between x.x.x.x and y.y.y.y, you will see only one reply or no reply. Here are items to look at if you are having trouble:
- Make sure you do not have a NAT box between you and the peer. Tunnelled IPv6 packets cannot go through a NAT box.
- Make sure you do not have any IPv4 packet filters between you and the peer.
Exchange routes: Depending on your upstream configuration, you may need to set up default route to the upstream, or you may need to run a routing daemon.
The above configuration uses an RFC2893 IPv6-over-IPv4 configured tunnel. Note that RFC2893 packets will not be able to go through a NAT router (if your tunnel endpoint itself - a NetBSD box - is a NAT router, it should not be a problem).
Suppose you have obtained your address prefix, 2001:db8:1234::/48 from your upstream for your home network. You have two ethernet segments in your home, like below. Both myrouter A and myrouter B run IPv6-capable NetBSD. IPv4 addresses are assigned like below. You wish to connect to the upstream via IPv6-over-IPv4 tunnel, from myrouter A at x.x.0.1/24 to upstream router at y.y.y.10.
myrouter A | IPv4 x.x.0.1/24 | ==+=== ethernet 0 | | IPv4 x.x.0.2/24 myrouter B | IPv4 x.x.1.2/24 | ==+=== ethernet 1
First, you need to configure your tunnel to the upstream from myrouter A. On myrouter A, configure the tunnel by using ifconfig(8), and then confirm the reachability by using ping6(8). "ff02::1" is referred to as an all-node multicast address, which should reach all nodes on the tunnel - in this case, myrouter A and upstream router. If you get answers from two nodes, the tunnel is working fine. If you get answer from only one node (myrouter A itself), something is bad between you and the upstream. It could be IPv4 filtering, it could be misconfiguration on either side, or something else. Track the problem down before proceeding.
# ifconfig gif0 create (only needed on post-1.5) # ifconfig gif0 tunnel x.x.0.1 y.y.y.10 # ping6 -I gif0 -n ff02::1 PING6(56=40+8+8 bytes) fe80::a00:5aff:fe38:6f86 --> ff02::1 16 bytes from fe80::a00:5aff:fe38:6f86%lo0, icmp_seq=0 hlim=64 time=0.334 ms 16 bytes from fe80::240:5ff:fea7:f092%gif0, icmp_seq=0 hlim=64 time=3.416 ms(DUP!)
Next, you need to assign a subnet address from your address block, 2001:db8:1234::/48, to two of your ethernet segments. Since the prefix length for IPv6 subnet is always /64, you have 65536 subnets available for you! Let's just assign 2001:db8:1234:0::/64 to ethernet 0, and 2001:db8:1234:1::/64 to ethernet 1.
myrouter A ---- tunnel -------> upstream | IPv4 x.x.0.1/24 IPv4 y.y.y.10 | ==+=== ethernet 0: x.x.0.0/24, 2001:db8:1234:0::/64 | | IPv4 x.x.0.2/24 myrouter B | IPv4 x.x.1.2/24 | ==+=== ethernet 1: x.x.1.0/24, 2001:db8:1234:1::/64
Let us assign IPv6 global address to your routers. Since routers MUST be manually configured, you need to perform the "ifconfig" as described in manual configuration section. For myrouter A, lookup link-local IPv6 address (it starts with "fe80"), take the lower 64 bits, attach upper 64 bits from the subnet address, and configure it. To preserve configuration across reboot, you may wish to append the setting to /etc/ifconfig.ne2.
# ifconfig ne2 ne2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 08:00:5a:38:6f:86 media: Ethernet manual inet x.x.0.1 netmask 0xffffff00 broadcast x.x.0.255 inet6 fe80::a00:5aff:fe38:6f86%ne2 prefixlen 64 scopeid 0x1 # ifconfig ne2 inet6 2001:db8:1234:0:a00:5aff:fe38:6f86 prefixlen 64 alias # echo 'inet6 2001:db8:1234:0:a00:5aff:fe38:6f86 prefixlen 64 alias' >> /etc/ifconfig.ne2
For myrouter B, do the similar thing.
# ifconfig tlp0 inet6 2001:db8:1234:0:a00:5aff:fe38:8765 prefixlen 64 alias (ethernet 0 side) # ifconfig tlp1 inet6 2001:db8:1234:1:a00:5aff:fe38:9710 prefixlen 64 alias (ethernet 1 side)
To exchange routing information, run route6d(8) on both routers. If the upstream asks you to aggregate route announcements, please consult the manual page for command line options. Now that connectivity to your upstream should be okay, try to ping external IPv6 nodes. Do not forget to specify "-n" to ping6(8); IPv6 reverse address lookup can take a very long time and should be avoided when you do tests.
# route6d (on both routers) # ping6 -n www.6bone.net
If you have end hosts (non-router nodes) on your network, you may want your router to advertise subnet information to end hosts. By doing this, your end hosts will be able to autoconfigure themselves. You will need to prepare /etc/rtadvd.conf, and run rtadvd(8). Note that you should advertise subnet information from the upstream router. In the picture, myrouter A should advertise to ethernet 0, and myrouter B should advertise to ethernet 0 and 1. You may want to disable advertisement from myrouter B to ethernet 0, because B is on the downstream and is not optimal as the default router (but if you disable it, machines on ethernet 0 will not be able to talk with machines on ethernet 1 when myrouter A is dead).
# rtadvd ne2 (from myrouter A to ethernet 0) # rtadvd tlp0 tlp1 (from myrouter B to ethernet 0 and 1)
In some cases, your upstream may ask you to configure differently from the above scenario.
If you have more than one static global IPv4 address, you can use 6to4 mechanism (RFC3056) for your own /48 IPv6 prefix.
There are routers called "public 6to4 relay router" out there, which will behave as the other side of tunnel for you. You will need to configure one of your machines to behave as 6to4 gateway, which will encapsulate IPv6 packets into IPv4 and throw them to public 6to4 relay router (and vice versa). If your IPv4 address is x.y.z.u, your IPv6 prefix will be 2002:xxyy:zzuu::/48 (xx, yy, zz and uu is hexadecimal notation for x, y, z and u, respectively).
If your ISP gave you a private IPv4 address (like 10.x.x.x), unfortunately you cannot use this mechanism. The mechanism does not work across NAT devices.
Let us assume the following topology, and machine myrouter A has an IPv4 address x.y.z.u. IPv4 address for myrouter B does not matter.
myrouter A | IPv4 x.y.z.u | ==+=== ethernet 0 | myrouter B | ==+=== ethernet 1
First, you need to configure 6to4 tunnel interface on myrouter A. We have picked an IPv6 subnet prefix, 2002:xxyy:zzuu:0000::/64, for use in the tunnel. With the promulgation of RFC 3068, everyone using 6to4 should now set their default router to 2002:c058:6301:: which is a special magic anycast address for the nearest (in BGP terms, anyhow) Relay Router. There's also a list of public 6to4 relay routers you can choose from. Note that we cannot use ff02::1 test on stf0 interface, as the interface is not capable of IPv6 multicasting. In older NetBSD releases, stf0 interface was not enabled by default in the GENERIC kernel and you may need to enable it and recompile your kernel (no longer necessary in NetBSD 4.0).
# ifconfig stf0 create (only needed on post-1.5) # ifconfig stf0 inet6 2002:xxyy:zzuu:0000::1 prefixlen 16 alias # route add -inet6 default 2002:c058:6301:: (or another one from the list)
Next, you need to assign a subnet address from your address block, 2002:xxyy:zzuu::/48, to two of your ethernet segments. Since we have already used 2002:xxyy:zzuu:0000::/64 for the tunnel, we cannot use it for our ethernet interfaces. Let us use 2002:xxyy:zzuu:0001::/64 and 2002:xxyy:zzuu:0002::/64 here.
: 6to4 tunnel, 2002:xxyy:zzuu:0000::/64 : myrouter A | IPv4 x.y.z.u | ==+=== ethernet 0: 2002:xxyy:zzuu:0001::/64 | myrouter B | ==+=== ethernet 1: 2002:xxyy:zzuu:0002::/64
You can now go back to the previous section and setup myrouter B, RIPng routing, as well as router advertisement.
To go to a totally IPv6 environment (without IPv4), you'd
need to contact name servers using IPv6 cloud. It's easy: you
just need to put IPv6 addresses into resolv.conf(5). If you
would like to run an IPv6 transport ready DNS server, try
configuration would be like this:
We cannot connect directly from an IPv6-only client to an IPv4-only server, or vice versa. We need a device called a "translator" to do this.
NetBSD is shipped with the faithd(8) TCP relay
translator, which can be used to enable an IPv6-only (or
IPv4/v6) client to contact IPv4-only servers by using IPv6 TCP.
By using it with
proxy server, you can install an IPv6-to-IPv4 translator
environment, like this:
+--IPv6 only cloud------+ | | |IPv6 only | IPv4 only |client == IPv6 ===> translator ----- IPv4 --> servers | tcp runs faithd(8) tcp | | +-----------------------+
For actual setup, please refer to the following documents.
If your organization has IPv4-only routers, IPv4 NAT routers, or other things that may become obstacles to direct IPv6 networking, you can overcome these hurdles by following ways. Pick the most suitable one for your network configuration:
- It is possible to place two routers, one for IPv4, and one for IPv6,
between two ethernet segments.
You can place IPv6-only routers between two segments,
enabling IPv6 routing only.
This way, you can keep IPv4 network untouched.
outgoing router | ==+=======================+=== IPv4/v6 subnet A | | IPv4-only router IPv6-only router | forward | forward | IPv4 only | IPv6 only ==+=======================+=== IPv4/v6 subnet B
- Usage of private/global address in IPv4 has nothing to do with
If it is allowed under your network management policy, you can
configure global IPv6 reachability, while splitting IPv4 network
into private address segment and global address segment by NAT box/
outgoing router | ==+=======================+=== subnet A: IPv4 global, IPv6 global | | IPv4-only NAT router IPv6-only router | | ==+=======================+=== subnet B: IPv4 private, IPv6 global
- In some cases, you can bridge IPv6 traffic across segments by using
normal IPv4 router.
If you can configure your IPv4 router to bridge ethernet protocol type
0x86dd, you can bridge IPv6 traffic only.
In this case, subnet allocation will become different between IPv4
and IPv6 - this may become headache if you do this too much...
outgoing router | ==+======== ether segment 1: IPv4 subnet A, IPv6 subnet X | IPv4-only router (bridge ether type 0x86dd) | ==+======== ether segment 2: IPv4 subnet B, IPv6 subnet X (same as above)
- If you have IPv4 reachability between two distant location in your
organization, you can use IPv6-over-IPv4 tunnel to go across IPv4-only
network in between.
+--- IPv4-only cloud -------------------+ | | +<================= IPv6-over-IPv4 tunnel =============>+ | | | | | +---------------------------------------+ | | | IPv4/v6 router IPv4/v6 router | | ==+======= IPv4/v6 segment 1 ==+======= IPv4/v6 segment 2
Because IPv6 is still in its infancy, there are several non-standard items or specification holes. The KAME IPv6 implementation tries to address those.
IPv6 specifies "scoped", or not-worldwide-unique, addresses in the specification. To disambiguate a scoped address, we need to explicitly specify the scope of the address. For example, the specification specifies a "link-local address" which is unique on a single link only. You need to specify the outgoing "link" with the address to disambiguate the address.
KAME IPv6 code embeds a scope identifier into the 3rd and 4th byte of a scoped address in the in-kernel structures. Because of this, you sometimes see embedded form, like "fe80:1::abcd:1234:abcd:1234" to mean "fe80:0000:0000:0000:abcd:1234:abcd:1234 on scope 1". You should not specify the embedded form whenever possible.
To disambiguate a scoped address, you have two options:
- When you perform some experiments in your local network, do not use site-local unicast addresses. The way the specification is written is too vague. If you wish to run partitioned networks (which does not connect to the outside), it is advisable to use unique-local addresses. Unique-local addressing is specified in RFC2893.
Not about the specification, but there are some things worth mentioning:
- Not all the tools are IPv6 transport ready. Though yp(8) can contain IPv6 address in their database, it does not support IPv6 transport (it cannot resolve names over the IPv6 cloud).
- Some of pkgsrc directories have been changed to use the
inet6option to switch between IPv4/v6 builds and IPv4-only builds. The option will automatically be turned on for IPv6-ready NetBSD systems.
- The implementation does not support automatic tunnels (RFC2893) nor 6over4 (RFC2529), as these standards are not widely in use and considered obsolete in IPv6 community.
AF_INET6wildcard listening sockets will grab IPv4 connection only with certain configurations (RFC2553 documents this behavior). This is for plugging security hole in specification. Consult inet6(4) and ip6(4) for more details.
- IPv6 requires network interfaces to have multicast support. If your driver has any problem in multicast support (like lack of support, bug in multicast filter configuration, etc), then IPv6 does not work at all. If you see this kind of problem, please do send a bug report.
- NetBSD does not ship with getipnodebyname(3); nor getipnodebyaddr(3), as they are practically deprecated in the IPv6 basic API specification. They also lack support for the scoped nature of IPv6 address. Use getaddrinfo(3) and getnameinfo(3) instead.
If you have any questions, do not hesitate to ask on the tech-net mailing list. When you ask about your configuration, be VERY sure to attach a network diagram (ASCII art is fine) for your site. Without a network diagram, nobody can guess your network configuration.
- Monitoring activity - useful tools
- ifconfig(8) - configure and display network interface parameters
- route(8) - manipulate the routing tables
- ping6(8) - send ICMPv6 ECHO_REQUEST packets to network nodes
- traceroute6(8) - print the route that packets take to reach a network node
net/tcpdump- selectively view traffic on a network interface
- netstat(1) - show network status
- ndp(8) - arp(8) lookalike for IPv6
- ifmcstat(8) - check kernel multicast group configuration
- systat(1) 'systat netstat' - dynamically display network connections
- IPv6 autoconfiguration
- Routing daemons
- IPv6-related pseudo interfaces
The following programs in the base system are known to be IPv6-enabled:
lpd(8) (and friends),
tcpdchk(8) (and friends),
X(7) (X server and libraries)
RPC and NFS now support IPv6.
An increasing number of packages are also ready for IPv6.
If you want IPv6-ready third-party software, you may need to get an IPv6 patch for the software. There are collections of IPv6 patches on the net.