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

From: Praveen Chaudhary <[email-masked]>
Date: Wed, 14 Aug 2013 10:52:05 +0000

Hi

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<http://en.wikipedia.org/wiki/IPv6> (IPv6), the address block fe80::/10 has been reserved for link-local unicast addressing.[2]<http://en.wikipedia.org/wiki/Link-local_address> The actual link local addresses are assigned with the prefix fe80::/64.[6]<http://en.wikipedia.org/wiki/Link-local_address>[note 2]<http://en.wikipedia.org/wiki/Link-local_address> 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.

Sorry if I am repeating a thread,

Thanks & Regards
Praveen

Juniper Networks

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Aug 2013 13:31:19 +0200

Praveen,

> “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.”
>  

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

---

From: Praveen Chaudhary <[email-masked]>
Date: Wed, 14 Aug 2013 11:40:12 +0000

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:[email-masked]] 
Sent: Wednesday, August 14, 2013 5:01 PM
To: Praveen Chaudhary
Cc: [email-masked]
Subject: Re: [v6ops] RFC 4291, link local address defination

Praveen,

> "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."
>  

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Aug 2013 13:52:26 +0200

Praveen,

> 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

---

From: Praveen Chaudhary <[email-masked]>
Date: Wed, 14 Aug 2013 12:11:02 +0000

These are manually configured on irb(logical) interface. (I was wondering if this config is correct).

Thanks & Regards
Praveen
Juniper Networks

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Wednesday, August 14, 2013 5:22 PM
To: Praveen Chaudhary
Cc: [email-masked]
Subject: Re: [v6ops] RFC 4291, link local address defination

Praveen,

cheers,
Ole

---

From: Tomoyuki Sahara <[email-masked]>
Date: Thu, 15 Aug 2013 09:36:57 +0900

NetBSD, a KAME-derived implementation, rejects incoming packets if one of
the source/destination addresses is in fe80:XXXX::/32 where XXXX != 0, and
we cannot send such packets in normal way on NetBSD.

Thanks,
Tomoyuki

On Wed, Aug 14, 2013 at 8:52 PM, Ole Troan <[email-masked]> wrote:

> > So many implementations which may put this constraint and in such case
> fe80:4888:208:ff8b:aa:21:0:2 may get discarded.
> 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
> >
> >
> >> 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::/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
> >
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>