Subject: dualstack udp_usrreq.c
To: None <tech-net@netbsd.org>
From: None <itojun@iijlab.net>
List: tech-net
Date: 09/23/1999 12:03:50
Hello,
NetBSD-current code has separate code for udp4 and udp6
(sys/netinet/udp_usrreq.c and sys/netinet6/udp6_usrreq.c). The
separation forbids use of IPv4 mapped address (::ffff:10.1.1.1)
documented in RFC2553.
I've put integrated udp_usrreq.c into KAME tree so could anyone
please look at it and send me comments?
Basically, it puts
- IPv4 packet dependent part (udp_input)
- IPv6 packet dependent part (udp6_input)
- AF_INET socket (inpcb) dependent part (udp4_realinput)
- AF_INET6 socket (in6pcb) dependent part (udp6_realinput)
into separate functions. This is a leap from good old BSD udp_usrreq.c
so I need your review before this goes into NetBSD-current tree.
It may raise compatibility/maintenance issue with other BSDs.
http://www.kame.net/dev/cvsweb.cgi/kame/netbsd/sys/netinet/udp_usrreq.c
http://www.kame.net/dev/cvsweb.cgi/kame/netbsd/sys/netinet6/udp6_usrreq.c
With the code you can:
- wait for IPv4 UDP packets on AF_INET6 socket, by wildcard bind
(it appears as came from ::ffff:10.1.1.1)
- send IPv4 UDP packet from AF_INET6 socket (send to ::ffff:10.1.1.1)
I've tested this on KAME stack for some days, without any problem.
There may be some discussion about how inpcb/in6pcb should be treated.
- integrated inpcb will comes with lots of lots of compatibility issues.
- non-integrated inpcb (inpcb+in6pcb) is better in terms of
compatibility, but tcp_timeout() is a bit tricky.
I currently prefer non-integrated inpcb for compatibility (so both
KAME and NetBSD-current uses separate inpcb/in6pcb). If we need to
go to integrated inpcb we may need to code udp_usrreq() differently.
itojun