137 lines
5.2 KiB
Plaintext
137 lines
5.2 KiB
Plaintext
KAME/NetBSD integration TODOs
|
|
$NetBSD: TODO,v 1.8 2000/01/06 15:46:08 itojun Exp $
|
|
Jun-ichiro itojun Hagino <itojun@itojun.org>
|
|
|
|
|
|
This file talks about issues/TODOs in KAME/NetBSD integration.
|
|
For details about original KAME distribution, please refer to
|
|
sys/netinet6/IMPLEMENTATION, or documents in KAME distribution.
|
|
(NOTE: description in 1.12 does not apply to integrated code)
|
|
|
|
|
|
KERNEL
|
|
======
|
|
* inpcb and in6pcb
|
|
|
|
KAME kit has been designed to have less influence (bad impact) to the base
|
|
IPv4 code. For this, KAME uses separate pcb structure for IPv6 connections,
|
|
namely struct in6pcb (sys/netinet6/in6_pcb.h). In unified-ipv6 codebase
|
|
(this part is from NRL) they are merged into one, but will need bunch of
|
|
changes into netinet/in_pcb.h - which will affect stability of IPv4 tree.
|
|
Let us see which is better.
|
|
|
|
* port number issues
|
|
|
|
No IETF document talks about how tcp4/tcp6 and udp4/udp6 port number space
|
|
should be handled. The only thing defined is, in RFC2553:
|
|
AF_INET6 socket listening to wildcard IPv6 address (::) should
|
|
accept IPv4 connections.
|
|
It is very unclear how port number spaces should be treated. If they are
|
|
to be unified, what happens if, for example, you bind(2) to IPv4 wildcard
|
|
address, then IPv6 specific address on that port? There are so many
|
|
possibilities to be considered. It is much clearer and easier for me if
|
|
they are totally separate. Also, separated port number space is
|
|
compatible/safe to future addition of "TCP over IPv7" :-)
|
|
|
|
Proper userland code should not be affected by this (see RFC2553 for
|
|
how to use getaddrinfo()), so KAME userland can cope with both cases.
|
|
|
|
Current kernel code implement separate port number spaces, since it uses
|
|
separate inpcb/in6pcb.
|
|
|
|
* net/if_types.h
|
|
|
|
IFT_GIF and IFT_FAITH are not defined in IANA assignment, but we need to
|
|
define these two (they are essential). If it is prohibited to define these,
|
|
where should we check to get interface type? if_xname?
|
|
|
|
* ATM PVC support in Adaptec/ENI ATM driver
|
|
|
|
Is it MI enough? If not, would you like it to be removed from the tree?
|
|
Actually this is quite useful (we use it in Japanese ATM PVC leased line
|
|
service and is quite stable).
|
|
|
|
* mbuf pullup consideration
|
|
|
|
KAME IPv6 onion-peeling routine assumes that headers are contiguous on
|
|
mbufs. For this we impose little restriction on drivers (namely,
|
|
MINCLSIZE has been modified for this). From stats we gathered it has no
|
|
impact on performance (maybe better due to less m_pullup), but some of
|
|
you may not like this (you may hate deep-copy code in net/if_loop.c).
|
|
We may need to implement safer way, something similar to m_pullup().
|
|
I have an idea but I still need some time for this. I'll test this in
|
|
KAME tree and then will bring it to NetBSD.
|
|
(NOTE: m_pullup is not very useful for IPv6 as the chained header length
|
|
can easily exceed MHLEN. Remember, IPv6 header itself already occupies 40
|
|
bytes)
|
|
|
|
KAME team is doing experiments with m_pulldown(). will migrate to m_pulldown()
|
|
after stabilization.
|
|
|
|
* ipsec socket pointer
|
|
|
|
We currently reuse m_pkthdr.rcvif for ipsec socket pointer, and ipf and
|
|
other code does not like this.
|
|
|
|
* gre/ipip compatibility
|
|
|
|
Hope I did not break any of these... Could someone check?
|
|
|
|
* mbuf flags
|
|
|
|
KAME code introduces 5 mbuf flags, which should be decreased. M_ANYCAST6
|
|
is local to IPv6 code so it should be M_PROTO0 or something like that.
|
|
Others (IPsec items) are used across IPv4 and IPv6 so they cannot be in
|
|
M_PROTO0 kind of thing.
|
|
|
|
|
|
USERLAND
|
|
========
|
|
* various routing daemons
|
|
|
|
KAME codebase includes several routing daemons, like route6d or bgpd (which
|
|
does RIPng and BGP4+, respectively). Should we put these into
|
|
/usr/src/usr.sbin, or should we treat those as third-party code (pkgsrc)?
|
|
|
|
pim6dd license issue should be clarified.
|
|
|
|
* IPv6-support in resolvers and libraries
|
|
|
|
Dual stack resolver code is from KAME. The change may not be compatible with
|
|
future bind8 code, so we may have to merge future bind8 carefully.
|
|
(or we should volunteer for bind8 improvements)
|
|
|
|
At this moment IPv6 support in lib/libc/net/* is implemented in very
|
|
conservative way so that it will not break existing codebase.
|
|
To be RFC2553 compilient, we need to supply getipnodeby{name,addr}.
|
|
However, it needs a total rewrite of gethostby{name,addr}.
|
|
It will make future upgrade to bind8x really harder.
|
|
|
|
rcmd() and iruserok() must be extended to support multiple address families.
|
|
Experiments in KAME but still unclear about API (no standard).
|
|
|
|
* -DINET6, -DIPSEC
|
|
|
|
Where should we define -DINET6? Should it be global option like
|
|
EXPORTABLE_SYSTEM=1 (in /etc/mk.conf), or local option defined somewhere?
|
|
(some people may need a binary tree with no IPv6 support at all, for
|
|
smaller footprint)
|
|
|
|
At this moment -DINET6 is placed in each of leaf directory Makefiles,
|
|
and there's no global option for enabling/disabling userland IPv6/IPsec
|
|
support. Since we ship single binary tree we want to ship them enabled
|
|
by default.
|
|
|
|
* if index
|
|
|
|
Should we hide if index (s6_addr16[1] in in6_addr) from the user, on "ifconfig"
|
|
or "netstat -in"? Those numbers are just for kernel internal
|
|
and should never be used from standard userland applications.
|
|
(see 1.3 in sys/netinet6/IMPLEMENTATION)
|
|
|
|
We start hiding it by using getnameinfo(NI_WITHSCOPEID).
|
|
|
|
* more IPv6 support
|
|
|
|
X11, NFS, RPC, whatever.
|