(posted at 09:52PM GMT) 
One of my side projects at the moment is building an OpenWRT-based replacement firmware for the Netgear DG834G v2/v4/v5 routers which is what Spilsby Internet Solutions currently ships to end users.
The primary motivation behind this is to provide a software-based upgrade path to our users in order for them to easily adopt IPv6 which we currently support on our ADSL/WBC platform; it wouldn't surprise me if Netgear, the proponents of 'open source routers' but distributors of 'closed source binary blobs', decide not to release their own IPv6-enabled firmware for these routers and will require users to purchase new hardware.
Some additional features are also on the roadmap which will benefit us; primarily the logging and reporting of ADSL line stats (attenuation, noise, etc, etc) which should make diagnosing and reporting faults to BT Wholesale so much easier.
The other reason why I'm working on this is because there is still some confusion about how IPv6 addresses/prefixes/nameservers are going to be propogated to the end-users' CPE via PPP - the general consensus to obtain an IPv6 address on the WAN interface is for the remote server to advertise a prefix via IPv6 Router Advertisement but this allows for IPv6 address spoofing as this address can be chosen by the client.
Prefixes/nameservers can only be passed via DHCPv6 as there are no LCP messages in the current PPP RFCs that cater for IPv6 prefixes/nameservers; the end result being that this needs to be implemented on both client and server ends - with no reference implementation for either currently endorsed or sponsored by the IETF.
The problem with DHCPv6 is that it works based on the link-local address which is assigned to the end-user and provides prefix delegation, nameservers and all other information based solely on the value of that link-local address; according to the author of MPD, it is the preferred way of assigning global IPv6 addresses and other information.
Unfortunately, this Daily WTF article highlights what is wrong with this approach - if the end-user can spoof their MAC address, they will obtain a different link-local address from the IPv6CP negotiation, which in turn, will result in them obtaining a different global IPv6 address from DHCPv6 - what happens if the user spoofs the MAC address of an existing user who is currently not connected ?
The only way this is going to work is if the link-local address is assigned by the server rather than being chosen by the client - the server can override a client preference but it is 'discouraged' by the RFCs.
This always makes me question myself; RFC documents are written by groups of very intelligent people who know their subject intimately - therefore, when I find myself disagreeing with an RFC, I almost always accuse myself of not knowing enough about the subject and sit down and read the RFC again.
Unfortunately, I have done this several times with this RFC over the last six weeks or so and I keep coming to the conclusion that the authors did not consider the possibility of 'spoofing' as per the Daily WTF article above - an attack which seems highly probable given that if it works with IPv4, it will work with IPv6 as well.
It is my honest opinion that the OSS world is in for a world of hurt when it realizes that its' IPv6 'support' is next to useless in so many ways; with commercial software being just as bad. | 
