TODO: udp6, and sendto consideration. as pmtud is mandatory for IPv6,
it is rather important for us to support those cases.
TODO: more testing
TODO: kame sync
entering rtentry's for hosts we're not actually communicating
with.
Do this by invoking the ctlinput for the protocol, which is
responsible for validating the ICMP message:
* TCP -- Lookup the connection based on the address/port
pairs in the ICMP message.
* AH/ESP -- Lookup the SA based on the SPI in the ICMP message.
If validation succeeds, ctlinput is responsible for calling
icmp_mtudisc(). icmp_mtudisc() then invokes callbacks registered
by protocols (such as TCP) which want to take some sort of special
action when a path's MTU changes. For TCP, this is where we now
refresh cached routes and re-enter slow-start.
As a side-effect, this fixes the problem where TCP would not be
notified when a path's MTU changed if AH/ESP were being used.
XXX Note, this is only a fix for the IPv4 case. For the IPv6
XXX case, we need to wait for the KAME folks.
Reviewed by sommerfeld@netbsd.org and itojun@netbsd.org.
if there's no rnd(4), random(9) will be used with one-time warning printf(9).
XXX not sure how good rnd_extract_data(RND_EXTRACT_ANY) is, under entropy-
starvation situation
- use of IPv4 mapped address on outbound socket
- explicit port numbers via sendto().
old code grabbed port number from inpcb/in6pcb.
in the above case, old code failed to lookup ipsec policy (oops).
sync with kame.
- correct byte lifetime computation to conform to RFC2401 p23 (use
packet BEFORE compression)
- stabilize deflate calls
- present error messages better
> in the check for the incoming redirect message, examine the gateway
> (from the routing table) only when the address family of the gateway is
> AF_INET6.
cbc-over-mbuf functions in sys/crypto.
the change should make it much easier to switch crypto function to
machine-dependent ones (like assembly code under sys/arch/i386/crypto?).
also it should be much easier to import AES algorithms.
XXX: it looks that past blowfish-cbc code was buggy. i ran some test pattern,
and new blowfish-cbc code looks more correct. there's no interoperability
between the old code (before the commit) and the new code (after the commit).
XXX: need serious interop tests before move it into 1.5 branch
- manually configure an address from prefix P (like P::1)
- autoconfigure additional address from the same prefix P (like P::ifid).
- rtrequest fails due to P/plen already exists
more fundamental solution should appear later, when kame side stablizes it.
from thopej.
multiple addresses from same prefix, onto single interface. PR 10427.
more info:
- 4.4BSD did not check return code from in_ifinit() at all.
4.4BSD does not support multiple address from same prefix.
- past KAME change passed in{,6}_ifinit() to upwards, toward ifconfig(8).
the behavior is filed as PR 10427.
- the commit inhibits EEXIST from rtinit(), hence partially recovers old
4.4BSD behavior.
- the right thing to happen is to properly support multiple address assignment
from the same prefix. KAME tree has more extensive change, however, it needs
much more time to get stabilized (rtentry refcnt change can cause serious
issue, we really need to bake it before bring it to netbsd)
sync with kame.
loopback, blowfish-cbc transport mode, 128bit key
before: 86588496 bytes received in 00:42 (1.94 MB/s)
after: 86588496 bytes received in 00:31 (2.58 MB/s)
address/routing table too much).
in6_ifloop_request()
not to request rtrequest to return an rtentry except for the ADD
operation, in order to avoid misdecreasing the refcnt (which might
cause leak of rtentry)
- add protection mechanism against ND cache corruption due to bad NUD hints.
- more stats
- icmp6 pps limitation. TOOD: should implement ppsratecheck(9).
to mention here. notable changes are like below.
kernel:
- make PF_KEY kernel interface more robust against broken input stream.
it includes complete internal structure change in sys/netkey/key.c.
- remove non-RFC compliant change in PF_KEY API, in particular,
in struct sadb_msg. we cannot just change these standard structs.
sadb_x_sa2 is introduced instead.
- remove prototypes for pfkey_xx functions from /usr/include/net/pfkeyv2.h.
these functions are not supplied in /usr/lib.
setkey(8):
- get/delete does not require "-m mode" (ignored with warning, if you
specify it)
- spddelete takes direction specification
correct interface address addition when link-local is added (check if ifp
matches).
make diff to kame repository easier (breaks some KNF)
sync with kame.
avoid use of macros to manipulate sockaddrs (hides error case too much).
correct IPv4 packet handling when ip option is present.
preparations for ipsec policy engine upgrades.
- use latest source address selection code - in6_src.c.
- correct frag header insertion.
- deep copy ip6 header portion in ip6_mloopback to avoid overwrite.
- do not bark when we forward packet to loopback.
- some cosmetics.
insufficient at this moment and we can bind(2) two sockets listen on same
port number.
for real fix, we need to check inpcb table with in6pcb. we can't
find inpcb chain from particular in6pcb chain (like finding tcbtable from tcb6)
luckily RFC2553 does not talk about bind(2) behavior for IPv4 mapped.
IPv4 mapped brings in too much complexities...
with "beyondscope" icmp6 support).
"options FAKE_LOOPBACK_IF" will honor scope on loopback outputs. rcvif will
be real interface, not the loopback, just like when multicast loopback.
(sync with kame)
to protocol handlers, based on src/dst (for ip proto #4/41).
see comment in ip_encap.c for details of the problem we have.
there are too many protocol specs for ip proto #4/41.
backward compatibility with MROUTING case is now provided in ip_encap.c.
fix ipip to work with gif (using ip_encap.c). sorry for breakage.
gif now uses ip_encap.c.
introduce stf pseudo interface (implements 6to4, another IPv6-over-IPv4 code
with ip proto #41).
- be persistent on initializing interfaces, even if there's manually-
assigned linklocal, multicast/whatever initialization is necessary.
- do not cache mac addr in the kernel. grab mac addr from existing cards
(this is important when you swap ethernet cards back and forth)
now ppp6 works just fine!
call in6_ifattach() on ATM PVC interface to assign link-local, using
hardware MAC address as seed.
(the change is in sync with kame tree).
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
- parse IPv6 header by using common function, ip6_{last,next}hdr.
- fix behaivior in multiple AH cases.
make strict boundary checks on mbuf chasing.
(sync with latest kame)
it was a bit too strong, and forbids multiple addresses from
same prefix to be assigned.
now the behavior is the same as previous - memory leak on interface address
addition failure.
http://orange.kame.net/dev/query-pr.cgi?pr=218
between protocol handlers.
ipsec socket pointers, ipsec decryption/auth information, tunnel
decapsulation information are in my mind - there can be several other usage.
at this moment, we use this for ipsec socket pointer passing. this will
avoid reuse of m->m_pkthdr.rcvif in ipsec code.
due to the change, MHLEN will be decreased by sizeof(void *) - for example,
for i386, MHLEN was 100 bytes, but is now 96 bytes.
we may want to increase MSIZE from 128 to 256 for some of our architectures.
take caution if you use it for keeping some data item for long period
of time - use extra caution on M_PREPEND() or m_adj(), as they may result
in loss of m->m_pkthdr.aux pointer (and mbuf leak).
this will bump kernel version.
(as discussed in tech-net, tested in kame tree)
draft-ietf-ipngwg-icmp-name-lookups-04.txt.
There are certain bitfield change in 04 draft to 05 draft, which makes
04 "ping6 -a" and 05 "ping6 -a" not interoperable. sigh.
of IPv4 transport layer code work correctly (specifically, ICMPv4
will transmit wrong packet if we don't strip AH here)
this is just for m_pulldown case. normal installations are not affected.
itojun