> > > > Anyway, last night (no joke :-( ) my parents called me up to > > > > troubleshoot their home DSL router. They had no external > > > connectivity. > > > > I had them log into the home router, and we quickly found > > > they had no > > > > WAN IP address. I had them re-enter their WAN > username/password > > > > credentials, and everything then was back to normal for them. > > > > > > > > We didn't have to worry about: > > > > (1) recognizing a temporary signaling IP address > > > > > > That's trivial. By now anyone who troubleshoots networks can > > > recognize IPv4 and IPv6 link-local addresses. And they know you > > > cannot get far using such IP addresses. > > > > My parents are not networking experts. > > We were talking about you as the person troubleshooting their > system. I wasn't expecting them to know that.
Yes, but I don't scale across my whole neighborhood either. (I am sure just about everyone one this list does nighttime work for their friends/family on home networking issues :-). > Like they'd not > know what various DHCP states resulting from EAP/DHCP or > other DHCP configurations would mean. > > > At all. But if they buy an > > off-the-shelf broadband router, they are expected to > troubleshoot its > > various states. > > > > A truism is that more states = more complexity when debugging. > > EAP and network access authentication related states do not > disappear just because you are embedding EAP inside the host > configuration protocol. Granted. I have been assuming troubleshooting the EAP part would be independent no matter what lower layer protocol is used. > It just happens that the host > configuration protocol all of a sudden starts having a > combined state machine that reflects all possible > combinations of the former type states and the latter types. > How is that a good thing? It is a *wonderful* thing to hide interim states from an end client when knowledge of that interim state wouldn't change the end result of the call flow. A good example of this is your typical credit card transaction: When you buy something on a credit card, your card-issuing bank is validated, your account is checked to see if it is active & in good standing, and the amount to be applied against the account is checked against the available balance. These are not three separate transactions with the CPE. All that really matters is a single response to a query which either indicates success, or the reason for a failure. If you accept that Authentication & IP Address assignment can be bundled when talking to some types of CPE (and not everyone agrees to that, but it works for PPPoE), then it is not unreasonable to reduce the number of interactions with a CPE. > A limited-access IP address configured before access > authentication is also a good thing. Like Alan was > suggesting, it helps the end user achieve limited > connectivity for troubleshooting. And also consider emergency > services. They expect you to dial 911 even without > authentication. There you need an IP address. 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). Eric > Btw, whether you like it or nor, even with your EAP/DHCP > solution you get one IPv6 link-local address on the CPE > before authentication. What do you want to do with that one? > > Alper > > > > > > Eric > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
