[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