> > > Another good way to meet the DSL Forum's requirement > would be to run > > > PANA over IPv6 link-local addresses. Assuming the presence of an > > > IPv6 stack on both ends, this seems to be the least > problematic way > > > to do all of this: you get to talk to the first layer 3 device > > > upstream without any layer 2 issues to worry about but address > > > provisioning hasn't happened yet so no difficulties there either. > > > This wouldn't be ethernet-specific but it would probably be > > > advantageous to correlate the MAC address that was used > in the PANA > > > exchange with the MAC address in subsequent DHCP exchanges. > > > > 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 (2) understanding any difference between authentication & IP address assignment 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. 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
