Lines Matching +full:pre +full:- +full:configurable
9 applicable to KAME-integrated *BSD releases, as we have certain amount
11 KAME-integrated *BSD releases.
23 1.4.1 Assignment of link-local, and special addresses
59 2.1 FreeBSD 2.2.x-RELEASE
62 2.4 FreeBSD 3.x-RELEASE
63 2.5 FreeBSD 4.x-RELEASE
68 3.2 IPv6-to-IPv4 header translator
79 4.8.2 draft-touch-ipsec-vpn approach
94 below (NOTE: this is not a complete list - this is too hard to maintain...).
110 * KAME-supplied route6d, bgpd and hroute6d support this.
111 RFC2283: Multiprotocol Extensions for BGP-4
112 * so-called "BGP4+".
113 * KAME-supplied bgpd supports this.
116 RFC2362: Protocol Independent Multicast-Sparse Mode (PIM-SM)
117 * RFC2362 defines the packet formats and the protcol of PIM-SM.
122 * KAME supports 64-bit length of Interface ID.
124 * Userland applications use the well-known addresses assigned in the RFC.
138 support is provided as patchkit for ucd-snmp.
141 support is provided as patchkit for ucd-snmp.
147 RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
170 * "gif" interface implements IPv[46]-over-IPv[46] tunnel in a generic way,
176 * So-called "6to4".
178 draft-itojun-ipv6-transition-abuse-01.txt
180 RFC3142: An IPv6-to-IPv4 transport relay translator
193 - supported and turned on by default on KAME/FreeBSD[34]
195 - supported but turned off by default on KAME/NetBSD and KAME/FreeBSD5,
196 - not supported on KAME/FreeBSD228, KAME/OpenBSD and KAME/BSDI3.
208 draft-ietf-ipngwg-icmp-name-lookups-09: IPv6 Name Lookups Through ICMP
209 draft-ietf-ipv6-router-selection-07.txt:
210 Default Router Preferences and More-Specific Routes
211 * router-side: both router preference and specific routes are supported.
212 * host-side: only router preference is supported.
213 draft-ietf-pim-sm-v2-new-02.txt
216 draft-ietf-dnsext-mdns-00.txt: Multicast DNS
220 draft-ietf-ipngwg-icmp-v3-02.txt: ICMPv6 for IPv6 specification (revised)
222 draft-itojun-ipv6-tcp-to-anycast-01.txt:
224 draft-ietf-ipv6-rfc2462bis-06.txt: IPv6 Stateless Address
226 draft-itojun-ipv6-transition-abuse-01.txt:
235 draft-itojun-ipv6-flowlabel-api-01.txt: Socket API for IPv6 flow label field
257 duplicate address is a link-local address formed from an interface
259 uniquely assigned (e.g., EUI-64 for an Ethernet interface), IPv6
273 DAD probes to not-really-ready network driver and the packet will not go out
288 RS/NS/NA/redirect packet without link-layer address
289 (2) neighbor cache handling on medium without link-layer address
295 IPv6 on-link determination rule (RFC2461) is quite different from
299 commands like "ndp -I de0" as root. Then the kernel will have a
334 # ndp -s fe80::1234%ne0 0:1:2:3:4:5 proxy
338 - It does not send unsolicited multicast NA on configuration. This is MAY
340 - It does not add random delay before transmission of solicited NA. This is
342 - We cannot configure proxy NDP for off-link address. The target address for
343 proxying must be link-local address, or must be in prefixes configured to
345 - RFC2461 is unclear about if it is legal for a host to perform proxy ND.
353 interoperability issues, you can turn off/on NUD by per-interface
354 basis. Use "ndp -i interface -nud" to turn it off. Consult ndp(8)
357 RFC2461 specifies upper-layer reachability confirmation hint. Whenever
358 upper-layer reachability confirmation hint comes, ND process can use it
359 to optimize neighbor discovery process - ND process can omit real ND exchange
366 process. Neighbor cache is a system-wide information pool, and it is
372 incorrect upper-layer reachability confirmation. The ND code counts
373 subsequent upper-layer hints. If the number of hints reaches the
374 maximum, the ND code will ignore further upper-layer hints and run
377 upper-layer hints to be accepted.
379 non-root process - after a local discussion, it looks that hints are not
384 "netstat -sn", icmp6 section. For detailed debugging session, you can
389 only be used for test/debug purposes - for a production environment,
396 specify the scope zone index (link index for a link-local address, or
397 site index for a site-local address) with an IPv6 address. Without a
404 One non-trivial point of the architecture is that the link scope is
407 normal operation, we can assume that there is 1-to-1 relationship
410 implementation assumes the 1-to-1 relationship. In particular, we use
412 be much more human-readable and intuitive than numeric identifiers,
416 Site-local addresses are very vaguely defined in the specs, and both
423 you to use global addresses for experiments - there are way too many
424 pitfalls if you use site-local addresses.
428 In the kernel, the link index for a link-local scope address is
429 embedded into the 2nd 16bit-word (the 3rd and 4th bytes) in the IPv6
434 in6_ifaddr). The address above is a link-local unicast address which
438 link-local addresses over multiple links effectively and with only a
453 - int sa6_embedscope(struct sockaddr_in6 *sa6, int defaultok);
454 Embed sa6->sin6_scope_id into sa6->sin6_addr. If sin6_scope_id is
455 0, defaultok is non-0, and the default zone ID (see RFC4007) is
457 sin6_scope_id field. On success, sa6->sin6_scope_id will be reset
460 This function returns 0 on success, or a non-0 error code otherwise.
462 - int sa6_recoverscope(struct sockaddr_in6 *sa6);
463 Extract embedded zone ID in sa6->sin6_addr and set
464 sa6->sin6_scope_id to that ID. The embedded ID will be cleared with
467 This function returns 0 on success, or a non-0 error code otherwise.
469 - int in6_clearscope(struct in6_addr *in6);
477 - int in6_setscope(struct in6_addr *in6, struct ifnet *ifp,
483 This function returns 0 on success, or a non-0 error code otherwise.
489 kernel-internal form. In this usage, the second argument is often the
506 will be NULL. A non-NULL value will be used when the validity of the
513 application with getaddrinfo() and the extended textual format - see
527 in6_setscope(&dst->sin6_addr, ifp, NULL);
530 zone ID) into the kernel-internal form. This can fail with an
536 the interface, and construct the kernel-internal form. See, for
545 if (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr))
546 sin6->sin6_addr.s6_addr16[1] = htons(ifp->if_index);
549 specific to link-local addresses (any non-global multicast addresses
551 interface-local addresses). Secondly, this is vulnerable to future
559 in6_setscope(&sin6->sin6_addr, ifp, NULL);
577 multi-sited node and suppose that more than one interface of the node
587 structure that has a non-zero sin6_scope_id value to the sendto(2)
601 - If your target system is limited to KAME based ones (i.e. BSD
604 - Otherwise, (i.e. if your program should be portable on other systems
611 should only consider link-local addresses and your system
612 assumes 1-to-1 relationship between links and interfaces.
620 will return IPv6 addresses with the 2nd 16bit-word filled in. The
628 "fe80::1%ne0" (again, note that we assume there is 1-to-1 relationship
630 link-local scoped address without much trouble.
641 notice, but please recall again that we assume 1-to-1 relationship
645 # route add -inet6 default fe80::9876:5432:1234:abcd%ne0
650 appropriate zone of a scoped address (like "ping6 -I ne0 ff02::1" to
673 1.4.1 Assignment of link-local, and special addresses
675 IPv6 link-local address is generated from IEEE802 address (ethernet MAC
676 address). Each of interface is assigned an IPv6 link-local address
678 for the link-local address is added to routing table.
690 If there is no IEEE802 hardware attached, last-resort pseudorandom value,
691 which is from MD5(hostname), will be used as source of link-local address.
693 link-local address manually.
696 support), link-local address will not be assigned to that interface.
700 link-local all-nodes multicast addresses (e.g. fe80::1:ff01:6317
702 In addition to a link-local address, the loopback address (::1) will be
705 node-local multicast group ff01::1.
725 variable and a per-interface flag managed in the kernel. The latter,
741 per-interface basis.
747 - Only hosts will listen to router advertisements
748 - Hosts have a single network interface (except loopback)
750 or multi-interface hosts. A misconfigured node can behave strange
756 --- --- ---
763 out-of-scope)
765 (out-of-scope of spec)
802 gif can be configured to be ECN-friendly. See 4.5 for ECN-friendliness
805 If you would like to configure an IPv4-in-IPv6 tunnel with gif interface,
806 read gif(4) carefully. You may need to remove IPv6 link-local address
830 kernel does not have pre-installed policy. It is expected that the
834 This draft allows an implementation to add implementation-specific
839 - prefer addresses on alive interfaces, that is, interfaces with
844 - prefer addresses on "preferred" interfaces. "Preferred"
875 the privacy, there is a system-wide sysctl(3) variable
877 non-zero, the kernel will rather prefer temporary addresses. The
892 KAME supports the Jumbo Payload hop-by-hop option used to send IPv6
904 Then you can test jumbo payloads by the ping6 command with -b and -s
905 options. The -b option must be specified to enlarge the size of the
906 socket buffer and the -s option specifies the length of the packet,
908 % ping6 -b 70000 -s 68000 ::1
921 statistics as output of netstat command with `-s -p ip6' option:
922 % netstat -s -p ip6
944 - mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it cannot hold
947 IPv6 header + link-layer header. Therefore, it must be expanded to at least
949 - We mistakingly use "int" to hold packet length in many places. We need
952 - We mistakingly check for ip6_plen field of IPv6 header for packet payload
956 - TCP code needs careful updates in bunch of places, of course.
977 Because of this, if you receive IPsec-over-IPv4 packet with massive
978 number of IPsec headers, kernel stack may blow up. IPsec-over-IPv6 is okay.
987 node, to avoid possible DoS attacks. KAME kernel implements two rate-
989 - Minimum time interval between ICMPv6 error packets
993 - Maximum ICMPv6 error packet-per-second
996 maximum packet-per-second value (default: 200pps)
1036 internal mbufs for 100 - 208 bytes data, however, KAME's reference
1039 "netstat -s -p ip6" tells you whether or not your driver conforms
1058 KAME's interfaces, however, have ALWAYS one link-local unicast
1065 - Accept IPv4 connections by AF_INET6 wildcard bind socket.
1066 - Transmit IPv4 packet over AF_INET6 socket by using special form of
1077 There are some OS-platform differences in KAME code, as we use tcp/udp
1083 --- ---
1086 KAME/FreeBSD3x configurable supported
1088 KAME/FreeBSD4x configurable supported
1090 KAME/NetBSD configurable supported
1121 kernel sometimes violate this - we will fix it).
1135 - NEVER hardcode AF_INET nor AF_INET6.
1136 - Use getaddrinfo() and getnameinfo() throughout the system.
1138 - If you would like to connect to destination, use getaddrinfo() and try
1140 - Some of the IPv6 stack is shipped with buggy getaddrinfo(). Ship a minimal
1177 (per-node), or setsockopt (per-socket).
1181 - there's no AF_INET socket that matches the IPv4 connection
1182 - the AF_INET6 socket is configured to accept IPv4 traffic, i.e.
1209 - default: special support code will be compiled in, but is disabled by
1212 - add "INET6_BINDV6ONLY": No special support code for AF_INET6 wildcard socket
1216 sysctl setting will affect per-socket configuration at in6pcb creation time
1217 only. In other words, per-socket configuration will be copied from sysctl
1218 configuration at in6pcb creation time. To change per-socket behavior, you
1226 - there's no AF_INET socket that matches the IPv4 connection
1227 - the AF_INET6 socket is configured to accept IPv4 traffic, i.e.
1244 KAME/BSDI4 uses NRL-based TCP/UDP stack and inpcb source code,
1256 - there's no AF_INET socket that matches the IPv4 connection
1265 KAME/OpenBSD uses NRL-based TCP/UDP stack and inpcb source code,
1275 access control will become much harder). KAME/BSDI4 uses NRL-based TCP/UDP
1293 - Access controls code becomes harder to write.
1297 - If a protocol on top of IPv4 is defined differently with IPv6, we need to be
1319 - By enabling kernel support for IPv4 mapped address (outgoing direction),
1322 draft-itojun-ipv6-transition-abuse-01.txt, draft-cmetz-v6ops-v4mapped-api-
1323 harmful-00.txt, and draft-itojun-v6ops-v4mapped-harmful-01.txt
1328 - rshd/rlogind do not accept connections from IPv4 mapped address.
1330 packet, to bypass source-address based authentication.
1331 - ftp/ftpd assume that you are on dual stack network. IPv4 mapped address
1344 (1) SIIT translators require end nodes in the SIIT cloud to be IPv6-only.
1345 Since we are unable to compile INET-less kernel, we are unable to become
1348 mapped address in the header, to secure non-SIIT case (which is much more
1352 There are documentation issues too - SIIT document requires very strange
1353 things. For example, SIIT document asks IPv6-only (meaning no IPv4 code)
1355 construct IPv4 IPsec headers, that is not an IPv6-only node, it is a dual-stack
1392 (2) have -Dss_family=__ss_family to unify all occurrences (including header
1396 family = ((struct sockaddr *)&ss)->sa_family
1403 documents covers up those issues, however, there are already-published RFCs
1409 - IPv4 mapped address that embeds unspecified/multicast/loopback/broadcast
1413 - 6to4 (RFC3056) prefix generated from unspecified/multicast/loopback/
1418 - IPv4 compatible address that embeds unspecified/multicast/loopback/broadcast
1428 header in dual-stack environment (not in SIIT environment), they indicate
1434 - IPv6 unspecified address can be used in IPv6 source address field, if and
1438 - If IPv6 TCP packet has IPv6 unspecified address, it is an attack attempt.
1441 - The following examples are seemingly illegal. It seems that there's general
1451 draft-itojun-ipv6-transition-abuse-01.txt, draft-cmetz-v6ops-v4mapped-api-
1452 harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt has more on
1465 - Loopback address
1466 - All-nodes multicast addresses (ff01::1)
1470 - Its link-local address for each interface
1471 - Solicited-node multicast address for link-local addresses
1472 - Link-local allnodes multicast address (ff02::1)
1477 - Assigned unicast/anycast addresses
1478 - Solicited-Node multicast address for assigned unicast address
1487 o The subnet-router anycast addresses for the interfaces it is configured
1493 o All-Routers Multicast Addresses (ff02::2)
1503 for backward compatibility purposes with *BSD-integrated codebase.
1505 *BSD-integrated codebase implements either RFC2292, or RFC3542, API.
1509 - *BSD-integrated binaries, compiled for RFC2292, will work on KAME kernel.
1511 - KAME binaries, compiled using RFC3542, will not work on *BSD-integrated
1514 - RFC3542 API is not compatible with RFC2292 API. RFC3542 #define symbols
1519 RFC2292-based code on Solaris 8, the binary can behave strange.
1523 - Type 0 routing header lacks support for strict/loose bitmap.
1533 - The IPV6_DONTFRAG and IPV6_RECVPATHMTU socket options for TCP
1541 - Can take "options insecure1" and "options insecure2" in /etc/resolv.conf,
1543 - EDNS0 receive buffer size notification support. It can be enabled by
1545 - IPv6 transport support (queries/responses over IPv6). Most of BSD official
1547 - Partial A6 chain chasing/DNAME/bit string label support (KAME/BSDI4).
1572 2.1 FreeBSD 2.2.x-RELEASE
1574 Here is a list of FreeBSD 2.2.x-RELEASE drivers and its conditions:
1577 --- --- --- ---
1579 ar looks ok - -
1584 sn looks ok - - (*)
1585 vx looks ok - -
1586 wlp ok ok - (*)
1588 zp ok ok -
1590 fpa looks ok ? -
1594 lp ? - not work
1595 sl ? - not work
1596 sr looks ok ok - (**)
1604 then up, the kernel may hang up. We have disabled frame-relay support from
1606 frame-relay support to come back, please contact KAME developers.
1613 --- --- --- ---
1616 de ok ok -
1617 df ok ok -
1618 eb ok ok -
1620 exp ok ok -
1623 we ok ok -
1625 fpa ok ok -
1627 en maybe ok -
1630 sl ? - not work
1631 appp ? - not work
1641 --- --- --- ---
1643 awi pcmcia/i386 ok ok -
1646 ep pcmcia/i386 ok ok -
1647 fxp pci/i386 ok(*2) ok -
1648 tlp pci/i386 ok ok -
1652 rtk pci/i386 ok ok -
1655 en pci/i386 ok ok -
1659 2.4 FreeBSD 3.x-RELEASE
1661 Here is a list of FreeBSD 3.x-RELEASE drivers and its conditions:
1664 --- --- --- ---
1666 cnw ok ok -(*)
1667 ed ? ok -
1668 ep ok ok -
1671 lnc ? ok -
1672 sn ? ? -(*)
1674 xl ? ok -
1680 More drivers will just simply work on KAME FreeBSD 3.x-RELEASE but have not
1683 2.5 FreeBSD 4.x-RELEASE
1685 Here is a list of FreeBSD 4.x-RELEASE drivers and its conditions:
1688 --- ---
1697 --- --- --- ---
1715 --- --- --- ---
1731 Translator A --- It is used in the early stage of transition to make
1735 Translator B --- It is used in the early stage of transition to make
1739 Translator C --- It is used in the late stage of transition to make it
1743 Translator D --- It is used in the late stage of transition to make it
1763 FAITH-relay dual stack node
1768 faithd must be invoked on FAITH-relay dual stack node.
1772 3.2 IPv6-to-IPv4 header translator
1786 as OpenBSD team has their home-brew IPsec stack and they have no plan
1795 to manage security policy. One is to configure per-socket policy using
1797 ipsec_set_policy(3). The other is to configure kernel packet filter-based
1806 home-brew PFKEY v2 implementation. This conforms to RFC2367.
1808 The home-brew IKE daemon, "racoon" is included in the kit (kame/kame/racoon,
1811 to require keys (like ping -P 'out ipsec esp/transport//use').
1837 and strips off daisy-chained header and padding for ESP/AH. It is
1842 extra daisy-chained headers inserted by ESP/AH. Our code takes care of
1851 - You cannot run routing daemon across IPsec tunnel, since we do not model
1853 - Authentication model for AH tunnel must be revisited. We'll need to
1855 - Path MTU discovery does not work across IPv6 IPsec tunnel gateway due to
1891 - IPComp is treated as part of IPsec protocol suite, and SPI and
1894 - IPComp association (IPCA) is kept in SAD.
1895 - It is possible to use well-known CPI (CPI=2 for DEFLATE for example),
1898 - pfkey is modified to support IPComp. However, there's no official
1901 - Spec says that IPComp output processing must be performed before AH/ESP
1909 - Though the packet size can be significantly decreased by using IPComp, no
1911 consideration). IPComp is designed for serial links, not ethernet-like
1913 - You can change compression ratio on outbound packet, by changing
1916 (should it be sysctl accessible, or per-SAD configurable?)
1917 - Tunnel mode IPComp is not working right. KAME box can generate tunnelled
1919 - You can negotiate IPComp association with racoon IKE daemon.
1920 - KAME code does not attach Adler32 checksum to compressed data.
1927 "old IPsec" specification documented in rfc182[5-9].txt
1929 rfc240[1-6].txt rfc241[01].txt rfc2451.txt rfc3602.txt
1932 IKE specifications (rfc240[7-9].txt) are implemented in userland
1945 DES-CBC mode (rfc1829.txt)
1952 HMAC SHA2-256 with 96bit crypto checksum (draft-ietf-ipsec-ciph-sha-256-00.txt)
1953 HMAC SHA2-384 with 96bit crypto checksum (no document)
1954 HMAC SHA2-512 with 96bit crypto checksum (no document)
1959 DES-CBC with derived IV
1960 (draft-ietf-ipsec-ciph-des-derived-01.txt, draft expired)
1961 DES-CBC with explicit IV (rfc2405.txt)
1962 3DES-CBC with explicit IV (rfc2451.txt)
1985 KAME IPsec implements ECN-friendly IPsec tunnel, described in
1986 draft-ietf-ipsec-ecn-02.txt.
1993 To make IPsec tunnel ECN-friendly, we should modify encapsulation
1995 draft-ietf-ipsec-ecn-02.txt, chapter 3.3.
1999 - RFC2401: no consideration for ECN (sysctl value -1)
2000 - ECN forbidden (sysctl value 0)
2001 - ECN allowed (sysctl value 1)
2002 Note that the behavior is configurable in per-node manner, not per-SA manner
2003 (draft-ietf-ipsec-ecn-02 wants per-SA configuration, but it looks too much
2009 --- ---
2023 - if both IPsec tunnel endpoint are capable of ECN-friendly behavior,
2025 - if the other end is very strict about TOS bit, use "RFC2401"
2026 (sysctl value -1).
2027 - in other cases, use "ECN forbidden" (sysctl value 0).
2031 draft-ietf-ipsec-ecn-02.txt
2049 6WIND, ACC, Allied-telesis, Altiga, Ashley-laurent (vpcom.com),
2050 BlueSteel, CISCO IOS, Checkpoint FW-1, Compaq Tru54 UNIX
2051 X5.1B-BL4, Cryptek, Data Fellows (F-Secure), Ericsson,
2052 F-Secure VPN+ 5.40, Fitec, Fitel, FreeS/WAN, HITACHI, HiFn,
2068 Compaq, IRE, SSH, NetLock, FreeS/WAN, F-Secure VPN+ 5.40
2084 filter-based SPD database matches, it would be natural for us to implement
2085 IPsec tunnel mode as filters - not as pseudo interfaces.
2090 in draft-touch-ipsec-vpn-01.txt. However, if you really define pseudo
2093 really mix RFC2401-based interpretation and draft-touch-ipsec-vpn-01.txt
2098 - RFC2401 IPsec tunnel mode approach (4.8.1)
2099 - draft-touch-ipsec-vpn approach (4.8.2)
2104 RFC2401 IPsec tunnel mode (filter-like) approach
2110 draft-touch-ipsec-vpn (transportmode + Pseudo-interface) approach
2119 CON: cannot negotiate IKE with other IPsec tunnel-mode devices
2125 - use draft-touch-ipsec-vpn if you have the control over the other end.
2127 - if the other end is normal IPsec device with RFC2401 implementation,
2129 - use RFC2401 approach if you just want to forward packets back and forth
2148 # setkey -c <<EOF
2149 spdadd A B any -P out ipsec esp/tunnel/C-D/use;
2150 spdadd B A any -P in ipsec esp/tunnel/D-C/use;
2158 - When you originate traffic from your VPN gateway device to VPN net on the
2165 IP[C -> B] payload
2167 - When you want to run routing protocols on top of the IPsec tunnel, it is
2172 4.8.2 draft-touch-ipsec-vpn approach
2179 # setkey -c <<EOF
2180 spdadd C D any -P out ipsec esp/transport//use;
2181 spdadd D C any -P in ipsec esp/transport//use;
2184 Since we have a pseudo-interface "gif0", and it affects the routes and
2192 the other end is using draft-touch-ipsec-vpn approach too. Since racoon(8)
2194 negotiating IPsec transport-mode SAs with the other end, not tunnel-mode SAs.
2196 be able to interoperate with a picky RFC2401 implementations - if the other
2208 (actually, ALTQ is developed on KAME repository since ALTQ 2.1 - Jan 2000)
2214 compile ALTQ-ready kernel for other architectures, take the following steps:
2215 - assume that your architecture is FOOBAA.
2216 - modify sys/arch/FOOBAA/FOOBAA/conf.c (or somewhere that defines cdevsw),
2219 - copy kernel configuration file (like ALTQ.v6 or GENERIC.v6) from i386,
2221 - build a kernel.
2222 - before building userland, change netbsd/{lib,usr.sbin,usr.bin}/Makefile
2223 (or openbsd/foobaa) so that it will visit altq-related sub directories.
2231 options header). No sub-options are supported. Interaction with
2236 KAME kit includes Ericsson mobile-ip6 code. The integration is just started
2241 The Ericsson code implements revision 09 of the mobile-ip6 draft. There
2243 NEC: http://www.6bone.nec.co.jp/mipv6/internal-dist/ (-13 draft)
2244 SFC: http://neo.sfc.wide.ad.jp/~mip6/ (-13 draft)
2252 - follow *BSD KNF where possible. note: there are multiple KNF standards.
2253 - the tab character should be 8 columns wide (tabstops are at 8, 16, 24, ...
2256 cc-mode with the variable "c-basic-offset" being 8;
2257 (add-hook 'c-mode-common-hook
2260 (c-set-style "bsd")
2261 (setq c-basic-offset 8) ; XXX for Emacs 20 only
2266 - each line should be within 80 characters.
2267 - keep a single open/close bracket in a comment such as in the following
2274 - add the following line to the head of every KAME-derived file:
2282 - when creating a new file with the WIDE copyright, tap "make copyright.c" at
2283 the top-level, and use copyright.c as a template. KAME RCS tag will be
2285 - when editing a third-party package, keep its own coding style as
2287 - it is recommended to always wrap an expression containing
2298 Thus, we should write a code to test if a bit-flag is set for a
2311 - When inserting a separate block just to define some intra-block
2313 control statement such as if-else, for, or while. For example,
2333 - Do not use printf() or log() in the packet input path of the kernel code.
2336 - (not a style issue)
2355 The goal of KAME is to provide freely redistributable, BSD-licensed,
2358 contract with IPR holder, and (2) are royalty-free.
2364 By doing so KAME is (implicitly) trying to advocate no-license-contract,
2365 royalty-free, release of IPRs.