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

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Jan 2019 16:17:09 +0100

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
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 31 Jan 2019 07:50:02 +1100

What problem are you trying to solve?

Is it a practical and wide spread problem making it worth solving, or
is a theoretical problem that either could be prevented in other ways,
or only exists because of human habit and familiarity?

Do the benefits of solving the problem outweigh the costs of solving it?

On Thu, 31 Jan 2019 at 02:18, Alexandre Petrescu
<[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Jan 2019 11:14:47 +1300

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.

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?

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

Regards
   Brian

** Historical note: RFC1972 specified the LL prefix length as 80 and used the raw 48-bit Ethernet address as the IID.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 11:22:56 +0100

> What problem are you trying to solve?

Making this question shows one has only a remote view of the context.

> or only exists because of human habit and familiarity?

Making this question sounds as if one wants the answer to be no.

So here it is as one wishes: no, the problem is not widespread, and it 
is not worth solving.

YEs, it is a theoretical problem.

And yes, the human habit and familiarity is to use 64.

> Do the benefits of solving the problem outweigh the costs of solving it?

Again, the question sounds as if one begs for the answer 'no'.

So here is the answer: the costs are high.

What is is easy to do, and what I do, is post an Internet Draft on this 
topic.

Have you read my Internet Draft, and if yes, please comment on it.

Thank you in advance,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 11:24:55 +0100

Le 30/01/2019 à 23:14, Brian E Carpenter a écrit :
> 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.
> 
> 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?

One of the two drafts involves a Network ID of length 24.

The question is why not use 24 for InterfaceID?  Just because Ethernet 
had it that way?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 12:11:12 +0100

Sorry,

Let me remove my preference and form a neutral question.

draft-hou-6lo-plc relies on a 24bit Network ID and a 12bit Terminal 
Equipment Identifier.

Why does it make a 64bit Interface ID and not a 36bit Interface ID?

The text in question is this:
>    For the 12-bit short addresses used by IEEE 1901.1, the 48-bit
>    pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY),
>    12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX).
>    The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE
>    into this 48-bit pseudo-address as follows:
> 
>        YYYY:YYFF:FE00:0XXX

Alex

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Jan 2019 08:15:54 -0300

> 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?

> far as I know. Is there a reason to do otherwise for the two drafts

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

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

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Jan 2019 08:17:37 -0300

> The question is why not use 24 for InterfaceID?  Just because Ethernet

You can certainly do that with OpenBSD. ;-)

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 12:33:35 +0100

> You can certainly do that with OpenBSD. ;-)

In linux too I can add (and we actually do) link-local addresses with 
prefix length 32.

I do not understand why there is insistance that it must be 64.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 12:57:16 +0100

[...]
> Why does it matter,

For me, it matters because it is important what we write in documents.

At this level of detail implementers rarely care, or understand, what is 
right or wrong.  But they do trust what is written.

It is a matter of responsability, if I can say so.

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

Refraining from forwarding (keep ll addressed packets on the link) 
implementations differ whether it is fe80::/10 or 64.

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

I agree there is no particular reason to use same IID to generate a LL 
and a GUA.

Alex

> 
> Regards Brian
> 
> ** Historical note: RFC1972 specified the LL prefix length as 80 and 
> used the raw 48-bit Ethernet address as the IID.
> 
>> Is it a practical and wide spread problem making it worth solving, 
>> or is a theoretical problem that either could be prevented in
>> other ways, or only exists because of human habit and familiarity?
>> 
>>> 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. 
>>> 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
>>>> 
>>>> <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>> 
>>>>>> [...]> Why? Since everybody agrees that the 54 bits are 
>>>>>> always zero,
>>>>> I have
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> 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.
>>>> 
>>>>> 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] Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative 
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Jan 2019 08:41:43 -0300

> In linux too I can add (and we actually do) link-local addresses with

They will not work if you try to employ them with BSDs. BSDs use bits in
the range /16 /64 to store information such as the interface index.
So... don't use prefixes shorter than /64 for link-locals, or you'll be
asking for trouble.

> I do not understand why there is insistance that it must be 64.

The least of my concerns would be the /64 for link-locals. A more
interesting question is probably why people insist on classfull globals ;-)

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 13:25:21 +0100

> So... don't use prefixes shorter than /64 for link-locals, or you'll be

Ah?  according to which spec do the BSD implementers put bits in the 
range 16-64?

> interesting question is probably why people insist on classfull globals ;-)

Agreed.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Jan 2019 09:31:14 -0300

> Ah?  according to which spec do the BSD implementers put bits in the

They don't send those bits on the wire. But they do use those bits as
described. -- According to no spec. If the link-local prefix is assumed
to be /64, then you're free to use those bits *internally* as you wish.
That's what BSDs do. Jinmei is quite likely in a better position ot
comment on this.

Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 14:00:04 +0100

> That's what BSDs do. Jinmei is quite likely in a better position ot

I would like to kindly ask Jinmei to make sure to keep that internal 
such that to not forbid the end user to ifconfig add fe80:1::1/63

If possible.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 31 Jan 2019 09:43:05 -0800

At Thu, 31 Jan 2019 14:00:04 +0100,

> such that to not forbid the end user to ifconfig add fe80:1::1/63

I don't think it's up to me anymore, but just to explain the current
state of art:
- an end user of a BSD box can't use fe80:1::1 as a "link-local" address
- BSD hosts generally drop incoming packets whose source or
  destination address matches fe80::/10 and contains a non-0 value in
  bits 15-31 (like fe80:1::1)

Basically it doesn't allow an IPv6 address that matches fe80::/10
unless it conforms to following format specified in RFC4291:

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 BSD implementation conforms to the RFC.  If someone wants to
violate the standard, they can freely do so, but they cannot assume
it's interoperable with other standard-compliant implementations.
That's a consequence of violating the standard.

I previously stated I was already done with this discussion, so I'll
stop here.  Anyone can freely hate this specification, but if it's not
even about an attempt of updating that specification (which is my
understanding of the previous cycle of this discussion), I don't think
it's a productive way of using my time to participate in it.

--
jinmei

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Jan 2019 19:30:43 +0100

Le 31/01/2019 à 18:43, 神明達哉 a écrit :
> Alexandre Petrescu <[email-masked] 

jinmei,

Thank you very much for the clarification.  I appreciate it.  Now I 
understand very much of our earlier discussions.

This situation is extremely worth considering.

In linux I must use fe80:1::1.  In BSD I cant.

Let us see how we can see further beyond the blocking situation.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Feb 2019 11:35:52 +1300

Hi Fernando,
> 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.

There's probably a privacy argument for *not* using the same IID for
LL and routeable addresses.

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

> 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