> > disallow bind(2) with IPv4 mapped address for now.  port number check is
> > insufficient at this moment and we can bind(2) two sockets listen on same
> > port number.
> > 
> > for real fix, we need to check inpcb table with in6pcb.  we can't
> > find inpcb chain from particular in6pcb chain (like finding tcbtable from tcb6)
> > luckily RFC2553 does not talk about bind(2) behavior for IPv4 mapped.
> > IPv4 mapped brings in too much complexities...
>Any reason not to merge inpcb and inpcb6 tables?

	I'm very worried about possible bugs with merger (including backward
	compatibility breakage), and maintenance nightmare in kame side
	(we have too many pcb layers to play with).
	if I do it, since there are portions we can share, and portions we do
	not want to share, it would become:
	- struct inpcb, which contains sharable part (inp_[lf]addr will be
	  struct sockaddr_storage or something alike)
	- ipv4 specific part in in4pcb (like tos field, header prototype and
	  others), with inpcb included at the top
		struct in4pcb {
			struct inpcb foo;	/*must be at the top*/
			...
		}
	- ipv6 specific part in in6pcb (like flowlabel and whatever)
		struct in6pcb {
			struct inpcb foo;	/*must be at the top*/
			...
		}

itojun