Ric, We are not saying DSLF MUST use PANA. But if DSLF is coming to IETF with the requirements it did and seeking a L3-based access authentication protocol, IETF has designed PANA exactly for that.
If DSLF is satisfied with a 802.1X extension and IEEE is delivering that, so be it. There is nothing wrong with that. There does not appear to be a strong justification to hack DHCP the way you are proposing. Many people spoke against that already. Based on a cost/benefit analysis, doing that to DHCP may be justified for a DSL product line group, I'd understand. But not for the IETF, imo. Alper > -----Original Message----- > From: Richard Pruss [mailto:[EMAIL PROTECTED] > Sent: Friday, October 19, 2007 6:01 AM > To: Yoshihiro Ohba > Cc: Internet Area > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > > > Yoshihiro Ohba wrote, around 19/10/07 11:39 AM: > > Option 82 makes no difference if option 82 is also > > inserted in PANA message. DHCP state transisions (excluding those for > > EAP state transitions) before completion of authentication makes no > > diffirence. The only difference would be DHCP state transitions after > > successful authentication in PANA, but I don't really think this is a > > big deal that can justify significant change to DHCP. > > > > > You still arguing PANA? The difference is that DHCP snooping and Option > 82 insertion is implemented. > Running code, get it? DHCP snooping and Option 82 insertion is > implemented and deployed worldwide, working for millions of subscribers... > > If the DSLForum is going to try recommend the huge cost to do something > that changes every device in the Ethernet layer I suspect they probably > will take something from IEEE, > that fixes MAC security and takes something like 802.1x but that > traverses client side and provider switches. Not PANA. > > DHCP Authentication is a small change to the existing deployment that > has Port as credentials for Option 82 and simply adds the ability to > have client supplied credentials but > otherwise uses the same architecture that is deployed today for Option > 82 driven Ethernet DSLAMs and the upstream terminating BRASes. > > - Ric > > > Yoshihiro Ohba > > > > > > > _______________________________________________ > 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
