De fato, é uma solução, mas nem sempre é uma possibilidade: talvez não queiram ou saibam mexer nisso, talvez a rede seja muito grande para sair mudando MTU em todo lugar, talvez algum equipamento não suporte o aumento de mais 8 bytes ou talvez já esteja no máximo com o PPPoE passando dentro de VLANs, VPLS, etc. (até EoIP tem que considerar, já que o @andrecarlim diz que gosta dele)... DHCP é uma solução que não requer muitas intervenções/alterações na rede nem equipamentos, e eu gosto disso.
Nas mensagens de requisição e resposta do DHCP as informações são enviadas em campos (ou "opções", embora eu não veja sentido no porquê de chamarem assim), que são identificados por um ID conhecido, definido pela IANA para cada tipo de dado: https://www.iana.org/assignments/boo....xhtml#options
A opção 82 é chamada Relay Agent Information e é dividia em 2 sub-campos, preenchidos pelo relay DHCP: Circuit-ID e Remote-ID. Circuit-ID identifica basicamente ou circuito ou rede em que a requisição DHCP chegou, enquanto Remote-ID identifica quem a originou. Cada relay preenche isso de uma forma: em uma OLT podem ser dados derivados da identificação da ONU na rede, com número do slot da placa e porta PON e identificador da ONU na porta, - FiberHome faz assim, pelo que sei - enquanto na maioria dos dispositivos (é o caso de MikroTik e acho que UBNT e todos switches também), Circuit-ID vai ser a porta física em que chegou a requisição e Remote-ID vai ser o endereço MAC de quem originou.
No caso de Remote-ID sendo MAC eu acho meio inútil, como já falei em um post anterior, mas se for usada outra informação, até mesmo definida manualmente, ou algo como as OLTs FiberHome fazem, é extremamente útil para identificar os assinantes na hora entregar o IP, pois o servidor DHCP vai enviar esses valores da opção 82 como parâmetros da Access-Request para o servidor Radius, que pode fazer comparações contra eles.