Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tag: racoon_s200401…
Fetching contributors…

Cannot retrieve contributors at this time

file 675 lines (543 sloc) 28.794 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675
$KAME: FAQ,v 1.80 2003/02/07 10:41:08 sumikawa Exp $

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

Q: I'm in trouble and would like to get help.
Please route your questions to public mailing lists, like or Make sure to include
all of your configuration details, version numbers and ways to
repeat your issue, by going through the topmost portion of

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
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

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,, or
- 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.
- has links to a set of good documents.
-, and (if you can read
Japanese texts).

Q: Which operating systems/vendor routers use KAME stack?
Operating systems:
- OpenBSD,
- NetBSD,
- FreeBSD,
- Apple Darwin

Vendor routers:
- Hitachi GR2000,
- (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.

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. 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 operationg 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.

Q: /etc/rc scripts do not work after replacing vanilla *BSD kernel by KAME
/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,

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

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

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

Craig Metz, "Protocol Independence Using the Sockets API",
Proceedings of the freenix track: 2000 USENIX annual
technical conference, June 2000.

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

Q: How can I connect my host to the worldwide IPv6 network?
Visit, all the information you need is there. 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:


the address the host actually has is


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
for detail.

Q: How do I configure IPsec? 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.
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

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. 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

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.

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
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 are focused to develop/enhance apache2.x. Our IPv6 patch never be
merged into apache1.3.x original distribution since some include
files for mod_xxx are highly depend on IPv4 so our IPv6 patch
is strongly influence 3rd party's modules. Apache2.x already
supports IPv6 and changes its APIs. takes over the maintainance. Latest
IPv6 patch are available at

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

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, AFAIK.

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 dianosing 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: How can I configure NAT-PT?
Natptconfig is a command for configuration of KAME NAT-PT.
The manual for the command is natptconfig(8), and the manual
for the configuration file is natpt.conf(5).
kame/kame/natptconfig/natpt.conf is a simple configuration sample.

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

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

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
* 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...

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

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

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",, 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

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.


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 ( One of core
member, itojun, got very tired of tracking bugs. There
was big stuffed turtle ( in the
laboratory. Itojun hugged the turtle and mumbled, "Mr
turtle please help me debug my code...".
( 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
( 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 :-)
Something went wrong with that request. Please try again.