>From the thread cited: > Or did the authors really intend that most of fe80::/10 > remain unused, and *only* a single /64 at the very > start of fe80::/10 would be valid?
Right. The intent was a bit clearer in RFC 3513, which RFC 4291 obsoletes. Section 4 has: > The initial assignment of IPv6 address space is as follows: > > Allocation Prefix Fraction of > (binary) Address Space > ----------------------------------- -------- ------------- ... > Link-Local Unicast Addresses 1111 1110 10 1/1024 > Site-Local Unicast Addresses 1111 1110 11 1/1024 And yet a bit clearer in RFC 2373 (and RFC 1884 the original). It has the same as above plus: > The only address prefixes which should be predefined in an > implementation are the: > > o Unspecified Address > o Loopback Address > o Multicast Prefix (FF) > o Local-Use Prefixes (Link-Local and Site-Local) > o Pre-Defined Multicast Addresses > o IPv4-Compatible Prefixes So they define the /10 as the link local *prefix*, within which any *addresses* have to fall into the /64. The rest of the /10 is unused but is still defined as link-local scope. -Dave > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alexandru Petrescu > Sent: Monday, May 07, 2012 12:51 AM > To: [email protected] > Subject: Re: There are claims of ambiguity over what is a link-local address > > That ambiguity around the prefix length /10 vs /64 of a link-local address > should be clarified. > > If clarified, among other advantages, it would allow to write C code which, > when typing "ifconfig eth0 add fe80::1" it would know to fill in the prefix > length by itself, and not wonder about which length should it be. > > Alex > > Le 07/05/2012 08:56, Brian E Carpenter a écrit : > > On 2012-05-07 00:59, Mark Andrews wrote: > >> See the nanog thread starting here: > >> http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html > >> > > > > I'm sure the intention was to reserve the entire /10 prefix but it's > > correct that the RFC is not clear about this. Seems like an erratum is > > needed. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list [email protected] Administrative > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
