- in in6_ifattach_getifid(), we can grab interface id source iff the source
is universally (worldwide) unique. ARCnet hardware address is of 8bit and
does not satisfy the condition.
(in6_ifattach_getifid() is for getting interface id usable for pseudo
interfaces like gif*)
- xx_to_eui64() should return EUI64 format, not IPv6 interface id format.
this may seem awkward so I wish to clean these things up.
- in nd6.c, change if clause into case clause to allow future addition
of IFT_xxx easier.
This situation happens on severe memory shortage. We may need more
improvements here and there.
- Grab IEEE802 address from IFT_ETHER card, even if the card is
inserted after bootup time. Is there any other card that can be
inserted afterwards? pcmcia fddi card? :-P
- RFC2373 u bit handling suggests that we SHOULD NOT copy interface id from
ethernet card to pseudo interface, when ethernet card has IEEE802/EUI64
with u bit != 0 (this means that IEEE802/EUI64 is not universally unique).
Do not use such address as, for example, interface id for gif interface.
(I have such an ethernet card myself)
This may change interface id for your gif interface. be careful upgrading
rc files.
(sync with recent KAME)
- do not perform IPv6 initialization for faith* interface, as they become
mistakingly IFF_UP. we are wondering if we should nuke in6_ifattach_p2p().
(sync with recent kame)
(Sorry for a big commit, I can't separate this into several pieces...)
Pls check sys/netinet6/TODO and sys/netinet6/IMPLEMENTATION for details.
- sys/kern: do not assume single mbuf, accept chained mbuf on passing
data from userland to kernel (or other way round).
- "midway" ATM card: ATM PVC pseudo device support, like those done in ALTQ
package (ftp://ftp.csl.sony.co.jp/pub/kjc/).
- sys/netinet/tcp*: IPv4/v6 dual stack tcp support.
- sys/netinet/{ip6,icmp6}.h, sys/net/pfkeyv2.h: IETF document assumes those
file to be there so we patch it up.
- sys/netinet: IPsec additions are here and there.
- sys/netinet6/*: most of IPv6 code sits here.
- sys/netkey: IPsec key management code
- dev/pci/pcidevs: regen
In my understanding no code here is subject to export control so it
should be safe.
is