Section 5.5 of DSL TR-101 says: R-181 The Broadband Network Gateway MUST be able to function as a DHCP Relay Agent as described in RFC 951 "BOOTP", RFC 2131 "DHCP" and RFC 3046 "DHCP Relay Agent Information Option" on selected untrusted interfaces.
R-182 The Broadband Network Gateway MUST be able to function as a DHCP relay agent on selected trusted interfaces, when an access node acts as a Layer 2 DHCP relay agent as specified in Appendix B -- Layer 2 DHCP Relay Agent. Given that BNG is equivalent to NAS and your answer is accurate, how does your answer satisfy the TR-101 requirements? Yoshihiro Ohba On Wed, Dec 05, 2007 at 10:10:17AM -0800, Richard Pruss wrote: > The answer you got was accurate but possibly not clear. > > The BRAS (NAS on the diagram) is a DHCP server to the client. > > We call a device acting like a DHCP server to the HGW and client to the > central DHCP Server a proxy and so does Juniper. > > In retrospect I made the mistake of calling it a relay in the document > because I was trying to support Richard Johnsons draft > which documents the existence of these implementations and tries to move > them towards being relays by documenting how to > override the server-id attribute. > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-dhc-server-override-05.txt > > - Ric > > > Alper Yegin wrote, around 4/12/07 10:59 PM: > >Today Sam asked a question about the EAP end-points with respect to > >dhcp-auth proposal. > > > >The answers we got were either not clear or not accurate. > > > >It is not true that EAP authenticator is always on the DHCP server. In > >Figure 5 of their I-D, EAP authenticator and DHCP relay are co-located in > >NAS: > > > > > > (HGW) (NAS) (AAA) (DHCP) > > DHCP Client AAA Client RADIUS Server DHCP Server > > AAA Client > > > > DHCPDISCOVER -------> > > (w/DHCP-auth-proto EAP) > > > > <------- DHCPEAP > > (w/EAP Message) > > > > DHCPEAP -------> > > (w/EAP Message) > > > > RADIUS Access-Request -------> > > (w/EAP Message) > > > > <-------- RADIUS > > Access-Accept (w/EAP Message) > > (Access-Reject (w/EAP Message) > > if unsuccessful) > > > > (DHCP messages continue normally from > > this point forward if successful) > > DHCPDISCOVER ------------------------------> > > (w/RADIUS attributes suboption) > > > > <----------------------------- DHCPOFFER > > > > <------- DHCPOFFER (w/EAP Success Message) > > (w/yiaddr) > > > > DHCPREQUEST -------> > > > > <------- DHCPACK > > > > Figure 5: Message Flow with new message and a DHCP relay > > > > > >As for EAP peer and DHCP client, we never got a clear acknowledgement that > >it may be on a device sitting behind the CPE (HGW) at home, like a PC. It > >has to be so because: > >- There are clear DSLF requirements for that [e.g., IPAuth-9 Should be > >simple to implement on client (PC or CPE)], > >- Replacing PPPoE means doing that on the home PCs as well, and > >- The I-D clearly states "The DHCP Client resides either on a home network > >device or the HGW,..." > > > > > >Alper > > > > > > > > > >_______________________________________________ > >Int-area mailing list > >[email protected] > >https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
