Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Owen DeLong <owen () delong com>]

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