Spelling fixes for share/
This commit is contained in:
Ulrich Spörlein
parent
487ac9ac21
commit
93b03d5dc7
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=228993
@ -1404,7 +1404,7 @@ both definitions. As an userland programmer, the most portable way of
|
||||
dealing with it is to:
|
||||
(1) ensure ss_family and/or ss_len are available on the platform, by using
|
||||
GNU autoconf,
|
||||
(2) have -Dss_family=__ss_family to unify all occurences (including header
|
||||
(2) have -Dss_family=__ss_family to unify all occurrences (including header
|
||||
file) into __ss_family, or
|
||||
(3) never touch __ss_family. cast to sockaddr * and use sa_family like:
|
||||
struct sockaddr_storage ss;
|
||||
@ -1414,7 +1414,7 @@ dealing with it is to:
|
||||
|
||||
Some of IPv6 transition technologies embed IPv4 address into IPv6 address.
|
||||
These specifications themselves are fine, however, there can be certain
|
||||
set of attacks enabled by these specifications. Recent speicifcation
|
||||
set of attacks enabled by these specifications. Recent specification
|
||||
documents covers up those issues, however, there are already-published RFCs
|
||||
that does not have protection against those (like using source address of
|
||||
::ffff:127.0.0.1 to bypass "reject packet from remote" filter).
|
||||
@ -1441,7 +1441,7 @@ compatible is very rare. You should take caution if you see those on the wire.
|
||||
|
||||
If we see IPv6 packets with IPv4 mapped address (::ffff:0.0.0.0/96) in the
|
||||
header in dual-stack environment (not in SIIT environment), they indicate
|
||||
that someone is trying to inpersonate IPv4 peer. The packet should be dropped.
|
||||
that someone is trying to impersonate IPv4 peer. The packet should be dropped.
|
||||
|
||||
IPv6 specifications do not talk very much about IPv6 unspecified address (::)
|
||||
in the IPv6 source address field. Clarification is in progress.
|
||||
@ -1456,10 +1456,10 @@ Here are couple of comments:
|
||||
- The following examples are seemingly illegal. It seems that there's general
|
||||
consensus among ipngwg for those. (1) Mobile IPv6 home address option,
|
||||
(2) offlink packets (so routers should not forward them).
|
||||
KAME implmements (2) already.
|
||||
KAME implements (2) already.
|
||||
|
||||
KAME code is carefully written to avoid such incidents. More specifically,
|
||||
KAME kernel will reject packets with certain source/dstination address in IPv6
|
||||
KAME kernel will reject packets with certain source/destination address in IPv6
|
||||
base header, or IPv6 routing header. Also, KAME default configuration file
|
||||
is written carefully, to avoid those attacks.
|
||||
|
||||
@ -1552,7 +1552,7 @@ KAME implementation treats them as follows:
|
||||
1.17 DNS resolver
|
||||
|
||||
KAME ships with modified DNS resolver, in libinet6.a.
|
||||
libinet6.a has a comple of extensions against libc DNS resolver:
|
||||
libinet6.a has a couple of extensions against libc DNS resolver:
|
||||
- Can take "options insecure1" and "options insecure2" in /etc/resolv.conf,
|
||||
which toggles RES_INSECURE[12] option flag bit.
|
||||
- EDNS0 receive buffer size notification support. It can be enabled by
|
||||
@ -1870,7 +1870,7 @@ Tunnel mode works basically fine, but comes with the following restrictions:
|
||||
- Path MTU discovery does not work across IPv6 IPsec tunnel gateway due to
|
||||
insufficient code.
|
||||
|
||||
AH specificaton does not talk much about "multiple AH on a packet" case.
|
||||
AH specification does not talk much about "multiple AH on a packet" case.
|
||||
We incrementally compute AH checksum, from inside to outside. Also, we
|
||||
treat inner AH to be immutable.
|
||||
For example, if we are to create the following packet:
|
||||
@ -1890,8 +1890,8 @@ to randomly pad packets shorter than N bytes, to random length smaller than
|
||||
or equal to N. Note that N does not include ESP authentication data length.
|
||||
Also note that the random padding is not included in TCP segment
|
||||
size computation. Negative value will turn off the functionality.
|
||||
Recommeded value for N is like 128, or 256. If you use a too big number
|
||||
as N, you may experience inefficiency due to fragmented packtes.
|
||||
Recommended value for N is like 128, or 256. If you use a too big number
|
||||
as N, you may experience inefficiency due to fragmented packets.
|
||||
|
||||
4.4 IPComp handling
|
||||
|
||||
@ -2097,7 +2097,7 @@ RFC2401 defines IPsec tunnel mode, within the context of IPsec. RFC2401
|
||||
defines tunnel mode packet encapsulation/decapsulation on its own, and
|
||||
does not refer other tunnelling specifications. Since RFC2401 advocates
|
||||
filter-based SPD database matches, it would be natural for us to implement
|
||||
IPsec IPsec tunnel mode as filters - not as pseudo interfaces.
|
||||
IPsec tunnel mode as filters - not as pseudo interfaces.
|
||||
|
||||
There are some people who are trying to separate IPsec "tunnel mode" from
|
||||
the IPsec itself. They would like to implement IPsec transport mode only,
|
||||
@ -2110,7 +2110,7 @@ interpretation.
|
||||
|
||||
The KAME stack implements can be configured in two ways. You may need
|
||||
to recompile your kernel to switch the behavior.
|
||||
- RFC2401 IPsec tunnel mode appraoch (4.8.1)
|
||||
- RFC2401 IPsec tunnel mode approach (4.8.1)
|
||||
- draft-touch-ipsec-vpn approach (4.8.2)
|
||||
Works in all kernel configuration, but racoon(8) may not interoperate.
|
||||
|
||||
@ -2226,7 +2226,7 @@ ALTQ occupies single character device number. For FreeBSD, it is officially
|
||||
allocated. For OpenBSD and NetBSD, we use the number which is not
|
||||
currently allocated (will eventually get an official number).
|
||||
The character device is enabled for i386 architecture only. To enable and
|
||||
compile ALTQ-ready kernel for other archititectures, take the following steps:
|
||||
compile ALTQ-ready kernel for other architectures, take the following steps:
|
||||
- assume that your architecture is FOOBAA.
|
||||
- modify sys/arch/FOOBAA/FOOBAA/conf.c (or somewhere that defines cdevsw),
|
||||
to include a line for ALTQ. look at sys/arch/i386/i386/conf.c for
|
||||
@ -2243,7 +2243,7 @@ compile ALTQ-ready kernel for other archititectures, take the following steps:
|
||||
6.1 KAME node as correspondent node
|
||||
|
||||
Default installation recognizes home address option (in destination
|
||||
options header). No sub-options are supported. interaction with
|
||||
options header). No sub-options are supported. Interaction with
|
||||
IPsec, and/or 2292bis API, needs further study.
|
||||
|
||||
6.2 KAME node as home agent/mobile node
|
||||
@ -2262,7 +2262,7 @@ are other implementations available:
|
||||
|
||||
The KAME developers basically do not make a bother about coding
|
||||
style. However, there is still some agreement on the style, in order
|
||||
to make the distributed develoment smooth.
|
||||
to make the distributed development smooth.
|
||||
|
||||
- follow *BSD KNF where possible. note: there are multiple KNF standards.
|
||||
- the tab character should be 8 columns wide (tabstops are at 8, 16, 24, ...
|
||||
@ -2291,13 +2291,13 @@ to make the distributed develoment smooth.
|
||||
where "(dollar)" is the dollar character ($), and around "$" are tabs.
|
||||
(this is for C. For other language, you should use its own comment
|
||||
line.)
|
||||
Once commited to the CVS repository, this line will contain its
|
||||
Once committed to the CVS repository, this line will contain its
|
||||
version number (see, for example, at the top of this file). This
|
||||
would make it easy to report a bug.
|
||||
- when creating a new file with the WIDE copyright, tap "make copyright.c" at
|
||||
the top-level, and use copyright.c as a template. KAME RCS tag will be
|
||||
included automatically.
|
||||
- when editting a third-party package, keep its own coding style as
|
||||
- when editing a third-party package, keep its own coding style as
|
||||
much as possible, even if the style does not follow the items above.
|
||||
- it is recommended to always wrap an expression containing
|
||||
bitwise operators by parentheses, especially when the expression is
|
||||
@ -2384,7 +2384,7 @@ is free of IPR infringement, you MUST check it if you are to integrate
|
||||
KAME into your product (or whatever):
|
||||
READ CAREFULLY: Several countries have legal enforcement for
|
||||
export/import/use of cryptographic software. Check it before playing
|
||||
with the kit. We do not intend to be your legalease clearing house
|
||||
with the kit. We do not intend to be your legalese clearing house
|
||||
(NO WARRANTY). If you intend to include KAME stack into your product,
|
||||
you'll need to check if the licenses on each file fit your situations,
|
||||
and/or possible intellectual property right issues.
|
||||
|
||||
@ -4409,11 +4409,11 @@ yterm10|yterm 1.0 UCB ascii.kbd:\
|
||||
:ku=^K:kd=^J:kl=^H:kr=^L:kh=^^:ma=^Hh\012j^Kk^Ll^^H:\
|
||||
:k0=\E0:k1=\E1:k2=\E2:k3=\E3:k4=\E4:k5=\E5:k6=\E6:k7=\E7:k8=\E8:k9=\E9:\
|
||||
:vs=^O\E[7i\E[m\E[?7h\E[?3g\r\EHY0 \EH \EH \EH \EH \EH \EH \EH \EH \EH\r:
|
||||
# YTERM varient version 1.1. (gts 9-13-84) Version 1.1 has :xn:.
|
||||
# YTERM variant version 1.1. (gts 9-13-84) Version 1.1 has :xn:.
|
||||
yterm11|yterm 1.1 UCB ascii.kbd:\
|
||||
:xn:is=^O\E[7i\E[m\E[?7h\E[?3g\r\EHY1 for \EHYTERM 1.\EH1 with A\EHSCII.KBD\EH 9-13-84\EH \EH \EH \EH \EH\n:\
|
||||
:tc=yterm10:
|
||||
# YTERM 1.0 varient no autowrap or tabs
|
||||
# YTERM 1.0 variant no autowrap or tabs
|
||||
# X does not remember autowrap or tabs when T is deleted and restarted.
|
||||
yterm10nat|yterm 1.0 UCB ascii.kbd no autowrap or tabs:\
|
||||
:am@:pt@:vs=^O\E[7i\E[m\E[?7l\E[?3g\rY2\r:\
|
||||
@ -4475,7 +4475,7 @@ h19k|h19kermit|heathkit emulation provided by Kermit (no auto margin):\
|
||||
:am@:ta@:pt@:xt:da:db:tc=h19-u:
|
||||
# Amiga termcap by Kent Polk, kent@swrinde.nde.swri.edu (30 May 90)
|
||||
# Added a few more entries, converted caret-type control sequence (^x) entries
|
||||
# to '\0xx' entries since a couple of people mentioned loosing '^x' sequences.
|
||||
# to '\0xx' entries since a couple of people mentioned losing '^x' sequences.
|
||||
#
|
||||
# :as, :ae Support for alternate character sets.
|
||||
# :ve=\E[\040p:vi=\E[\060\040p cursor visible/invisible.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user