Re: (usagi-users 00291) Re: USAGI IPv6 patches

[itojun@iijlab.net]

>> 	yes, I believe IPv4 mapped address (RFC2553 section 3.7) behavior is
>> 	poorly documented, complicates both kernel and user code, leads to
>> 	insecure user code, and should be deprecated.  yes, I dislike it.
>> 	I have been vocal about this in IETF because I believe the issue is
>> 	serious.
>What's the ipng wg position on it? Could we translate this discussion there?
>
>In the meantime the USAGI patch that i sent would let linux in the same
>position that FBSD and BSD/OS 4, and IMHO a lot better than what we have
>now, would you davem/alexey apply it or at least tell us your opinion about
>this issue?

	we had a kind of small group ("design team") discussion for updating
	RFC2553 to 2553bis-xx, regarding to this issue.  there are a lot of
	guys from OS vendors.  basically i failed to convince the editor of
	2553bis-xx; the discussion went to the wrong direction (IMHO).  I
	tried to convince that the discussion should focus on security and
	application portability/reusability, however, the discussion went to
	"how to keep my kernel unchanged and be conformant" direction.

	the result is on 2553bis-03, and that is:
	- AF_INET6 socket will get IPv4 traffic (as being from IPv4 mapped
	  address), by default
	- the above behavior can be turned off/on by IPV6_V6ONLY setsockopt
	  (new feature)
	- bind(2) ordering constraint and conflict logic is not documented.

	IMHO, the first bullet is rather unfortunate, if we could convince
	that the default value is "unspecified, vendor specific",
	we could make netbsd/openbsd behavior "2553bis-03 conformant".

	it was good that we now have second bullet, however,
	due to the last bullet it is rather twisted.  for example, if a stack
	disallows AF_INET wildcard bind(2) after AF_INET6 wildcard bind(2),
	even with IPv6_V6ONLY turned on (= AF_INET6 grabs IPv6 traffic only)
	we can never listen to IPv4 traffic.  because bind(2) ordering is
	not documented, stacks can be very different from each other.
	try kame "bindtest" tool on random platforms and see what happens :-)

	if we look at BSD status against 2553bis-03 spec, it is like this.
	(and at this moment no plan to change behavior too much)
	- freebsd/bsdi: to be 2553bis-03 conformant need to implement
	  IPv6_V6ONLY setsockopt.
	- openbsd: is not 2553bis-03 conformant (completely lacks the
	  first bullet, no intention to provide it)
	- netbsd: is not 2553bis-03 conformant (slightly violates the first
	  bullet - default value is opposite from the spec with reason).

itojun