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

[Praveen Chaudhary <[e-mail]>]

Thanks Ole

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 :).

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