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

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 2 Dec 2018 17:42:06 +0100

Le 01/12/2018 à 03:54, Brian E Carpenter a écrit :
> On 2018-12-01 09:47, Alexandre Petrescu wrote:
> ...
>> 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.
> 
> ...
> 
>>> 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.

I have never tried fe80::2%1 on linux.

I am not sure I understand how distinct 'scopes' would work on a same 
link-local subnet, or on multiple link-local subnets.

I am not asking to get educated.  I will look it up myself.

But: that %1 is a new concept that needs to be understood (you dont have 
%1 in IPv4), and typed at each ping command.  I said the requirement is 
to have as least as possible things to remember when typing addresses.

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

I do not know what whether that 178 has a particular meaning in IPv4, 
like the %1 in IPv6.

I am not asking to get educated, I will look it up myself.

Alex

---

From: Matthew Petach <[email-masked]>
Date: Sun, 2 Dec 2018 11:18:48 -0800

If it's any consolation, Alex, I also use
addresses from the entire fe80::/10 range
in my network to make clearer homologues
between the IPv4 and IPv6 world.  I use an
explicit discard filter for all fe80::/10 packets
at the border of my network, just in case
different vendors treat the notion of what
should or should not be forwarded in
different ways.

IANA allocated the entire fe80::/10 range
for use in local scope addressing.

The IETF chose to give special meaning
to one particular /64 out of the fe80::/10
range.  I honor and respect the IETF
definition for that fe80::/64 prefix.

But the IETF has chosen to leave the rest
of the fe80::/10 prefix unaccounted for, which
leaves it wide open for people like you and I
to use as we please, as long as we recognize
vendors may not intrinsically be preventing the
forwarding of packets within the rest of the fe80::/10
range.  So long as we handle that ourselves,
there seems to be no issues with making use
of the rest of the fe80::/10 range.   fe80::/64 retains
its special place, per IETF documents, no problems
there; I'm just using the rest of the undefined space
the IETF isn't making use of.

Thanks!

Matt

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Dec 2018 08:51:24 +1100

On Mon, 3 Dec 2018 at 03:42, Alexandre Petrescu
<[email-masked]> wrote:
> But: that %1 is a new concept
> that needs to be understood (you dont have

Why are people having to type in addresses or manually ping things at all?

There's a skills boundary between network operators and end-users. By
trying to making pinging link-local addresses as easy as possible, it
sounds like you're trying to have end-users be occasional network
operators.

I think that is trying to make the wrong thing easy. Make it so that
no manual pinging has to be done at all. Don't use LLs if their
non-uniqueness is such a problem that you're violating specs to make
them unique.

I find this sounding a bit like a car manufacturer expecting all
people who buy cars to tune the engine after they buy it, and then
saying that tuning the engine should be much easier because it is hard
to do now. Tune it at the factory so the purchaser doesn't have to it,
and ideally have it self tuning after they've bought it.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Dec 2018 11:08:32 +1300

> sounds like you're trying to have end-users be occasional network

Yes, that's IPv4 thinking. At one stage we even used to tell users
"Your assigned address is 128.141.X.Y, your router's address is 
128.141.X.1, and the DNS server address is 128.141.P.Q. Find your
model of computer in the detailed instructions below in order to
configure these addresses." One of the goals of IPv6 was to avoid
this sort of thing, and making IPv6 addresses memorable was explicitly
a non-goal.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Dec 2018 08:44:57 +0100

Alexandre,

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

I want to commend you on (finally) informing the working group about what problem you are trying to solve.

If you want to create easy to remember (and easy to type (ignoring why that might not be the best approach for managing a network)), addresses, you have 64 bits to play with, there doesn’t seem to be a justification to step on to the MBZ bits.

Of course an even easier approach is to just give every router the exact same link-local address on every interface.
Then, as Jinmei pointed out it simply can be referred to as fe80::1%<link-id>

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 3 Dec 2018 09:13:42 +0100

> and ideally have it self tuning after they've bought it.

It's a good direction.  It will come later.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 3 Dec 2018 09:15:13 +0100

> this sort of thing, and making IPv6 addresses memorable was explicitly

You are asking too much.

Have you ever seen somebody deploying IPv6 who never had to ping an IPv6 
literal.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 3 Dec 2018 09:18:42 +0100

Le 03/12/2018 à 08:44, Ole Troan a écrit :
> Alexandre,
> 
>> 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.
> 

I wrote the problem in an earlier email.  Please re-read it and commend 
be back when I got educated myself about %1 and when you understood the 
problem.

> If you want to create easy to remember (and easy to type (ignoring
> why that might not be the best approach for managing a network)),
> addresses, you have 64 bits to play with, there doesn’t seem to be a
> justification to step on to the MBZ bits.

64 bits (8 octets) is way too much to remember for the common.

Besides, what I need is also a Subnet ID for LL addresses.

> Of course an even easier approach is to just give every router the
> exact same link-local address on every interface. Then, as Jinmei
> pointed out it simply can be referred to as fe80::1%<link-id>

Does link-id work on linux.  I am not asking you to answer, and I will 
find it for myself.

Just to say that link-id is a new thing to memorize, and has no 
counterpart in the common IPv4 thinking.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Mon, 3 Dec 2018 10:29:20 +0000

> Why are people having to type in addresses or manually ping things at all?

Only someone who has never had to actually diagnose real network problems could write that !

Alexandre Petrescu <[email-masked]> wrote:

> You are asking too much.
> 
> Have you ever seen somebody deploying IPv6 who never had to ping an IPv6 literal.

+1

When the user phones up (and bear in mind that it could be a client the other side of the country, and a user who thinks the CD drive is a cup holder*) complaining that "nothing works" then you have to start at the basics - is the machine actually switched on ? do they have a network cable in the back of the machine ? does the interface have an IP[4|6] address ? can you ping a device (eg router) known to be on the network by IP address ? can you ping what is supposed to be providing DNS service ? and so on.
Asking "can you ping www.google.com ?" tells you nothing about what problem may be preventing them from accessing anything. It doesn't give you any information to differentiate between a local network (link level) problem, a DNS problem, an address assignment problem, internet connection down, etc, etc.

Wes Borg's "Internet Helpdesk" sketch isn't made up - seriously I've watched the helldesk guys at my last job try and deal with that type of person.
http://www.smart-jokes.org/it-computer-help-desk.html

The analogy, following Mark's lead, would be a car that comes ready tuned, fuelled, oiled, etc from the factory. It has no fuel gauges, no warning lights/messages - because it "just works". So when the car "stops working" the user has no way of diagnosing the problem. Did they just run out of fuel (there's no gauge or low fuel warning) ? Has it shut down to protect the engine (eg low oil, there's no gauge, warning, or even dipstick) ? Or is there some other fault.
No, you wouldn't expect the average driver to be a skilled mechanic - but you would expect them to be able to do simple things like "tell me what the fuel gauge shows" or "does ${light} come on when you turn on the ignition ?".

Actually that does bring to mind the very old joke about if Microsoft made cars. It would randomly stop and just display a red light that says "fault" - no other information. Sometimes it will fix itself if you get out and hold the door handle and radio aerial while you press the button on the remote control, but other times you will have to go back to where you were and start the journey again. :D

* Yes at my last job we genuinely did have such a user !

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Dec 2018 22:21:51 +1100

> Only someone who has never had to actually diagnose real network problems could write that !

The people I'm asking about are Alexandre's users. They don't sound
like they should be having to type in addresses or perform manual
pings if a primary requirement is to make IPv6 addresses resemble and
act like IPv4 addresses as much as possible. Knowledge about IPv6 is
being purposely avoided, it would probably be better to avoid exposing
IPv6 at all to these users.

Network operators should be capable of typing in (or more likely
cutting-and-pasting) any IPv6 address and performing manual pings,
because that is their claimed domain of expertise.

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Dec 2018 22:31:45 +1100

> Have you ever seen somebody deploying IPv6 who never had to ping an IPv6

You need to explain to us why you are in a situation where people who
aren't trained in IPv6 are deploying IPv6. That's a formula for failure.

Who are these users who are typing in ping commands yet cannot cope with
interface identifiers at the time of typing in the IPv6 address. (Actually
most people don't type in IPv6 addesses most of the time, they
cut-and-paste them with a mouse.)

Why do they have to type the address in? Where does that address
information come from so they have to type it in e.g. a sheet of paper?

One way to avoid knowing or typing the specific LL address is to ping the
all-nodes link scoped multicast address, and looking for the address you're
after in the response.

E.g. under Linux, the following command will show all IPv6 link local
addresses on the link (assuming they reply to an ICMPv6 echo request) that
respond within 1 second:

(IIDs obfuscated, they are all different)

--
[mark@opy ~]$ ping -w 1 -I wlp3s0 ff02::1
ping6: Warning: source address might be selected on device other than
wlp3s0.
PING ff02::1(ff02::1) from :: wlp3s0: 56 data bytes
64 bytes from fe80::xxxx:xxxx:xxxx:xxxx%wlp3s0: icmp_seq=1 ttl=64
time=0.095 ms
64 bytes from fe80::xxxx:xxxx:xxxx:xxxx%wlp3s0: icmp_seq=1 ttl=64 time=1.47
ms (DUP!)
64 bytes from fe80::xxxx:xxxx:xxxx:xxxx%wlp3s0: icmp_seq=1 ttl=64 time=1.50
ms (DUP!)
64 bytes from fe80::xxxx:xxxx:xxxx:xxxx%wlp3s0: icmp_seq=1 ttl=64 time=134
ms (DUP!)
64 bytes from fe80::xxxx:xxxx:xxxx:xxxx%wlp3s0: icmp_seq=1 ttl=64 time=136
ms (DUP!)
64 bytes from fe80::xxxx:xxxx:xxxx:xxxx%wlp3s0: icmp_seq=1 ttl=64 time=340
ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.095/102.083/339.598/121.939 ms

[mark@opy ~]$
--

Note that the "(DUP!)" is because they all have icmp_seq=1.

Regards,
Mark.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 3 Dec 2018 14:16:16 +0000

Mark Smith <[email-masked]> wrote:

> The people I'm asking about are Alexandre's users.
...
> because that is their claimed domain of expertise.

So only the network operator will be doing any network diagnostics ?
Presumably you don't have any remote sites or sites so large that "just popping round" to someone's desk to do the initial basic diagnostics is impractical ?

In the real world I work in, when the network is down, you need to be able to talk users through some basic diagnostics - and that includes "ping ... and tell me what happens". So regardless of Alexandre's issues, it is just simply wrong to say that end users don't need to do this. And for good measure, if their network is down, you can't send them an email to copy and paste from ...

However, I do fully understand where you are coming from : users should not, for normal use of the network, have to know or care about IP addresses - that's what DNS and/or mDNS/DNSSD is for. Having gone from managing my own networks and being able to make sure everything was doable with DNS, to working at a small IT services outfit - one of the things that really irritated me was the number of client sites where basics like this were ... lets stay polite ... not setup as well as they could be. And don't get me started on those* who plug in a device, get an address by DHCP, then declare that as "fixed" and point stuff at it by IP address - that's great fun to fix weeks, months, or even years down the line when it breaks.

* Seems to be a special skill amongst the likes of copier and access control system installers.

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 Dec 2018 10:23:56 -0800

> On Dec 3, 2018, at 12:18 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> what I need is also a Subnet ID for LL addresses.

Why? For an address that is only used point to point between interfaces attached to the same LAN, what purpose does it serve?

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 3 Dec 2018 21:33:23 +0000

> -----Original Message-----
> From: Fred Baker <[email-masked]>
> Why? For an address that is only used point to point between interfaces
> attached to the same LAN, what purpose does it serve?
 
The difference is whether you want to give a name to a link/broadcast domain or not.  With % suffix, you are naming physical interfaces only.

Say, you have   A===B===C.   You can assign A (fe80:1::1), B(fe80:1::2, fe80:2::1), C(fe80:2::2), and it is clear what is connected to what, because each link has a shared name.
That said, one would still typically need to know the actual interface name for any operation like this ping from A:   ping fe80:1::2%rl0

- Igor

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Dec 2018 11:12:12 +1300

On 2018-12-03 21:15, Alexandre Petrescu wrote:
...
> Have you ever seen somebody deploying IPv6 who never had to ping an IPv6 

No, of course not. I've done it by cut-and-paste and I've done it
by manually transcribing from screen A to keyboard B. For that
matter, in my youth I patched software by entering machine
instructions in hexadecimal, octal or even binary (on the front
panel switches). But our goal needs to be ensuring that *users*
never need to do any of those things.

On 2018-12-04 10:33, Lubashev, Igor wrote:
...
> Say, you have   A===B===C.   You can assign A (fe80:1::1), B(fe80:1::2, fe80:2::1), C(fe80:2::2), and it is clear what is connected to what, because each link has a shared name.

And since there are 64 bits in the IID, you could perfectly well
number them as fe80::1:1, fe80::1:2, fe80::2:1, fe80::2:2

> That said, one would still typically need to know the actual interface name for any operation like this ping from A:   ping fe80:1::2%rl0

Exactly. And you expect the dumb user to get, say, %eth0 right first time?

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Dec 2018 10:14:29 +1100

Hi Fred,

> attached to the same LAN, what purpose does it serve?

I've thought there is value in that idea for multi-homed hosts (which are
generally more common these days), as it means that applications, users and
operators would not have to supply a scope ID/interface ID when using a LL
address, as the host's route table now has the interface information
because it is indirectly encoded in the subnet ID. Not having to supply a
scope id when using a Link Local address on a single homed host would also
be simpler.

Of course it isn't (or rather shouldn't be) as simple as just saying that a
subnet ID is placed in the current 54 bit all zeros part of the LL prefix.
That would involve a lot of manual configuration.

To do it in a user and operator friendly automated manner, you'd want a
scheme such that the first device on a link (host or router) generates a
globally unique LL subnet ID (the ULA scheme would probably do), and
advertises it to its peers when they join the link (RA with a PIO for the
GU LL prefix and a Router Lifetime of zero). The second device on the link
would learn that globally unique LL prefix and would be prepared to take
over announcing it if the first device disappeared (or the second could
advertise in parallel after learning from the first, the 3rd device
prepares to take over if one of the first two disappear), somewhat similar
to how OSPF has primary and backup designated routers on a link.

This scheme would be quite similar to how Appletalk seed routers worked,
although in this case select hosts are also advertising the globally unique
LL prefix.

I've thought about this scheme for quite a while. While I like the
simplicity of being able to treat LL addresses no differently to GUAs and
ULAs in applications, rather than as a special case, the question is
whether it is worth this development and deployment effort, compared to the
current method of supplying a scope id. It might be for use in more closed
and managed environments where it can be ensured that all hosts and their
LL applications support this scheme.

Regards,
Mark.

> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Dec 2018 10:18:04 +1100

You've taken my comments out of context.

On Tue, 4 Dec 2018 at 01:17, Simon Hobson <[email-masked]> wrote:
> ....

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 11:06:10 +0100

Le 03/12/2018 à 23:12, Brian E Carpenter a écrit :
> by manually transcribing from screen A to keyboard B.

Brian - thank you for the reply.

I agree with you and others that copy-paste literals from one xterm to 
another is a good way, but it assumes the X console has a working 
connection to each other computer.  Presumably that is an ssh over IPv4, 
or similar.  We dont have that.

> For that

YEs, that is good for users like an analyst, or an operator.  It is good 
one wants to smooth their working conditions.

For my users who are skilled in their professional application on CLI, 
working uncomfortably under vehicles, without mouse, twisted between 
seats, or under severe weather conditions: it's good to have simple to 
remember addresses.

They ask for it, I will not tell them to copy/paste instead.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 11:11:26 +0100

Le 03/12/2018 à 19:23, Fred Baker a écrit :
> Why? 

It's for the human to know that that LL is on that subnet.

If we put the same LL on distinct subnets, and there is a reply to a 
ping, we dont know from which subnet the reply comes (because subnets 
may overlap), and thus we dont know from which computer it comes.

 > For an address that is only used point to point between
 > interfaces attached to the same LAN, what purpose does it serve?

We ponder over whether we should use these constant and manually 
assigned addresses also as next hop for routes between subnets (instead 
of using the MAC-derived or privacy LL addresses).  But that is for later.

For now, it is just for the human to be able to ping between those two 
points.

It's subnets that move and may overlap.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 11:20:15 +0100

Le 03/12/2018 à 22:33, Lubashev, Igor a écrit :
>> -----Original Message----- From: Fred Baker
>> <[email-masked]>
>> Why? For an address that is only used point to point between
> The difference is whether you want to give a name to a link/broadcast
> domain or not.  With % suffix, you are naming physical interfaces
> only.
> 
> Say, you have   A===B===C.   

YEs that's the kind of network.  B has two interfaces.

We never ping from A to C using LLs.  If there is a reply to such a ping 
then there is a problem in the subnet formation.  The subnet formation 
is done by setting some link-layer parameters (notably, the center 
frequency and the band width).

We often ping from A to B and from B to C.  When there is reply we want 
to be sure the reply is coming from that subnet.

> You can assign A (fe80:1::1),
> B(fe80:1::2, fe80:2::1), C(fe80:2::2), and it is clear what is
> connected to what, because each link has a shared name. That said,
> one would still typically need to know the actual interface name for
> any operation like this ping from A:   ping fe80:1::2%rl0

YEs.  We use ping6 -I interface-name.  We dont use '%' because we dont 
know yet how it works, and whether it work son linux.  That "-I 
interface-name" is already an additional burden.

Using '%' instead of '-I iface-name' is shortening of about 6 
characters.  It is good.

Using 'fe80:1::2' instead of 'fe80::aa:bb:cc:dd:ee:11' is shortening of 
about 18 characters.  It is much better.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 11:22:33 +0100

Le 04/12/2018 à 00:14, Mark Smith a écrit :
[...]
> advertises it to its peers when they join the link (RA with a PIO for 
> the GU LL prefix and a Router Lifetime of zero). The second device on 
> the link would learn that globally unique LL prefix and would be 
> prepared to take over announcing it if the first device disappeared (or 
> the second could advertise in parallel after learning from the first, 
> the 3rd device prepares to take over if one of the first two disappear), 
> somewhat similar to how OSPF has primary and backup designated routers 
> on a link.

Noted.

I dont know how we'd decide who's the first device on a link.

But yes, noted.

Alex

> although in this case select hosts are also advertising the globally 
> unique LL prefix.
> 
> simplicity of being able to treat LL addresses no differently to GUAs 
> and ULAs in applications, rather than as a special case, the question is 
> whether it is worth this development and deployment effort, compared to 
> the current method of supplying a scope id. It might be for use in more 
> closed and managed environments where it can be ensured that all hosts 
> and their LL applications support this scheme.
> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
>     The fact that there is a highway to hell and a stairway to heaven is
>     an interesting comment on projected traffic volume...
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Dec 2018 08:22:58 +1100

> I dont know how we'd decide who's the first device on a link.

When a device does its first series of Router Solicitations when its
interface comes up on the link, if it gets no RAs with a PIO containing the
link's globally unique Link Local prefix then it would know it is the first
and it then takes on the role of generating and announcing the globally
unique LL prefix for the link.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Dec 2018 20:27:56 +0100

Le 30/11/2018 à 19:57, 神明達哉 a écrit :
> At Fri, 30 Nov 2018 10:33:01 +0100, Alexandre Petrescu
> <[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.
>> 
> So far it's understandable (except, of course, that fe80:1::2
> violates Section 2.5.6 of RFC4291 and is not standard-compliant).
> 
> 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: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Dec 2018 10:32:44 +0100

Le 30/11/2018 à 19:57, 神明達哉 a écrit :
> At Fri, 30 Nov 2018 10:33:01 +0100,
> Alexandre Petrescu <[email-masked] 
> <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.
> 
> 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.
> 
> nitpicking.  I suspect that's one major reason why we cannot have very
> 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".

But, if one considers the BCP 'IPv6 plen recommendations for 
forwarding', then one is tempted to use disambiguated connected fe80 LL 
routes in the routing table (rather than multiple ambiguated fe80::/64); 
this allows to comfortably ping or ssh without using %1 or -I ifacename.

This is the topology:

       i1 ------- i2      i3-------i4
       --|Router1|---------|Router2|---
          -------           -------

i2 address is fe80:12::1:1/32 ('12' means subnet between R1 and R2,
                                 '1' is R1, 2nd '1' is 'front' interface)
i3 address is fe80:12::2:2/32

On R1, ping R2's LL w/o specifying the iface name.

Alex

> JINMEI, Tatuya

---

From: Yucel Guven <[email-masked]>
Date: Fri, 14 Dec 2018 16:37:06 +0200

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Dec 2018 08:03:31 -0800

At Fri, 14 Dec 2018 10:32:44 +0100,

> this allows to comfortably ping or ssh without using %1 or -I ifacename.

The above comment of mine is in the context of disambiguating
link-local addresses without violating the current protocol
standards.  It's not surprising that it's more convenient for someone
to use a different way that violates the standards for their specific
purposes, if they don't care about standard conformance (or not even
about updating the standard to make it valid).  In that sense I think
I'm done with this thread.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Dec 2018 20:36:57 +0100

Thank you for the comment.

You have the last word.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Dec 2018 15:38:49 +0100

I also agree that 'prefix' includes a 'prefix length' otherwise it's not 
a prefix but an address.

Alex

Le 14/12/2018 à 15:37, Yucel Guven a écrit :
> and for subnet formation. A prefix must have an integer length value 
> from 1 to 127
> On Mon, Dec 10, 2018 at 9:28 PM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      > wrote:
>      >