> > I will venture a guess here: they don't want to deploy a new protocol. > > It would be good to get the exact details from Ric or Mark or whoever > knows them. But my understanding is that their desires relate to
There was a requirements document presented some time ago. If Mark and Ric add to that, I think we'd have better understanding. ... > - DSLAMs are already looking at DHCP packets and filtering > them appropriately. A new protocol would require changes > in DSLAMs. I don't remember not touching the DSLAM was a requirement. But at any rate, whichever solution you pick, I believe DSLAM would be touched. > - 802.1x runs between a port and a switch, I think this means > that in the DSL world this would translate into a requirement > for the DSLAM rather than the BRAS performing the > authentication. I think that's not the issue. There may be switches even between the CPE and the DSLAM. For that, 802.1X does not work at all in practical deployments. > - Practical implementations on the BRAS side currently do > the option 82 processing in the DHCP code, so new processing > steps for related purposes are convenient to have in the > same part of the code. Today some DHCP option may be used as a line "identification" tool and therefore assist AAA in some way. But that does not justify all of a sudden turning host configuration protocol DHCP into a network access authentication protocol. That'd be a hack! Many people spoke against doing that to DHCP. I don't see a justification for IETF to endorse such a solution, especially when IETF already has a solution for this problem. I can recap on earlier points and expand on why it is such a bad idea to overload DHCP for this purpose. But before I do that, I really want to understand why expand any energy on this when IETF has designed PANA. Can the supporters of dhcp-auth explain why they think PANA does not solve the DSL authentication problem? Alper > > The different reasons have a different nature. The first two > items do not imply that a DHCP-based solution is needed, just > that some AAA-based approach is. Last item is more about > convenience than anything else. Not sure what would be > involved in the third and fourth items. > > Jari > > > > _______________________________________________ > 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
