Re: [v6ops] RFC 4291, link local address defination

[Ole Troan <[e-mail]>]

Praveen,

> Yeah that's is the problem here, RFC 4291 says it must be followed by 54 bits of 0. 
> So many implementations which may put this constraint and in such case fe80:4888:208:ff8b:aa:21:0:2 may get discarded.
> Should not we have one fix definition :).

probably. the formation of the link-local address is link-specific. which link-layer do you see this problem?
or is this manual configuration? I remember BSD used to put interface index in those bits, but I can't remember if they masked out those bits before putting packets on the wire.

cheers,
Ole


> 
> Thanks & Regards
> Praveen
> Juniper Networks
> 
> 
> -----Original Message-----
> From: Ole Troan [mailto:[e-mail]] 
> Sent: Wednesday, August 14, 2013 5:01 PM
> To: Praveen Chaudhary
> Cc: [e-mail]
> Subject: Re: [v6ops] RFC 4291, link local address defination
> 
> Praveen,
> 
>> As per RFC 4291 section 2.5.6 link local address are defines with the prefix fe80::/64, but many definition says even fe80::/10 qualifies as link local address.
>> Like on wiki:
>> "In the Internet Protocol Version 6 (IPv6), the address block fe80::/10 has been reserved for link-local unicast addressing.[2] The actual link local addresses are assigned with the prefix fe80::/64.[6][note 2] They may be assigned by automatic (stateless) or stateful e.g. manual) mechanisms."
>> 
>> So if we have an address as below, which does not match prefix condition, how an implementation should treat them.
>> fe80:4888:208:ff8b:aa:21:0:2
>> 
>> process as global address surely not ??, but as link local , it does not qualify. Kindly suggest.
> 
> FE80::/10 are reserved for link-local addresses, so they should be treated as link-locals in your implementation.
> 
> RFC4291 does not say that link-local addresses must be assigned from FE80::/64. it states that the prefix must be followed by 54 bits of 0. I agree that RFC4291 is a little ambiguous, and that the link-local address format should be defined like the global unicast address in section 2.5.4.
> 
> cheers,
> Ole
>