Ted Lemon <[email protected]> wrote: Ted> Historically this has been proposed to be done with a stateful BRAS Ted> that retains authentication information from the PPP client/RADIUS Ted> server authentication process, and provides that to the DHCP server Ted> using a relay option. The DHCP server can then go to the RADIUS Ted> server to get prefix information if appropriate (although I would Ted> argue that this is unnecessary and probably harmful, since it Ted> requires static provisioning for all customers).
Some radius servers have the ability to allocate from a pool and the keep
that lease for a period of time.
Ted> Have you looked at RFC 4014 and RFC 7037?
Thank you for the reference, which I missed in scanning relevant WG documents.
Reading.
Ted> really be a problem. If the RADIUS server were doing dynamic
Ted> allocation, it would potentially be a problem since resources that
Ted> are committed during the solicit/advertise phase ought to be freed
Ted> if no request/reply phase follows. I don't know enough about
Ted> RADIUS to know if this ever happens, but it's my understanding that
Ted> it does not.
It can occur.
Ted> Of course, the larger question here is, why the heck would you want
Ted> to use PPPoE with all the MTU woes it brings into the picture? I
Ted> know the answers that are usually given, but I think this is
Ted> something that ought to be treated as a less-preferred approach to
Ted> delivering IPv6 service.
This is not a greenfield deployment. The existing service(s) is IPv4 PPPoE.
To be clear: this is an existing product being updated to support IPv6
because the customers asked for it. (Truly!)
PPPoE is also significantly easier for third party operators to work with in
many jurisdictions.
--
Michael Richardson <[email protected]>, Sandelman Software Works
pgplBo_TxyX6Z.pgp
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
