We can start a long theoretical discussion on pros and cons of relay versus dhcp proxy in the NAS, but that has nothing to do with TR-101, and it has nothing to do with the draft, no one said that if the NAS is working as a dhcp proxy it is incapable of working as a dhcp relay if setup to do so.
I think it is true for all features functionalities that a device will perform what it is configured to do, if you configure it to do dhcp proxy, then it is because there are clear advantages for you to do so in a specific setup, if you configure it to act as a normal dhcp relay then it will do so, and you loose the added functionality and benefits of the dhcp proxy. The dhcp proxy functionality which is used in many NAS devices will make the NAS look like a dhcp server to the client and make it look like a dhcp relay to the actual dhcp server. I really think we are getting of track with the discussion, it seem much more about about finding mistakes in statement, comments instead of keeping the eye on the ball and discuss if there are some advantage to include an authentication functionality to the dhcp process. So as stated earlier I think one of the advantages the draft is providing is to allow authentication before address assignment. As I understand it with pana we have to have address assignment before the authentication, and as such if the end-device is getting ip-address from dhcp, the end-device will have to get a ip-address from dhcp, then do authentication, and possible be rejected or possible have the dhcp process boot-strapped to pana, so when the authentication is successful the dhcp process can request a new public address. I do not think anyone is argueing that the pana solution is not workable, what is said is it will require more time and more resources on the NAS to handle several dhcp address allocations per end-device. Knowing how carriers in broadband networks constantly are trying to get as many subscriber authentications in as little time as possible, I think options that will streamline the authentication process have to be looked at. Peter > -----Original Message----- > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Sent: 5. december 2007 10:54 > To: Richard Pruss > Cc: [EMAIL PROTECTED]; 'Sam Hartman' > Subject: Re: [Int-area] EAP and DHCP end-points > > 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-d > hc-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 > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
