Historically this has been proposed to be done with a stateful BRAS that retains authentication information from the PPP client/RADIUS server authentication process, and provides that to the DHCP server using a relay option. The DHCP server can then go to the RADIUS server to get prefix information if appropriate (although I would argue that this is unnecessary and probably harmful, since it requires static provisioning for all customers).
Have you looked at RFC 4014 and RFC 7037? The reason for the state diagram in 4818 looking as it does is that the DHCP server has to know how it's going to respond to a request from the client before it sends its advertise message. Since the prefix is statically configured on the RADIUS server, this shouldn't really be a problem. If the RADIUS server were doing dynamic allocation, it would potentially be a problem since resources that are committed during the solicit/advertise phase ought to be freed if no request/reply phase follows. I don't know enough about RADIUS to know if this ever happens, but it's my understanding that it does not. Of course, the larger question here is, why the heck would you want to use PPPoE with all the MTU woes it brings into the picture? I know the answers that are usually given, but I think this is something that ought to be treated as a less-preferred approach to delivering IPv6 service. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
