Subject: RE: What is the length of the Link-Local prefix?

From: "Suresh Krishnan (QB/EMC)" <[email-masked]>
Date: Wed, 27 Aug 2003 09:57:23 -0500

Hi Chirayu,
	No. You cannot use fe81::/16 as a link local address. Even though the RFC states that the prefix is fe80::/10 it really should be fe80::/64. Section 2.5.6 of RFC3513 explicitly states that the 54 bits following 1111111010 should be set to 0 and thus the only allowable prefix is fe80::/64.

Regards
Suresh

-----Original Message-----
From: Chirayu Patel [mailto:[email-masked]]
Sent: Wednesday, August 27, 2003 8:49 AM
To: [email-masked]
Subject: What is the length of the Link-Local prefix?

I was always under the assumption that the prefix is fe80::/64, and not
fe80::/10. However, the latest and the best version of the Addressing
Architecture [RFC 3513] states the prefix as fe80::/10. Does it mean that
fe81::/16 can also be used as a link local prefix (note : section 2.5.6 in RFC
3513 says that the next 54 bits after the prefix should be zero)?

A grep for fe80 in my rfc repository yields (note: the fe80::/64, and
fe80::/10) 

----
rfc2464.txt:179:   the prefix FE80::/64.
rfc2467.txt:252:   prefix FE80::/64.
rfc2470.txt:299:   prefix FE80::/64.
rfc2491.txt:1259:   token, as defined above, to the prefix FE80::/64.
rfc2497.txt:135:   prefix FE80::/64.
rfc2529.txt:184:   the prefix FE80::/64.
rfc2529.txt:296:   cases with the prefix FE80::/64. Note that the prefix-
rfc2546.txt:98:   The link-local prefix (FE80::/10) MUST NOT be advertised 
rfc2590.txt:480:   above, to the prefix FE80::/64 [AARCH].
rfc2740.txt:1751:     Link-local Interface Address = fe80:0001::RT3
rfc2772.txt:156:   This link-local prefix (FE80::/10) MUST NOT be advertised
through
rfc2893.txt:966:   the prefix FE80::/64.
rfc3146.txt:152:   the prefix FE80::/64.
rfc3484.txt:1034:      fe80::/10             33     1
rfc3513.txt:327:   Link-local unicast   1111111010           FE80::/10       
----

Am I missing something? 

Thanks,
CP

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 27 Aug 2003 17:19:25 +0100

On Wed, Aug 27, 2003 at 09:57:23AM -0500, Suresh Krishnan (QB/EMC) wrote:
> Hi Chirayu,
> 	No. You cannot use fe81::/16 as a link local address

Of course you can.

> Even though the RFC states that the prefix is fe80::/10 it really should be fe80::/64. Section 2.5.6 of RFC3513 explicitly states that the 54 bits following 1111111010 should be set to 0 and thus the only allowable prefix is fe80::/64.

The contents of the 54 bits are only a should,  as such one can use whatever
one wants in there.

Nothing breaks (wrt normal LL address usage) if those 54 bits have non zero
values.

Certainly a given platform shouldn't object to finding non zero values in
a LL packet it receives (e.g. say a src address of fe80:1910::10).

DF

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 27 Aug 2003 11:14:53 -0700

On Aug 27, 2003, at 9:19 AM, Derek Fawcus wrote:

>> Even though the RFC states that the prefix is fe80::/10 it really 
>> should be fe80::/64. Section 2.5.6 of RFC3513 explicitly states that 
>> the 54 bits following 1111111010 should be set to 0 and thus the only 
>> allowable prefix is fe80::/64.
>

Actually, you'll run in to some issues with any IPv6 stack based on 
Kame's implementation. Kame makes use of some of those bits to embed 
the scope id in some places while packets are handled in the kernel and 
in a few cases this may be used between the kernel/userspace boundary. 
Arguably, it's not the right thing for the stack to do, but it is done.

-josh

---

From: "Chirayu Patel" <[email-masked]>
Date: Thu, 28 Aug 2003 08:26:03 +0530

If the next 54 bits are always expected to be zero then the prefix should be
declared to fe80::/64, and RFC 3513 should be corrected.

Do any of the old timers have a take on this one? Jim, Keith, Tony, Brian.....
anyone? :-)

CP

---

From: "Chirayu Patel" <[email-masked]>
Date: Thu, 28 Aug 2003 10:05:47 +0530

> Arguably, it's not the right thing for the stack to do, but it is done.

FYI, from what I can see, USAGI will work with fe80::/10.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Aug 2003 11:00:25 +0200

In your previous mail you wrote:

   
=> there is a semantic problem:
 - if the question is how to distinguish link-locals using a prefix
   notation, the answer is fe80::/10.
 - if the question is what kind of link-local prefixes should be used,
   for instance in routing tables (i.e., in concrete instances), then
   the answer is fe80::/64 and in general with a zone id (aka scope id)
   constraint, i.e., fe80::/64%<link-id>.

Regards

[email-masked]