Subject: Re: SLAAC RFC4862 - appropriate length of fe80:: prefix

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Nov 2018 17:43:15 +0100

Tatuya,

I just wanted to let you know about this, as a side note.

Le 20/09/2018 à 20:57, 神明達哉 a écrit :
[context]

>  > > The short answer would be:
>  > > - "the link-local prefix" is fe80::/10
>  > > - "the bits" in bullet #2 are the rightmost 118 bits
>  >
>  > Thus, an address is made of 3 parts (10bit of network prefix, 54 0 bits,
>  > and the 64bits of the Interface ID), not of 2 parts (network prefix,
>  > Interface ID).
> 
> In this context the 10 bit prefix is not a "network prefix" but a
> "link-local prefix" (to autoconfigure a link-local address), but other
> than that, yes, it can consist of three parts if the interface
> identifier is longer than 64 bits: the 10-bit link-local prefix,
> intermediate bits, and the interface identifier.  I don't see RFC4862
> says anything against it.

The pppd program uses fe80::/10 and interface id of length 118.

I just tested it on a very recent IoT device connected on 4G.

(pppd 'option' called 'ipv6' needs at least one argument which is the 
Interface ID, which is then combined to fe80::/10 and gives an address 
fe80::1/10).

I think this is reason enough to consider that the length of the 
link-local prefix on some point-to-point links is 10, and not 64.

Alex
> 
>  > The inner 54 0 bits have no name.  They are neither subnet prefix, nor
>  > Interface ID.
> 
> Correct, and I don't see the absolute need for it to have a name.
> So...
> 
>  > It is strange.
> 
> ...I don't see what's strange.  There are many things that don't have
> a name (e.g. as far as I know the intermediate 'ffff' 16 bits of
> IPv4-mapped IPv6 addresses don't have a defined name), and I just see
> this case as one of such things.  But if you have a particular problem
> like interoperability failure due to the fact that these intermediate
> bits aren't given a name, please feel free to write a draft to explain
> the problem and how naming the bits solves the problem.  With some
> energy and luck, it might eventually be published as an RFC and might
> help someone else.
> 
> --
> JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 19 Nov 2018 08:58:23 -0800

At Mon, 19 Nov 2018 17:43:15 +0100,

> link-local prefix on some point-to-point links is 10, and not 64.

I'm not sure how to interpret this additional note in the original
context, where I said the length of the "link-local prefix" referenced
in the bullet #1 of Section 5.3 of RFC4862

   1.  The left-most 'prefix length' bits of the address are those of
       the link-local prefix.

is 10.  It's ambiguous to me what "fe80::/10" means (whether it means
the "prefix length" of the above bullet or the "subnet prefix" per
RFC 4291), but if it's the former, that's just consistent with what I
said, and it's not even really specific to point-to-point links.  If
it means the latter, it's irrelevant to the original context (Section
5.3 of RFC4862) anyway.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Nov 2018 13:37:31 -0800

> On Nov 19, 2018, at 8:43 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> I think this is reason enough to consider that the length of the link-local prefix on some point-to-point links is 10, and not 64.

Except that this disagrees with the definition of the prefix.

https://tools.ietf.org/html/rfc4291#section-2.5.6 defines the link-local prefix.
https://tools.ietf.org/html/rfc4291#section-2.5.7 defines the site-local prefix.

https://tools.ietf.org/html/rfc3879 deprecated site-local. The inclusion of the definition in RFC 4291 was because, while deprecated, the site-local prefix was still *defined*. I see no RFC before or since that says otherwise. Hence, I conclude that FE8::/64 with the 54 low-order bits of the prefix zero is a link-local address, and the other 2^54-1 values in FE8::/64 are part of a weirdly-defined and deprecated prefix. That doesn't make them link-local.

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Musa Stephen Honlue <[email-masked]>
Date: Tue, 20 Nov 2018 07:17:05 +0300

I thought this was clear enough?

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

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

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

The 54 bits to 0 is not optional but part of the prefix, thus prefix is
fe80::/64.
So far haven't seen an implementation with the /10.
So my question is: what problem are we trying to solve?

Regards.

On Tue, 20 Nov 2018, 00:37 Fred Baker <[email-masked] wrote:

> https://tools.ietf.org/html/rfc3879 deprecated site-local. The inclusion
> of the definition in RFC 4291 was because, while deprecated, the site-local
> prefix was still *defined*. I see no RFC before or since that says
> otherwise. Hence, I conclude that FE8::/64 with the 54 low-order bits of
> the prefix zero is a link-local address, and the other 2^54-1 values in
> FE8::/64 are part of a weirdly-defined and deprecated prefix. That doesn't
> make them link-local.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Nov 2018 10:52:54 +0100

Le 20/11/2018 à 05:17, Musa Stephen Honlue a écrit :
>         2.5.6 <https://tools.ietf.org/html/rfc4291#section-2.5.6>.
>         Link-Local IPv6 Unicast Addresses
> 
> 
> 

You are saying "54 bits to is not optional but part of the prefix". 
That is you who is saying that.  Others also think that way.  But the 
RFC 4291 does not say that.

Worse, it calls an "IPv6 notation" of the "LL unicast" to be "fe80::/10" 
(sec. 2.4).  It is further aggravated by the '/' character not being 
defined in any RFC despite its widespread use as a separator for prefix 
length (i.e. X in A::/X means a prefix length).

> So far haven't seen an implementation with the /10.

Please try the pppd software.   It is open source on linux.

Its 'options' file needs an 'ipv6' option, which in turn needs at least 
one Interface ID (the local interface's).  That Interface ID parameter 
does not specify a parameter.

After having run the pppd command, and obtained a connection, check the 
addresses on the interface by using the 'ifconfig' command.  If the 
Interface ID was, for example, ::1, the ifconfig output will show 
'fe80::1/10'.

> So my question is: what problem are we trying to solve?

I am trying to write a recommendation for the prefix length of the link 
local addresses (see draft-petrescu-6man-ll-prefix-len-00.)

Alex

> 
> Regards.
> 
> On Tue, 20 Nov 2018, 00:37 Fred Baker <[email-masked] 
> <mailto:[email-masked]> wrote:
> 
> 
> 
>      > On Nov 19, 2018, at 8:43 AM, Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >
>     https://tools.ietf.org/html/rfc3879 deprecated site-local. The
>     inclusion of the definition in RFC 4291 was because, while
>     deprecated, the site-local prefix was still *defined*. I see no RFC
>     before or since that says otherwise. Hence, I conclude that FE8::/64
>     with the 54 low-order bits of the prefix zero is a link-local
>     address, and the other 2^54-1 values in FE8::/64 are part of a
>     weirdly-defined and deprecated prefix. That doesn't make them
>     link-local.
> 
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Nov 2018 11:19:40 +0100

> https://tools.ietf.org/html/rfc4291#section-2.5.6 defines the link-local prefix.

Fred, I tend to agree, but that pointer defines an address, not a prefix.

> 2.5.6.  Link-Local IPv6 Unicast Addresses
> 
>    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.

> inclusion of the definition in RFC 4291 was because, while deprecated,
> the site-local prefix was still *defined*. I see no RFC before or since
> that says otherwise. Hence, I conclude that FE8::/64 with the 54
> low-order bits of the prefix zero is a link-local address,

Fred, I think you may be right to conclude so.

For my part, I do not conclude so.

It looks as being a 'stretch': we think fe80::/64 is a link-local prefix 
because of reason X and Y.  It would be much easier to think fe80::/64 
were the link-local prefix if it was written down as such, not as a 
conclusion of a reasoning.

> and the other
> 2^54-1 values in FE8::/64 are part of a weirdly-defined and deprecated
> prefix. That doesn't make them link-local.

Do you mean fe80:1::/64 is _not_ a link-local prefix?

Alex

---

From: Dennis Ferguson <[email-masked]>
Date: Tue, 20 Nov 2018 11:00:43 -0800

> On Nov 19, 2018, at 13:37, Fred Baker <[email-masked]> wrote:
> 
>> 

It is bothering me that I don’t understand this argument at all.

https://tools.ietf.org/html/rfc3513#section-2.4 defines site-local addresses as having a prefix of FEC0::/10. Their deprecation can have no apparent effect on addresses with a prefix of FE80::/10 since no addresses with a prefix of FEC0::/10 have a prefix of FE80::/10. More than this the site-local addresses themselves weren’t deprecated, what was deprecated was the special-case border-patrol handling of them by routers, turning them into ordinary global unicast addresses. This is explicitly mentioned in your Section 2.5.7.

Link-local addresses also require special handling, it is this special handling that makes them link-local addresses. Routers need to avoid forwarding packets carrying link-local addresses off the link, and hosts should understand that link-local destinations are only reachable if they are directly reachable. To implement this special handling requires that routers and hosts know the prefix that identifies an address as link-local; ambiguity about what that prefix is will result in packets being mis-directed. Is there any doubt that the prefix that identifies link-local addresses in forwarding operations should be FE80::/10?

Dennis Ferguson

---

From: Sander Steffann <[email-masked]>
Date: Tue, 20 Nov 2018 21:42:39 +0100

Hi,

> Link-local addresses also require special handling, it is this special handling that makes them link-local addresses. Routers need to avoid forwarding packets carrying link-local addresses off the…

I don't think so. The spec says that fe80::/10 is link-local. On ethernet the subnet prefix length is /64, and the 54 bits in the middle have to be 0, so it uses fe80::/64 on the link. AFAICT Alexandre just wants this written down in a single document.

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Nov 2018 11:04:57 +0100

Le 20/11/2018 à 21:42, Sander Steffann a écrit :
> Hi,
> 
>> Link-local addresses also require special handling, it is this
>> special handling that makes them link-local addresses. Routers need
>> to avoid forwarding packets carrying link-local addresses off the
>> link, and hosts should understand that link-local destinations are
>> only reachable if they are directly reachable. To implement this
>> special handling requires that routers and hosts know the prefix
>> that identifies an address as link-local; ambiguity about what that
>> prefix is will result in packets being mis-directed. Is there any
>> doubt that the prefix that identifies link-local addresses in
>> forwarding operations should be FE80::/10?
> 
> I don't think so. The spec says that fe80::/10 is link-local. On
> ethernet the subnet prefix length is /64, and the 54 bits in the
> middle have to be 0, so it uses fe80::/64 on the link.

So, do you think this makes that the link-local subnet prefix length on 
Ethernet is 64?

(for my part, I am tempted to not think so: one couldnt say that the LL 
prefixlen depends on the link type, no more than other Global Unicast 
prefixlen depends on link types).

Alex

  AFAICT
> Alexandre just wants this written down in a single document.
> 
> Cheers, Sander
> 
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Nov 2018 11:39:00 +0100

Alexandre,

You seem to be the only one who is concerned about this.
Given that, would you mind dropping this topic on the mailing list?

Best regards,
Ole

> On 21 Nov 2018, at 11:04, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> So, do you think this makes that the link-local subnet prefix length on Ethernet is 64?
> 
> (for my part, I am tempted to not think so: one couldnt say that the LL prefixlen depends on the link type, no more than other Global Unicast prefixlen depends on link types).
> 
> Alex
> 
> 
> AFAICT

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 22 Nov 2018 00:11:08 +0000

RFC 4291 sure left this topic of fe80::/10 vs fe80::/64 confused.  This topic is discussed in the errata review: https://www.rfc-editor.org/errata/eid4406

The way I read it:
* fe80::/10 is reserved for LL unicast addresses.  (https://tools.ietf.org/html/rfc4291#section-2.4).
* fe80::/64 is what is to be used as LL unicast addresses (ethernet or any other link type). (https://tools.ietf.org/html/rfc4291#section-2.5.6).

As a practical matter, I do not see a completely unambiguous indication of what the routers are proscribed by RFC4291 to forward.  RFC4291 says "Routers must not forward any packets with Link-Local source or destination addresses to other links."  Context-free reading would mean that it includes fe80::/10 (LL unicast addresses) as well as ff?2::/16 (LL multicast addresses).  However, this sentence is in Section 2.5.6, which specifically defines fe80::/64 to be used as LL unicast addresses...  Still, I think it is safe and wise to consider RFC4291 as prohibiting off-link routing of fe80::/10 and ff?2::/16.

- Igor

> -----Original Message-----
> From: Alexandre Petrescu <[email-masked]>
> Sent: Wednesday, November 21, 2018 5:05 AM
> To: Sander Steffann <[email-masked]>; Dennis Ferguson
> <[email-masked]>
> Cc: IPv6 IPv6 List <[email-masked]>; 神明達哉 <[email-masked]>
> Subject: Re: SLAAC RFC4862 - appropriate length of fe80:: prefix
> 
> 
> 
> >> special handling requires that routers and hosts know the prefix that
> >> identifies an address as link-local; ambiguity about what that prefix
> >> is will result in packets being mis-directed. Is there any doubt that
> >> the prefix that identifies link-local addresses in forwarding
> >> operations should be FE80::/10?
> >

---

From: Mark Smith <[email-masked]>
Date: Thu, 22 Nov 2018 12:09:59 +1100

On Thu, 22 Nov 2018 at 11:12, Lubashev, Igor <[email-masked]> wrote:
>
> RFC 4291 sure left this topic of fe80::/10 vs fe80::/64 confused.

I don't think it really did.

IANA allocate address space, and then the IETF, as one of the parties
that IANA allocate address space to, can define structure,
interpretation and functions performed with and on that address space.

So IANA allocated fe80::/10 to the IETF, with an address space name of
 "Link-Scoped Unicast", and then the IETF defined what Link Local
address space meant and the structure of the bits from /10 through
/128 in RFC4291 and other RFCs, such as RFC4007. (There is an
inconsistency, IANA are calling it by a different name than the IETF).

Similarly, IANA allocated ff::/8 to the IETF, with an address space
name of "Multicast", and then RFC4291 and other RFCs define what
Multicast addresses are and how packets with them are processed.

There are two separate parties and roles here; IANA can allocate
address space but can't specify its purpose, where as the IETF can
only request address space from IANA but can specify its purpose.

Alexandre seems to be expecting that the IETF does the IANA role, and
is therefore thinking something is missing because the IETF haven't.

Regards,
Mark.

>  This topic is discussed in the errata review: https://www.rfc-editor.org/errata/eid4406
>
> The way I read it:

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 22 Nov 2018 01:54:01 +0000

Thanks for a very clear explanation, Mark. I only wish that RFC 4291 were that lucid on the distinction between the IANA-allocated address block and IETF-mandated address structure with a very similar name. If RFC 4291 ever gets an update, I would urge an update in terminology to avoid any confusion.

Best,
- Igor

-----Original Message-----
From: Mark Smith [[email-masked]]
Received: Wednesday, 21 Nov 2018, 8:10PM
To: Lubashev, Igor [[email-masked]]
CC: Alexandre Petrescu [[email-masked]]; Sander Steffann [[email-masked]]; Dennis Ferguson [[email-masked]]; 6man WG [[email-masked]]; 神明達哉 [[email-masked]]
Subject: Re: SLAAC RFC4862 - appropriate length of fe80:: prefix

Regards,
Mark.

---

From: Yucel Guven <[email-masked]>
Date: Mon, 26 Nov 2018 20:29:03 +0200

I'm also a bit concerned about naming the address type.
>From the RFC6890 (Special-Purpose Address Registries) :

                     Attribute            | Value                 |
                +----------------------+-----------------------+
                | Address Block        | fe80::/10          |
                | Name                 | Linked-Scoped Unicast |
                | RFC                  | [RFC4291
<https://tools.ietf.org/html/rfc4291>]             |
                | Allocation Date      | February 2006  |
                | Termination Date     | N/A                |
                | Source               | True                    |
                | Destination          | True                  |
                | Forwardable          | False               |
                | Global               | False                    |
                | Reserved-by-Protocol | True           |
                +----------------------+-----------------------+
The prefix fe80::/10
Start Address> fe80:0000:0000:0000:0000:0000:0000:0000
End Address  > febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

which is different from the prefix fe80::/64
Start Address> fe80:0000:0000:0000:0000:0000:0000:0000
End Address  > fe80:0000:0000:0000:ffff:ffff:ffff:ffff

RFC4291 diagram explicitly tells that "54 bits are set to ZERO".
And I think most of the people understand that it should be fe80::/64

And just to make crystal clear, how about the classification/naming the
address type?
e.g., should we call "fe80:0123::/64" as a Link-Local address?
Linked-Scoped Unicast ? or what?

Regards,
-Yucel Guven

On Thu, Nov 22, 2018 at 3:54 AM Lubashev, Igor <[email-masked]> wrote:

> Thanks for a very clear explanation, Mark. I only wish that RFC 4291 were
> that lucid on the distinction between the IANA-allocated address block and
> IETF-mandated address structure with a very similar name. If RFC 4291 ever
> gets an update, I would urge an update in terminology to avoid any
> confusion.
>
> Best,
> - Igor
>
> *From:* Mark Smith [[email-masked]]
> *Received:* Wednesday, 21 Nov 2018, 8:10PM
> *To:* Lubashev, Igor [[email-masked]]
> *CC:* Alexandre Petrescu [[email-masked]]; Sander Steffann [
> [email-masked]]; Dennis Ferguson [[email-masked]]; 6man
> WG [[email-masked]]; 神明達哉 [[email-masked]]
> *Subject:* Re: SLAAC RFC4862 - appropriate length of fe80:: prefix
>
> >  This topic is discussed in the errata review:
> https://www.rfc-editor.org/errata/eid4406
> >
> > The way I read it:
> > * fe80::/10 is reserved for LL unicast addresses.  (
> https://tools.ietf.org/html/rfc4291#section-2.4).
> > * fe80::/64 is what is to be used as LL unicast addresses (ethernet or
> any other link type). (https://tools.ietf.org/html/rfc4291#section-2.5.6).
> >
> > As a practical matter, I do not see a completely unambiguous indication
> of what the routers are proscribed by RFC4291 to forward.  RFC4291 says
> "Routers must not forward any packets with Link-Local source or destination
> addresses to other links."  Context-free reading would mean that it
> includes fe80::/10 (LL unicast addresses) as well as ff?2::/16 (LL
> multicast addresses).  However, this sentence is in Section 2.5.6, which
> specifically defines fe80::/64 to be used as LL unicast addresses...
> Still, I think it is safe and wise to consider RFC4291 as prohibiting
> off-link routing of fe80::/10 and ff?2::/16.
> >
> > - Igor
> >
> >
> >
> that
> > > > I don't think so. The spec says that fe80::/10 is link-local.. On

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Nov 2018 08:45:42 +1300

On 2018-11-27 07:29, Yucel Guven wrote:
...
> Linked-Scoped Unicast ? or what?

It's invalid, that's all. (Also, it's a pseudo-prefix, not an address.)

   Brian

---

From: Yucel Guven <[email-masked]>
Date: Mon, 26 Nov 2018 22:52:45 +0200

Exactly Brian, it's a prefix(pseudo) not an address, for sure. Just
excessive typing, sorry.

However, fe80:0123::/64 falls into the fe80::/10 range.
Then why we name it as "invalid" instead of "Linked-Scoped Unicast" with
respect to RFC6890?

Regards,
-Yucel Guven

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Nov 2018 10:59:15 +1300

> Then why we name it as "invalid" instead of "Linked-Scoped Unicast" with

Because it's specified elsewhere (RFC4291 section 2.5.6) that the remaining
bits of the /64 are zero. Note that the reference for that entry in the
IANA registry is indeed RFC4291, so there is really no ambiguity.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Nov 2018 17:10:54 -0800

> So, do you think this makes that the link-local subnet prefix length on Ethernet is 64?

The prefix is strangely defined, in that the definition includes not only the number of bits but their content. But I would suggest that a CIDR description of link-local is fe80::/64 or fe80::/64, and is a more-specific of fe80::/10, which is the site-local prefix.

> (for my part, I am tempted to not think so: one couldnt say that the LL prefixlen depends on the link type, no more than other Global Unicast prefixlen depends on link types).

I don't see anything in 4291 that is dependent on the link type, so I don't think the question makes much sense in context.

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Nov 2018 09:35:46 +0100

Fred,

> The prefix is strangely defined, in that the definition includes not only the number of bits but their content. But I would suggest that a CIDR description of link-local is fe80::/64 or fe80::/64,…

Just to correct you, since I have seen you state this a couple of times.
fe80::/10 is _not_ the (deprecated) site-local prefix.
fec0::/10 is.

cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 11:34:59 +0100

Le 28/11/2018 à 09:35, Ole Troan a écrit :
>> The prefix is strangely defined, in that the definition includes
>> not only the number of bits but their content. But I would suggest
>> that a CIDR description of link-local is fe80::/64 or fe80::/64,
>> and is a more-specific of fe80::/10, which is the site-local
>> prefix.
> 
> Just to correct you, since I have seen you state this a couple of
> times. fe80::/10 is _not_ the (deprecated) site-local prefix. 
> fec0::/10 is.

Yes, there is a bit difference at position 10 decimal:

fe80::/10 1111 1110 10 00 0000
fec0::/10 1111 1110 11 00 0000

It is also true that fe80::/9 and fec0::/9 have the same meaning,
despite "fe80" and "fec0" sounding very much different, a situation also 
found in ULA fd00::/7 and fc00::/7.

On another hand, it is also true that a deprecated site-local fec0::/10 
(forbidden to be used), practically means fe80::/10 is actually an fe80::/9.

Do you disagree with this last point?

Alex

> cheers, Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Nov 2018 12:35:30 +0100

>> times. fe80::/10 is _not_ the (deprecated) site-local prefix. fec0::/10 is.
> 
> despite "fe80" and "fec0" sounding very much different, a situation also found in ULA fd00::/7 and fc00::/7.
> 
> On another hand, it is also true that a deprecated site-local fec0::/10 (forbidden to be used), practically means fe80::/10 is actually an fe80::/9.
> 

Yes.

Ole

---

From: Yucel Guven <[email-masked]>
Date: Wed, 28 Nov 2018 16:39:01 +0200

I completely agree that there's no ambiguity, it's all clear.
The prefix "fe80::/64" is clearly stated in RFC4291 section 2.5.6. as
Link-local.

That is not my point.

My point is:
If we have "2001:db8::/32", we all say that the prefix "reserved for
documentation-only".
Or if we have "2001:db8:0123::/48" which is more specific of 2001:db8::/32,
it's again "reserved for documentation-only".

 Question:
 If you have the prefix "fe80:0123::/64" which is more specific of
"fe80::/10",
 then it's called as:

 a) Invalid
 b) Linked-Scoped Unicast
 c) Link-Local Unicast
 d) Global Unicast
 e) No Name / Undefined (but inside Linked-Scoped Unicast range)

 If none of the above, then your suggestion?

Regards,
-Yucel Guven

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 14:51:15 +0100

>   If none of the above, then your suggestion?

b and c.

Alex

> 
> Regards,
> -Yucel Guven
> 
> 
> On Mon, Nov 26, 2018 at 11:59 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > [email-masked] <mailto:[email-masked]>>
>     wrote:
>      >

---

From: Yucel Guven <[email-masked]>
Date: Wed, 28 Nov 2018 17:14:52 +0200

Alex,

Agree with 'b',  but disagree with 'c' due to RFC4291 section 2.5.6.

Regards,
-Yucel Guven

---

From: Sander Steffann <[email-masked]>
Date: Wed, 28 Nov 2018 09:38:45 -0500

Hi,

> The prefix "fe80::/64" is clearly stated in RFC4291 section 2.5.6. as Link-local.
> 
> That is not my point.
> 
> My point is:
> If we have "2001:db8::/32", we all say that the prefix "reserved for documentation-only".
>  If you have the prefix "fe80:0123::/64" which is more specific of "fe80::/10",
>  then it's called as:
> 
>  a) Invalid

Yes: RFC4291 section 2.5.6 clearly states that the 54 bits between the /10 and /64 boundaries must be 0.

>  c) Link-Local Unicast

These two names seem to be used interchangeably. RFC4291 defines fe80::/10 as "Link-Local unicast". RFC 6890 defines it as "Linked-Scoped Unicast". They are currently the same thing. The later RFC seems to distinguish between link-scope and link-local to allow for future definitions of other link-scoped addresses that are not RFC4291 section 2.5.6 Link-Local addresses. But no such addresses are currently defined.

>  d) Global Unicast

Definitely not, as defines by RFC 4291 section 2.4.

>  e) No Name / Undefined (but inside Linked-Scoped Unicast range)

I think the word you are looking for here is "reserved". The /10 is defined as link-local scope. RFC7136 says "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long.", so the used prefix is fe80::/64. And RFC4291 states that the 54 bits between the /10 and the /64 are all 0 for link-local addresses. Until an RFC is written that defines addresses where those bits are not all 0 they cannot be used.

Cheers
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 15:52:58 +0100

Noted for me, thank you for the questionnaire.  I am curious about others.

Alex

Le 28/11/2018 à 16:14, Yucel Guven a écrit :
> On Wed, Nov 28, 2018 at 3:51 PM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >      > Exactly Brian, it's a prefix(pseudo) not an address, for
>     sure. Just
>      >      > excessive typing, sorry.
>      >      >
>      >      > However, fe80:0123::/64 falls into the fe80::/10 range.
>      >      > Then why we name it as "invalid" instead of "Linked-Scoped
>      >     Unicast" with
>      >      > respect to RFC6890?
>      >
>      >      >
>      >      > Regards,
>      >      > -Yucel Guven
>      >      >
>      >      >
>      >      > On Mon, Nov 26, 2018 at 9:45 PM Brian E Carpenter <
>      >      > [email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >     wrote:
>      >      >
>      >      >> On 2018-11-27 07:29, Yucel Guven wrote:
>      >      >> ...
>      >      >>> e.g., should we call "fe80:0123::/64" as a Link-Local
>     address?
>      >      >>> Linked-Scoped Unicast ? or what?
>      >      >>
>      >      >> It's invalid, that's all. (Also, it's a pseudo-prefix, not an
>      >     address.)
>      >      >>
>      >      >>    Brian
>      >      >>
>      >      >
>      >
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 16:01:13 +0100

Le 28/11/2018 à 15:38, Sander Steffann a écrit :
[...]
> Interface IDs are required to be 64 bits long.", so the used prefix
> is fe80::/64. And RFC4291 states that the 54 bits between the /10 and
> the /64 are all 0

Ok: the link-local prefix is fe80::/10 but it is fe80::/64 because 54 
bits are zero.

And so fe80:1::/65 a link-local prefix too.

Alex

> for link-local addresses. Until an RFC is written that defines 
> addresses where those bits are not all 0 they cannot be used.

> Cheers Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 16:03:00 +0100

DEfinitely...

> And so fe80:1::/65 a link-local prefix too.

I meant fe80:0:0:0:1::/65 is a link-local prefix.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Wed, 28 Nov 2018 10:25:29 -0500

Hi,

>> Ok: the link-local prefix is fe80::/10 but it is fe80::/64 because 54 bits are zero.

"Interface IDs are required to be 64 bits long", that means that the prefix length has to be /64, and that is not a /64.

Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 16:26:25 +0100

> "Interface IDs are required to be 64 bits long", that means that the prefix length has to be /64, and that is not a /64.

Well, that quoted text is wrong.

Implementations do not abide.

Please correct the quoted text.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Wed, 28 Nov 2018 10:30:46 -0500

Hi Alexandre,

> Please correct the quoted text.

"implementations do not comply with the standard, therefore the standard is wrong"...

That's not how it works :)
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 16:32:18 +0100

> That's not how it works :)

Let me shut up then :-)

Alex

---

From: Yucel Guven <[email-masked]>
Date: Wed, 28 Nov 2018 20:13:24 +0200

Yes, Agreed. And can I ask about "fe80:0123::/40" ? I think I hear your
answer as 'Linked-Scoped Unicast', is it?

> I think the word you are looking for here is "reserved". The /10 is
defined as link-local scope. RFC7136 says "For all unicast addresses,
except those that start with
> the binary value 000, Interface IDs are required to be 64 bits long.", so
the used prefix is fe80::/64. And RFC4291 states that the 54 bits between
the /10 and the /64
> are all 0 for link-local addresses. Until an RFC is written that defines

Well, personally I do not prefer to use the word "reserved" since when you
use it, then the first question comes into mind is "reserved FOR WHAT?"
If it was a seat/ticket/copyright or whatever, then it makes 'sense' to
use. A reserved seat, a reserved ticket or you reserve all rights for your
copyright.
But in IPv6 prefix context, a prefix which have 'not defined' yet, may
easily be called "Undefined". Because IETF makes 'definitions' or 'defines'
the functions of prefixes.
Of course we should follow the de-factos/standards for compatibility and
say 'reserved.  ;-|

Regards,
-Yucel Guven

On Wed, Nov 28, 2018 at 4:38 PM Sander Steffann <[email-masked]> wrote:

> These two names seem to be used interchangeably. RFC4291 defines fe80::/10
> as "Link-Local unicast". RFC 6890 defines it as "Linked-Scoped Unicast".
> They are currently the same thing. The later RFC seems to distinguish
> between link-scope and link-local to allow for future definitions of other
> link-scoped addresses that are not RFC4291 section 2.5.6 Link-Local
> addresses. But no such addresses are currently defined.
>
> >  d) Global Unicast
>
> I think the word you are looking for here is "reserved". The /10 is
> defined as link-local scope. RFC7136 says "For all unicast addresses,
> except those that start with the binary value 000, Interface IDs are
> required to be 64 bits long.", so the used prefix is fe80::/64. And RFC4291
> states that the 54 bits between the /10 and the /64 are all 0 for
> link-local addresses. Until an RFC is written that defines addresses where
> those bits are not all 0 they cannot be used.
>
> Cheers
> Sander
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 28 Nov 2018 17:59:39 +0000

(Preface: I wish we did not need to engage in the kind of verbal sophistry usually enjoyed by lawyers and not engineers.)

RFC 4291 #2.4 states that all IPv6 addresses in fe80::/10 are "identified" as "Link-Local unicast".
RFC 4291 #2.5.6 states that "Link-Local IPv6 Unicast" addresses [MUST] have bits 10-63 cleared.

So, how wrong is it to call addresses within fe80:0123::/64 prefix "Invalid Link-Local unicast addresses"?
I could also agree to "Undefined Link-Local unicast addresses" (not that there is a semantic difference between "invalid" and "undefined" AFAIK).
 
- Igor

> Sent: Wednesday, November 28, 2018 9:53 AM
> To: Yucel Guven <[email-masked]>
> Cc: [email-masked]; Lubashev, Igor <[email-masked]>;
> [email-masked]; [email-masked]
> > <[email-masked]
> <mailto:[email-masked]>> wrote:
> >
> >
> >

---

From: Yucel Guven <[email-masked]>
Date: Wed, 28 Nov 2018 21:59:07 +0200

> So, how wrong is it to call addresses within fe80:0123::/64 prefix
"Invalid Link-Local unicast addresses"?

(Just repeating the same thing)
It's not wrong, it's definitely true to say 'Invalid' specifically if the
prefix length is /64. I thought we all agreed on that.
fe80:0123::/64 does not have zeros in between /10 and /64 (not all 54 bits
are set to zero), so that's why it's 'Invalid'.
RFC 4291 section 2.5.6 STRICTLY DEFINES all /64 bits. Any prefix that does
not comply with it is simply called 'Invalid' (As BrianCarpenter noted
above).
There should not be an 'undefined' address which are produced with the
prefix fe80::/64, or fe80:0000:0000:0000::/64.

However, if you say fe80:0123::/40, then yes we may call 'Undefined' or
'Reserved'. But in that case, fe80:0123::/40 belongs to fe80::/10 range.
Then ambiguity comes: shall we call it "Link-Local unicast" w.r.t. RFC4291
#2.4  OR  call it "Link-Scoped unicast" w.r.t. RFC6890 ?
As Sander Steffann noted, if "Link-Local unicast" and "Link-Scoped
unicast"  is used interchangeably,
then why we have different terms for the same thing in two RFCs?

Regards,
-Yucel Guven

On Wed, Nov 28, 2018 at 8:00 PM Lubashev, Igor <[email-masked]> wrote:

> (Preface: I wish we did not need to engage in the kind of verbal sophistry
> usually enjoyed by lawyers and not engineers.)
>
> I could also agree to "Undefined Link-Local unicast addresses" (not that
> there is a semantic difference between "invalid" and "undefined" AFAIK).
>
> - Igor
>
> > >      >      > Then why we name it as "invalid" instead of
> "Linked-Scoped
> > >      >     Unicast" with
> > >      >      > respect to RFC6890?
> > >      >
> > >      >     Because it's specified elsewhere (RFC4291 section 2.5.6)
> that the
> > >      >     remaining
> > >      >      > [email-masked]
> > >      >      >> It's invalid, that's all. (Also, it's a pseudo-prefix,
> not an
> > >      >     address.)
> > >      >      >>
> > >      >      >>    Brian
> > >      >      >>
> > >      >      >
> > >      >
> > >
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 28 Nov 2018 20:28:01 +0000

There are no fe80::/10 or fe80:0123::/64 or fe80:0123::/40 addresses.  There are just shortcuts to name a set of (128-bit) addresses that share the same prefix.  There is no hierarchical precedence.

My current understanding is that:

  *   IANA allocated fe80∷/10 address block for RFC 4291 and called that "Linked-Scoped Unicast" address block.
  *   RFC 4291 #2.4 chose a different name for addresses in that block -- “Link-local [IPv6] Unicast Addresses”.  (It should had stuck to IANA’s name, however awkward!)
  *   RFC 4291 #2.5.6 assigned special semantics (beyond just a name) to fe80∷/64 addresses (a subset of “Link-local IPv6 Unicast” addresses).

That’s why I think fe80:0123::/40 addresses fall within “Link-local unicast” address block but are undefined/invalid (have no semantics).  Yet, for the practical reasons, I think that all restrictions that apply to “Link-local Unicast” addresses apply to fe80∷/10 and not just fe80∷/64.

  *   Igor

From: Yucel Guven <[email-masked]>

(Just repeating the same thing)
It's not wrong, it's definitely true to say 'Invalid' specifically if the prefix length is /64. I thought we all agreed on that.
fe80:0123::/64 does not have zeros in between /10 and /64 (not all 54 bits are set to zero), so that's why it's 'Invalid'.
RFC 4291 section 2.5.6 STRICTLY DEFINES all /64 bits. Any prefix that does not comply with it is simply called 'Invalid' (As BrianCarpenter noted above).
There should not be an 'undefined' address which are produced with the prefix fe80::/64, or fe80:0000:0000:0000::/64.

However, if you say fe80:0123::/40, then yes we may call 'Undefined' or 'Reserved'. But in that case, fe80:0123::/40 belongs to fe80::/10 range.
Then ambiguity comes: shall we call it "Link-Local unicast" w.r.t. RFC4291 #2.4  OR  call it "Link-Scoped unicast" w.r.t. RFC6890 ?
As Sander Steffann noted, if "Link-Local unicast" and "Link-Scoped unicast"  is used interchangeably,
then why we have different terms for the same thing in two RFCs?

Regards,
-Yucel Guven

On Wed, Nov 28, 2018 at 8:00 PM Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
(Preface: I wish we did not need to engage in the kind of verbal sophistry usually enjoyed by lawyers and not engineers.)

- Igor

> From: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
> To: Yucel Guven <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Lubashev, Igor <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >
> >
> >      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >     <mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
> >      >
> >      >      > [email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>
> >     <mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>>
> >      >     wrote:
> >      >      >

---

From: Yucel Guven <[email-masked]>
Date: Thu, 29 Nov 2018 01:33:32 +0200

> That’s why I think fe80:0123::/40 addresses fall within “Link-local
unicast” address block but are undefined/invalid (have no semantics).
> Yet, for the practical reasons, I think that all restrictions that apply
to “Link-local Unicast” addresses apply to fe80∷/10 and not just fe80∷/64.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Igor,
Then, the term "Linked-Scoped Unicast" for "fe80::/10" in RFC6890 should be
renamed as "Link-Local Unicast".
Agree?

Regards,
-Yucel Guven

On Wed, Nov 28, 2018 at 10:28 PM Lubashev, Igor <[email-masked]> wrote:

> There are no fe80::/10 or fe80:0123::/64 or fe80:0123::/40 addresses.
> There are just shortcuts to name a set of (128-bit) addresses that share
> the same prefix.  There is no hierarchical precedence.
>
>
>
>    - IANA allocated fe80∷/10 address block for RFC 4291 and called that
>    "Linked-Scoped Unicast" address block.
>    - RFC 4291 #2.4 chose a different name for addresses in that block --
>    “Link-local [IPv6] Unicast Addresses”.  (It should had stuck to IANA’s
>    name, however awkward!)
>    - RFC 4291 #2.5.6 assigned special semantics (beyond just a name) to
>    fe80∷/64 addresses (a subset of “Link-local IPv6 Unicast” addresses).
>
>
>
> That’s why I think fe80:0123::/40 addresses fall within “Link-local
> unicast” address block but are undefined/invalid (have no semantics).  Yet,
> for the practical reasons, I think that all restrictions that apply to
> “Link-local Unicast” addresses apply to fe80∷/10 and not just fe80∷/64.
>
>
>
>    - Igor
>
>
>
> *From:* Yucel Guven <[email-masked]>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Nov 2018 15:05:23 +0100

>     "Linked-Scoped Unicast" address block.

A 'prefix' is not the same thing as an 'address block'.

The fe80::/10 'address block' surely has the address fe80:1::1 in it, 
which is thus a link-scoped unicast address because a 'link-scoped 
unicast address' could not, by any reasonable argument, be any different 
than a 'link-local address'.

On another hand, the fe80::/10 'prefix' does not seem to exist (as you 
say - awkward).  People think that the prefix fe80::/64 (remark 64 
instead of 10) exists.  If one thinks that fe80::/64 exists, then the 
same fe80:1::1 which was part of fe80::/10 is now excluded by fe80::/64, 
and thus is not a link-local address.

This is very cumbersome.

I agree with what you say below.

Alex

>   * RFC 4291 #2.4 chose a different name for addresses in that block --
>     “Link-local [IPv6] Unicast Addresses”.  (It should had stuck to
>     IANA’s name, however awkward!)
>   * RFC 4291 #2.5.6 assigned special semantics (beyond just a name) to
> It's not wrong, it's definitely true to say 'Invalid' specifically if 
> the prefix length is /64. I thought we all agreed on that.
> fe80:0123::/64 does not have zeros in between /10 and /64 (not all 54 
> bits are set to zero), so that's why it's 'Invalid'.
> RFC 4291 section 2.5.6 STRICTLY DEFINES all /64 bits. Any prefix that 
> does not comply with it is simply called 'Invalid' (As BrianCarpenter 
> noted above).
> Then ambiguity comes: shall we call it "Link-Local unicast" w.r.t. 
> RFC4291 #2.4  OR  call it "Link-Scoped unicast" w.r.t. RFC6890 ?
> 
>     (Preface: I wish we did not need to engage in the kind of verbal
>     sophistry usually enjoyed by lawyers and not engineers.)
> 
>     I could also agree to "Undefined Link-Local unicast addresses" (not
>     that there is a semantic difference between "invalid" and
>     "undefined" AFAIK).
> 
>     - Igor
> 
>      > Cc: [email-masked]
>     <mailto:[email-masked]>; Lubashev, Igor
>     <[email-masked] <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>      > > <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      > >
>      > >
>      > >
>      > >      > I completely agree that there's no ambiguity, it's all
>     clear.
>      > >      > The prefix "fe80::/64" is clearly stated in RFC4291 section
>      > >     2.5.6. as
>      > >      > Link-local.
>      > >      >
>      > >      > That is not my point.
>      > >      >
>      > >      > My point is:
>      > >      > If we have "2001:db8::/32", we all say that the prefix
>     "reserved for
>      > >      > documentation-only".
>      > >      > Or if we have "2001:db8:0123::/48" which is more specific of
>      > >     2001:db8::/32,
>      > >      > it's again "reserved for documentation-only".
>      > >      >
>      > >      >   Question:
>      > >      >   If you have the prefix "fe80:0123::/64" which is more
>     specific of
>      > >      > "fe80::/10",
>      > >      >   then it's called as:
>      > >      >
>      > >      >   a) Invalid
>      > >      >   b) Linked-Scoped Unicast
>      > >      >   c) Link-Local Unicast
>      > >      >   d) Global Unicast
>      > >      >   e) No Name / Undefined (but inside Linked-Scoped
>     Unicast range)
>      > >      >
>      > >      >   If none of the above, then your suggestion?
>      > >
>      > >     b and c.
>      > >
>      > >     Alex
>      > >
>      > >      >
>      > >      > Regards,
>      > >      > -Yucel Guven
>      > >      >
>      > >      >
>      > >      > On Mon, Nov 26, 2018 at 11:59 PM Brian E Carpenter
>      > >      > <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>> wrote:
>      > >      >
>      > >      >     On 2018-11-27 09:52, Yucel Guven wrote:
>      > >      >      > Exactly Brian, it's a prefix(pseudo) not an
>     address, for
>      > >     sure. Just
>      > >      >      > excessive typing, sorry.
>      > >      >      >
>      > >      >      > However, fe80:0123::/64 falls into the fe80::/10
>     range.
>      > >      >      > Then why we name it as "invalid" instead of
>     "Linked-Scoped
>      > >      >     Unicast" with
>      > >      >      > respect to RFC6890?
>      > >      >
>      > >      >     Because it's specified elsewhere (RFC4291 section
>     2.5.6) that the
>      > >      >     remaining
>      > >      >     bits of the /64 are zero. Note that the reference
>     for that
>      > >     entry in the
>      > >      >     IANA registry is indeed RFC4291, so there is really
>     no ambiguity.
>      > >      >
>      > >      >          Brian
>      > >      >      >
>      > >      >      > Regards,
>      > >      >      > -Yucel Guven
>      > >      >      >
>      > >      >      >
>      > >      >      > On Mon, Nov 26, 2018 at 9:45 PM Brian E Carpenter <
>      > >      >      > [email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>>
>      > >      >     wrote:
>      > >      >      >
>      > >      >      >> On 2018-11-27 07:29, Yucel Guven wrote:
>      > >      >      >> ...
>      > >      >      >>> e.g., should we call "fe80:0123::/64" as a
>     Link-Local
>      > >     address?
>      > >      >      >>> Linked-Scoped Unicast ? or what?
>      > >      >      >>
>      > >      >      >> It's invalid, that's all. (Also, it's a
>     pseudo-prefix, not an
>      > >      >     address.)
>      > >      >      >>
>      > >      >      >>    Brian
>      > >      >      >>
>      > >      >      >
>      > >      >
>      > >
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 29 Nov 2018 15:34:21 +0000

>> That’s why I think fe80:0123::/40 addresses fall within “Link-local unicast” address block but are undefined/invalid (have no semantics).
>> Yet, for the practical reasons, I think that all restrictions that apply to “Link-local Unicast” addresses apply to fe80∷/10 and not just fe80∷/64.
> Then, the term "Linked-Scoped Unicast" for "fe80::/10" in RFC6890 should be renamed as "Link-Local Unicast".
> Agree?

It would had been better for IANA's name (RFC6890) and IETF's name (RFC4291) to match.  I also prefer "Link-Local" to "Linked-Scoped", especially because IANA already names a similar IPv4 address block (169.254.0.0/16) "Link Local".

- Igor

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 29 Nov 2018 23:23:49 +0000

Sorry for making this long thread one message longer...

> From: Lubashev, Igor <[email-masked]>
> > Then, the term "Linked-Scoped Unicast" for "fe80::/10" in
> RFC6890 should be renamed as "Link-Local Unicast".
> > Agree?
> 
> It would had been better for IANA's name (RFC6890) and IETF's name
> (RFC4291) to match.  I also prefer "Link-Local" to "Linked-Scoped", especially
> because IANA already names a similar IPv4 address block (169.254.0.0/16)
> "Link Local".

Actually, it looks like IANA itself is using "Linked-Scoped Unicast", "Link-Scoped Unicast", and "Link-Local Unicast" interchangeably.

"Linked-Scoped Unicast": https://tools.ietf.org/html/rfc6890#section-2.2.3

"Link-Scoped Unicast": https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

"Link-Local Unicast": https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

What would be truly helpful is if IETF were to use a different name for the fef80::/10 block and the subset of addresses (fe80::/64) to which it assigned a special purpose.  These fe80::/64 addresses could be called something like "Link-Local Unicast Interface Addresses" (though it is a mouthful).

If there is interest in this, I can put together a short draft for Prague.

- Igor

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Nov 2018 14:01:39 +1300

On 2018-11-30 12:23, Lubashev, Igor wrote:
> What would be truly helpful 

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

is if IETF were to use a different name for the fef80::/10 block and the subset of addresses (fe80::/64) to which it assigned a special purpose.  These fe80::/64 addresses could be called something like "Link-Local Unicast Interface Addresses" (though it is a mouthful).

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Nov 2018 10:33:01 +0100

Le 30/11/2018 à 02:01, Brian E Carpenter a écrit :
[...]> 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.

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.

Should I use fe80::1:2/64 instead of fe80:1::2/32?  Yes and no.  Yes, 
because the 54bits should be zero.  No, because the IID must be 64, so 
the '2' is not a Subnet ID.

Should I use randomly generated Interface IDs?  Yes, because they are of 
arbitrary length.  No because they are too long to remember.  This is a 
strong requirement.  Also no, because many implementations of the 
randomly generated privacy IDs change it all the time (I need them 
constant) and sometimes they are two privacy addresses so I dont know 
which one to use in the other's rt table.

A final point is that is also very important that these MUST be 
link-local addresses with the well understood link-local semantics: do 
not forward LL-scoped packets out of subnets.  'Not to forward' implies 
the computer understand clearly when to forward, and that can only 
happen meaningfully if we know precisely the prefix lengths in the 
routing tables.

That's about it, and thank you for asking.

In return, let me ask you: is an 'address block' (IANA term to denote 
"fe80::/10") the same thing as a 'prefix' (RFC4291 term to denote 
fe80::/64)?

Alex

> 
> Brian
> 
> is if IETF were to use a different name for the fef80::/10 block and
> the subset of addresses (fe80::/64) to which it assigned a special
> purpose.  These fe80::/64 addresses could be called something like
> "Link-Local Unicast Interface Addresses" (though it is a mouthful).
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Yucel Guven <[email-masked]>
Date: Fri, 30 Nov 2018 15:52:51 +0200

> What would be truly helpful is if IETF were to use a different name for
the fef80::/10 block and the subset of addresses (fe80::/64) to which it
assigned a special
> If there is interest in this, I can put together a short draft for Prague.

+1 .
Agree. Many people prefers and in fact got used to the term "Link-local
Unicast" as can be clearly seen in tech writtings, emails, documentations,
etc.
I think no need to say 'Interface' together with 'Link'.  Saying
'Interface' seems redundant, and makes it mouthful as you indicated.

Regards,
-Yucel Guven

On Fri, Nov 30, 2018 at 1:23 AM Lubashev, Igor <[email-masked]> wrote:

> Actually, it looks like IANA itself is using "Linked-Scoped Unicast",
> "Link-Scoped Unicast", and "Link-Local Unicast" interchangeably.
>
> "Link-Scoped Unicast":
> https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
>
> "Link-Local Unicast":
> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>
>
> What would be truly helpful is if IETF were to use a different name for
> the fef80::/10 block and the subset of addresses (fe80::/64) to which it
> assigned a special purpose.  These fe80::/64 addresses could be called
> something like "Link-Local Unicast Interface Addresses" (though it is a
> mouthful).
>

---

From: Yucel Guven <[email-masked]>
Date: Fri, 30 Nov 2018 16:02:42 +0200

Brian,
Could you please explain why there is two different terms -yes, despite
meaning same thing and used interchangeably-
for the prefix 'fe80::/10' ? Why don't we just say 'Link-local Unicast' or
' just 'Link-Scoped Unicast' ?

Regards,
-Yucel Guven

On Fri, Nov 30, 2018 at 3:01 AM Brian E Carpenter <
[email-masked]> wrote:

> > "Linked-Scoped Unicast":
> https://tools.ietf.org/html/rfc6890#section-2.2.3
> >
> > "Link-Scoped Unicast":
> is if IETF were to use a different name for the fef80::/10 block and the
> subset of addresses (fe80::/64) to which it assigned a special purpose.
> These fe80::/64 addresses could be called something like "Link-Local
> Unicast Interface Addresses" (though it is a mouthful).
> >

---

From: 神明達哉 <[email-masked]>
Date: Fri, 30 Nov 2018 10:57:57 -0800

At Fri, 30 Nov 2018 10:33:01 +0100,

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

> definition of a link-local address.

Now you're unnecessarily making your actual problem a terminology
nitpicking.  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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Nov 2018 21:47:11 +0100

Le 30/11/2018 à 19:57, 神明達哉 a écrit :
> Alexandre Petrescu <[email-masked] 
> nitpicking. 

I agree I should not nitpick.

  I suspect that's one major reason why we cannot have very
> affect the fact that you can't use fe80:1::2 without being
I need to use fe80:1::2 link-local address for the reasons I explained, 
regardless of being compliant to any RFC.  There is no alternative 
possible to the use of fe80:1::2 in multiple LL-only subnets.

I will update the draft with summary of what I understand from this 
discussion.  In this way, you will not feel it was unproductive.

BTW thank you for your earlier invitation to write the draft.  It proved 
very relevant, together with that draft request from the Errata.

But I will not follow your invitation below (write new requirements and 
problem description) - you are asking way too much; in general the bar 
is way too high here.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Dec 2018 15:54:22 +1300

On 2018-12-01 09:47, Alexandre Petrescu wrote:
...

...

>> So, you might use "fe80::2%1" instead of "fe80:1::2".

What is the problem with that solution? It works well enough in my
experience, and seems more logical to explain to users.

It also has the convenience factor that your devices can have the
same LL address on every subnet. Just like good old 192.168.178.2.

    Brian