forked from kame/kame
-
Notifications
You must be signed in to change notification settings - Fork 0
/
FAQ
672 lines (541 loc) · 28 KB
/
FAQ
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
KAME FAQ
$KAME: FAQ,v 1.88 2007/05/13 15:06:43 itojun 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
[email protected] or [email protected]. 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.
[email protected] 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 [email protected]
* 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://rechten.uvt.nl/koops/cryptolaw/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://rechten.uvt.nl/koops/cryptolaw/index.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. Yeah, 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?
Finally, there are! See http://www.kame.net/ for more details!
If you need more variety of goods (like mugs, teddybear or whatever)
just drop snap-users@kame a note.