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