and implement a far more subtle and correct fix.
The reason behind the infinite loop was that ppp was trying to make up
initial IPv6 numbers and wasn't giving up when it failed unexpectedly to
assign the addresses it just fabricated to it's interface (thinking that
the reason was because another interface was using the same address).
It now attempts this up to 100 times before just failing and trying to
muddle along (in reality, this should never happen more than a couple
of times unless our random number generator doesn't work).
Also, when IPv6 is not available, don't even try to assign the IPv6
interface address in the first place...
structures (well, they're treated as opaque).
It's now possible to manage IPv6 interface addresses and routing
table entries and to filter IPV6 traffic whether encapsulated or
not.
IPV6CP support is crude for now, and hasn't been tested against
any other implementations.
RADIUS and IPv6 are independent of eachother for now.
ppp.linkup/ppp.linkdown aren't currently used by IPV6CP
o Understand all protocols(5) in filter rules rather than only a select
few.
o Allow a mask specification for the ``delete'' command. It's now
possible to specifically delete one of two conflicting routes.
o When creating and deleting proxy arp entries, do it for all IPv4
interface addresses rather than doing it just for the ``current''
peer address.
o When iface-alias isn't in effect, don't blow away manually (via ``iface
add'') added interface addresses.
o When listening on a tcp server (diagnostic) socket, bind so that a
tcp46 socket is created -- allowing both IPv4 and IPv6 connections.
o When displaying ICMP traffic, don't display the icmp type twice.
When display traffic, display at least some information about unrecognised
traffic.
o Bump version
Inspired after filtering work by: Makoto MATSUSHITA <matusita@jp.FreeBSD.org>
