Lines Matching +full:assigned +full:- +full:resolution +full:- +full:bits
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
241 Address Resolution, Duplicated Address Detection, and Neighbor
247 is assigned to a network interface, or the network interface is enabled
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
703 assigned to the loopback interface. Also, ::1/128 and ff01::/32 are
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)
782 bits in RA have no special effect to stateful autoconfiguration procedure
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
807 automatically assigned to the gif interface.
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
1057 address is assigned to the interface, in_mrejoin() must be called.
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 --- ---
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
1147 it does not handle scoped IPv6 addresses at all. For IPv6 name resolution
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
1436 include, but may not be limited to, (1) MLD while no IPv6 address is assigned
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
1463 The following items are automatically assigned to the node (or the node will
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.
1524 Even if we see packets with "strict" bit set, those bits will not be made
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 --- ---
2010 RFC2401 copy all TOS bits drop TOS bits on outer
2011 from inner to outer. (use inner TOS bits as is)
2013 ECN forbidden copy TOS bits except for ECN drop TOS bits on outer
2014 (masked with 0xfc) from inner (use inner TOS bits as is)
2015 to outer. set ECN bits to 0.
2017 ECN allowed copy TOS bits except for ECN use inner TOS bits with some
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
2118 (those who check TOS bits, for example)
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.