[Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Owen DeLong
owen at delong.com
Mon Apr 26 06:41:16 UTC 2010
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
More information about the NANOG
mailing list