On Apr 25, 2010, at 7:37 PM, Mikael Abrahamsson wrote: > On Sun, 25 Apr 2010, Doug Barton wrote: > >> On 04/25/10 16:42, Owen DeLong wrote: >>> That's what Link Local is for. >>> >>> fe80::<EUI-64>%<interface> >>> >>> For example, if the CPE is connected to the customer's network on eth0 >>> and the CPE mac address is 00:45:4b:b9:02:be, you could go to: >>> >>> http://[fe80::0245:4bff:feb9:02be]%eth0 >> >> ... and regardless of the specific method, the vendors already document >> the procedure for connecting to the web interface for IPv4, there is no >> reason to believe that they could not or would not do the same for IPv6 >> if necessary. > > Does anyone actually believe that the above is user-friendly and will work in > real life? Using link-local for this kind of end-user administration of their > equipment is doomed to fail. There needs to be a procedure for devices which > are going to get DHCP-PD from the provider, that they have a certain prefix > they use until they actually get the real PD prefix, so end user dns etc > works so it's easy to do administration of the device. > I fail to see how link local is any more difficult than any other IPv6 address.
I also fail to see how this is significantly different from the way these devices work in IPv4. > We can't expect end-users to do the above procedure. > Of course not... End users will get a slip of paper with the computed Link Local already on it in the form of connect to http://[fe80::0245:4bff:feb9:02be]%xxx Where xxx will be en0 for Mac, eth0 for Linux, etc. If it's a wireless adapter, it will be en1 for Mac. Windows might get interesting as windows interface naming is, uh, creative at best. Owen
