Subject: Re: appropriate length of fe80:: prefix and new IP-over-foo drafts

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 16:59:42 +0200

Brian,

LEt me try to understand you.

Le 31/01/2019 à 23:35, Brian E Carpenter a écrit :
> Hi Fernando,
> On 2019-02-01 00:15, Fernando Gont wrote:
>> On 30/1/19 19:14, Brian E Carpenter wrote:
>>> Section 5.3 "Creation of Link-Local Addresses" of RFC4862 refers to
>>> an interface identifier of N bits and an fe80::0 prefix "of
>>> appropriate length", which according to the addressing architecture
>>> is 128-N. But N is undefined by RFC4862 and cannot be derived from an
>>> RA because all this happens as soon as the interface is enabled.
>>> Therefore N must be predefined.
>>
>> I guess that since link-local addresses are generated with SLAAC, at
>> least according to current specs that implies a prefix length of /64?
> 
> All the current specs (including the ones Alexandre mentioned) specify
> 64 bit IIDs for LL assignment. But as I pointed out, it isn't necessary
> that the same IID is used for LL creation and for a routeable address
> created later after receiving an RA/PIO. I can't see anything in nature
> or RFC4862 that requires the lengths to be the same either.
> 
> I have no problem with every ipv6-over-foo specifying 64 for the LL IID,
> or with implementations using the same IID for both LL and SLAAC, but
> these are choices, not rules.

I understand that you mean there is a choice where all ipv6-over-foo 
specify IID be 64.

I understand that is not a rule, but a choice; hence there is another 
choice where some ipv6-over-foo specifies IID to be not 64.

Do I get this right?

Alex

> 
> There's probably a privacy argument for *not* using the same IID for
> LL and routeable addresses.
> 
>>> As pioneered by RFC2464**, all ipv6-over-foo documents must therefore
>>> specify N for their link type. So far, everybody has specified 64, as
>>> far as I know. Is there a reason to do otherwise for the two drafts
>>> mentioned below?
>>
>> I'd regard that as an artifact of history ;-) , which made sense at a
>> time when we generated IIDs embedding MAC addresses in the IID.
>> Nowadays, I don't think there's a valid technical reason for a link
>> layer to specify the IID length. Why would they care? In fact, some
>> might even regard that as a layering violation...
> 
> You're 100% correct about the historical reason for this. It's quite
> amusing to see the magical 0xfffe appearing in draft-hou-6lo-plc
> for no obvious reason. But I think that an ipv6-over-foo MUST specify
> the IID length for LL addresses, because it's explicitly a free parameter
> N in RFC4862. Of course these days the IID bits should be specified
> as "see [RFC8064], [RFC7217]".
> 
>>> Why does it matter, since the unrouteable fe80::/(128-N) prefix is
>>> quite disjoint from the question of the routeable /64 prefix? All we
>>> care about is that it matches fe80::/10.
>>>
>>> (As a matter of curiousity, is there any particular reason to use the
>>> same IID to generate the LL address and the stable routeable address?
>>> It surely isn't necessary, otherwise temporary addresses wouldn't
>>> work.)
>>
>> Where I've found this "expectation", it has been associated with some
>> sort of "compression" -- some way to avoid storing or transmitting part
>> of the IP address because you can derive/imply it form elsewhere.
> 
> Which sounds like bad computer science. And again, temporary addresses
> seem to show that it is a wrong assumption.
> 
>      Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Apr 2019 11:41:44 +1200

> choice where some ipv6-over-foo specifies IID to be not 64.

I suggest looking at https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6
where the issue is discussed at some length.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Apr 2019 21:36:34 -0400

My understanding from the RFC for LL is that the 64 bits of network portion of the /10 must remain intact and cannot be altered. 

As a design best practice for IPv6 deployments that I have developed over the years is that we hardcore the IPv6 address 64 bits matching the global unicast configured on any interface with routing protocol enabled so the next hop is intuitive based on the global uni mapping the global uni LSB bits in the 64 bit network portion directly into the remaining bits proceeding the fe80 16 bit field so dropping the msb 16 bits so it fits into the 64 bit network portion of the LL address.  I believe from the RFC it’s a 50 bit field proceeding the fe80 first 16 bits so it’s that 50 bits of the global uni that we map over LSB over to the LL.

That being said from an mix vendor interoperability perspective for routing ospf or isis neighbor to come up the 64 bit network prefix must match and be contained within the 64 bit field or the routing adjacencies won’t form.  We actually had this issue as we did not drop the 1st 16 bits of the global uni when mapping it to the LL so had basically 16 bits that bled into the station ID and that caused the adjacencies to not build.

Thank you 

Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000

Sent from my iPhone

> On Jan 30, 2019, at 10:17 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> I wanted to let the group know that at least two new IP-over-foo drafts do use 64 as prefix length for link-local addresses. (draft-ietf-lpwan-ipv6-static-context-hc-18 and  draft-hou-6lo-plc).
> 
> I think it should not be that way.
> 
> I think the prefix length of link-local addresses is a minimum 10 and a maximum 127. (draft-petrescu-6man-ll-prefix-len-06)
> 
> Alex
> 
>> Le 14/12/2018 à 15:37, Yucel Guven a écrit :
>> Alex,
>> Absolutely agree.  "A 'prefix' must have a prefix length."
>> Not specific for Link-Local, but I suggest to add your draft:
>> "prefix: a contiguous string of bits valid for forwarding operations
>> and for subnet formation. A prefix must have an integer length value from 1 to 127
>> and prefix-length must be indicated in its textual representation."
>> -Yucel Guven
>> On Mon, Dec 10, 2018 at 9:28 PM Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>>    Le 30/11/2018 à 19:57, 神明達哉 a écrit :
>>     > At Fri, 30 Nov 2018 10:33:01 +0100, Alexandre Petrescu
>>     > <[email-masked]
>>    <mailto:[email-masked]>
>>    <mailto:[email-masked]
>>    <mailto:[email-masked]>>>
>>     > wrote:
>>     >
>>     >> [...]> Why? Since everybody agrees that the 54 bits are always
>>     >> zero,
>>     > I have
>>     >>> no idea what the problem is that led to this thread.
>>     >>
>>     >> Brian, I trust this question is not provokative.  Also, I seriously
>>     >> try to avoid the situation Ole points about disagreeing just for
>>     >> the easiness of it.
>>     >>
>>     >> Let me try to explain my problem.
>>     >>
>>     >> I am routinely confronted with links on which link-local addresses
>>     >> are very important: ptp links on 4G, intermediary router-to-router
>>     >> WiFi GUA-less links, and others.
>>     >>
>>     >> I am under a strong requirement from end users migrating to IPv6 to
>>     >> use simple to memorize IPv6 addresses (they routinely do IPv4
>>     >> 192.168.1.2 hard-coded in many places).  This primes over the
>>     >> privacy requirements, which are present too, but as a second.  This
>>     >> phase of using IPv6 with simple to remember addresses but an
>>     >> initial step, before bringing in more complex addresses.  If I fail
>>     >> this initial step then IPv6 will not be used, because IPv4 is
>>     >> simpler to be used there.  The users must be able to be quickly
>>     >> succeed with ping6 as they are with ping.
>>     >>
>>     >> Under these circumstances I am led to design a WiFi ad-hoc network
>>     >> of routers with LL prefixes and addresses like fe80:1::2/32.  The 1
>>     >> means the LL Subnet ID 1, and 2 means the IID of a particular
>>     >> router.
>>     >
>>     > So far it's understandable (except, of course, that fe80:1::2
>>     > violates Section 2.5.6 of RFC4291 and is not standard-compliant).
>>     >
>>     >> Is fe80:1::2 a link-local address?  Yes and no.  Yes, because it
>>     >> falls within the "fe80::/10" block reserved by IANA for LL
>>     >> purposes.  No, because it has a 1 somewhere in the 54bits thus
>>     >> contradicting RFC4291's definition of a link-local address.
>>     >
>>     > Now you're unnecessarily making your actual problem a terminology
>>     > nitpicking.
>>    It is not nitpicking.
>>    It is true that hexadecimal 3FA is the leftmost 10 bits of an IPv6
>>    link-local address (binary 1111111010).  We just cant write 3FA with our
>>    existing IPv6 textual notation method which groups 'hextets'; because of
>>    that notation we must write fe80::/10.  Yet that does not make 3fa a
>>    prefix, no more than 1111111010 is.  A 'prefix' must have a prefix
>>    length.
>>    I will update the draft about this, calling this a Difficulty.
>>    Alex
>>        I suspect that's one major reason why we cannot have very
>>     > productive discussion in this thread.  Even if there's some kind of
>>     > small ambiguity about the term of "link-local unicast address (or
>>     > prefix)", as long as we have Section 2.5.6 of RFC4291 it doesn't
>>     > affect the fact that you can't use fe80:1::2 without being
>>     > non-compliant.
>>     >
>>     > If you have a specific operational problem that could be resolved by
>>     > loosening the requirement of Section 2.5.6 of RFC4291 (i.e.,
>>     > allowing non-0 values for the intermediate 54 bits), you should
>>     > simply propose that with the problem description.  The proposal may
>>     > or may not be accepted, of course, but at least the discussion will
>>     > be more focused that way.
>>     >
>>     > BTW, I don't know if it helps in your specific case, but you may
>>     > want to look at RFC4007.  It tries to answer this exact problem with
>>     > an extended syntax for scoped addresses.  So, you might use
>>     > "fe80::2%1" instead of "fe80:1::2".
>>     >
>>     > -- JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 11:17:06 +0200

Le 18/04/2019 à 03:36, Gyan Mishra a écrit :
> My understanding from the RFC for LL is that the 64 bits of network 
> portion of the /10 must remain intact and cannot be altered.

What do you mean by intact?

Do you mean the inner 54bits of an LL address must always be reset (i.e.
==0)?

Why?

Or do you mean that the inner 54bits of a literal representing an IPv6 
link-local address must not be touched by the inner data structure 
representation of a link-local address, which may mangle these 54bits 
with a Zone ID?

> As a design best practice for IPv6 deployments that I have developed
>  over the years is that we hardcode the IPv6 address 64 bits matching
> the global unicast configured on any interface

Well, I hope that hardcoding is on a variable bit boundary, not an exact
  match on 64bits.

Exact matching on precise boundaries is not IP.  It is more like
Ethernet address matching, or maybe some preliminary firewall filtering
rules.

> with routing protocol enabled so the next hop is intuitive based on
> the global uni mapping the global uni LSB bits in the 64 bit network
> portion directly into the remaining bits proceeding the fe80 16 bit
> field so dropping the msb 16 bits so it fits into the 64 bit network
> portion of the LL address.

Longest-prefix match should happen on variable length bit boundaries, 
not on byte boundaries, even less on 64bit boundaries.

Many times probably the best and fastest boundary is 64bit, but not always.

> I believe from the RFC it’s a 50 bit field proceeding the fe80 first
> 16 bits so it’s that 50 bits of the global uni that we map over LSB
> over to the LL.

It's 54 bits between fe80::/10 and 64bit IID, if you count them.

> That being said from an mix vendor interoperability perspective for 
> routing ospf or isis neighbor to come up the 64 bit network prefix
> must match and be contained within the 64 bit field or the routing 
> adjacencies won’t form.  We actually had this issue as we did not
> drop the 1st 16 bits of the global uni when mapping it to the LL so
> had basically 16 bits that bled into the station ID and that caused
> the adjacencies to not build.

But, there is an RFC Best Common Practice that I co-author and that says
forwarding involves bitwise operations, not fixed boundaries.

The mixed vendor interoperability is fine, but one should also  consider 
other vendors that are not in the mix.  Will they all implement these 
fixed boundaries?

Alex

> 
> Thank you
> 
> Gyan S. Mishra IT Network Engineering & Technology Consultant Routing
> & Switching / Service Provider MPLS & IPv6 Expert 
> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT> 
> Mobile – 202-734-1000 <tel:202-734-1000>
> 
> Sent from my iPhone
> 
> On Jan 30, 2019, at 10:17 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>> I wanted to let the group know that at least two new IP-over-foo 
>> drafts do use 64 as prefix length for link-local addresses. 
>> (draft-ietf-lpwan-ipv6-static-context-hc-18 and
>> draft-hou-6lo-plc).
>> 
>> I think the prefix length of link-local addresses is a minimum 10
>> and a maximum 127. (draft-petrescu-6man-ll-prefix-len-06)
>> 
>> Alex
>> 
>>> Alex, Absolutely agree.  "A 'prefix' must have a prefix length." 
>>> "prefix: a contiguous string of bits valid for forwarding
>>> operations and for subnet formation. A prefix must have an
>>> integer length value from 1 to 127 and prefix-length must be
>>> indicated in its textual representation." -Yucel Guven On Mon,
>>> Dec 10, 2018 at 9:28 PM Alexandre Petrescu 
>>> <mailto:[email-masked]>> wrote: Le 30/11/2018 à
>>> 19:57, 神明達哉 a écrit :
>>>>> [...]> Why? Since everybody agrees that the 54 bits are
>>>>> always zero,
>>>> I have
>>>>> try to avoid the situation Ole points about disagreeing just
>>>>> for the easiness of it.
>>>>> 
>>>>> I am routinely confronted with links on which link-local
>>>>> addresses are very important: ptp links on 4G, intermediary
>>>>> router-to-router WiFi GUA-less links, and others.
>>>>> 
>>>>> use simple to memorize IPv6 addresses (they routinely do
>>>>> IPv4 192.168.1.2 hard-coded in many places).  This primes
>>>>> over the privacy requirements, which are present too, but as
>>>>> a second.
>>> This
>>>>> initial step, before bringing in more complex addresses.  If
>>>>> I
>>> fail
>>>>> this initial step then IPv6 will not be used, because IPv4
>>>>> is simpler to be used there.  The users must be able to be
>>>>> quickly succeed with ping6 as they are with ping.
>>>>> 
>>>>> Under these circumstances I am led to design a WiFi ad-hoc
>>>>> network of routers with LL prefixes and addresses like
>>>>> fe80:1::2/32.
>>> The 1
>>>>> means the LL Subnet ID 1, and 2 means the IID of a
>>>>> particular router.
>>>> 
>>>>> Is fe80:1::2 a link-local address?  Yes and no.  Yes, because
>>>>> it falls within the "fe80::/10" block reserved by IANA for
>>>>> LL purposes.  No, because it has a 1 somewhere in the 54bits
>>>>> thus contradicting RFC4291's definition of a link-local
>>>>> address.
>>>> 
>>>> Now you're unnecessarily making your actual problem a
>>>> terminology nitpicking.
>>> It is not nitpicking. It is true that hexadecimal 3FA is the
>>> leftmost 10 bits of an IPv6 link-local address (binary
>>> 1111111010).  We just cant write 3FA with our existing IPv6
>>> textual notation method which groups 'hextets'; because of that
>>> notation we must write fe80::/10.  Yet that does not make 3fa a 
>>> prefix, no more than 1111111010 is.  A 'prefix' must have a
>>> prefix length. I will update the draft about this, calling this a
>>> Difficulty. Alex I suspect that's one major reason why we cannot
>>> have very
>>>> productive discussion in this thread.  Even if there's some
>>>> kind of small ambiguity about the term of "link-local unicast
>>>> address (or prefix)", as long as we have Section 2.5.6 of
>>>> RFC4291 it doesn't affect the fact that you can't use fe80:1::2
>>>> without being non-compliant.
>>>> 
>>>> allowing non-0 values for the intermediate 54 bits), you
>>>> should simply propose that with the problem description.  The
>>>> proposal may or may not be accepted, of course, but at least
>>>> the discussion will be more focused that way.
>>>> 
>>>> BTW, I don't know if it helps in your specific case, but you
>>>> may want to look at RFC4007.  It tries to answer this exact
>>>> problem
>>> with
>> [email-masked] <mailto:[email-masked]> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 12:38:34 +0200

> where the issue is discussed at some length.

Thanks for the reference, I will read it and insert it.

I always wondered why the real authors chose a fictitious name.  Maybe 
you know.

Pseudonyms may some times put trust at risk, other times enhance it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 12:59:23 +0200

> where the issue is discussed at some length.

Yes, but it does not talk about IP-over-foo.

I was under the impression that you thought IPv6-over-foo were free to 
specify the IID length they needed.  I might be wrong though.

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 18 Apr 2019 12:34:17 -0400

Alex

I have done some interoperability testing between Cisco Nexus switch &
Checkpoint firewall & Citrix Netscaler load balancer and we have had issues
where the IPv6 LL was coded but was greater then 64 bits however the
problem is other vendors do not support changing the prefix length to be
larger then 64 bits so from further troubleshooting we were only able to
get OSPF neighbor to come up if we kept the prefix length of the LL on the
Cisco Nexus to 64 bits maximum length and the OSPF neighbor came up.

The Citrix & Firewall had default EUI64 which what happens is by default
the is FE80::{EUI64} so you have a 64 bit length prefix on the Citrix &
Firewall appliances that cannot change their Link local values to greater
then 64 bits.  So to accommodate the devices not able to change the link
local value to greater then 64bit prefix we ended up changing the Nexus to
64bit prefix and firewall & citrix remained with the Default FE80::{EUI64}
and the OSPF neighbor came up.

We had cases where Cisco to Cisco we were OK with going over 64bit as long
as the mask lenght matched but when you have multi vendor environment it
does not work as not all vendors allow changing the link local address thus
we had to change our IT network standard for all of my customers running
IPv6 to only use 64bit prefix length max for Link local.

This is the use case scenario which I mentioned where we map the global uni
64bit prefix into the LL but had to drop the 1st 16bits of the global UNI
as workaround so we don't bleed 16 bits into the station id and conform
with the 64 bit maximum prefix length for inter vendor interoperability.

So I can see it would be nice to do greater but given the EUI64 default and
vendors not supporting and issues with multi vendor environment and the
problems it has caused I would like to see the RFC be more strict and not
allow link local prefix to be greater then 64 bits.

Thank you

I agree that the LL address if modified the prefix length for the LL should
be maximum of 64 bits and not bleed into the station id portion larger
prefix length then 64 bits.

RFC 3513:

2.5.6 <https://tools.ietf.org/html/rfc3513#section-2.5.6> Local-Use
IPv6 Unicast Addresses

   There are two types of local-use unicast addresses defined.  These
   are Link-Local and Site-Local.  The Link-Local is for use on a single
   link and the Site-Local is for use in a single site.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with link-local source or
   destination addresses to other links.

   Site-Local addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

   Site-local addresses are designed to be used for addressing inside of
   a site without the need for a global prefix.  Although a subnet ID
   may be up to 54-bits long, it is expected that globally-connected
   sites will use the same subnet IDs for site-local and global
   prefixes.

   Routers must not forward any packets with site-local source or
   destination addresses outside of the site.

Gyan S. Mishra

On Wed, Jan 30, 2019 at 10:17 AM Alexandre Petrescu <
[email-masked]> wrote:

> I wanted to let the group know that at least two new IP-over-foo drafts
> do use 64 as prefix length for link-local addresses.
> (draft-ietf-lpwan-ipv6-static-context-hc-18 and  draft-hou-6lo-plc).
>
> I think the prefix length of link-local addresses is a minimum 10 and a
> maximum 127. (draft-petrescu-6man-ll-prefix-len-06)
>
> Alex
>
> > On Mon, Dec 10, 2018 at 9:28 PM Alexandre Petrescu
> addresses
> network

-- 
Gyan S. Mishra

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 19:27:45 +0200

Gyan,

I would like to invite you to co-author the draft.  Please provide me in 
private your affiliation data (email address, and your organisation 
name, at a minimum).

The current text in the draft suggests that the length of the link-local 
prefix ranges between 10 and 64.  I hope you support that statement.

The text that you write below should be improved a bit and to express 
implementation aspects of the above goal.

But, let me make sure: if you think we are not right to request the 
link-local prefix to be of variable length; i.e. you think it must 
always be 64, then I dont think it is worth the effort for you to spend 
time on this.

(there is already another person in that situation, and I want to avoid 
it again).

Thank you,

Alex

Le 18/04/2019 à 18:34, Gyan Mishra a écrit :
> Checkpoint firewall & Citrix Netscaler load balancer and we have had 
> issues where the IPv6 LL was coded but was greater then 64 bits however 
> the problem is other vendors do not support changing the prefix length 
> to be larger then 64 bits so from further troubleshooting we were only 
> able to get OSPF neighbor to come up if we kept the prefix length of the 
> LL on the Cisco Nexus to 64 bits maximum length and the OSPF neighbor 
> came up.
> 
> Firewall appliances that cannot change their Link local values to 
> greater then 64 bits.  So to accommodate the devices not able to change 
> the link local value to greater then 64bit prefix we ended up changing 
> the Nexus to 64bit prefix and firewall & citrix remained with the 
> Default FE80::{EUI64} and the OSPF neighbor came up.
> 
> We had cases where Cisco to Cisco we were OK with going over 64bit as 
> long as the mask lenght matched but when you have multi vendor 
> environment it does not work as not all vendors allow changing the link 
> local address thus we had to change our IT network standard for all of 
> my customers running IPv6 to only use 64bit prefix length max for Link 
> local.
> 
> This is the use case scenario which I mentioned where we map the global 
> uni 64bit prefix into the LL but had to drop the 1st 16bits of the 
> global UNI as workaround so we don't bleed 16 bits into the station id 
> and conform with the 64 bit maximum prefix length for inter vendor 
> interoperability.
> 
> So I can see it would be nice to do greater but given the EUI64 default 
> and vendors not supporting and issues with multi vendor environment and 
> the problems it has caused I would like to see the RFC be more strict 
> and not allow link local prefix to be greater then 64 bits.
> 
> Thank you
> 
> 
> 
> I agree that the LL address if modified the prefix length for the LL 
> should be maximum of 64 bits and not bleed into the station id portion 
> larger prefix length then 64 bits.
> 
> RFC 3513:
> 
> 
>         2.5.6 <https://tools.ietf.org/html/rfc3513#section-2.5.6>
>         Local-Use IPv6 Unicast Addresses
> 
> 
> 
> On Wed, Jan 30, 2019 at 10:17 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >
>      >      > At Fri, 30 Nov 2018 10:33:01 +0100, Alexandre Petrescu
>      >      > <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>>
>      >      > wrote:
>      >      >
>      >      >> [...]> Why? Since everybody agrees that the 54 bits are
>     always
>      >      >> zero,
>      >      > I have
>      >      >>> no idea what the problem is that led to this thread.
>      >      >>
>      >      >> Brian, I trust this question is not provokative.  Also, I
>     seriously
>      >      >> try to avoid the situation Ole points about disagreeing
>     just for
>      >      >> the easiness of it.
>      >      >>
>      >      >> Let me try to explain my problem.
>      >      >>
>      >      >> I am routinely confronted with links on which link-local
>     addresses
>      >      >> are very important: ptp links on 4G, intermediary
>     router-to-router
>      >      >> WiFi GUA-less links, and others.
>      >      >>
>      >      >> I am under a strong requirement from end users migrating
>     to IPv6 to
>      >      >> use simple to memorize IPv6 addresses (they routinely do IPv4
>      >      >> 192.168.1.2 hard-coded in many places).  This primes over the
>      >      >> privacy requirements, which are present too, but as a
>     second.  This
>      >      >> phase of using IPv6 with simple to remember addresses but an
>      >      >> initial step, before bringing in more complex addresses. 
>     If I fail
>      >      >> this initial step then IPv6 will not be used, because IPv4 is
>      >      >> simpler to be used there.  The users must be able to be
>     quickly
>      >      >> succeed with ping6 as they are with ping.
>      >      >>
>      >      >> Under these circumstances I am led to design a WiFi
>     ad-hoc network
>      >      >> of routers with LL prefixes and addresses like
>     fe80:1::2/32.  The 1
>      >      >> means the LL Subnet ID 1, and 2 means the IID of a particular
>      >      >> router.
>      >      >
>      >      > So far it's understandable (except, of course, that fe80:1::2
>      >      > violates Section 2.5.6 of RFC4291 and is not
>     standard-compliant).
>      >      >
>      >      >> Is fe80:1::2 a link-local address?  Yes and no.  Yes,
>     because it
>      >      >> falls within the "fe80::/10" block reserved by IANA for LL
>      >      >> purposes.  No, because it has a 1 somewhere in the 54bits
>     thus
>      >      >> contradicting RFC4291's definition of a link-local address.
>      >      >
>      >      > Now you're unnecessarily making your actual problem a
>     terminology
>      >      > nitpicking.
>      >
>      >     It is not nitpicking.
>      >
>     prefix
>      >      > productive discussion in this thread.  Even if there's
>     some kind of
>      >      > small ambiguity about the term of "link-local unicast
>     address (or
>      >      > prefix)", as long as we have Section 2.5.6 of RFC4291 it
>     doesn't
>      >      > affect the fact that you can't use fe80:1::2 without being
>      >      > non-compliant.
>      >      >
>      >      > If you have a specific operational problem that could be
>     resolved by
>      >      > loosening the requirement of Section 2.5.6 of RFC4291 (i.e.,
>      >      > allowing non-0 values for the intermediate 54 bits), you
>     should
>      >      > simply propose that with the problem description.  The
>     proposal may
>      >      > or may not be accepted, of course, but at least the
>     discussion will
>      >      > be more focused that way.
>      >      >
>      >      > BTW, I don't know if it helps in your specific case, but
>     you may
>      >      > want to look at RFC4007.  It tries to answer this exact
>     problem with
>      >      > an extended syntax for scoped addresses.  So, you might use
>      >      > "fe80::2%1" instead of "fe80:1::2".
>      >      >
>      >      > -- JINMEI, Tatuya
>      >
> 
>     [email-masked] <mailto:[email-masked]>