Re-test IPv6 (and specifically MulticastSocket) with latest Linux & USAGI code

This bug is to remind us to schedule time to test IPv6 (esp.
multicasting) with the latest Linux distributions and USAGI snapshots.

Some specific items to test are :-

- IPV6_MULTICAST_IF sets the outgoing interface for IPv6 multicats
but appears not to set the outgoing interface for IPv4 multicasts
sent from same socket. A similiar issues needs to be examined
for the outgoing ttl set via IPV6_MULTICAST_HOPS.

- SO_REUSEADDR behaviour has gone through a number of iterations in
the USAGI snapshots - we need to check the ability to bind multiple
UDP sockets to the same port is still okay.

- IPV6ONLY socket options is now implemented - need to check
default behaviour and specifically that !IPV6ONLY still implies a
unified port space.

- USAGI appears to have implemented the RFCs dealing with IPv6
source address selection. This means that we should be able to
test sending of multicasts with scopes greater than the scope
of any local address.

- SuSE 8.0 apparently ships with 2.4.16 kernel with experimental
IPv6 enabled. At least one developer has observed IPv4 multicasting to
stop working with this distribution (-Djava.net.preferIPv4Stack=true
works okay). This is likely to be a SuSE configuration issue as
2.4.16+IPv6 works with RedHat.

- On current distributions !IPV6_MULTICAST_LOOP isn't preventing
the loopback of IPv4 multicast packets.

- getaddrinfo doesn't reject many invalid IPv6 addresses - need
to check latest USAGI changes to see if this has been addressed.

- We have dependencies on the /proc file system to enumerate
IPv6 interfaces and additionally we need access to the IPv6
routing table to select outgoing interfaces when the destination
is a link-local address. We need to check that the format hasn't
changed.

- Linux/gcc's header files define the sockaddr_in6 structure
incorrectly (missing the sin6_scope_id field) so we are forced
to use our own definition. Need to check for any updates to this
(esp with the tentative move to gcc3.x).

###@###.### 2002-09-05