>> An even better way to do it would be one suggested by Matt Thomas --
>> IPv4 as a separate code base simply goes away, and instead takes the
>> mapped-address path through the IPv6 stack.
> Yeah, but only if you're prepared to use AF_INET6's ipv4-mapped
> addresses.  It's a non-starter for existing applications which create
> PF_INET sockets and bind()/connect() them to PF_INET addresses.

I see no reason the PF_INET API/ABI can't be converted to v4-mapped v6
calls as soon as they hit the kernel.

You'd have to touch things up a little to prevent non-mappedv4 v6
addresses from connecting to them and confusing userland with peer
addresses not representable in the API in use, but that's a
comparatively minor change.

> Or for people who want to comment out INET6 from their kernels.

I see no particular reason we have to support INET-and-no-INET6 (or
INET6-and-no-INET, for that matter) kernels, any more than we support
INET-but-no-SACK-or-window-scaling kernels.  (We may want to, sure.
But I see no reason we should have to.  Of course, if we don't, we
probably should subsume both under a single kernel option.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B