In short: if you want to make it work better on IPv4-only kernel,
	please volunteer.  send *repeatable* bug reports when you see breakage.
	I will react as quickest as I can.

>The issue at stake is how well (or at all, in some cases) those
>same IPv6 userland mods are being tested in non-IPv6 kernels.
>Or, to put it another way, who do we collectively think is
>supposed to test them, and who *is* acutally testing them?
>Until now I'd assumed that was part and parcel of "IPv6 integration".
>Is that wrong?  If it *is* wrong, who is actually be testing IPv6
>changes on V4-only systems?
>Itojun's answers so far seem designed to avoid those questions.
>I wish Itojun would answer, instead of obfuscating.

	We have baked IPv6/IPsec code *more than 2 years* before committing.
	KAME users have been sending bug reports to KAME mailing list for
	IPv4-only systems, since some of these users are more interested in
	IPsec part, not IPv6 part (so they would configure IPv4-only IPsec
	kernel and send us bug reports whenever it chokes).  I myself do try
	to test on IPv4-only configuration.

	However,
	- human can make mistakes, so I make mistakes too.
	  In some of seemingly-trivial case I commit without visiting
	  IPv4-only kernel.  if the "seemingly trivial" assumption is
	  incorrect, you see breakage.  You may not understand this, however,
	  my network relies fully upon IPv6 and it's rather hard for me to test
	  non-IPv6 node.  I think I have only ONE (yes, one) node which is
	  IPv4-only, out of more than dozens of nodes I manage for my
	  development work  Some of these nodes have IPv4/v6 kernel, with no
	  IPv4 address assigned to it (I don't run NAT and ISP does not give
	  me enough IPv4 address - yes, this is where IPv6 comes in).
	- Noone can test for every possible code path, and every possible
	  configurations.  KAME coders cannot test for every possiblilities.
	  Even though we have reports from KAME users and reports from *BSD
	  mailing lists, that does not cover all the cases.
	  Also, we do have NetBSD-specific patches/corrections/integrations
	  and tweaks, to make NetBSD tightly integrated IPv6 system than most
	  of vendor un*x variants (it is already a very highly integrated IPv6
	  system).  When we put NetBSD-specific changes, reports from
	  KAME users mailing list does not really help.  This is where I
	  really need your help.
	  How do we really able to test every code path for every libc
	  changes, for example?  I'm not sure if it is ever possible.
	  I refer here "every possible cases" since, for highly configurable
	  portion like pppd(8), breakage can appear in very specific
	  configuration only.  You may object my position to generalize
	  IPv4-only kernel configuration into "every possible configuration",
	  but I have too many cases to tackle BEFORE IPv4-only configuration.
	I really need your help and repeatable bug reports, if any breakage
	happens.

	I don't think there's someone devoted to testing on IPv4-only kernel.
	If you think you need something to be done, would you please volunteer.
	If not as an assigned task to you, please do send **repeatable** bug
	reports.  Your email on breakage has been helpful as a trigger for me,
	however, recent ones did not help me repeat it, at all.  Some of
	them are misguided.  please track down problem a bit, make it very sure
	that I am prime suspect before pointing your finger!
	I understand you are busy, but I'm busy too.  NetBSD is a voluntary
	effort of collective people, so why not volunteer to make it better.
	I think I have reacted to bug reports quickest as possible
	(I believe the roundtrip time between any breakage report to a fix
	was, in most cases, less than a day.  I'm living in strange timezone
	to catch up with western timezones, it is killing my braincells).
	If you say I'm not doing enough, please volunteer to test, and send
	repeatable bug reports, to help making NetBSD the greatest operating
	system, for IPv4-only kernel configuration (which is what you really
	care about).

itojun