I don't understand why "reinstalling filters" is needed here. The sequence I am thinking is as follows: In the initial state (i.e., before PANA authentication), filters are open for DHCP and PANA only. After PANA authentication, filters for binding the MAC address and service IP address as well as routes are installed and another DHCP delivers the service IP address to the client.
Yoshihiro Ohba On Thu, Oct 11, 2007 at 08:32:15PM +0200, Mark Townsley wrote: > Stig Venaas wrote: > >Eric Voit (evoit) wrote: > > > >>Two of the reasons the DSLF is asking for DHCP Auth to be considered by > >>the IETF are that: > >> > >>(1) PANA does not meet IPAuth-14 "Must allow for authentication and > >>download of subscriber service profile before service IP address is > >>assigned." IPAuth14 is from the earlier DSLF liaison document to which > >>Mark referred. > >> > > > >It says service IP address. I suppose you could possibly get an initial > >IP address that allows you to do PANA but not much else, and then after > >you are authenticated you would get the service IP address? > > > > Possibly. But, remember that the auth step in DHCP is mostly rounding > out use cases for the operational model that is already in place for DSL > without PPP. The current model uses Option 82 inserted in the DHCP > Discover message transiting the network to authenticate the subscriber > line before IP addresses are assigned, routes installed, and filters > opened up (binding a MAC address to an IP address) along the path > between the home and the BRAS. Auth in DHCP allows additional > credentials from equipment on the residential side of the subscriber > line to be used by AAA, rather than relying on credentials inserted by > the DSLAM alone. Allowing an IP address to be assigned, opening filters > specifically for PANA/EAP alone (as well as inserting the same option 82 > information into PANA during transit, as this will certainly come next > for cases where RG+DSLAM credentials are necessary at the same time) > then changing that IP address on the fly, reinstalling filters, etc, is > a rather significant change in the currently deployed behavior for not a > lot of gain from the provider's perspective. > > - Mark > >Stig > > > > > >_______________________________________________ > >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
