> > 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.
This doesn't square up to the fact that specific technology groups do have requirements that the IETF is engaged in addressing, eg capwap, ancp, 16ng, etc, etc. DHCP extensions to suit specific technologies also abound, eg RFC 3594, RFC 4390, etc. All in all, thus it seems like the IETF is open to allowing technology specific protocols or extensions there-of, which is even more understandable, imo. -Woj. > > > 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 > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
