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

[itojun@iijlab.net]

>> The applying of this patch would let us in the "IPV6 Sockets Accept IPV4,
>> Specific IPV4 Address Bindings Succeed" class with -for example- DEC Unix
>> and old KAME, because we yet do IPv4 mapping.
>> 
>> KAME people seems to want to deprecate IPv6 mapped address, and newer
>> versions don't let IPv6 sockets accept IPv4 connections. That's the MS
>Wrong; KAME for freebsd[34], BSD4 and netbsd support ipv4-mapped address
>while itojun, a core developer of KAME Project, dislikes it.  
>See IMPLEMENTATION file in kame kit.

	the above description is partially correct, but rather misleading
	overall.  be sure not not mislead people.

	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 we did for the BSD-integrated KAME code is to talk with each of
	the *BSD projects and implement the behavior agreed with developers,
	or users mailing lists.  i have described about possible threats
	(draft-itojun-ipv6-transition-abuse-02.txt), workarounds, and
	standards status.

	the result:
	bsdi and freebsd preferred spec conformance to RFC2553 section 3.7,
	and turned IPv4 mapped address on by default.  therefore, they
	present an insecure behavior by default.
	openbsd (of course) picked security over spec conformance, so
	completely disabled IPv4 mapped address.  it helped us simplify
	kernel pcb layer code and userland code, however, some of the third
	party code may not work because of this (like mozilla).
	netbsd picked an intermediate approach.  the behavior is
	disabled by default, but if an user asks for it by setsockopt, can
	be enabled.  for third party software that require this behavior,
	we can put a small amount of patches for setsockopt.

	for older platforms like freebsd2 and bsdi3, to aim for easier
	code sharing, we did not implement this.

	we cannot implement certain behavior into widely-usrd operating systems,
	just because "itojun dislikes it".

itojun