NetBSD/sys/netinet6/TODO

KAME/NetBSD integration TODOs
$NetBSD: TODO,v 1.5 1999/08/14 19:17:19 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.

* udp4/6 wildcard bind

Currently udp4 and udp6 are handled in separate source code, and AF_INET6
socket listening to wildcard IPv4 address does not accept IPv4 connections.
This is not compatible with what described in RFC2553.
This is related to the above two items (in6pcb and port number issues).

* tcp4/6 wildcard bind

As we share tcp4 and tcp6 code (sys/netinet/tcp*) we have implemented
AF_INET6 wildcard bind socket behavior (AF_INET6 wildcard bind socket 
will receive IPv4 packets, with get{peer,sock}name translated into
IPv6 address like ::ffff:10.1.1.1).  At this moment there is no way to
disable this behavior.  We may want to add setsockopt() for this.

* 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)

* gre/ipip compatibility

Hope I did not break any of these...  Could someone check?

* kernel config

Should we have GENERIC.v6 and GENERIC, or IPv6 items should be integrated into
GENERIC?  How can we maintain IPv6 items efficiently?  Is there good place to
list MI compilation options?

* 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)?

* IPv6-support in resolvers

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.

* IPsec library

Should IPsec library be enabled on userland programs by default?
(NOTE: no crypto code will be put into userland - crypto code for IPsec
is in kernel only)

* -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)

* 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)

* more IPv6 support

libwrap, ppp, you-name-it.