> > > What you describe is certainly possible. But to me it seems more > > > complicated for failure mode debugging than the DHCP Auth proposals. > > > > Can you elaborate on that? > > My comment on "certainly possible" related to the larger discussion > earlier in your thread (now cut out) on provisional IP addresses. > Re-inserting your thoughts below: > > "As others have already explained, PANA can be run using an IP address > that is solely configured/assigned for the PANA signaling (e.g., a > link-local address, or a short-lease private address, etc.) Once PANA is > successful, the client is allowed to configure another IP address, and > that'd be your "service IP address." We have already taken this into > account in PANA design." > > 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. > (2) understanding any difference between authentication & IP address > assignment Not sure I understand how performing both using the same protocol helps here. > In this case all we had to understand is that their WAN connection is > either "on" or "off". > > *This is not a knock on PANA* I am absolutely sure there are extra > capabilities which come from PANA's additional messages. But the extra > PANA messages/state machines by definition mean more failure modes and > therefore debugging opportunities. Somehow this sounds like we are as close to defining EAP/DHCP as defining just a DHCP option. That's very unrealistic. EAP and network access authentication process have its own state machine. See IEEE 802.X and IEEE PKMv2 state machines. You cannot not have one if you are defining a new EAP transport. And the problem is, those state machines are not compatible with the DHCP state machine. EAP/DHCP will have to have a state machine, and even the "extra" messages to be a proper EAP lower layer for network access authentication. Alper > > Hopefully any PANA client software can hide most of these. But I am not > looking forward to the day when my parents call me up and their home > gateway has a provisional IP address, the Authentication has passed > successfully, but for some reason the IP address reconfig has failed. > > Eric > > > > > (And remember, DSL providers already use DHCP & Option 82.) > > > > Yes, that is for "line identification". The problem at hand > > is "subscriber authentication". They are not quite the same thing. > > > > Alper > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
