On Thu, Oct 18, 2007 at 09:08:53PM -0400, Eric Voit (evoit) wrote: > > From: Yoshihiro Ohba, October 18, 2007 7:37 PM > > On Thu, Oct 18, 2007 at 04:59:05PM -0400, Eric Voit (evoit) wrote: > > > > > > Any standardized DHCP Auth mechanism shouldn't preclude this. In > > > fact, non-standard 802.1x implementations have already blazed this > > > trail. EAP over 802.1x credential failure can allow the > > access port > > > to be allocated to a guest VLAN instead of the access port > > going into > > > a port-blocked mode. Likewise, DHCP Auth EAP credential > > failure could > > > result in the L3 edge assigning the subscriber a non-public > > IP Address, and associating > > > the customer with a diagnostic VRF (w/ 911 support of course). > > > > Then how is DHCP auth different from PANA in terms of debugging? > > ? Compare the number of total state transitions between CPE boot & > operation; compare the operational delta from existing/embedded DHCP > Option 82 deployments.
I was mentinoning in terms of the number of combinations of IP address allocation state (no address/non-service address/service address) and authentication state (unauthenticated/authenticated) that may be used for debugging/troubleshooting. But even in terms of state transtions, I don't see much difference. EAP state transitions make no diffirence. 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. Yoshihiro Ohba > > > Yoshihiro Ohba > > > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
