FAQ

KAME FAQ
$KAME: FAQ,v 1.84 2005/07/21 11:03:20 keiichi Exp $


GENERAL
=======
Q: What is the KAME project?
	The KAME Project is a joint effort to create single solid software set,
	especially targeted at IPv6/IPsec.  Talented researchers from several
	Japanese major companies joined the project.  This joint effort will
	avoid unnecessary duplicated development in the same area, and
	effectively provides a high quality, advanced featured package. 

	The project aims to revamp BSD sys/net* tree, and:

	- to provide a FREE IPv6 protocol stack for research/commercial use.
	  (under BSD copyright)
	- to provide FREE IPsec to all over the world. (For free software,
	  crypto export from Japan seems to be legal.)
	- to provide FREE reference code for advanced internetworking.
	    (Advanced packet queuing, ATM, mobility, and whatever interesting.)

	To understand more about the KAME project itself, please proceed to
	http://www.kame.net/project-overview.html.

Q: I'm in trouble and would like to get help.
	Please route your questions to public mailing lists, like
	snap-users@kame.net or users@ipv6.org.  Make sure to include
	all of your configuration details, version numbers and ways to
	repeat your issue, by going through the topmost portion of
	http://www.kame.net/dev/send-pr.html.

Q: How can I contribute?
	- Implement "ports" or "pkgsrc" for IPv6 apps
	  Sometimes nontrivial steps are needed to install IPv6 applications,
	  because IPv6 patches are redistributed separately from the original
	  application.  Please create FreeBSD/OpenBSD "ports", or NetBSD
	  "pkgsrc" and contribute those to *BSD projects.

	- Submit bug reports
	  PLEASE go through the top of http://www.kame.net/dev/send-pr.html
	  and supply enough information.

	- Review documents
	  Since the KAME core team does not have a native English speaker,
	  documents in English include many typos, wording mistakes,
	  and so forth.  We would be very grateful if you review our
	  documents and send us updates.

	- Design a logo/T-shirt :-)

Q: What is the standard document the KAME code is based upon?
Which version of IPv6/IPsec does KAME support?
	The KAME project tries to support the latest specification possible.

	For list of currently-supported standard documents, please refer to
	IMPLEMENTATION in the distribution kit, or
	http://www.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION.

Q: Why does KAME separate ping6 from ping (for IPv4), and traceroute6 from
   traceroute (for IPv4)?
	There have been many discussions on why we separate ping6(8)
	and ping(8).  Some people argued that it would be more
	convenient to uniform the ping command for both IPv4 and
	IPv6.  The followings are an answer to the request.

	From a developer's point of view: since the underlying raw socket API
	is totally different between IPv4 and IPv6, we would end
	up having two types of code base.  There would actually be
	less benefit to unify the two commands into a single
	command from the developer's standpoint.

	From an operator's point of view: unlike ordinary network
	applications like web, mail, and remote login tools, we are
	usually aware of address family when using network management
	tools.  We do not just want to know the reachability to the
	host, but want to know the reachability to the host via a
	particular network protocol such as IPv6.  Thus, even if we
	had a unified ping(8) command for both IPv4 and IPv6, we would
	usually type a -6 or -4 option (or something like those) to
	specify the particular address family.  This essentially means
	that we have two different commands.

Q: Are there other documents/FAQ lists I may want to check?
	- Depending on which BSD you are using, you will want to check the
	  project webpages, like http://www.openbsd.org/,
	  http://www.netbsd.org/, or http://www.freebsd.org/.
	- If you are using a KAME patch kit (like weekly snap, not the
	  integrated *BSD releases), you really need to go through all the
	  documents shipped in tar.gz.
	- http://www.kame.net/ has links to a set of good documents.
	- http://www.ipv6.org/, and http://www.jp.ipv6.org/ (if you can read
	  Japanese texts).
	- http://www.netbsd.org/Documentation/network/ipv6/

Q: Which operating systems/vendor routers use KAME stack?
	Operating systems:
	- OpenBSD, http://www.openbsd.org/
	- NetBSD, http://www.netbsd.org/
	- FreeBSD, http://www.freebsd.org/
	- BSD/OS, http://www.bsdi.com/
	- Apple Darwin

	Vendor routers:
	- Hitachi GR2000, http://www.v6.hitachi.co.jp/GR2000/
	- IIJ SEIL-T1, http://www.seil-t1.com/
	- (more)

Q: How portable is the KAME stack?  Is it possible to port it to embedded
   operating systems like VxWorks?
	KAME stack assumes that the following items are available:
	- mbuf for holding packet data
	- software interrupts to handle incoming packets
	- timer interrupts like timeout(9)
	- spl for concurrency control with interrupting threads
	i.e. we assume 4.4BSD kernel programming environment.  We don't have
	time to port it to VxWorks or any other operating systems, so if you
	want to do it you need to port it on your own.

	We have heard of an Win95/98 port of KAME IPsec stack in the past.
	Also it is apparent that some of the vendor routers are using KAME
	stack on top of VxWorks.

Q: How should "gif" be pronounced?
	To be answered.


INSTALLATION
============
Q: I heard that the *BSDs have integrated KAME code already.
Do I still need to install KAME patches?
	Depends on your goal.  Roughly speaking,
	- If you want IPv6 for normal day-to-day use, you will be happy with
	  *BSD integrated code (no need for KAME patches).
	- If you want a bleeding-edge IPv6 code (including experimental and
	  unstable ones) you'd need to install KAME patches.

	http://www.kame.net/project-overview.html#release talks about this
	topic in more detail.

Q: How/where can I get recent KAME stable (not snap) releases?
	Since the KAME stack has been merged into all *BSD releases
	officially, the KAME project will not release stable releases
	from the project.  These official *BSD releases should be
	considered as stable releases instead.

Q: I replaced the kernel and rebooted, and lost IPv4 connectivity.  Why?
	There are several possibilities, but it is almost always
	due to kernel configuration differences.  If you have
	been using a specific kernel configuration for your IPv4
	kernel, and you have installed a GENERIC.v6 kernel, you lose
	your special configurations.

	One good way to deal with this problem is to, (1) copy
	your original configuration file FOO into FOO.v6, (2)
	incorporate the difference between GENERIC and GENERIC.v6 into
	FOO.v6, (3) carefully look at FOO.v6 and configure a new
	kernel from that one.

Q: Is anything special required for network interface card drivers?
	(freebsd and bsdi) For efficient processing of IPv6 chained headers,
	KAME assumes the network driver will pass the packet to upper layers
	(IPv6 code), in the following form:

	(1) single internal mbuf
	(2) single external (cluster) mbuf
	(3) multiple external (cluster) mbufs

	Some of traditional drivers will pass the packet to upper layers in
	two linked internal mbufs.  In this case, the driver must be modified.
	You can check this situation by using netstat -sn.

	If you see the following line ("two or more mbufs") for your ethernet
	card in netstat output (ip6 section), your driver needs to be modified.

		Mbuf statistics:
			58 one mbufs
			two or more mbuf:
				foo0 = 2	<--- foo0 needs modification
			6486 one ext mbufs
			0 two or more ext mbufs

	The modification is very simple.  You should check the use of MINCLSIZE
	in the driver, change that to MHLEN.  In this way you can avoid two
	linked internal mbufs.

	(all operating systems) Multicast support is required for IPv6,
	since IPv6 uses multicast for hardware address (MAC address) resolution.
	Therefore, your network driver has to have multicast support,
	and have IFF_MULTICAST properly set.  Also be sure to check if
	the driver handles multicast ioctls, like SIOCADDMULTI.

	Even though it is better to have a hardware multicast packet
	filter, it is not mandatory; in most cases it is just fine
	to use promiscuous mode as the last resort, if there's no
	multicast packet filter support.


OPERATION AND PROGRAMMING
=========================
Q: /etc/rc scripts do not work after replacing vanilla *BSD kernel by KAME
kernel.
	/etc/rc scripts usually use tools in /sbin, like /sbin/ifconfig.
	In some cases, they do not work on a KAME kernel.  Be very sure to
	use tools in /usr/local/v6 instead.

	Note, however, depending on the ordering of /etc/rc initialization,
	/usr may not be ready when the network interfaces get initialized
	(for NFS-mounted /usr support).
	It may be safer to put network interface initialization into
	/etc/rc.local, and remove all network configurations from /etc/rc.conf
	and/or /etc/netstart (you won't be able to use diskless configuration,
	however).

Q: Why do link-local addresses in the kernel structure have
s6_addr[2] and s6_addr[3] filled?
	Due to the "scoped address" design in the IPv6 spec, the
	kernel must treat link-local addresses in a special manner.
	Link-local address has to be memorized with the incoming
	interface.  KAME uses s6_addr[2-3] to keep the interface index
	(ifp->if_index) in the kernel structure.

	Note that this is only for internal kernel structures.
	Any data coming out of socket file descriptor is not
	affected.  KAME uses advanced API (rfc2292) for passing/getting
	interface index from/to userland.

	Also note that this hack may go away in the near future,
	by introduction of the sin6_ifindex field in sockaddr_in6
	structure.

	See the IMPLEMENTATION document for a full description.

Q: Does KAME support site-local addresses?
	Yes and no.

	KAME can handle site-local address, but it is not aware of
	the site boundary.  Therefore, KAME cannot become a site-border
	router.

	Site-local addressing (the spec itself, not KAME) has a
	bunch of issues/twists to be solved, such as site-border management
	and name servers.  We are trying very hard to solve them.

	On many of KAME-ready BSD systems, reject routes are installed in
	/etc/rc for fec0::/10 as a precaution.  If you plan to use site-local
	addresses, you first need to remove the route.

Q: How can I implement address-family independent applications?
Q: How can I modify my application to support IPv6 as well as IPv4?
	We have a short newsletter for that, titled "implementing AF-
	independent application".  Please visit
	http://www.kame.net/newsletter/19980604/.

	Craig Metz, "Protocol Independence Using the Sockets API",
	Proceedings of the freenix track: 2000 USENIX annual
	technical conference, June 2000.
	http://www.usenix.org/event/usenix2000/freenix/metzprotocol.html

Q: route6d dies with "IPV6_ADD_MEMBERSHIP" failure.
	This error occurs when you have configured an interface
	that is not capable of handling IPv6 packets.  This includes
	the slip interface (sl0) and some other interfaces.  Please
	remove those interfaces from the kernel configuration file.

Q: Which IPv6 routing daemon should I use?
	For easy installation, route6d (implemented by Akira Kato) is
	simple and easy-to-use, but not very configurable.

	For production use, try zebra from http://www.zebra.org/.

Q: How can I connect my host to the worldwide IPv6 network?
	Visit http://www.6bone.net/, all the information you need is there.

	http://www.kame.net/newsletter/19981224/ has detailed discussions
	on how you can be connected to 6bone.  It also has a cgi script to
	help you send a connection request.

Q: When I invoke ifconfig or netstat, garbled output is generated.
	I suspect that you are invoking old (original) ifconfig or netstat.

	Currently the KAME kit does not overwrite existing userland
	tools.  Instead, tools provided by KAME will be installed
	into /usr/local/v6/bin and alike.  Therefore, to use
	IPv6-enabled tools, you must invoke /usr/local/v6/sbin/ifconfig
	or such.  You can of course add /usr/local/v6/bin to your
	command search path.  Consult the manpage for your shell.

Q: How can I restrict RIPng route announcement for some particular interfaces?
	First of all, you should choose appropriate routing daemon.

	route6d (by Akira Kato) is designed to be simple and easy,
	so it has no configuration option for ignoring some of the
	interfaces.  You cannot use this for the purpose.

	hroute6d (contributed from Hitachi) has a very complex
	configuration file, which makes it possible to skip some
	of the interfaces.

	bgpd (contributed from Toshiba) also uses a configuration
	file.  You can specify not to listen and/or advertise RIPng
	messages on the specified interfaces.

	Other routing daemons (zebra/mrt/whatever) may have
	configuration options, so please refer to the document
	specific to the tool you chosen.

Q: I would like to configure IPsec for IPv4 only, and I do not need IPv6.
Is it possible to configure KAME for this?
	Of course, it should work.  Try configure a kernel without
	"options INET6".

	If it does not work well, add "options INET6" and ignore
	any IPv6 related things appear on messages/command
	options/whatever.  It is safe to ignore those things.

Q: IPv6 ping from other OSes does not seem to work.
	Are you using link-local address for that? (fe80::x) If
	so, be sure to clear the 2nd 16-bit field to 0.  KAME kernels
	use those bits internally, and some older versions of ifconfig show
	the value, but the value MUST NOT appear on the wire.

	If ifconfig command shows that your KAME host has the
	following address:

	fe80:1::x:y:z:u

	the address the host actually has is

	fe80::x:y:z:u

	Also, on many of existing operating systems, it is suggested (or even
	mandatory) to specify the outgoing link, when you try to ping
	(or ping6) link-local addresses.  This is to disambiguate link-local
	addresses on multiple links.

Q: How do I configure a IPv6-over-IPv4 tunnel?
	The simplest way to do this is to configure outer IPv4 address only, by
	the following command:

	hostA# gifconfig gif0 a.a.a.1 b.b.b.1

	hostB# gifconfig gif0 b.b.b.1 a.a.a.1

	As a gif interface has a link-local address, it is not
	necessary to configure inner IPv6 addresses.  Routing
	daemons will work just fine and packets will get forwarded
	between the two routers.  If you want to configure a global IPv6
	address on such a host, configure it to an ethernet interface.

	NOTE: on netbsd and openbsd, gifconfig is integrated into ifconfig(8).

Q: Some of my IPv6-ready programs show strange behavior after kernel update.
	As the IPv6 socket API is still an moving target, the KAME team
	sometimes have to change important structure definitions
	used in the socket API.  We have experienced changes in struct
	sockaddr_in6 several times already.

	If you have installed your IPv6-ready programs before the
	change, and the kernel is built from the KAME tree after
	the change, your programs will not work properly.  Be sure
	to update, or re-compile, userland tools too.

	We try to announce important changes to snap-users mailing
	list.  Please subscribe to snap-users mailing list, if you
	are willing to use SNAP kits.  See http://www.kame.net/snap-users/
	for detail.

Q: How do I configure IPsec?
	http://www.kame.net/newsletter/19980626/ covers the topic.

Q: I would like to connect from an IPv6-only host to an IPv4-only host.
	You MUST have a translator box between those two host, for
	protocol conversion.  http://www.kame.net/newsletter/19981001/
	covers the topic.

	socks64, which is a modified version of socks5, can be used
	so that IPv6-only host can make a proxy connection via a
	"socks64 server" on a dual-stack host.  For implementation
	please visit ftp://ftp.kame.net/pub/kame/misc/.

Q: How can I enable FAITH IPv6-to-IPv4 tcp relay?
	Please consult KAME faithd/README.* for details.

Q: How do I configure ATM PVC?
	KAME includes ATM PVC support, from the ALTQ package.  No SVC support is
	implemented.  A very limited variety of ATM cards are supported.

	http://www.kame.net/newsletter/19980701/ covers this topic
	(though it is a bit dated).

Q: I think I have problem with my tunnel; how do I track it?
	assume that your tunnel interface is "gif0".

	try: ping6 -I gif0 -n ff02::1

	If you get replies from two different nodes, your tunnel is
	working right.  It can be routing problem.  The two nodes
	are your node and the peer's node.

	If you get replies from single node only, you have a problem
	with your tunnel.  It could be a packet filter between your node
	and peer (like a firewall), IPv4 routing screwup, or anything.
	You need to make sure that IPv4 protocol # 41 goes through.
	If you have a packet filter blocking you, ask your network
	administrator to open up the filters.

	Another hint: always use "-n" when you try ping6 or
	traceroute6.  Reverse lookup timeouts can make it harder to track
	down.

Q: My operating system does not have gifconfig(8).
	On FreeBSD 4.4, NetBSD, and OpenBSD, gifconfig(8) is integrated
	into ifconfig(8), using the "tunnel" keyword (older OpenBSD
	releases use "giftunnel" keyword).

Q: I would like to know the merge status of KAME kit to *BSD.
	See http://www.kame.net/dev/cvsweb.cgi/kame/COVERAGE.

Q: How can I differentiate IPv6 http connections from IPv4 ones on my
web page?  (In other words, how can I provide dancing stuff for IPv6
users only, like www.kame.net?)
	If you are using an apache webserver, you can refer to environment
	variable REMOTE_ADDR to know the address of the client (in textual
	numeric representation).  For example, the following perl script
	fragment would print "IPv6 <address>" or "not IPv6 <address>"
	depending on the clients' address.

		if ($ENV{'REMOTE_ADDR'} =~ /^[a-fA-F0-9:]+$/) {
			print "IPv6 " . $ENV{'REMOTE_ADDR'} . "\n";
		} else {
			print "not IPv6 " . $ENV{'REMOTE_ADDR'} . "\n";
		}

Q: Won't you release new IPv6 patch for apache1.3.x?
	We focus on developing/enhancing apache2.x.  Our IPv6 patch
	will never be merged into the apache1.3.x original distribution
	since some include files for mod_xxx highly depend on IPv4
	and our IPv6 patch strongly affects modules from 3rd parties.
	Apache2.x already supports IPv6 and changes its APIs.

	martti.kuparinen@iki.fi takes over the maintenance. Latest
	IPv6 patch are available at ftp://ftp.piuha.net/pub/misc/.

Q: Why don't KAME's getaddrinfo/getnameinfo support PF_LOCAL?
	We do not really like to support PF_LOCAL, unless there's
	clear standard behavior for the AF_LOCAL case.  For an AF
	independent programming point of view, unlink(2) call issue is
	really bitching us.  NI_NUMERICxx, AI_NAMEREQD and
	AI_NUMERICxx has no valid meaning on PF_LOCAL.  Also, we
	cannot just add incompatible functionality from others.  Note
	that glibc now drops it for security risks with /tmp race
	conditions (they supported PF_LOCAL in the past), so we are
	now compatible with glibc at this point.

	getaddrinfo/getnameinfo behavior itself is rather vaguely
	defined in the standards (POSIX drafts as well as RFC2553/bis),
	and we don't want to add more jitter to them.

	Additionally, we've never heard of practical examples of
	applications that need to the support of PF_LOCAL in get*info.
	We don't think it is a good idea just to pursue superficial
	uniformity without concrete usages, especially when we do not
	have a standard specification of it.

	If it is really really necessary to play with it, we can probably
	do that on KAME tree - but not on *BSD-current nor *BSD official
	releases.

Q: Is there an API or other mechanism for a user level program (e.g.
telnet) to inquire of the kernel whether AH/ESP is in use (i.e.
whether a security association exists between the local host and a
remote host)?
	At this moment there's no API to tell if the traffic (packet) was
	encrypted or not, from the kernel to userland.  It is a bit difficult
	API to implement/design, as the granularity is different between IP
	packet and sockets (TCP stream), and it is unclear what to tell the
	userland (per-packet, or per-stream?).

	What you can do now is to use setsockopt(IP_IPSEC_POLICY) and inject
	policy like "in ipsec esp/transport//require" (use ipsec_set_policy(3)
	to convert textual policy representation into binary).  This way, you
	can make sure that inbound packet is always encrypted (non-encrypted
	packets get dropped).  See sbin/ping for usage example.
	This is a KAME-only API.  There's no standard API for this, as
	far as we know.

Q: I see a lot of messages like follows when I try to throw packets to
a gif tunnel interface:
    nd6_output: failed to add route fora neighbor(ADDR), errno=17
	The message gets generated when the kernel fails to create a neighbor
	cache entry for NUD.  The source of the problem is considered
	operational.  You need to change your configuration to solve the
	problem (NOTE: with recent KAME kits, the message won't get generated
	due to a couple of changes we made).

	We are convinced that a tunnel interface has to have the either of
	the following configuration:
		ifconfig gif0 inet6 A B prefixlen 128 alias
		ifconfig gif0 inet6 A prefixlen 64 alias
	NOT the following:
		ifconfig gif0 inet6 A B prefixlen 64 alias
	since the last example is ambiguous when B is within A/64.  The message
	gets generated when you use the last (3rd) configuration, which is
	not correct in our interpretation.

Q: I see a lot of messages like follows:
    nd6_ns_input: invalid hlim(NUM) from FROM to TO on IF
	The message gets generated when someone configures an IPv6 router
	wrongly and neighbor solicitation messages are leaking from the router.
	If you have time, send a note to the owner of the machine indicated
	in FROM.

	The message gets generated only with older KAME SNAP kit, or *BSD
	releases.  Kernel upgrade is suggested if you are using KAME SNAP kit.

Q: I have problem diagnosing IPsec issues.  Are there any good tools?
	tcpdump and netstat -sn are your friend.  Always try to take packet
	dumps during your tests.  Also, you can reveal many things with the
	following operations:
	% netstat -sn >/tmp/1
	% (some operation)
	% netstat -sn >/tmp/2
	% diff -c1 /tmp/1 /tmp/2

Q: When I configure an IPv6 address by ifconfig(8) on a node doing
stateless autoconfiguration, the interface route corresponding to the
configured with ifconfig(8) immediately disappears.
	This is probably because the prefix corresponding to the
	address is regarded as "detached".  Check the output of
	ndp(8).  The entry for the prefix should have a "D" flag like
	this:

	3ffe:501:ffff::/64 if=exp0
	flags=LD vltime=infinity, pltime=infinity, expire=Never, ref=0
	  No advertising router

	The KAME kernel basically does not assume a mixture of
	stateless autoconfiguration and manual configuration of
	addresses, and, in such a case, prefers the autoconfigured
	prefix by marking the manual prefix as "detached."  Even with
	this situation, however, reachability to neighbors covered by
	the prefix should be ensured via a default router that
	advertises an "attached" prefix.

	For the notion of "detached", see Section 3.4 of the following
	paper:
	http://www.isoc.org/inet99/4s/4s_2.htm

Q: Why "ifconfig gif* create/destroy" does not work?
	In KAME kit, we have dropped support for create/destroy interfaces
	in October 8, 2002.  See the following changelog item for the reason.

	Tue Oct  8 17:05:56 JST 2002  itojun@iijlab.net
	* sys/net/if_*.c: drop support for cloning interfaces, to free us from
	  coping with *BSD differences.  it is not our goal to cope with *BSD
	  differences, our goal is to provide high-quality networking code.
	  it's pity that *BSDs have a lot of differences...


LICENSE AND CRYPTO EXPORT
=========================
Q: What is the crypto export/import situation in Japan?
	NOTE: the following description does not reflect intentions
	of KAME participating companies, employers of KAME core
	team or KAME contributors, or such.  The KAME project and other
	parties are completely separate entity.  Please do not
	misinterpret.

	As far as I checked, there's no legal restriction for
	exporting/import crypto software, if it is done without
	fee.

	Japan seems to be in the Wassenaar agreement, and the Wassenaar
	agreement is reflected to the Japan's export/import control
	law.  It says that business parties must acquire approval
	for crypto export orders larger than 50000JPY.

	We checked with several attorneys to get answers which varied
	widely.  The answer reflected how aggressive/defensive the
	attorney is :-)

	See "crypto law survey page",
	http://cwis.kub.nl/~frw/people/koops/cls2.htm#ja, for more
	information. (the page is really great)

Q: Can I download KAME without infringing crypto law?
	The question can be separated into two parts: export from
	Japan and import to your country.

	For export from Japan, it looks that there's no restriction,
	for free software.  See the previous item for more info.

	For import to your country, please check "crypto law survey
	page" for your country.  Please proceed to
	http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm.

Q: Under what kind of license is the KAME kit redistributed?
	The KAME kit itself obeys the following BSD-like AS-IS license.
	Contributed or derived software may be distributed under other licenses,
	so please look at each of the files.

	Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
	All rights reserved.

	Redistribution and use in source and binary forms, with or without
	modification, are permitted provided that the following conditions
	are met:
	1. Redistributions of source code must retain the above copyright
	   notice, this list of conditions and the following disclaimer.
	2. Redistributions in binary form must reproduce the above copyright
	   notice, this list of conditions and the following disclaimer in the
	   documentation and/or other materials provided with the distribution.
	3. Neither the name of the project nor the names of its contributors
	   may be used to endorse or promote products derived from this software
	   without specific prior written permission.

	THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
	ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
	IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
	ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
	FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
	DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
	OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
	HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
	LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
	OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
	SUCH DAMAGE.


FUN STUFF
=========
Q: What is "KAME"?  Why did you choose the name?
	KAME is "turtle" in Japanese.  Then, you may wonder why it is
	"turtle"... :-)  See answers below.

	Official answer #1: Our office was once located at Karigome
	village, Fujisawa, Kanagawa JAPAN.  Take the very first
	two letters and last two letters from KArigoME.  Yea, you
	got KAME.

	Official answer #2: In Asian/Indian mythology, the world
	is on a tray supported by elephants, and the elephants are
	on a giant turtle and a giant snake.  The universe consists
	of the turtle and the snake.  We are trying to shake the
	universe by our code, so the name is KAME.

	Real answer: We got together in IPv6 hacking workshop at
	JAIST university (http://www.jaist.ac.jp/).  One of core
	member, itojun, got very tired of tracking bugs.  There
	was big stuffed turtle (http://www.nui.org/Kame/) in the
	laboratory.  Itojun hugged the turtle and mumbled, "Mr
	turtle please help me debug my code...".
	(http://www.itojun.org/diary/19970930-1005/kame.html) This
	is the real reason for the name.

Q: Official stuffed turtles?
	We have distributed official stuffed turtles at IETFs and other
	events, however, they are out of stock already.  Too bad.  Plat'home
	(www.plathome.co.jp) may still have some, so order them over the web
	(not sure about overseas shipping).

	History: Nakajima corporation (specialized in stuffed animals)
	had a really cute turtle, but they were discontinued.  Some people
	at KAME project and friends have ordered 2400 of them for re-issue.
	The official turtles had a special label on them, which has the
	URL of the KAME project webpage.

Q: T-shirt?  Mugs?
	Sorry, not yet.  We need someone who can draw/design :-)