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