Subject: about violation of standards

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

In private conversation this debate happened:

is an implementation that uses fe80:1::2 address on an interface a 
violation of standards? (RFC 4291 does not allow for '1' to be there).

My point of view is that as long as that mplementation is widely used, 
that is not a violation of standards.  Rather, the situation makes it 
that that standard is not in agreement with implementations.

Alex

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 18 Apr 2019 15:30:34 -0400

On Thu, Apr 18, 2019 at 2:59 PM Alexandre Petrescu <
[email-masked]> wrote:

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

Which came first, the standard or the egg?

Kerry

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 18 Apr 2019 15:49:42 -0400

Hi Alex,

> violation of standards? (RFC 4291 does not allow for '1' to be there).

<AD Hat on>

Yes. It is certainly a violation of the standards.

> that that standard is not in agreement with implementations.

If you think this is the case, the right way to do it is to fix the
standards. I do have a feeling that your implementation is an outlier here.
If you can point to a "widely used" implementation that does it please do
share.

Thanks
Suresh

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 18 Apr 2019 15:53:30 -0400

> Which came first, the standard or the egg?

Let me expand on my answer, which was (perhaps) pithy but not very helpful.
I don't believe, in general, that standards are created in a vacuum or for
no
purpose.  Particularly when one is working in very constrained environments,
it is often the case that violating one constraint may have knock-on
effects.

In the case of 6LoWPAN HC1 compression, it is assumed the 54 bits following
fe80::/10 are zero, which, in turn, allows the lower 64 bits of the IPv6
address to
be elided for all 6lo data links that I'm familiar with.

I suppose one could argue that for link-local traffic, all the nodes could
agree
that fe80:1::/64 is the local convention, but 1) don't then claim
conformance with
HC1 header compression and 2) prepare to write your own sniffer.

Kerry

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 22:09:50 +0200

Le 18/04/2019 à 21:49, Suresh Krishnan a écrit :
> Hi Alex,
> 
> On Thu, Apr 18, 2019, 2:59 PM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]> wrote:
> 
> standards. I do have a feeling that your implementation is an outlier 
> here. If you can point to a "widely used" implementation that does it 
> please do share.

It is not _my_ implementation.  What is mine is the addressing 
architecture that uses fe80:1::1.

The implementation is linux.  Linux is in widespread use.  Anybody with 
linux can type ifconfig eth0 add fe80:1::1.

I think that command is not a violation of standards.

The only thing that may contradict someone's mind when typing that 
command is the 54 0 bits in RFC4291 (because ifconfig says '1' instead 
of 0).

I wonder whether this answers your invitation to share.

(and I do not know what is an 'outlier').

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 22:13:39 +0200

Le 18/04/2019 à 21:53, Kerry Lynn a écrit :
> On Thu, Apr 18, 2019 at 3:30 PM Kerry Lynn <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On Thu, Apr 18, 2019 at 2:59 PM Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>         [email-masked] <mailto:[email-masked]>
> I don't believe, in general, that standards are created in a vacuum or 
> for no
> I suppose one could argue that for link-local traffic, all the nodes 
> could agree

Thank you for the suggestion.

In another foo (not 6LoWPAN) some nodes agree with fe80:1::.  This does 
not disturb 6lowpan links.

In this sense, I think it can not be said that fe80:1::/32 violates 
anything in 6lowpan.

This is why I do not understand the suggestion.

Alex

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 18 Apr 2019 16:36:38 -0400

On Thu, Apr 18, 2019 at 4:13 PM Alexandre Petrescu <
[email-masked]> wrote:

> If you're referring to a 6lo foo proposal, I'd like to know which one.
If you're not, I probably don't care so much what you do ;-)

> anything in 6lowpan.
>
> My point is simply don't expect to use the LOWPAN dispatch header or
header compression methods.

Kerry

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 22:47:20 +0200

Le 18/04/2019 à 22:36, Kerry Lynn a écrit :
> On Thu, Apr 18, 2019 at 4:13 PM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 

I am using 802.11 in OCB mode.  That is not 6lo, nor 6lowpan.

The foo is "802.11-OCB".

OCB is higher power and other frequencies than 802.15.4.

> header compression methods.

Right, on OCB  I do not expect to use LOWPAN dispatch header, nor header 
compression methods like the ones of 6lo.  In the domain of HEader 
Compression, probably ROHC will work ok on OCB, though.

In linux, IPv6 over OCB works ok with fe80:1::1.

BSD has no OCB support, so it is irrelevant to expect fe80:1::1 from BSD.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Apr 2019 14:01:31 -0700

>    that that standard is not in agreement with implementations.

This logic doesn't make sense to me at all.  There was a very widely used
implementation of commercial router (I don't name it as it's not my
purpose to pick a particular vendor) that forwarded an IPv6 packet
whose source address is link-local from one link to another link,
instead of returning an ICMPv6 destination unreachable error, code 2,
as specified in RFC4443.  According to that logic, this implementation
would be considered not violating the RFC "because it's widely used";
most people call it an implementation bug.

Regarding Linux, I'd note that link-local addresses are automatically
generated by the system, and the generated address conforms to the
format specified in Section 2.5.6 of RFC4291.  More specifically, its
intermediate 54 bits are all set to 0.  Plus, as far as I know, the
vast majority of people never bother to change the auto-generated
link-local addresses.  In that sense the use of addresses like
"fe80:1::2" are not really widely used, even if the implementation
that allows its users to manually configure such addresses is widely
used.

Almost any implementation has some weapon that allows its user to
shoot their feet, often violating protocol standards.  An extreme case
is a tool like bpf, with which you can send out almost any broken
packets to the wire.  BPF is widely used tools, but as far as I know
no one uses the existence of that tool to justify the violation of the
standard.

Now, I'm open to the discussion of possibly updating RFC4291 to allow
non-0 value in the intermediate 54-bit field, starting from the fact
that it currently violates the standard.  But I don't buy an argument
that a behavior against the current standard is not a violation simply
because there's a system utility of a widely used OS that allows that
particular behavior.

--
JINMEI, Tatuya

---

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

I am happy you are open if suggestions of modification RFC4291 are made.

If ever a question should be raised on this topic here is probably about 
one being open or not open to modifications of RFC4291.

Le 18/04/2019 à 23:01, 神明達哉 a écrit :
> On Thu, Apr 18, 2019 at 11:59 AM Alexandre Petrescu 

I read, and I am inclined to think like you when I read it.

But that is a manner of making arguments.

A similar argument can be made like this: the Link Local addresses are 
addresses.  Any RFC that puts any particular semantic on any bits are 
violations of the fact that these are addresses.

It is argument against counter argument, ad infinitum.

But the best thing I heard today is that you are open for RFC4291 changes.

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Apr 2019 08:06:13 +0930

On Fri., 19 Apr. 2019, 04:29 Alexandre Petrescu, <
[email-masked]> wrote:

> that is not a violation of standards.

This is completely wrong.

  Rather, the situation makes it

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Apr 2019 02:07:20 +0200

On 18/4/19 23:01, 神明達哉 wrote:
>>    that that standard is not in agreement with implementations..
> 
> This logic doesn't make sense to me at all. 

+1

[....]
> because there's a system utility of a widely used OS that allows that

In this particular case, it would be mostly useless: such addresses not
only violate existing standards, but also don't work with
widely-deployed implementations. That is, you cannot safely employ them.
As result, there's no point in trying.

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

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Apr 2019 17:50:51 -0700

At Fri, 19 Apr 2019 02:07:20 +0200,

> As result, there's no point in trying.

I'm basically on the same page with you, but I guess some background
context helps here.  In my understanding this is a followup on a
recent int-dir review discussion on
draft-ietf-ipwave-ipv6-over-80211ocb.  In that context, (my
understanding of) the author's argument about the incompatibility with
the "widely-deployed implementations", or more specifically, BSD
variants, is that "that doesn't matter, since they only need to
legitimize this violation for a specific Linux implementation of
IPv6-over-OCB, and they don't care about BSDs since BSDs don't support
OCB" (btw I don't know if there's any BSDs that support OCB or not).
I don't buy that argument either; my response to it is this:
https://mailarchive.ietf.org/arch/msg/int-dir/_tk437U1eq6kHDE3O6c-VrUaeXw

That said, I personally wouldn't close the door immediately.  There
might be even stronger argument for the update even if that would break
some existing implementations that are currently standard-compliant.
IMO that bar should be very high, but I wouldn't say it can never be
cleared.  Sometimes even a disruptive update can be justified (like an
extreme case of some security matters).  Now that the author seems to
choose the option to try that bar, I'm now waiting for a stronger
argument than "we don't care about those existing incompatible
implementations".

--
JINMEI, Tatuya

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Apr 2019 07:00:01 +0000

Hello Jinmei San

Agreed

While I completely object with Alexandre’s argument I tend to agree with the end goal.

Some functions in the router are complex to implement because same value for a link local address appears on multiple interfaces.

It would be useful to be able to encode an abstract interface ID somewhere in the /64. Legacy 00 would mean unspecified...

All the best,

Pascal

Le 19 avr. 2019 à 02:51, 神明達哉 <[email-masked]<mailto:[email-masked]>> a écrit :

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Apr 2019 09:25:31 -0700

At Fri, 19 Apr 2019 07:00:01 +0000,
"Pascal Thubert (pthubert)" <[email-masked]> wrote:

> Some functions in the router are complex to implement because same value
for a link local address appears on multiple interfaces.

Yeah, I see that motivation.  The generic/usual answer of mine to that
kind of problem is to use the sockaddr_in6::sin6_scope_id (or anything
similar to it for a non-POSIX platform) and the extended textual
format for scoped addresses as described in RFC4007.  But I can
imagine there are cases where they are not enough and/or applicable.

So...

> It would be useful to be able to encode an abstract interface ID
somewhere in the /64. Legacy 00 would mean unspecified...

(As a co-author of RFC4007 I can't help correcting it to "link ID"
instead of "interface ID" but:-)... yes, I can imagine we might reach
some consensus of using some portion of the 128-bit space to encode
that information.  But, that will require a lot of considerations,
including

- whether the goal is really impossible to achieve with currently
  available tools
- especially if the first answer is something like "it can, but it's
  not convenient", then whether the goal really justifies to consume
  a particular space of the finite resource of address space
- whether it has to be inside the upper 64 bits (or in more general,
  inside the "subnet prefix" part).  If it has to be so, whether it
  has to be within the first 32 bits (if not, at least it doesn't
  conflict with the BSD implementation).
- if, like draft-petrescu-6man-ll-prefix-len suggests, the encoded ID
  is the same for all nodes in the link, how we assign those IDs and
  how we ensure their uniqueness, how each node knows the ID on
  generating addresses, etc.

When I said "I'm open to discussion", I meant I'm willing to discuss
these matters.  Of course, since there are so many open questions, I'd
expect it to take quite a long time, and I can't say at this point
whether I support the eventual proposal that the WG might come up
with, or whether we can really expect any WG-wide consensus.  I'm now
clarifying the intent, as it didn't seem to be clear enough.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Apr 2019 10:57:44 -0700

At Fri, 19 Apr 2019 10:44:50 -0700,
Erik Kline <[email-masked]> wrote:

> The thing here is that the standard currently keeps the 54 bits between
/10
> and /64 as zero-valued.  As such, an implementation can lean on the
> standard for safety to create a non-standard internal representation
where,
> say, in6_addr.s6_addr32[1] = ifindex.
>
> *Not* changing the standard actually gives cover to what people want to do
> internally.  Changing the standard opens this space up for other competing
> uses that might need to be given consideration and, IMO, only serves to
> confuse matters.
>
> No change to any standard is required here, as I currently see it.

Sure, that's my current position, too.  So the bar for justification
is very high, but I personally wouldn't just deny any discussion for
the possibility outright, hence "open to discussion".  Some others,
perhaps including you, might think the bar is too high to even
consider the possibility.  I wouldn't be that strict, but it's also
understandable.

--
JINMEI, Tatuya

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Apr 2019 19:34:48 -0400

Suresh & Alexandre 

There are many implementations worldwide that I have been involved in deployment of IPv6 using a standard architecture that I deploy to all my customers and that involves setting the station id on the link local address so that the next hop is more intuitive and easily recognizable that it’s your local next hop since by default all routers and hosts set the station id to EUI64 format FFFE big stuff into the MAC address between the 3rd and 4th octet which is “non intuitive”

So the IPv6 addressing RFC 4291 states the 1st 10 bits used for fe80 and the next 54 bits must be set to 0 which covers the 64 bit prefix length so the entire station id 64 bits is open to be modified and changed as the end user desires on any platform and that is following the current RFC standard.  

So in Alexandre scenario with BSD setting the LL to FE80::1 would be fine but if you did fe80:1::1 that would be setting 1s in the all 0s 54 bit field of the station id which is not allowed.

So as far a variable link local address I am in favor of variable and you have the entire 64 bit station id to modify which is fine but I am completely not in favor of violating the current standard of writing into the 54 bit all 0s portion of the network prefix.

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

Sent from my iPhone

> On Apr 19, 2019, at 12:25 PM, 神明達哉 <[email-masked]> wrote:
> 
> with, or whether we can really expect any WG-wide consensus..  I'm now

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Apr 2019 20:23:13 -0400

One other comment I would like to make as far as standard and that we should not allow the OS Unix or Windows or any network operating system drive or change the standards.

Here is the case and point.

Cisco routers for example most all platforms these days use a Linux BSD kernel so is similar to a standalone Linux flavor server.

What I have noticed and confirmed and this is from extensive IPv6 testing is that the OS for IPv4 has the capability to do subnet and mask check for valid IPv4 address coded however IPv6 due to the complexity of IPv6 with 128 bits a subnet check is done and will spit out error for router anycast if used but major loophole exists and that is that you can configure any global unicast address in the network 64 bit portion that is not valid and same goes for Link local addresses.

I believe that is due the coding checks limitations within the OS to check against what is valid and what is not is so complex to code that OS allows anything to be configured even though from an IETF RFC perspective it’s not following the standard IPv6 format.

For example for my CCIE studies I would always code my v6 marching v4 so v4 is let’s say 10.0.0.1/30 I would make my v6 address 10::1/126.

That being said the fe80:1::1 can be coded on both Linux host and a CISCO router with Linux kernel under the hood but that does not make it correct or valid that we should now change the RFC 4291 to allow that to happen.

I don’t see any justification to allowing the 54 bits in the network 64 bit portion of the link local address to be changed from all 0s.

Please respond back to this email thread if you feel differently and also respond if you agree.

Thank you

Gyan

Sent from my iPhone

> On Apr 20, 2019, at 7:34 PM, Gyan Mishra <[email-masked]> wrote:
> 
> Suresh & Alexandre 
>

---

From: Yucel Guven <[email-masked]>
Date: Mon, 22 Apr 2019 18:37:08 +0200

Hi Jinmei Tatuya,

> as specified in RFC4443.

That is very interesting point indeed.
Do you mean that billions of people's data, information, etc...etc... from
their Link-locals
can easily be routed to somewhere that no one knows? Just because of
"that vendor" (or vendors?)
If that's the case, I really wonder about what can be done with "127.0.0.1".

Anyways, my concern is about huge amount of addresses of the fe80::/10.
There are 281,474,976,710,655 =  281 Trillion 474 Billion 976 million 710
Thousand 655 addresses
in between  fe80:0:0:0::/64  and fe80:ffff:ffff:ffff::/64.
If we just take  fe80:1::/32 or /64, then it breaks RFC4291 due to 54 zeros.

Is it right time to modify RFC4291?

---

From: 神明達哉 <[email-masked]>
Date: Mon, 22 Apr 2019 09:15:30 -0700

At Mon, 22 Apr 2019 18:37:08 +0200,

> "that vendor" (or vendors?)

In theory yes, but I suspect it was quite unlikely in practice,
since when the source address is link-local, the destination address
is usually also link-local.  That implementation didn't let such
packets leak to a different link; this bug only happened when the
destination address was global.  I also don't know if this
implementation still has this bug today (note the past tense).

Anyway, such details are not the main point in this thread.  I just
gave a concrete example of why it doesn't make sense to justify a
broken behavior because of a "widely used implementation".  (hmm,
actually, these two cases have some common point that may matter in
the main context: in both cases the underlying implementation is
"widely used", but the usage of the broken behavior should be pretty
rare).

> If we just take  fe80:1::/32 or /64, then it breaks RFC4291 due to 54
zeros..
> Is it right time to modify RFC4291?

I don't think it's my call, but I provided some view of mine on a
related point in a separate thread:
https://mailarchive.ietf.org/arch/msg/ipv6/nRuLvdZptV2aR3TTzvh0WCKo7fQ
https://mailarchive.ietf.org/arch/msg/ipv6/D4YaezwdzKJ31mhKiqa8J8UWhoU

I don't know if it's the "right time", but I don't refuse an attempt
of updating RFC4291 on this point outright.  In my understanding many
of the participants in the recent relevant threads were also open to
listen to such attempts; they just rightly requested a valid
justification, and they simply didn't see it (neither did I, btw).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Apr 2019 21:38:25 +0200

Le 22/04/2019 à 18:37, Yucel Guven a écrit :
[...]
> On Thu, Apr 18, 2019 at 11:03 PM 神明達哉 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
[...]
Tauya said:
> Regarding Linux, I'd note that link-local addresses are
> automatically generated by the system, and the generated address
> conforms to the format specified in Section 2.5.6 of RFC4291.

YEs, RFC4291.  As a side not they are not privacy addresses, probably
risking to be discarded in conversation.

> More specifically, its intermediate 54 bits are all set to 0.

YEs.

> Plus, as far as I know, the vast majority of people never bother to 
> change the auto-generated link-local addresses.

Do these people ping on CLIs w/o mice? (use ping command on a Command
Line Interface without having access to mouse top copy paste long IIDs;
like in a car, or in some position where kbd is available but not the
mouse).

> In that sense the use of addresses like "fe80:1::2" are not really
> widely used,

Agreed.  It is a matter of saying what is widely used and what not.

Probably only a few people type ifconfig fe80:1::1.  But I think I have 
heard some people on the mailist list doing so, and in private too. 
True, it was based on my request.

In my setting, it would be advantageous to do it.

BTW, I do not think anybody on linux uses fe80::1 on lo, right?

> even if the implementation that allows its users to
> manually configure such addresses is widely used.

YEs, that is how to say it: the implementation that allows its users to 
manually configure such addresses is widely used.

I would like to add something else: the implementation that does _not_ 
allow the users to add fe80:1::1 (BSD) does not complain about it.  It 
silently refuses.

> shoot their feet, often violating protocol standards.  An extreme 
> case is a tool like bpf, with which you can send out almost any 
> broken packets to the wire. 

:-)

> BPF is widely used tools, but as far as
>  I know no one uses the existence of that tool to justify the 
> violation of the standard.
> 
> Now, I'm open to the discussion of possibly updating RFC4291 to
> allow non-0 value in the intermediate 54-bit field, starting from the
> fact that it currently violates the standard.  But I don't buy an
> argument that a behavior against the current standard is not a
> violation simply because there's a system utility of a widely used OS
> that allows that particular behavior.

I understand.

Alex

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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Apr 2019 23:04:12 +0100

> allow the users to add fe80:1::1 (BSD) does not complain about it.  It 

this is expected behaviour on BSD (Kame derivatives?). fe80::/10 
configuration is controlled by the "ifconfig XX auto_linklocal" 
directive.  If auto_linklocal is configured, then the kernel will 
automatically configure the fe80::/64 prefix.  You cannot configure the 
value directly.

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Apr 2019 20:00:17 -0400

I honestly cannot believe that we have been discussing or even entertaining
discussing this topic.

The IPv6 WG was developed to define standards and not think of ways of
loopholes to violate the rules of the standard that have been developed and
especially that have been the standard for decades.  Absolutely absurd!!!

BELOW IS MY EARLIER POST

WE SHOULD NOT AT ALL COSTS VIOLATE RFC 4291!!!!!!!!!!!!!!!!!!!!!

There are many implementations worldwide that I have been involved in
deployment of IPv6 using a standard architecture that I deploy to all my
customers and that involves setting the station id on the link local
address so that the next hop is more intuitive and easily recognizable that
it’s your local next hop since by default all routers and hosts set the
station id to EUI64 format FFFE big stuff into the MAC address between the
3rd and 4th octet which is “non intuitive”

So the IPv6 addressing RFC 4291 states the 1st 10 bits used for fe80 and
the next 54 bits must be set to 0 which covers the 64 bit prefix length so
the entire station id 64 bits is open to be modified and changed as the end
user desires on any platform and that is following the current RFC
standard.

So in Alexandre scenario with BSD setting the LL to FE80::1 would be fine
but if you did fe80:1::1 that would be setting 1s in the all 0s 54 bit
field of the station id which is not allowed.

So as far a variable link local address I am in favor of variable and you
have the entire 64 bit station id to modify which is fine but I am
completely not in favor of violating the current standard of writing into
the 54 bit all 0s portion of the network prefix.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Apr 2019 20:04:03 -0400

...this is also from one of my earlier posts at a desperate hope to put
this discussion about allowing fe80:1::1 and having a consensus agreement
by all that it is not allowed per RED 4291.

One other comment I would like to make as far as standard and that we
should not allow the OS Unix or Windows or any network operating system
drive or change the standards.

Cisco routers for example most all platforms these days use a Linux BSD
kernel so is similar to a standalone Linux flavor server.

What I have noticed and confirmed and this is from extensive IPv6 testing
is that the OS for IPv4 has the capability to do subnet and mask check for
valid IPv4 address coded however IPv6 due to the complexity of IPv6 with
128 bits a subnet check is done and will spit out error for router anycast
if used but major loophole exists and that is that you can configure any
global unicast address in the network 64 bit portion that is not valid and
same goes for Link local addresses.

I believe that is due the coding checks limitations within the OS to check
against what is valid and what is not is so complex to code that OS allows
anything to be configured even though from an IETF RFC perspective it’s not
following the standard IPv6 format.

For example for my CCIE studies I would always code my v6 marching v4 so v4
is let’s say 10.0.0.1/30 I would make my v6 address 10::1/126.

That being said the fe80:1::1 can be coded on both Linux host and a CISCO
router with Linux kernel under the hood but that does not make it correct
or valid that we should now change the RFC 4291 to allow that to happen.

I don’t see any justification to allowing the 54 bits in the network 64 bit
portion of the link local address to be changed from all 0s.

Please respond back to this email thread if you feel differently and also
respond if you agree.

On Mon, Apr 22, 2019, 8:00 PM Gyan Mishra <[email-masked]> wrote:

> I honestly cannot believe that we have been discussing or even
> entertaining discussing this topic.
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Apr 2019 20:16:03 -0400

My concern  with all this is that you have to have and show even one use
case where 2^64  64 bits of station id is not enough bits and you need to
encroach on the 54 bit all 0's field.

Just give me one example showing me a use case that 1.84467441E+19 is just
not big big enough.

Gyan

On Mon, Apr 22, 2019, 11:37 AM Yucel Guven <[email-masked]> wrote:

> zeros.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Apr 2019 20:27:09 -0400

Here is an abstract thougut ...

So given BAD Unix allows you to write onto the 54 bit all 0s field not
following the standard due inability to provide those checks due to coding
complexity.

So router and switch firewall and load balancer and server can still due to
their inability to check the link local can still code whatever they want
it's just that the inter vendor interoperability may not work is the
disclaimer if not following the RFC 4291 standard.

We can all sing kum bay ah and all finally agree to disagree but all have a
consensus.

Gyan

On Mon, Apr 22, 2019, 8:16 PM Gyan Mishra <[email-masked]> wrote:

> Just give me one example showing me a use case that 1.84467441E+19 is
> just not big big enough.
>
> Gyan
>
>> Do you mean that billions of people's data, information, etc...etc...
>> from their Link-locals

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Apr 2019 09:32:34 +0200

> Some functions in the router are complex to implement because same value for a link local address appears on multiple interfaces. 

Like what?

> It would be useful to be able to encode an abstract interface ID somewhere in the /64. Legacy 00 would mean unspecified...

Sounds like you need subnet-id election?

Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Apr 2019 19:57:46 +1000

> for a link local address appears on multiple interfaces.

I don't specifically know about complex to implement router functions,
however it would be simpler for applications to not have to special case
Link-Local addresses and use sin6_scope_id.

> Sounds like you need subnet-id election?

Here's how I've thought you could do it for quite a while.

I've thought the best idea would be to have a subnet ID that is generated
using the same/similar algorithm ULAs are generated with, to try to avoid
subnet ID collision across links attached to interfaces on the same
multihomed host or router.

A name could be Globally Unique Link Local Addresses (GULLAs) or Unique
Link Local Addresses (ULLAs). (I'd think the first, just because its a more
easily pronounceable word.)

1. First node on the link looks at the RAs that it receives due to its RSes.

2. If none of them have a PIO for a subnet within the GULLA aggregate
prefix (which may be fe80::/10), it generates a subnet ID per the ULA
algorithm, resulting in the link's GULLA Subnet Prefix.

3. The node starts advertising RAs containing the GULLA Subnet PIO. If the
node is a host, the Router Lifetime is 0. The GULLA Subnet PIO lifetimes
are not Infinite, unlike the lifetimes for the traditional LL prefix and
addresses. Lifetimes in this PIO probably should be the RFC 4861 defaults.
(If the node is also a router, it would advertise any other PIOs in the
same RA, with a non-zero router life time if it is a default router.)

4. Second node on the link, due to its RSes, would see that another node is
already announcing a GULLA Subnet PIO in one of the received RAs.

5. Second node starts also issuing RAs also containing the GULLA Subnet
PIO. Again, if the node is a host, RA router lifetime of zero.

6. 3rd and subsequent nodes attached to the link have some sort of election
or selection algorithm to determine which one or ones take over if the
first or both nodes stop issuing periodic RAs containing the GULLA Subnet
PIO.

Ideally it would be good to have non-GULLA nodes also learn and use this
new GULLA Subnet, learning it from the GULLA RA announcing nodes. However,
that would mean that the fe80::/10 prefix couldn't be used, because
per-RFC4861, nodes are to ignore RA PIOs for the Link-Local prefix. So the
GULLA aggregate prefix would have to be outside of fe80::/10.

The above is mostly inspired by very distant memories of how Appletalk seed
routers work to convey cable range (network prefix) information to other
Appletalk routers on the link.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Apr 2019 20:03:08 +1000

On Tue, 23 Apr 2019 at 19:57, Mark Smith <[email-masked]> wrote:
> I don't specifically know about complex to implement router functions, however it would be simpler for applications to not have to special case Link-Local addresses and use sin6_scope_id.
>
>>
> I've thought the best idea would be to have a subnet ID that is generated using the same/similar algorithm ULAs are generated with, to try to avoid subnet ID collision across links attached to interfaces on the same multihomed host or router.
>
> A name could be Globally Unique Link Local Addresses (GULLAs) or Unique Link Local Addresses (ULLAs). (I'd think the first, just because its a more easily pronounceable word.)
>
> 2. If none of them have a PIO for a subnet within the GULLA aggregate prefix (which may be fe80::/10), it generates a subnet ID per the ULA algorithm, resulting in the link's GULLA Subnet Prefix.
>
> 3. The node starts advertising RAs containing the GULLA Subnet PIO. If the node is a host, the Router Lifetime is 0. The GULLA Subnet PIO lifetimes are not Infinite, unlike the lifetimes for the traditional LL prefix and addresses. Lifetimes in this PIO probably should be the RFC 4861 defaults. (If the node is also a router, it would advertise any other PIOs in the same RA, with a non-zero router life time if it is a default router.)
>
> 4. Second node on the link, due to its RSes, would see that another node is already announcing a GULLA Subnet PIO in one of the received RAs.
>
> 5. Second node starts also issuing RAs also containing the GULLA Subnet PIO. Again, if the node is a host, RA router lifetime of zero.
>
> 6. 3rd and subsequent nodes attached to the link have some sort of election or selection algorithm to determine which one or ones take over if the first or both nodes stop issuing periodic RAs containing the GULLA Subnet PIO.
>
> Ideally it would be good to have non-GULLA nodes also learn and use this new GULLA Subnet, learning it from the GULLA RA announcing nodes. However, that would mean that the fe80::/10 prefix couldn't be used, because per-RFC4861, nodes are to ignore RA PIOs for the Link-Local prefix. So the GULLA aggregate prefix would have to be outside of fe80::/10.
>

Another thought to add, since the GULLA Subnet Prefix is globally
unique, it may be worth considering a scheme to periodically
transition to a new GULLA prefix on the link, just in case the GULLA
addresses leak off-link or are recorded by an on-link sniffing device
in a central global database.

> The above is mostly inspired by very distant memories of how Appletalk seed routers work to convey cable range (network prefix) information to other Appletalk routers on the link.
>
> Regards,
> Mark.
>
>
>
>>
>>
>> Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Apr 2019 10:19:52 +0000

> for a link local address appears on multiple interfaces.

Like structuring the tables where you maintain the address binding.

Because a link local is only unique within the link / broadcast domain where DAD occurs, you have to add the sense of that link / broadcast domain as an additional key to your binding table, whereas for the GUA the prefix gives you that from within the address, and the address is sufficient as a key.

Turns out nothing is too particularly neat for the role. On Ethernet, a VLAN does not guarantee a unique global value though at least it is a local sense of the broadcast domain and you can use it as a node-local key. But you cannot get a global sense of where the link local address is in your network by just looking at it. 

If there was an encoding of that global sense of the broadcast domain in the link local address, one could log in or even send a message to any router in that domain and ask if the link local is live by making it ping or what. And one could generate that request using the link local address only, as opposed to encoding a address%interface that is locally significant to the particular router or host that I'd use to ping the link local address, always a hassle.

This would extend the value of the link local without changing its scope, and enable common APIs, tables and GUIs, understanding that what we'd encode represents a physical domain that is not necessarily mapped to a logical subnet. 

> > It would be useful to be able to encode an abstract interface ID somewhere
> in the /64. Legacy 00 would mean unspecified...
> 

Not of a subnet, rather an ID for a link or a broadcast domain, a bit like what DNA was after. On an Ethernet domain it is easy to confuse those things because the shared wiring defines at the same time the physical link, the broadcast domain and the subnet that we map over it. But the difference shows on legacy NBMA like ATM or FR, on shared links and on newer types of NBMA such as radio and composite radio-wires networks. 

In radios, the broadcast domain is defined differently by each transmitter as opposed to defined commonly by a shared wire. 
In mesh-under (e.g., a Wi-Fi mesh or IEEE 802.15.10) the link extends beyond the broadcast domain. In route-over (e.g., 6TiSCH with RPL), the subnet extends beyond the link.
Note that a Wi-Fi BSS is an exception whereby the broadcast domain of the AP emulates the common wire, but that takes a particular L2 emulation that is not present in other types of WPAN/WLAN/LPWAN radio links.

On radios without a BSS, links between peers come and go as their individual broadcast domains meet physically. The ND DAD operation cannot provide once and for all guarantees on the broadcast domain defined by one radio transmitter if that transmitter keeps meeting new peers on the go. The nodes may need to form new LLAs to talk to one another and the scope where LLA uniqueness can be dynamically checked is really that pair of nodes. As long as there's no conflict a node may use the same LLA with multiple peers but it has to revalidate DAD very time. So it's like if each pair of nodes defines a temporary P2P link, like a sub-interface of the radio interface. In that case, we could encode something about that P2P link in the LLA, like something derived from MAC addresses, while keeping the same IID. 

All the best,

Pascal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Ole Troan
> Sent: mardi 23 avril 2019 09:33
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; Alexandre Petrescu
> <[email-masked]>; 6man WG <[email-masked]>; 神明達哉
> <[email-masked]>
> Subject: Re: about violation of standards
> 
> > It would be useful to be able to encode an abstract interface ID somewhere
> in the /64. Legacy 00 would mean unspecified...
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Apr 2019 12:36:02 +0200

Pascal,

Sounds like what you want is to replace link-local addresses with ULAs.
I’m quite convinced that the complexity tradeoff of that scheme is much worse than having to deal with scoped addressed. ;-)

Cheers,
Ole

> On 23 Apr 2019, at 12:19, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 23 Apr 2019 23:17:17 +0200

>multihomed host or router.

I wonder about a use case that is important enough that it is worth adding
quite a bit of protocol to every host.

My first question was, what if there is router on the link? In that case the
router could announce a ULA and there would no need for hosts to do anything.
Even if that would require extra protocol in routers then that would be
better than having all hosts implement an election protocol. I think
homenet already has a coordination protocol.

Okay, no router. In that case you would probably use some sort of
service discovery protocol, like mDNS, DNS-SD, etc., Would it really be hard
to pass a sockaddr_in6 around in an application? 

What else do we have. Debugging. There is a syntax for scope in link local
address literals. Maybe a bit more typing, but you don't want to type IPv6
addresses anyhow. There is a bit of a problem that browsers don't want to
implement that.

So the use case is not clear to me.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Apr 2019 09:52:13 +1200

Firstly, I don't believe they could in any sense be globally unique.
(Even ULAs don't claim to be mathematically unique, just probably unique.)
So let's call them LULLAs (Locally Unique...), a.k.a. Lullabies.

However:

> however it would be simpler for applications to not have to special case Link-Local addresses and use sin6_scope_id.

But they have to anyway, because you can't know in the general case whether LULLAs are in use or not. Anyway, there's nothing new about needing to store an
interface index number (or name) with an LL address. Any existing code that
is LL-dependent already does this, unless it's broken.

Regards
   Brian

On 23-Apr-19 21:57, Mark Smith wrote:
> 
> 
> On Tue., 23 Apr. 2019, 17:33 Ole Troan, <[email-masked] <mailto:otroan@employees..org>> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Apr 2019 11:21:51 +1200

> Sounds like what you want is to replace link-local addresses with ULAs.

No, because ULAs have a different constraint: they are valid within a specific domain, which we assume to be relatively stable, so that its border routers can filter the ULA prefix. What Pascal describes is a much more fluid situation, where link-local domains are forming and dissolving all the time and unpredictably. (Exactly the OCB situation in heavy traffic, in fact.)

> I’m quite convinced that the complexity tradeoff of that scheme is much worse than having to deal with scoped addressed. ;-)

It is. Mesh networks are not easy, especially with other SDOs trying to solve mesh network problems at layer 2. This discussion is at layer 2.5. But I think Pascal is correct to say "nodes may need to form new LLAs to talk to one another and the scope where LLA uniqueness can be dynamically checked is really that pair of nodes." How can GUA routing be stable in such a network?

    Brian

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 23 Apr 2019 23:27:36 -0400

Alexandre, Brian & Pascal & Ole

Sorry -  I misunderstood the earlier thread subject "about violating
standard" and Alexandre's example with BSD fe80:1::1  - took me on a
tangent.  Sorry about that.

Now I think I am on board that what we are trying to do is build a new
revision for the link local addressing schema we have today and address the
pitfalls and provide improvements to help with future use cases.

After reading through the the dialog I am seeing that what we are trying to
do is develop or improve what currently is defined for link local with a
new specification or idea that provides a means of DAD that is done with
EUI64 stationid or random station id or address based algorithm that
provides for a more intuitive ULA type subnet field where the 00 -54 bits
would become legacy IPv6 and  new products deployed would be able to
support this new GULLA type local address that has global significance but
still used for local packet processing ICMPv6 Type 133/134 RA/RS & Type
135/136 NS/NA ND cache but have an ability to be dynamic algorithm that has
a DAD type capability to prevent overlap such as is done with ULA RFC 4193.

ULA provides the ability to use private non routed space similar to IPV4
RFC 6761 but then requires 6to6 NAT overload for external access which I
think in the auto use case would work so we don't burn through /48 per
manufacturer but then have the 6to6 nat overhead.

So with this new link local revision we are trying to address the pitfalls
with the current RFC 4291 RFC addressing schema for link local.  Is that
correct?

I think one of the pitfalls of the current link local fe80::/10 is it is
one big space and their is no subnet-id so I think with this new version
link local revision we would essentially use the 54 bit field as the
subnet-id using a ULA type GULLA randomness in assigning.   In most cases
the fe80::/10 is fine and using the EUI64 for unique station-id but I guess
if you want to build more meaning into the link local I can now see adding
a new subnet-id field for the new link local revision does make sense.

Below is from RFC 4291 - ULA - so I guess we are thinking the subnet-id
would have a similar GULLA randomness built in to ensure uniqueness.  Makes
sense.

3.2.1 <https://tools.ietf.org/html/rfc4193#section-3.2.1>.  Locally
Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM
<https://tools.ietf.org/html/rfc4193#ref-RANDOM>].  Section 3.2.2
<https://tools.ietf.org/html/rfc4193#section-3.2.2> describes a
   suggested algorithm.  It is important that all sites generating
   Global IDs use a functionally similar algorithm to ensure there is a
   high probability of uniqueness.

   The use of a pseudo-random algorithm to generate Global IDs in the
   locally assigned prefix gives an assurance that any network numbered
   using such a prefix is highly unlikely to have that address space
   clash with any other network that has another locally assigned prefix
   allocated to it.  This is a particularly useful property when
   considering a number of scenarios including networks that merge,
   overlapping VPN address space, or hosts mobile between such networks.

>From that angle of improvement the 54 bit all 0's field does seem like a
waste being all 0's and maybe the original author back in 1998 meant that
was for the "now" almost 20 years ago but was meant to keep open for future
change and uses cases.  Understood and that makes sense.

While we are looking at improvement of the link local address and
addressing pitfalls I was wondering if this maybe another change we could
make to the link local addressing structure.

So IGP routing protocols such as ISIS & OSPF use the Link Local as the next
hop which is not intuitive having the EUI64 station-id which I understand
that was done to maintain uniqueness.  What if we did something similar to
a GULLA randomness with the station-id so that it is not MAC based.

In implementations I have worked with to make the next hop more intuitive
where we have an IPv6 address on the routed interface and not just the link
local we have embedded the LSB bits excluding the 1st 16 bits into the
station-id to make it similar to the global unicast address assigned to the
routed interface.  For a routed interface you don't necessarily have to
have a IPv6 address and there are Cisco and other vendor implementations
that have a Cisco like knob "ipv6 enable" which enables IPv6 packet
processing so you don't have to assign a IPv6 address.  However in IPv6
implementations I have worked with we have done so, so that when you
traceroute  you can see global unicast addresses along the routed next hops
hop by hop along the path for ease of troubleshooting and MTTR in cases of
failures or routing issues.

I wonder if this is something we can do to improve on with the current
standard EUI64 or random station-id used for the link local address today.

Thank you

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

On Tue, Apr 23, 2019 at 7:22 PM Brian E Carpenter <
[email-masked]> wrote:

> No, because ULAs have a different constraint: they are valid within a
> specific domain, which we assume to be relatively stable, so that its
> border routers can filter the ULA prefix. What Pascal describes is a much
> more fluid situation, where link-local domains are forming and dissolving
> all the time and unpredictably. (Exactly the OCB situation in heavy
> traffic, in fact.)
>
> > I’m quite convinced that the complexity tradeoff of that scheme is much
> worse than having to deal with scoped addressed. ;-)
>
> It is. Mesh networks are not easy, especially with other SDOs trying to
> solve mesh network problems at layer 2. This discussion is at layer 2.5.
> But I think Pascal is correct to say "nodes may need to form new LLAs to
> talk to one another and the scope where LLA uniqueness can be dynamically
> checked is really that pair of nodes." How can GUA routing be stable in
> such a network?
>
>     Brian
>
>    Brian
>
> > Cheers,
> > Ole
> >
> >> Because a link local is only unique within the link / broadcast domain
> where DAD occurs, you have to add the sense of that link / broadcast domain
> as an additional key to your binding table, whereas for the GUA the prefix
> gives you that from within the address, and the address is sufficient as a
> key.
> >>
> >> Turns out nothing is too particularly neat for the role. On Ethernet, a
> VLAN does not guarantee a unique global value though at least it is a local
> sense of the broadcast domain and you can use it as a node-local key. But
> you cannot get a global sense of where the link local address is in your
> network by just looking at it.
> >>
> >> If there was an encoding of that global sense of the broadcast domain
> in the link local address, one could log in or even send a message to any
> router in that domain and ask if the link local is live by making it ping
> or what. And one could generate that request using the link local address
> only, as opposed to encoding a address%interface that is locally
> significant to the particular router or host that I'd use to ping the link
> local address, always a hassle.
> >>
> >> This would extend the value of the link local without changing its
> scope, and enable common APIs, tables and GUIs, understanding that what
> we'd encode represents a physical domain that is not necessarily mapped to
> a logical subnet.
> >>
> >>
> somewhere
> >> Not of a subnet, rather an ID for a link or a broadcast domain, a bit
> like what DNA was after. On an Ethernet domain it is easy to confuse those
> things because the shared wiring defines at the same time the physical
> link, the broadcast domain and the subnet that we map over it. But the
> difference shows on legacy NBMA like ATM or FR, on shared links and on
> newer types of NBMA such as radio and composite radio-wires networks.
> >>
> >> In radios, the broadcast domain is defined differently by each
> transmitter as opposed to defined commonly by a shared wire.
> >> In mesh-under (e.g., a Wi-Fi mesh or IEEE 802.15.10) the link extends
> beyond the broadcast domain. In route-over (e.g., 6TiSCH with RPL), the
> subnet extends beyond the link.
> >> Note that a Wi-Fi BSS is an exception whereby the broadcast domain of
> the AP emulates the common wire, but that takes a particular L2 emulation
> that is not present in other types of WPAN/WLAN/LPWAN radio links.
> >>
> >> On radios without a BSS, links between peers come and go as their
> individual broadcast domains meet physically. The ND DAD operation cannot
> provide once and for all guarantees on the broadcast domain defined by one
> radio transmitter if that transmitter keeps meeting new peers on the go.
> The nodes may need to form new LLAs to talk to one another and the scope
> where LLA uniqueness can be dynamically checked is really that pair of
> nodes. As long as there's no conflict a node may use the same LLA with
> multiple peers but it has to revalidate DAD very time. So it's like if each
> pair of nodes defines a temporary P2P link, like a sub-interface of the
> radio interface. In that case, we could encode something about that P2P
> link in the LLA, like something derived from MAC addresses, while keeping
> the same IID.
> >>
> >> All the best,
> >>
> >> Pascal
> >>
> somewhere

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Apr 2019 13:28:48 +1000

Hi Brian,

> So let's call them LULLAs (Locally Unique...), a.k.a. Lullabies.

Agree, was really only adding the Global in there as more of a goal
rather than a fact or guarantee and as a more pronounceable acronym.

I think "ULA" suffers from a bit of ambiguity too to get brevity.

> is LL-dependent already does this, unless it's broken.

I think the advantage of LLs is that they're required on all IPv6
enabled interfaces, so there is always an IPv6 address available for
an application (and other things) to use.

However, the drawback of using LL addresses is that each application
has to be written to specifically handle them via sin6_scope_id.

Ideally, applications wouldn't have to be written to specially handle
link-local scope addresses. Some type of link-local scope addresses
with some link-attached nodes agreed unique Subnet ID would facilitate
that, pushing the issue of interface selection down into each node's
route table. All applications would then inherently support the use of
these link-local scope addresses.

I understand that one of the motivations for Link-Local addressing was
the "dentist's office" scenario i.e. non-technical, plug and play, "it
just works" networking. Having to have specially adapted applications
to suit that that scenario is pretty contradictory to that goal.

The scheme I've suggested below could work with the ULA address space.
The only real difference is that packets with Link-Local addresses are
formally prohibited from being forwarded off of the link, which could
provide a useful security benefit to certain applications, although we
know they do leak on occasion. With the ULA address space, off link
forwarding of course it isn't prohibited, so it's a specific risk if
the ULA address space was used.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 23 Apr 2019 23:39:25 -0400

Hi Brian

I think the LULLA or GULLA would work as the uniqueness would come from the
station-id not from the subnet-id field that is using the LULLA style
algorithm which is not bullet proof for uniqueness and is based on
probability.

I am guessing what the LULLA would provide is a means to better manage the
fe80::/10 space being subnetted even though still "non routable" as  the
1st 10 bits being fe80 the subnet-id even if that were changed would not
make it even locally routable so it that it would be bleed out into the
network even locally.

This new version of the link local adress would still be "non routable".

Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000
On Tue, Apr 23, 2019 at 11:29 PM Mark Smith <[email-masked]> wrote:

> > > however it would be simpler for applications to not have to special
> case Link-Local addresses and use sin6_scope_id.
> >
> > But they have to anyway, because you can't know in the general case
> whether LULLAs are in use or not. Anyway, there's nothing new about needing
> to store an
> > >     > Some functions in the router are complex to implement because
> same value for a link local address appears on multiple interfaces.
> > >
> > >     Like what?
> > >
> > >
> > >
> > > I've thought the best idea would be to have a subnet ID that is
> generated using the same/similar algorithm ULAs are generated with, to try
> to avoid subnet ID collision across links attached to interfaces on the
> same multihomed host or router.
> > >
> > > A name could be Globally Unique Link Local Addresses (GULLAs) or
> Unique Link Local Addresses (ULLAs). (I'd think the first, just because its
> a more easily pronounceable word.)
> > >
> > > 3. The node starts advertising RAs containing the GULLA Subnet PIO. If
> the node is a host, the Router Lifetime is 0. The GULLA Subnet PIO
> lifetimes are not Infinite, unlike the lifetimes for the traditional LL
> prefix and addresses. Lifetimes in this PIO probably should be the RFC 4861
> defaults. (If the node is also a router, it would advertise any other PIOs
> in the same RA, with a non-zero router life time if it is a default router.)
> > >
> > > 4. Second node on the link, due to its RSes, would see that another
> node is already announcing a GULLA Subnet PIO in one of the received RAs.
> > >
> > > 5. Second node starts also issuing RAs also containing the GULLA
> Subnet PIO. Again, if the node is a host, RA router lifetime of zero.
> > >
> > > 6. 3rd and subsequent nodes attached to the link have some sort of
> election or selection algorithm to determine which one or ones take over if
> the first or both nodes stop issuing periodic RAs containing the GULLA
> Subnet PIO.
> > >
> > > Ideally it would be good to have non-GULLA nodes also learn and use
> this new GULLA Subnet, learning it from the GULLA RA announcing nodes.
> However, that would mean that the fe80::/10 prefix couldn't be used,
> because per-RFC4861, nodes are to ignore RA PIOs for the Link-Local prefix.
> So the GULLA aggregate prefix would have to be outside of fe80::/10.
> > >
> > > The above is mostly inspired by very distant memories of how Appletalk
> seed routers work to convey cable range (network prefix) information to
> other Appletalk routers on the link.
> > >
> > > Regards,
> > > Mark.
> > >
> > >
> > >
> > >
> > >
> > >     Ole
> > >
> > >     Administrative Requests:

---

From: 神明達哉 <[email-masked]>
Date: Tue, 23 Apr 2019 21:01:34 -0700

At Wed, 24 Apr 2019 13:28:48 +1000,

> has to be written to specifically handle them via sin6_scope_id.

This is not entirely accurate.  Section 11 of RFC 4007 exists exactly
for this purpose.  And, in fact, applications like ssh can perfectly
work for a link-local destination even on a multi-link host even if
the application (ssh client) doesn't do anything special for
link-local address:

% ssh fe80::1%lo0 'echo ok'
ok

It's true that *some* applications may still need to handle link-local
addresses as a special case, though.

> to suit that that scenario is pretty contradictory to that goal.

I wouldn't expect a dentist to type in a textual link-local address
(or for that matter, perhaps any textual IPv6 address) anyway.  In
this context it's more about a higher level problem than
scope-awareness of the application.  It would have to use some kind of
zero-config service discovery library with sophisticated user
interface.  That "library" may have to be aware of the concept of
scoped addresses more explicitly, but the application would be more
likely to be agnostic about it.

--
JINMEI, Tatuya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Apr 2019 07:02:33 +0200 (CEST)

On Tue, 23 Apr 2019, Gyan Mishra wrote:

> So with this new link local revision we are trying to address the 
> pitfalls with the current RFC 4291 RFC addressing schema for link local. 
> Is that correct?

Can someone please start a new mail thread (or draft) where there is a 
succinct problem statement and proposal for solution?

I spent non-trivial amount of time yesterday trying to make sense out of 
all the emails that had been sent in the past week. I am not against 
changing the standards if there is a problem that the current standards 
doesn't address. I just want to understand it and the past 50-100 emails 
has been causing me more confusion than clarity.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Apr 2019 15:12:29 +1000

> % ssh fe80::1%lo0 'echo ok'

So what Sockets API function converts "fe80::1%lo0" into a populated
sockaddr_in6 structure including sin6_scope_id?

inet_pton() only deals with and returns addresses, so it seems you have to
write additional special case code that handles the % zone suffix.

> (or for that matter, perhaps any textual IPv6 address) anyway.
>

So my thoughts have been that things like MDNS would also return the zone
information for a LL address to the resolver, although I haven't looked
into whether it does or not.

I still see that it would be simpler if interface or zone information was
effectively embedded in the LL address, as it is in GUA and ULA addresses,
using the, transparent to the application, node's route table to resolve
and determine the ingress/egress network link interface.

  In

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Apr 2019 16:04:46 +1000

getaddrinfo() does in most implementations as it returns a pointer to a
struct sockaddr_in6 which have a sin6_scope_id field.  inet_pton() deals
with the part to the left of the % symbol.

From various getaddrinfo man pages.

MacOS:

     This implementation of getaddrinfo() allows numeric IPv6 address notation
     with scope identifier, as documented in section 11 of RFC 4007.  By
     appending the percent character and scope identifier to addresses, one
     can fill the sin6_scope_id field for addresses.  This would make manage-
     ment of scoped addresses easier and allows cut-and-paste input of scoped
     addresses.

     At this moment the code supports only link-local addresses with the for-
     mat.  The scope identifier is hardcoded to the name of the hardware
     interface associated with the link (such as ne0).  An example is
     ``fe80::1%ne0'', which means ``fe80::1 on the link associated with the
     ne0 interface''.

     The current implementation assumes a one-to-one relationship between the
     interface and link, which is not necessarily true from the specification.

Linux:
     Notes

     getaddrinfo() supports the address%scope-id notation for specifying the IPv6
     scope-ID.

Mark

> On 24 Apr 2019, at 3:12 pm, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> > has to be written to specifically handle them viasin6_scope_id.
> 
> So what Sockets API function converts "fe80::1%lo0" into a populated sockaddr_in6 structure including sin6_scope_id?
> 
> inet_pton() only deals with and returns addresses, so it seems you have to write additional special case code that handles the % zone suffix.
> 
> 
> So my thoughts have been that things like MDNS would also return the zone information for a LL address to the resolver, although I haven't looked into whether it does or not.
> 
> I still see that it would be simpler if interface or zone information was effectively embedded in the LL address, as it is in GUA and ULA addresses, using the, transparent to the application, node's route table to resolve and determine the ingress/egress network link interface.
> 
> 
>   In

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Apr 2019 20:29:57 +1000

> with the part to the left of the % symbol.

I was more thinking about scenarios where only an address is expected to be
supplied, so there would not be a need for a DNS lookup.

So it wouldn't and didn't occur to me to use getaddrinfo() just for the
purpose of converting an LL address % string into a sockaddr_in6 structure.

LL addresses not being useful to applications if stored in unicast DNS,
because of the absent necessary zone info in a AAAA response, also means
getaddrinfo() doesn't sound like the right thing to use.

> > inet_pton() only deals with and returns addresses, so it seems you have
> to write additional special case code that handles the % zone suffix.
> >
> >
> > So my thoughts have been that things like MDNS would also return the
> zone information for a LL address to the resolver, although I haven't
> looked into whether it does or not.
> >
> > I still see that it would be simpler if interface or zone information
> was effectively embedded in the LL address, as it is in GUA and ULA
> addresses, using the, transparent to the application, node's route table to
> resolve and determine the ingress/egress network link interface.
> >
> >
> >   In

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 15:56:22 +0200

Le 19/04/2019 à 02:50, 神明達哉 a écrit :
> At Fri, 19 Apr 2019 02:07:20 +0200, Fernando Gont 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> [....]
> Sometimes even a disruptive update can be justified (like an extreme
>  case of some security matters). [...]

I take advantage of your message about security.

I am not a security expert.

I am not suggesting to use this security matter - it is not extreme - in 
order to justify the ll discussion.

I will not blow whistles.

--------------------------------------------------------------
I often listen to packets at 5.9GHz (DSRC, 802.11-OCB, 802.11p, WAVE,
ITS-G5), that are emitted by Road-Side Units, that are relevant to
IPWAVE WG and to 6MAN WG

Rarely - if ever at all - can I hear encrypted packets.
Some times they have signatures, but their CAs are not widely ack'ed.

The messages that I listen to are IP, CAM, SPAT, MAP and DENM.
Sometimes the DENM packets warn of accidents.  The DENM packet contains
some warning.  The DENM packet is in clear.  Anyone can fake it.  If I
remember correctly, I think I saw a DENM containing an accident warning,
that was not signed nor encrypted.  Anyone can send a fake DENM message
with an accident warning which, if taken seriously, may actually provoke
some accident.

Some times I hear SPAT messages that may contain the status of the
traffic lights.  I am happy because I can see that status without being
there.  But I wonder what happens if someone fakes them.

There are also IPv6 RA packets, that are not encrypted, not signed.  It
does not surprise me, because I know how hard is it to secure RAs.

I recently (April 2019) encountered one RSU with a dongling (dangling?)
Ethernet cable that anyone on the curbside (trottoir) could plug.  It is 
an area under construction but the cars do circulate at 50km/h or so.
-----------------------------------------------------------------------

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:02:11 +0200

Le 19/04/2019 à 18:25, 神明達哉 a écrit :
> "Pascal Thubert (pthubert)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  > Some functions in the router are complex to implement because same 
> value for a link local address appears on multiple interfaces.
> 

In my case, it  is a human sysadmin (myself) that assigns those IDs (the
IID and the ID in fe80:1::/32) and I ensure the uniqueness.

I think it is common practice to have sysadmins to ensure uniqueness;
this is what I also do with some of the /56s assigned to me for GUAs.  I
make a plan, get agreement, document it and share it with the interested
parties in my setting.  I also teach every new comer this addressing
archi for a while, then I stop, because the plans are there.

I am not sure I need to document that outside my setting.

Alex

---

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

Le 22/04/2019 à 18:15, 神明達哉 a écrit :
> Yucel Guven <[email-masked] <mailto:[email-masked]>> wrote:
[...]
> "widely used", but the usage of the broken behavior should be pretty

As a response, I would like to ask whether fe80::1/128 on lo is a 
violation of standards.

This is not a provocation.  It is for me to understand.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:31:26 +0200

Le 23/04/2019 à 00:04, Nick Hilliard a écrit :
>> I would like to add something else: the implementation that does
>> _not_ allow the users to add fe80:1::1 (BSD) does not complain
>> about it.  It silently refuses.
> 
> automatically configure the fe80::/64 prefix.  You cannot configure
> the value directly.

YEt the link-local addresses should have the ability to be manually 
configured too, I guess.

Or are the LLs forbidden to be manually configured?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:35:27 +0200

If somebody starts a Problem Statement draft I am willing to help.

Alex

Le 24/04/2019 à 07:02, Mikael Abrahamsson a écrit :
>> pitfalls with the current RFC 4291 RFC addressing schema for link 
>> local. Is that correct?
>

---

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

> Anyways, my concern is about huge amount of addresses of the fe80::/10.

I do not understand the concern.

Is the concern that too much space is allocated by fe80::/10?

Or is the concern that too much space is wasted between fe80::/10 and 
fe80::/64?

I know that talking about numbers, and about waste, is a doubly-edged 
sword: one can claim either fe80::/10 or fe80::/64 is a waste.

Alex

> There are 281,474,976,710,655 =  281 Trillion 474 Billion 976 million 
> 710 Thousand 655 addresses

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:48:55 +0200

Le 21/04/2019 à 01:34, Gyan Mishra a écrit :
> address so that the next hop is more intuitive and easily recognizable 
> that it’s your local next hop since by default all routers and hosts set 
> the station id to EUI64 format FFFE big stuff into the MAC address 
> between the 3rd and 4th octet which is “non intuitive”

I fully agree.

In my deployments too there is often an ULA or an LL that is manually 
set with some IID that is much shorter than EUI-64.

That is easier to remember, to document and to try with ping.

In addition to that, in my settings we often use fe80:something::1.  Did 
you see something like that in your settings?

[...]
> So as far a variable link local address I am in favor of variable and 
> you have the entire 64 bit station id to modify which is fine but I am 
> completely not in favor of violating the current standard of writing 
> into the 54 bit all 0s portion of the network prefix.

Noted.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Wed, 24 Apr 2019 07:49:32 -0700

At Wed, 24 Apr 2019 16:29:59 +0200,

> As a response, I would like to ask whether fe80::1/128 on lo is a

First off, assuming you refer to the behavior of BSD variants
(including MacOS X), it's not 'lo' but 'loN' (normally just lo0 but
can also be lo1, lo2, etc, if these are also configured).  The world
doesn't only consist of Linux.

Secondly, again assuming it's BSD variants, it's not /128 but /64.

Third, I don't see which standard it might violate.  Could you be
more specific?

If you simply mean whether an implementation could choose to use ::1
as the mandatory link-local address on a loopback interface and skip
assigning an fe80 address on it, then I'd say it should be allowed as
we discussed off-list.  But IMO that would also require some update to
RFC4291, which is hopefully much less controversial than using a non-0
value in the intermediate 54-bit field.  And in any case, that doesn't
mean assigning an fe80 address on such an interface is a violation.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:53:11 +0200

Le 21/04/2019 à 02:23, Gyan Mishra a écrit :
[...]
> That being said the fe80:1::1 can be coded on both Linux host and a 
> CISCO router with Linux kernel under the hood but that does not make it 
> correct or valid that we should now change the RFC 4291 to allow that to 
> happen.

Noted.

By 'now' do you mean 'not'?

I will add in the draft that Cisco also supports fe80:1::1.  I think I 
forgot that, but now that you say it I trust it too.

> I don’t see any justification to allowing the 54 bits in the network 64 
> bit portion of the link local address to be changed from all 0s.

I dont understand you.

You say fe80:1::1 works on Cisco, but then you say you seee no 
justification to allow the 54bits to change from 0.  The first 1 in 
fe80:1::1 means a change from 0.

So, do you mean Cisco is wrong?

Or do you mean such things are wrong and the RFC is right?

I do not understand you.

Let me rate limit my messages.

Alex

> On Apr 20, 2019, at 7:34 PM, Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> Suresh & Alexandre
>>
>> deployment of IPv6 using a standard architecture that I deploy to all 
>> my customers and that involves setting the station id on the link 
>> local address so that the next hop is more intuitive and easily 
>> recognizable that it’s your local next hop since by default all 
>> routers and hosts set the station id to EUI64 format FFFE big stuff 
>> into the MAC address between the 3rd and 4th octet which is “non 
>> intuitive”
>>
>> So the IPv6 addressing RFC 4291 states the 1st 10 bits used for fe80 
>> and the next 54 bits must be set to 0 which covers the 64 bit prefix 
>> length so the entire station id 64 bits is open to be modified and 
>> changed as the end user desires on any platform and that is following 
>> the current RFC standard.
>>
>> So in Alexandre scenario with BSD setting the LL to FE80::1 would be 
>> fine but if you did fe80:1::1 that would be setting 1s in the all 0s 
>> 54 bit field of the station id which is not allowed.
>>
>> On Apr 19, 2019, at 12:25 PM, 神明達哉 <[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Apr 2019 17:04:59 +0200

> On 24 Apr 2019, at 16:53, Alexandre Petrescu <[email-masked]> wrote:
> 
> I will add in the draft that Cisco also supports fe80:1::1.  I think I forgot that, but now that you say it I trust it too.
> 
> You say fe80:1::1 works on Cisco, but then you say you seee no justification to allow the 54bits to change from 0.  The first 1 in fe80:1::1 means a change from 0.
> 

That an implementation allows you to do something does not mean that it is supported (in the product sense) nor that the RFC is wrong. 
(And I am very familiar with why that particular implementation does what it does).

This has been repeated many times over the last few years. If you want this changed, please provide a problem statement. 

Ole

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 24 Apr 2019 16:39:12 +0100

> Or are the LLs forbidden to be manually configured?

on bsd, you can't manually configure fe80::/10 link-local addresses. 
You configure the auto_linklocal flag, and then the kernel does 
everything else.  The auto_linklocal flag does not work on bsd loopback 
interfaces.  This is all a local implementation detail: other operating 
systems have different approaches, equally valid.

Nick

---

From: Yucel Guven <[email-masked]>
Date: Wed, 24 Apr 2019 22:05:22 +0200

Yes, it is:  64 - 10 = 54, and 2^54= 18,014,398,509,481,984 prefixes, not
even 2^48.

 Too much space is allocated/reserved. That's what I think.

 Wasted or not is a different seperate subject, time will show the answer.

 I can not know what the writers of RFC4291 thought or design or plan.
 I'm sure they made much more detailed calculations.

 What I clearly understand is that first 10 bits are fixed, and 54 bits are
0,
 and using fe80:1::2 on an interface does not comply with it.

 We should be open to the discussion of updating 4291, that's why we have
draft docs.

On Wed, Apr 24, 2019 at 4:42 PM Alexandre Petrescu <
[email-masked]> wrote:

> case

---

From: 神明達哉 <[email-masked]>
Date: Wed, 24 Apr 2019 13:08:12 -0700

At Wed, 24 Apr 2019 20:29:57 +1000,
Mark Smith <[email-masked]> wrote:

> supplied, so there would not be a need for a DNS look up.
>

Today's applications use getaddrinfo() primarily to be protocol
independent (and to support both IPv6 and IPv4 as a result), not
necessarily for scenarios involving name-to-address resolution, let
alone specifically for converting LL addresses with the % notation:
apps don't have to use protocol-dependent code logic whether it's
invoked as "ssh 192.0.2.1" or "ssh 2001:db8::1".  And for this primary
reason the use of getaddrinfo() is very common.

The better support for scoped addresses is just a bonus effect of it,
but thanks to the common adoption most modern applications can
understand the % notation without doing anything special for
link-local addresses within their application code.

> for this purpose.

the point is that "each application has to be written to specifically
handle them via sin6_scope_id" is not correct for most modern
applications.  I don't deny there are still exceptions, but they are
exceptions, and would be weak to be used as a rationale to introduce
something new.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Apr 2019 08:46:39 +1200

getaddrinfo() also does the job in Winsock2.

(For Python programmers, there are subtleties depending on
O/S version and Python version. If you care:
https://github.com/becarpenter/graspy/blob/master/acp.py )

Regards
   Brian

---

From: 神明達哉 <[email-masked]>
Date: Wed, 24 Apr 2019 14:00:34 -0700

At Wed, 24 Apr 2019 17:04:59 +0200,

> >
> >> I don’t see any justification to allowing the 54 bits in the network
64 bit portion of the link local address to be changed from all 0s.
> That an implementation allows you to do something does not mean that it
is supported (in the product sense) nor that the RFC is wrong.

Right, but I actually don't understand why we still have to have this
kind of conversation.  Almost all real-world implementations have some
glitch; sometimes the bug is fixed quickly, sometimes it's considered
too minor to be prioritized and can stay longer.  It happens all the
time.  I simply don't understand why such a corner case behavior is
discussed in the context of whether an RFC is "right".

If my previous example of broken router behavior wasn't enough,
there's another one for the loved OS: Linux allows you to send a
packet with the source address being ::1 outside of the sending node
by running this script:

import socket
s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
s.bind(('::1', 0))
s.sendto(b'', ('2001:db8::1', 4200))

I hope no one seriously asks whether this text of RFC4291, Section
2.5.3 is "right" because of that bug:

   The loopback address must not be used as the source address in IPv6
   packets that are sent outside of a single node.

Then, can we now really stop talking about whether the RFC is right or
wrong about the intermediate 54 bits by referring to an implementation
that allows a user to violate it?

A bug is a bug.  If someone wants to legitimize that buggy behavior,
make a proposal with a valid justification to update the relevant
standard (sometimes it can actually succeed).  An attempt to make it
valid because of the existence of the buggy behavior itself is just
time wasting.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Apr 2019 09:35:26 +0200

Le 24/04/2019 à 22:53, Erik Kline a écrit :
> What prevents you from adding a directly connected route to fe80:Y::/64 
> dev <ifname_with_ifindexY>?
> 
> On my Linux workstation eno1 has ifindex 2, and I tried the following:
> 
>      ip -6 route add fe80:2::/64 dev eno1
>      ip -6 route
> 
> shows: [...]

There is no error there, so it seems fe80:2::/64 works on your linux 
workstation.

For comparing to other OSs (I maintain a list: some do, some dont), can 
I dare to ask you to check on Android.  I dont have an Android at hand. 
It would be sufficient to ifconfig eth0 add fe80:2::1/64 and re-type 
ifconfig to see whether the address appears on the interface.

> 
>      fe80::/64 dev eno1 proto kernel metric 100 pref medium
>      fe80:2::/64 dev eno1 metric 1024 pref medium
> 
> I then continued with:
> 
>      ip -6 addr add fe80:2::345/64 dev eno1 noprefixroute
>      ip -6 addr
> 
> shows:
> 
>      inet6 fe80:2::345/64 scope link noprefixroute
>         valid_lft forever preferred_lft forever
>      inet6 fe80::5bcb:c30c:c5e0:d3cf/64 scope link noprefixroute
>         valid_lft forever preferred_lft forever
> 
> and finally:
> 
>      ip -6 route get fe80:2::123
> 
> shows:
> 
>      fe80:2::123 from :: dev eno1 proto kernel src fe80:2::345 metric 
> 100 pref medium
> 
> so source address selection seems to be working as I would want it to in 
> this situation.
> 
> I'm not sure what other tests to run, but it seems like you can 
> certainly add fe80:ifindex::/64 routes to each separate device and 
> manually add your IP addresses as you wish...as least with recent Linux.

YEs, I agree.  In that way maybe some kind of waste may be avoided. (the 
waste of the 54 0 bits, if I can say so).

Alex

> 
> 
> On Wed, 24 Apr 2019 at 12:05, Yucel Guven <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>       Yes, it is:  64 - 10 = 54, and 2^54= 18,014,398,509,481,984
>     prefixes, not even 2^48.
> 
>       What I clearly understand is that first 10 bits are fixed, and 54
>     bits are 0,
>       We should be open to the discussion of updating 4291, that's why
>     we have draft docs.
> 
> 
>     On Wed, Apr 24, 2019 at 4:42 PM Alexandre Petrescu
>          >  > This logic doesn't make sense to me at all.  There was a
>         very widely used
>          >  > implementation of commercial router (I don't name it as
>         it's not my
>          >  > purpose to pick a particular vendor) that forwarded an
>         IPv6 packet
>          >  > whose source address is link-local from one link to
>         another link,
>          >  > instead of returning an ICMPv6 destination unreachable
>         error, code 2,
>          >  > as specified in RFC4443.
>          >
>          > Do you mean that billions of people's data,
>         information, etc....etc...
>          > from their Link-locals
>         <mailto:[email-masked]>
>          > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          >
>          >     <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>          >     wrote:
>          >
>          >      >    In private conversation this debate happened:
>          >
>          >      >    is an implementation that uses fe80:1::2 address on
>         an interface a
>          >      >    violation of standards? (RFC 4291 does not allow
>         for '1' to be
>          >     there).
>          >
>          >      >    My point of view is that as long as that
>         mplementation is
>          >     widely used,
>          >      >    that is not a violation of standards.  Rather, the
>         situation
>          >     makes it
>          >      >    that that standard is not in agreement with
>         implementations..
>          >
>          >     This logic doesn't make sense to me at all.  There was a
>         very widely
>          >     used
>         automatically
>          > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>          >     Administrative Requests:

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Apr 2019 09:41:35 +0200

Le 24/04/2019 à 23:00, 神明達哉 a écrit :
> Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  > > I will add in the draft that Cisco also supports fe80:1::1.  I 
> think I forgot that, but now that you say it I trust it too.
>  > >
>  > >> I don’t see any justification to allowing the 54 bits in the 
> network 64 bit portion of the link local address to be changed from all 0s.
>  > >
>  > > I dont understand you.
>  > >
>  > That an implementation allows you to do something does not mean that 
> it is supported (in the product sense) nor that the RFC is wrong.
> 
> glitch;

The problem here would be to ask which of the OSs have the glitch: the 
ones that support fe80:1:: or the ones that dont?

We dont want the loved OS to correct a non-existent bug and the 
non-loved OS to continue with the bug.

> sometimes the bug is fixed quickly, sometimes it's considered
> time.  

I agree.

> I simply don't understand why such a corner case behavior is

達哉-san,

Bugs should be corrected.  Time should not be wasted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Apr 2019 09:55:21 +0200

Le 24/04/2019 à 17:04, Ole Troan a écrit :
>> justification to allow the 54bits to change from 0.  The first 1
>> in fe80:1::1 means a change from 0.
>> 
> This has been repeated many times over the last few years. If you 
> want this changed, please provide a problem statement.

Ole,

These are three tries for a problem statement:

1 A rejected Errata to RFC4291 "IPv6 Addr Archi" on the topic of link-
   local addresses 'would need' a draft.  (The errata ID is 4406; the URL
   is https://www.rfc-editor.org/errata/eid4406)

Do you disagree with the recommendation of this Errata?

2 IPv6 link-local addresses are typically self-configured according to 4
   RFCs and relying on the fe80::/10 IANA allocation, RFC 54 0 bits, and
   RFC MAC-based 64bit Interface IDs.  In some cases, it is advantageous
   to manually configure link-local addresses.  This is useful for easy
   remembering by humans, and for parameter resilience during
   network interface replacement.

   Manual configuration of an LL may use short IID and Subnet ID
   The Subnet ID presence in the link-local address is useful in some
   wireless settings where the subnet structure parameters depend on the
   link locality.  Other settings may also benefit.

   When manually setting the link-local address it is necessary to know
   the length of the prefix of the subnet on which this link-local
   address is present.  This length is necessary for on-link
   determination.

   Implementation status: manually configuring link-local addresses is an
   operation permitted by some Operating Systems but forbidden by others.
   The ones that permit it need a parameter for the length of the prefix.
   The length of the prefix is sometimes 10 (cf. IANA allocation), at
   times 64 (cf. RFC assignment), at times 128 (cf. 2 RFCs) and other
   intermediary values are known to work.

Is this 2nd try along your line of thought?

3 more problem statements about 'some wireless settings' can be found in
   the IPWAVE WG Problem Statement draft.

Is this 3rd kind of problem statement something that may be answering 
your request to provide a problem statement?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Apr 2019 09:58:21 +0200

but getaddrinfo(), sin_scope_id, etc are a C functions and structures - 
need to write C software, need compiler, need cross-compiler... all this 
just for setting an address?

I need this subnet ID in the address such that a scripted call to 
ifconfig can work

---

From: Philip Homburg <[email-masked]>
Date: Thu, 25 Apr 2019 11:48:12 +0200

>    local addresses 'would need' a draft.  (The errata ID is 4406;
>    the URL is https://www.rfc-editor.org/errata/eid4406)

One of the goals of internet standards is to provide interoperability between
independently developed implementations.

In this case, as long as you stick to fe80::/64, Linux and BSDs can
interoperate. However, if you go outside of RFC-4291, you will find that
Linux and BSDs can no longer interoperate.

You propose to amend RFC-4291 to allow the reserved bits be set to something
other than zero. If such a proposal would be accepted then BSDs would no 
long comply with the amended RFC.

At this stage of standardisation of IPv6 it is bad to render currently 
complying implementations non-compliant unless there is a serious reason to do
so. 

It is also quite likely that it will be quite a bit of work for the BSDs
to implement the change you want.

Now what is so massively broken that it would be worth marking the BSDs as
non-compliant with one of the core IPv6 RFC?

The main example you gave is somebody typing IPv6 literals while sitting in a
car. 

In my opinion, there are so many other options to debug a network that it 
doesn't make sense declaring existing BSDs non-compliant just for this reason.

I cannot find anything in draft-ietf-ipwave-vehicular-networking-08 that
says that link local with 64-bit IIDs cannot work. Maybe you can be more
specific about the IPWAVE requirements.

---

From: Ole Troan <[email-masked]>
Date: Thu, 25 Apr 2019 12:10:01 +0200

Hi Alexandre,

> Do you disagree with the recommendation of this Errata?

The errata claims an inconsistency.
I do agree with the errata rejection if that's what you are asking.

Whichever way I try to interpret this "try #1 for a problem statement", I cannot find a reading that resolves into an actual problem.

>  address is present.  This length is necessary for on-link

There is nothing in our documents that prohibit you from doing manual configuration of link-local addresses.
You can achieve easy to type and addresses you can remember, and that are different per-subnet simply by doing something like:

FE80::<16-bit subnet id>:<48-bit "station-id">

> Is this 2nd try along your line of thought?

Sure, and what with my solution doesn't solve your problem?

> Is this 3rd kind of problem statement something that may be answering your request to provide a problem statement?

Sorry, I see nothing in draft-ietf-ipwave-vehicular-networking that directly points to the length of the link-local prefix being a problem.

Cheers,
Ole

---

From: Yucel Guven <[email-masked]>
Date: Thu, 25 Apr 2019 18:05:30 +0200

Nothing prevents me, I'm sure it also works with other linux distributions.

But, do you mean that it worked in your linux,
and in fact "RFC is not compatible" with your machine's OS?

Then;
What prevents you from opening your word processor
and from proposing/writing your ideas
into a document that is called a 'draft'?

On Wed, Apr 24, 2019 at 10:54 PM Erik Kline <[email-masked]> wrote:

>     fe80:2::123 from :: dev eno1 proto kernel src fe80:2::345 metric 100
> pref medium
>
> I'm not sure what other tests to run, but it seems like you can certainly
> add fe80:ifindex::/64 routes to each separate device and manually add your
> IP addresses as you wish...as least with recent Linux.
>
>
> On Wed, 24 Apr 2019 at 12:05, Yucel Guven <[email-masked]> wrote:
>
>>  Yes, it is:  64 - 10 = 54, and 2^54= 18,014,398,509,481,984 prefixes,
>> not even 2^48.
>>
>>  What I clearly understand is that first 10 bits are fixed, and 54 bits
>> are 0,
>>> > Do you mean that billions of people's data, information, etc....etc...
>>> > from their Link-locals
>>> >     <[email-masked] <mailto:[email-masked]
>>> >>
>>> >     wrote:
>>> >
>>> >      >    violation of standards? (RFC 4291 does not allow for '1' to
>>> be
>>> >     there).
>>> >
>>> >     This logic doesn't make sense to me at all.  There was a very
>>> widely
>>> >     used
>>> allow

---

From: 神明達哉 <[email-masked]>
Date: Thu, 25 Apr 2019 09:09:59 -0700

At Thu, 25 Apr 2019 09:41:35 +0200,

> ones that support fe80:1:: or the ones that dont?

Obviously the former.  The question itself is nonsense to me, equal to
a question asking which OS has the glitch: an implementation allowing
to send a packet with source=::1 outside of the node, or an
implementation that prevents it.

If you don't like to consider it to be a glitch, update RFC4291.  As
you've already seen it would be quite hard, but it's not necessarily
impossible.  Insisting a standard violation behavior is not a glitch
because of the existence of the behavior is just a time wasting
effort.

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2019 07:47:08 +1000

Which mythical application only takes IP addresses then connects to them?  I’ve yet to see one written.

Yes, scoped addresses are a small pain.

Yes, storing scoped addresses in the DNS is not currently supported.  It wouldn’t be that hard to add support with a new type that provided a globally unique name for the link and that name gets locally mapped to a scope id.   The A6 record format repurposed would work. Add a RA option to publish the globally unique link name to each link.  Getaddinfo could filter out non local link local addresses. 

Getaddrinfo doesn’t just optionally look stuff up in the DNS. It also does transformations like converting to mapped addresses when the node is IPv6 only.  It could potentially apply DNS64 translations as well.

Using getaddrinfo for address literals has been advised for years.
-- 
Mark Andrews

> On 24 Apr 2019, at 20:29, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> I was more thinking about scenarios where only an address is expected to be supplied, so there would not be a need for a DNS lookup.
> 
> So it wouldn't and didn't occur to me to use getaddrinfo() just for the purpose of converting an LL address % string into a sockaddr_in6 structure. 
> 
> LL addresses not being useful to applications if stored in unicast DNS, because of the absent necessary zone info in a AAAA response, also means getaddrinfo() doesn't sound like the right thing to use.
> 
> 
>>

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Apr 2019 09:56:17 +1000

> link-local addresses within their application code.

So perhaps there could be an update to RFC 3493.

It seems that inet_pton() and inet_ntop() should be now considered
more internal, "under the hood/bonnet" functions, rather than things
you might use to convert user input, and getaddrinfo() is now more
general purpose rather than something you use only when you need name
resolution/DNS lookup to be performed.

Regards,
Mark.

<snip>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 26 Apr 2019 00:24:37 -0400

What I am trying to say and this is very confusing is that CISCO and other BSD Linux based OS don’t have the ability to check for valid IPv6 global unicast or link local configuration that it is following the RFC Standards as with IPv4.

So just because it works does not mean it is correct or ok or that the standards should now change because it works on various OSs that are not following the RFC that we now chant to make that now ok and standard.

We need more justification then that to change the standards.  

In one of the other threads I mentioned that if we are trying to improve or enhance the standard because we have valid future user cases that would require having a new “subnet id” 54 bit  field then it’s ok as we are improving with newer RFC revision making the older one obsolete.

For backwards compatibility the all’s 0s 54 bits would be for legacy devices supporting RFC 4291 so they are not impacted and anything on newer coder can now look at supporting the new RFC.

Gyan

Sent from my iPhone

> On Apr 24, 2019, at 10:49 AM, 神明達哉 <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Apr 2019 16:31:56 +1200

Regards
   Brian Carpenter

On 25-Apr-19 21:48, Philip Homburg wrote:
...
> The main example you gave is somebody typing IPv6 literals while sitting in a

Indeed, we said from the very beginning (I mean 1994) that users should never be required to type in IPv6 addresses.

Is this so hard to avoid? In my browser, I can simply type "fritzy" and it takes me to the user interface of my Fritz box. In my hosts file, I added a line like:
fd63:45be:cd14:0:be05:43ff:fe8e:ce39 fritzy

Or I can ping fritzy.

It's easy enough to give simple names to predefined magic addresses.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Apr 2019 16:20:45 +1000

> Which mythical application only takes IP addresses then connects to them?  I’ve yet to see one written.

BGP "application" on a router or a route server for example. Router
control planes are functionally hosts by RFC 8200, and all of their
applications e.g. OSPF, BGP processes etc. all deal with raw IP
addresses, including LLs, most of the time.

Here's one I wrote. As it is relatively low level, using IP addresses
explicitly instead of DNS names seemed more suitable. So I wrote
routines to handle % suffixes in supplied unicast and multicast
addresses. I would have used getaddrinfo() for that if it had been
more obvious to do so.

https://github.com/markzzzsmith/replicast

> Yes, storing scoped addresses in the DNS is not currently supported.  It wouldn’t be that hard to add support with a new type that provided a globally unique name for the link and that name gets locally mapped to a scope id.
> The A6 record format repurposed would work. Add a RA option to publish the globally unique link name to each link.  Getaddinfo could filter out non local link local addresses.
>

That could work.

> Using getaddrinfo for address literals has been advised for years.

The trouble is that getaddrinfo() seems to have become more general
purpose than in the past, where it was specifically for name
resolution for a long time e.g. per RFC 3493 and how it is presented
in Unix Network Programming.

I think it would have been more logical to have adapted inet_pton()
and inet_ntop() to handle % suffixes, understandably not possible
because they only return binary address representations. Some way of
embedding a unique link identifier within the IPv6 LL address would
allow them to be used rather than the less obvious getaddrinfo().

Regards,
Mark.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 26 Apr 2019 07:11:24 +0000

There’s a difference here Gyan.

Those implementations are liberal in what they accept, which here means that they will not deny connectivity to a peer that doesn’t strictly conform the RFCs as they were at the time this particular software was compiled.

It also means that we can probably change those RFCs if we really want to, and it may not as painful as some voices claim. Certainly a step to take before doing anything would be to evaluate that.

Now depending on which function you talk about in the router there is a capability to check for Martian formats. You’d be surprised at what gets caught. But turning those things on usually causes a lot more problems than it solves, and in the end the Postel principle stands...

Regards,

Pascal

Le 26 avr. 2019 à 06:25, Gyan Mishra <[email-masked]<mailto:[email-masked]>> a écrit :

Gyan

Sent from my iPhone

On Apr 24, 2019, at 10:49 AM, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2019 17:33:34 +1000

> On 26 Apr 2019, at 4:20 pm, Mark Smith <[email-masked]> wrote:
> 

Yet, RFC 3493 has these flags for controlling getaddrinfo’s behaviour.

AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.

It was *never* as simple as you make it out to be. It was intended to
replace testing for literal addresses, then performing hostname lookups
and getservbyname lookups, then filling out struct sockaddr structures.
Adding scope handling to this was natural.  Add DNS64 handling would also
be natural.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 11:11:56 +0200

Le 25/04/2019 à 18:09, 神明達哉 a écrit :
> Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  > >  > That an implementation allows you to do something does not mean 
> that
> Obviously the former.

I think it is the latter: the OSs that dont support fe80:1:: should change.

Alex

-------------------------------------------------------------------------
If time permits:

I would like to make a note here.  I know that AD and Chairs read these 
messages.  I would like to invite consideration of these messages, if 
time permits, when pondering about which way the balance tips.

My reading of these discussions is that:

- one person, or small group of persons, indeed highly knowledgeable, 
consider fe80:1:: to be a violation of standards, an RFC to be right, 
one OS to be right, manual config of LLs to be wrong.

- probably more persons, or at least several persons, consider fe80:1:: 
to not be a violation of standards, some other OSs to be right, manual 
config of LLs to be right, 'liberal in what you accept', 'open minded'.

(some person is in both categories).

This is my reading of the discussion.

Alex

   The question itself is nonsense to me, equal to

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 11:17:35 +0200

Le 25/04/2019 à 18:46, Erik Kline a écrit :
> I not sure I see any standards violation and therefore I don't see any 
> need to update any standards.

Let me show this: RFC4291 requires 54 0 bits between fe80::/10 and 
fe80::IID/64.

Do you see a problem in this?

> Every interface had the default link-local prefix assigned (fe80::/64).  
> No problem.

Right.

> Every interface also had another prefx, fe80:ifindex::/64, configured.  

ifindex is the Interface Index?

I need the Subnet ID there, not the Interface Index.

The Interface Index of eth1 on a PC is '1' and distinct than the 
Interface Index of eth2 on another PC, both in same Ethernet.

One couldnt ping fe80:1::1/64 from fe80:2::1/64 on the same Ethernet cable.

Alex

> This prefix is also link-local because it's from within fe80::/10.
> 
> I see no problem here.  I don't see that any standards need to be 
> updated, bis'ed, amended, or tweaked.

> 
> On Thu, 25 Apr 2019 at 08:05, Yucel Guven <[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 11:28:27 +0200

Le 26/04/2019 à 06:31, Brian E Carpenter a écrit :
> 
> 
> Regards Brian Carpenter
> 
> On 25-Apr-19 21:48, Philip Homburg wrote: ...
>> The main example you gave is somebody typing IPv6 literals while 
>> sitting in a car.
> 
> Indeed, we said from the very beginning (I mean 1994) that users 
> should never be required to type in IPv6 addresses.
> 
> Is this so hard to avoid?

It may be easy to avoid typing IPv6 addresse when DNS was available.

But think about three cars in a covoy; the convoy is disconnected from
the IPv6 Internet, yet fully connected on IPv6 between all computers in
the convoy.  Which of the cars should host the DNS server?

Until we figure that out we are left with /etc/hosts files.  But there
are numerous computers in these 3 cars; a change in an address on an
interface leads to changes in all these /etc/hosts files.  These changes
are happening often: move this USB wifi key from here to there, replace
this Ethernet dongle because heated, etc.

Worse: many of the computers in these 3 cars dont have screens nor
keyboards nor mice.  Those who have screens (tablets, smartphones) have
difficult ways to type addresses in fields.

This is why, in this setting, manual configuration of easy to remember
link-local addresses is key to help the network administrator.

> In my browser, I can simply type "fritzy" and it takes me to the user
> interface of my Fritz box. In my hosts file, I added a line like:

I think the /etc/hosts file is a great idea, in many settings, like with 
the fritz box at home.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 11:45:00 +0200

Le 25/04/2019 à 12:10, Ole Troan a écrit :
>> 1 A rejected Errata to RFC4291 "IPv6 Addr Archi" on the topic of 
>> link- local addresses 'would need' a draft.  (The errata ID is 
>> 4406; the URL is https://www.rfc-editor.org/errata/eid4406)
>> 
> The errata claims an inconsistency. I do agree with the errata 
> rejection if that's what you are asking.

It is not that that I am asking.

I am asking this: do you disagree with the Verifier Notes text? (I am 
asking because a part of the Verifier Notes seems to me to be a 
recommendation.)

For your convenience, this is the part from the Verifier Notes:
> [...] The re-definition of the link-local address would need to be
> driven by a draft updating RFC 4291.

> Whichever way I try to interpret this "try #1 for a problem 
> statement", I cannot find a reading that resolves into an actual 
> problem.
> 
>> 2 IPv6 link-local addresses are typically self-configured according
>> to 4 RFCs and relying on the fe80::/10 IANA allocation, RFC 54 0
>> bits, and RFC MAC-based 64bit Interface IDs.  In some cases, it is
>> advantageous to manually configure link-local addresses.  This is
>> useful for easy remembering by humans, and for parameter resilience
>> during network interface replacement.
>> 
>> Manual configuration of an LL may use short IID and Subnet ID The 
>> Subnet ID presence in the link-local address is useful in some 
>> wireless settings where the subnet structure parameters depend on 
>> the link locality.  Other settings may also benefit.
>> 
>> When manually setting the link-local address it is necessary to 
>> know the length of the prefix of the subnet on which this 
>> link-local address is present.  This length is necessary for 
>> on-link determination.
> 

I agree.

But some OSs prohibits it.  The reasoning behind that OS prohibition is 
invoking this RFC.  It is an interpretation of this RFC that leads to 
prohibit people on that OS to do manual configuration.

> You can achieve easy to type
> and addresses you can remember, and that are different per-subnet
> simply by doing something like:
> 

YEs, fe80::1:1 is a solution too.  But others suggested other solutions 
like fe80:1::1.

The fact that there are two distinct solutions makes it an even stronger 
problem.

On my side, I would not agree with
FE80::<16-bit subnet id>:<48-bit "station-id">
because these ids are part of an Interface ID.

Subnet ID and Interface ID are distinct parts in an IPv6 address, as 
defined by RFC4291.  Can not put a Subnet ID in an Interface ID.

> 
>> Implementation status: manually configuring link-local addresses is
>> an operation permitted by some Operating Systems but forbidden by
>> others. The ones that permit it need a parameter for the length of
>> the prefix. The length of the prefix is sometimes 10 (cf. IANA 
>> allocation), at times 64 (cf. RFC assignment), at times 128 (cf. 2
>>  RFCs) and other intermediary values are known to work.
>> 
> Sure,

Thank you.

If you you do not mind, I will tweak this text a little, and add it in 
the draft about the prefix len of LL addresses.  I will put it as a 
separate section.

> and what with my solution doesn't solve your problem?

It does solve the problem, but in a slightly different way than 
fe80:1::1 does, and which seems little compatible with RFC 4291 Subnet 
ID - IID distinction.

>> 3 more problem statements about 'some wireless settings' can be 
>> found in the IPWAVE WG Problem Statement draft.
>> 
>> Is this 3rd kind of problem statement something that may be 
>> answering your request to provide a problem statement?
> 
> Sorry, I see nothing in draft-ietf-ipwave-vehicular-networking that 
> directly points to the length of the link-local prefix being a 
> problem.

The problems in that draft are probably of less importance to 6MAN WG 
specialised reader.  Your reaction makes me think it is not this kind of 
3rd problem that you requested when you asked for a Problem Statement.

Probably number 2 is, and less probably number 1 is.

Alex

> Cheers, Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Apr 2019 19:46:48 +1000

> the convoy.  Which of the cars should host the DNS server?

All of them.

http://www.multicastdns.org/

Multicast DNS
https://www.ietf.org/rfc/rfc6762.txt

There's also a good book on it:

""Zero Configuration Networking: The Definitive Guide
https://www.amazon.com/gp/product/0596101007

A number of implementations:

https://www.avahi.org/ - Linux

https://developer.apple.com/bonjour/ - Apple, Windows

And if you want to know what inspired it,

"Requirements for a Protocol to Replace the AppleTalk Name Binding
Protocol (NBP)"
https://tools.ietf.org/html/rfc6760

This is why you need to explain your problem, not just what you think
is the solution. You'll get much quicker answers.

<snip>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 11:54:43 +0200

>> the convoy.  Which of the cars should host the DNS server?

Mark,

Thank you very much for the suggestion.  I will consider it.

I would like to ask you: is multicast DNS (mDNS) working on a single 
subnet only?  Or does it work across subnets?

(because the numerous computers in these three cars are not all on a 
single subnet; they are all interconnected with IP, but there are 
multiple subnets with routers in between).

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Apr 2019 20:05:51 +1000

> subnet only?  Or does it work across subnets?

I'm not an expert in mDNS or related, have just read enough to know
what problem they're solving and (very) roughly how it works.

DNS Service Discovery is intended to convey that information across subnets:

http://www.dns-sd.org/

> multiple subnets with routers in between).

There may be other options that better suit or can be better made to
suit what you're trying to do, such as the work done in the Homenet or
the ANIMA Working Groups.

Autonomic networking (the focus of ANIMA WG), sounds like it might be
working on solutions to your problem domain.

"Autonomic networking refers to the self-managing characteristics
(configuration, protection, healing, and optimization) of distributed
network elements, adapting to unpredictable changes while hiding
intrinsic complexity from operators and users."

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 13:36:35 +0200

> DNS Service Discovery is intended to convey that information across subnets:

I suppose DNS Service Discovery works ok on IPv6, and over multiple 
subnets, and that it relies on the proper use of IPv6 multicast routing 
protocols.  I never tried IPv6 multicast routing protocols on links 
involving OCB (a kind of stripped ad-hoc WiFi at 5.9GHz).

I suppose the use of DNS resolver address in RA is also an option in 
this space.  I have tried this DNS-in-RA and it works ok.

Whether DNS-in-RA, DNS-SD and mDNS should be used in cars, and how, can 
be a subject of debate.  There is a Problem Statement draft in the 
IPWAVE WG that lists in section "DNS Naming Service" some considered 
problems.

Until these things get fixed (how to use DNS in car convoy?) I need the 
manual configuration of easy to remember link-local addresses

When DNS works in car convoys, I expect other inconvenients using 
name-to-address mappings compared to IP address literals.

I might need to update the DNS servers' files with new IPv6 Link-Local 
address to name mappings, whenever a faulty interface is replaced, or 
when USB interface keys are moved, or when 1Gb Ethernet cards are 
migrated to 10Gb Ethernet.

If I am to update files, why not updating rather the computer startup 
scripts (not DNS)?  These computer startup scripts are present in all 
computers, including embedded, as unencumbered and open source.

Second,

If I use DNS names I must remember a name like:
front-Lead-First (means the IP address on the front bumper of the
                   Follower, in the subnet between Lead and First
                   Follower)
rear-Lead-First
front-First-Second
rear-First-Second
etc.
These names are too long to type.  So I would abbreviate them to:
flf
rlf
ffs
rfs
etc.

These flf, rlf, etc are no less cryptic than a literal like fe80:1::1 is.

The short IP address literals are loved and understood by more people.

> intrinsic complexity from operators and users."

Yes, they should be considered.

I will make this suggestion in the IPWAVE WG for the Problem Statement 
draft.

Alex

---

From: Yucel Guven <[email-masked]>
Date: Fri, 26 Apr 2019 16:41:01 +0200

> This prefix is also link-local because it's from within fe80::/10.

Can you compare rfc4291-sec.2.5.6  with  your sentences above
and say that it complied to it?

-Yucel

On Thu, Apr 25, 2019 at 6:46 PM Erik Kline <[email-masked]> wrote:

> I see no problem here.  I don't see that any standards need to be updated,
> bis'ed, amended, or tweaked.
>
> On Thu, 25 Apr 2019 at 08:05, Yucel Guven <[email-masked]> wrote:
>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 26 Apr 2019 12:38:42 -0400

> >>> is the solution. You'll get much quicker answers.
Alex,

You might want to read https://datatracker.ietf.org/wg/dnssd/about/

Kerry

---

From: Erik Kline <[email-masked]>
Date: Fri, 26 Apr 2019 11:27:22 -0700

The text in that block doesn't even state that fe80::/10 is reserved for
link-local unicast, and yet -- per IANA -- it is.  The full context is
important, I feel.

What I see is:

    (a) fe80::/10 is the over-arching block allocated for link-local
unicast addresses, and

    (b) fe80::/64 is the one link-local unicast prefix guaranteed by the
standard to be assumed operable on every link.

Nothing more, nothing less.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 26 Apr 2019 16:59:33 -0400

Thank you Pascal

I agree with what you are saying 

Gyan

Sent from my iPhone

> On Apr 26, 2019, at 3:33 AM, Mark Andrews <[email-masked]> wrote:
> 
> 
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 27 Apr 2019 12:19:52 +1000

<snip>

> protocols.

No, I'm pretty sure it doesn't. It's designed to be able to work over
the Internet, so no multicast required.

> I never tried IPv6 multicast routing protocols on links

It will be much easier to adapt existing name and resource discovery
methods and protocols to your problem space than to get RFC4291
updated to include a unique subnet ID in Link-Local addresses.

> name-to-address mappings compared to IP address literals.

You need to read "The Design of Everyday Things" if you think typing
in IP address literals is more user friendly than device names.

https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things

The importance if giving names to devices instead of expecting users
to remember numbers has been recognised for at least as long as the
last 47 years, when the ARPA Network only had 20 hosts on it, and
single octet addresses -

RFC 226, "STANDARDIZATION OF HOST MNEUMONICS", 20 SEPT 71.

Discovery of services and resources with names on the network is as
least as old as 1982 -

(Xerox) "Grapevine: An exercise in distributed computing"
http://birrell.org/andrew/papers/Grapevine.pdf

> The short IP address literals are loved and understood by more people.

A test for you. Which would you find easier to remember?

This series of numbers?

821
826
791
1035

or this series of acronyms and what they stand for?

SMTP
ARP
IP
DNS

> >> multiple subnets with routers in between).

Right. This confirms my suspicion. If you got us to add Subnet IDs to
Link-Local addresses, I'm confident you'd next be lobbying them to be
routeable across different links attached to routers.

In other words, you'd want these Link-Local addresses to have a scope
that is greater than a link.

We used to have an address space for that, called the Site-Local address space.

Read why they were deprecated and then replaced by ULAs in RFC 3879.

You won't like that they're easy to type, however that is the cost of
solving all of the issues described in RFC 3879.

(If you wanted a problem description of the problems that duplication
IPv4 address spaces cause i.e. RFC1918 addresses, RFC 3879 would serve
that purpose too - as does RFC1627 - "Network 10 Considered Harmful
(Some Practices Shouldn't be Codified)".)

> I will make this suggestion in the IPWAVE WG for the Problem Statement

Good.

We really shouldn't have cars that can literally drive themselves,
while at the same time expecting end users (or anybody) to be spending
a lot of time typing in literal IP addresses.

Typing in literal IP addresses is the car equivalent of starting the
engine with a hand crank at the front bumper. Most cars stopped being
started that way in the 1920s.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 27 Apr 2019 12:22:49 +1000

<snip>

> solving all of the issues described in RFC 3879.

Correction to previous email:

You won't like that they're *not* easy to type, however that is the
cost of solving all of the issues described in RFC 3879.

<snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Apr 2019 14:42:40 +1200

> the Internet, so no multicast required.

Correct. I played with it a bit as a peripheral aspect of the ANIMA WG and both unicast DNS and mDNS could be used. There are examples like _printer._sub._http._tcp.dns-sd.org. around for testing.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Apr 2019 01:13:28 -0400

Alex

I agree and that completely makes sense what you are saying.

So with RFC 4291 all hosts for all subnets we’re actually sitting on the same fe80::/64 even though different physical or logical interfaces and each host was made unique by the EUI64 station id.  

So with the new  draft if all hosts would sitting on the same global unicast subnet now also sit on the same unique Link local subnet.  So the RA for Default route sent to all hosts on the subnet would be this new LInk local set on the router 

Subnet 1:
Router A fe80:1::EUI64 bia vrrp vip fe80:1::1  ::/0 sent to host

Router B fe80:1::EUI64 bia vrrp vip fe80:1::1 ::/0 sent to host

Host A fe80:1::EUI64 bia 

Host B fe80:1::EUI64 bia 

Subnet 2:
Router  A fe80:2::EUI64 bia  vrrp vip fe80:2::1 ::/0 sent to host

Router B fe80:2::EUI64 bia vrrp vip fe80:2::1 ::/0 sent to host

Host A fe80:2::EUI64 bia 

Host B fe80:2::EUI64 bia 

Gyan

Sent from my iPhone

> On Apr 26, 2019, at 5:11 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>> Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> I would like to make a note here.  I know that AD and Chairs read these messages.  I would like to invite consideration of these messages, if time permits, when pondering about which way the balance tips.
> 
> - one person, or small group of persons, indeed highly knowledgeable, consider fe80:1:: to be a violation of standards, an RFC to be right, one OS to be right, manual config of LLs to be wrong.
> 
> - probably more persons, or at least several persons, consider fe80:1:: to not be a violation of standards, some other OSs to be right, manual config of LLs to be right, 'liberal in what you accept', 'open minded'.
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Apr 2019 01:10:10 +0200

> standard to be assumed operable on every link.

If a /64 is assumed -- which it is -- and one uses anything else other
than 0 for the 54 bits after fe80::/10, then you might not be able to
employ such addresses because route-wise, they would be off-link.

(not disagreeing or answering to you, but rather adding on top of what
you've just said...)

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 27 Apr 2019 19:54:10 +1200

I don't understand this discussion. LL addresses exist in the absence of
any routers and are created spontaneously by hosts with no external inputs.
Therefore, there is no such thing as an identity for a link, there is only
an interface identifier which is strictly local to the host. Even in a
point to point case, there is no reason that the two hosts would agree
about the link's identity.

Regards
    Brian
    (via tiny screen & keyboard)

On Sat, 27 Apr 2019, 17:13 Gyan Mishra, <[email-masked]> wrote:

> So with RFC 4291 all hosts for all subnets we’re actually sitting on the
> same fe80::/64 even though different physical or logical interfaces and
> each host was made unique by the EUI64 station id.
>
> So with the new  draft if all hosts would sitting on the same global
> unicast subnet now also sit on the same unique Link local subnet.  So the
> RA for Default route sent to all hosts on the subnet would be this new LInk
> local set on the router
>
> Subnet 1:
> messages.  I would like to invite consideration of these messages, if time
> permits, when pondering about which way the balance tips.
> >
> consider fe80:1:: to be a violation of standards, an RFC to be right, one
> OS to be right, manual config of LLs to be wrong.
> >

---

From: Ole Troan <[email-masked]>
Date: Sat, 27 Apr 2019 10:33:35 +0200

Quite. The most prudent action is to stop responding to messages in these sets of threads. I will do so, and I encourage everyone else to do the same. 

Cheers,
Ole

> On 27 Apr 2019, at 09:54, Brian Carpenter <[email-masked]> wrote:
> 
> I don't understand this discussion. LL addresses exist in the absence of any routers and are created spontaneously by hosts with no external inputs. Therefore, there is no such thing as an identity for a link, there is only an interface identifier which is strictly local to the host. Even in a point to point case, there is no reason that the two hosts would agree about the link's identity.
> 
> Regards
>     Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Apr 2019 10:40:50 +0200

On 27/4/19 09:54, Brian Carpenter wrote:
> I don't understand this discussion. 

Sigh.. I thought it was just me & insufficient amounts of caffeine :-)

> LL addresses exist in the absence of
> any routers and are created spontaneously by hosts with no external
> inputs. Therefore, there is no such thing as an identity for a link,
> there is only an interface identifier which is strictly local to the
> host. 

The IID ends up being meaningful link-wise -- that's why there's (at
least in theory) DAD for LLs.

> Even in a point to point case, there is no reason that the two
> hosts would agree about the link's identity.

In fact, if one assumes /64, and selects non-zero bits for the rest of
the prefix, then either you have to come up with a subnet-id
election/disovery mechanism/algorithm, or you just can use the LLs,
since most other nodes would probably be considered off-link.

An alternative is to introduce an onlink route for fe80::/10... at which
point the rest of the bits become, in practice, part of the IID.

Cheers,

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 17:03:53 +0200

Le 27/04/2019 à 10:33, Ole Troan a écrit :
> Quite. The most prudent action is to stop responding to messages in 
> these sets of threads. I will do so, and I encourage everyone else to do 
> the same.

Ole,

I do not understand this.

You invited me to rate limit my messages.  I did.

Now you invite everyone (probably myself too) to not respond to these 
sets of threads I initiated.

I would like to ask you: do you think I should stop this topic?  Do you 
ask this as a WG Chair?

If so, please be explicit.

Thank you,

Alex

> 
> Cheers,
> Ole
> 
> On 27 Apr 2019, at 09:54, Brian Carpenter <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> I don't understand this discussion. LL addresses exist in the absence 
>> of any routers and are created spontaneously by hosts with no external 
>> host. Even in a point to point case, there is no reason that the two 
>> On Sat, 27 Apr 2019, 17:13 Gyan Mishra, <[email-masked] 
>>     So with RFC 4291 all hosts for all subnets we’re actually sitting
>>     on the same fe80::/64 even though different physical or logical
>>     interfaces and each host was made unique by the EUI64 station id.
>>
>>     So with the new  draft if all hosts would sitting on the same
>>     global unicast subnet now also sit on the same unique Link local
>>     subnet.  So the RA for Default route sent to all hosts on the
>>     subnet would be this new LInk local set on the router
>>
>>     Subnet 1:
>>     > On Apr 26, 2019, at 5:11 AM, Alexandre Petrescu
>>     <mailto:[email-masked]>>> wrote:
>>     >> > >  > That an implementation allows you to do something does
>>     not mean that
>>     > I would like to make a note here.  I know that AD and Chairs
>>     read these messages.  I would like to invite consideration of
>>     these messages, if time permits, when pondering about which way
>>     the balance tips.
>>     >
>>     > - one person, or small group of persons, indeed highly
>>     knowledgeable, consider fe80:1:: to be a violation of standards,
>>     an RFC to be right, one OS to be right, manual config of LLs to be
>>     wrong.
>>     >
>>     > - probably more persons, or at least several persons, consider
>>     fe80:1:: to not be a violation of standards, some other OSs to be
>>     right, manual config of LLs to be right, 'liberal in what you
>>     accept', 'open minded'.
>>     >

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 17:04:43 +0200

Le 26/04/2019 à 18:38, Kerry Lynn a écrit :
> On Fri, Apr 26, 2019 at 7:36 AM Alexandre Petrescu 

Noted.  I will forward this to IPWAVE WG where there is a Problem 
Statement draft under writing.

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Apr 2019 12:38:12 -0400

Fernando and Brian

I agree with what both of you are saying.

Post inline

On Sat, Apr 27, 2019, 5:02 AM Fernando Gont <[email-masked]> wrote:

> Gyan - I agree the link local can exist in the absence of any routers so
> that's a huge issue with subnet id.  So I see the problem now with subnet
> id.  This now gets very complicated as the router had to have a special
> auto config SLAAC with a DAD algorithm to allocate the subnet prefix to
> hosts similar to global unicast SLAAC auto config.  So in the absence of
> any routers the hosts would not have any link  identity until a router came
> up and then the this new link local SLAAC with DAD would initiate and
> assign the hosts on the subnet a auto configured subnet id prefix giving
> all the hosts  now link significance and now being on the same link local
> subnet dolled out by the router via this new link local SLAAC process.
>
> Gyan -  this is a simpler approach alternative option  if we made the 54
> bits part to the station id 118 bits as one large station  id field which
> is already unique by the EUI64 station id and we can still use the
> existing  link local DAD process.
>

Cheers,

---

From: 神明達哉 <[email-masked]>
Date: Sat, 27 Apr 2019 10:02:23 -0700

On Sat, Apr 27, 2019 at 1:33 AM Ole Troan <[email-masked]> wrote:

>    Quite. The most prudent action is to stop responding to messages
>    in these sets of threads. I will do so, and I encourage everyone
>    else to do the same.

+1.  It now looks like I can't contribute any useful bit to these
threads.  I'll stop participating in them at this point.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Sat, 27 Apr 2019 10:41:18 -0700

> On Apr 27, 2019, at 12:54 AM, Brian Carpenter <[email-masked]> wrote:
> 

+1

Bob

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Apr 2019 14:10:33 -0400

Alex

What real world  problem are we trying to solve with updating the link
local address format.

I don't think a valid reason for updating the standard because of OS
glitches that allow using 1s in the 54 bit all 0s field of the link local
prefix.

I think if we don't have a real world problem  we are trying to solve then
if  nothing is broken why fix something that is not broken.

As you can see it is complicated and there are two methods of making the
change but both options have their complexities and issues.

Option 1:  54 bit all 0s field would be part of the 64 bit EUI station id
so 118 bit field basically a 54 bit extension of the interface is.

Issue with this option I see is that all hosts have the concept of 64 bit
station id EUI64 or random but because of the 64 bit boundary for network
prefix and station id so the 54 bits end up falling in the network prefix
portion of the IPv6 address so then if those bits are set now the hosts
become off net not on the same link local local subnet as other hosts and
all hosts including the router need to have the same exact 54 bits set to
be on now the same subnet.

This option won't work as it really transforms into option #2 with slaac
for link local and dad for link local subnet field

Option #2 link local slaac with DAD algorithm of auto config assignment via
router RA the 54 bit station id.

So for this to work we would have to create a new SLAAC with DAD algorithm
for this new link local subnet field.

For this draft to be viable Option #2 Is the only way I see it possible.

Gyan

Gyan

---

From: Bob Hinden <[email-masked]>
Date: Sat, 27 Apr 2019 11:27:06 -0700

Alex,

> On Apr 27, 2019, at 8:03 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

I see 4 emails so far today, 7 yesterday, 4 on the 25th, and 13 on the 24th.

That doesn’t look like rate limiting to me.

Bob

> 
> Now you invite everyone (probably myself too) to not respond to these sets of threads I initiated.
> 
> I would like to ask you: do you think I should stop this topic?  Do you ask this as a WG Chair?
> 
>> On 27 Apr 2019, at 09:54, Brian Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Sat, 27 Apr 2019, 17:13 Gyan Mishra, <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>    Alex
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 20:33:23 +0200

Le 27/04/2019 à 04:19, Mark Smith a écrit :
[...]

> routeable across different links attached to routers.

No, your assumption is wrong.

Let me reassure you, I want this: I want the link-local addresses to 
stay on a single link, in the same subnet.  Pinging them ok makes the 
logic of deciding whether the subnet set up was correctly done (channel 
number, MHz).

If these were ULAs, or site-locals, then the IP forwarding would have 
also played a role that is a difficult to consider.  It is not good to 
use IP forwarding to construct subnets, but to forward between them.

Again: I do not want site-locals.

> that is greater than a link.

No.  I want the link-local addresses that have a Subnet ID inside to 
have a link scope.

> Read why they were deprecated and then replaced by ULAs in RFC 3879.

I was in the room, I voted no to deprecation.

But I then thid agree with the IETF recommendation and removed all 
site-locals from my deployment.  Then I also removed 6to4.  I am happy 
about these decisions.

But for SubnetID-in-LL the situation is different.

> solving all of the issues described in RFC 3879.

No.

Given that I do not want Site Local addresses, as explained above, do 
you still want me to read RFC3879?

In turn, let me bring back your suspicion: you suspect the car network I 
build needs Site Locals because you think this is disconnected from the 
Internet.  Do you know why this car network is disconnected from the 
IPv6 Internet?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 20:38:00 +0200

> inputs. Therefore, there is no such thing as an identity for a link,

Yet I need an identity of the link.

If you think that the identity of the link is the GUA (or ULA) prefix 
then I can tell you that I do not know what GUA (or ULA) prefix to put 
between cars.  If you know, please tell me.

Peugeot cant put 1::/64 between cars where Ford puts 2::/64.

>      (via tiny screen & keyboard)

mouse?

Alex

>     So with RFC 4291 all hosts for all subnets we’re actually sitting on
>     the same fe80::/64 even though different physical or logical
>     unicast subnet now also sit on the same unique Link local subnet. 
>     So the RA for Default route sent to all hosts on the subnet would be
>     this new LInk local set on the router
> 
>     Subnet 1:
>      > I would like to make a note here.  I know that AD and Chairs read
>     these messages.  I would like to invite consideration of these
>     messages, if time permits, when pondering about which way the
>     balance tips.
>      >
>     knowledgeable, consider fe80:1:: to be a violation of standards, an
>     RFC to be right, one OS to be right, manual config of LLs to be wrong.
>      >

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 20:53:41 +0200

Le 27/04/2019 à 20:10, Gyan Mishra a écrit :
> glitches that allow using 1s in the 54 bit all 0s field of the link 
> local prefix.

BSD does not support manaual LLs.  But it does not support OCB either. 
SO I do not think BSD is a relevant OS for vehicular networks.  AT that 
point I think it is not worth discussing about BSD at all in this topic, 
because it is issued by vehicular networks.

On another hand, linux supports both subnet id in LLs, as well as manual 
setting of LLs.  Also linux supports OCB mode.  That makes it highly 
relevant for vehicular communications.

If there is a glitch, it is in BSD.

> I think if we don't have a real world problem  we are trying to solve 
> then if  nothing is broken why fix something that is not broken.

I listed two problems.  One is in the Internet Draft, and the other in 
an email I just posted.  I could include that second problem in the 
Internet Draft as well, but I have a problem: should I include it in 
this Internet Draft?  Or should I suggest inclusion in the IPWAVE WG 
Problem STatement Internet Draft?

> Option 1:  54 bit all 0s field would be part of the 64 bit EUI station 
> id so 118 bit field basically a 54 bit extension of the interface is.
> 
> Issue with this option I see is that all hosts have the concept of 64 
> bit station id EUI64 or random but because of the 64 bit boundary for 
> network prefix and station id so the 54 bits end up falling in the 
> network prefix portion of the IPv6 address so then if those bits are set 
> now the hosts become off net not on the same link local local subnet as 
> other hosts and all hosts including the router need to have the same 
> exact 54 bits set to be on now the same subnet.

YEs one could have worries because of that.

But trying it in practice shows that linux can set fe80:1::1/32 on two 
Hosts on same link and it works.

> Option #2 link local slaac with DAD algorithm of auto config assignment 
> via router RA the 54 bit station id.
> 
> So for this to work we would have to create a new SLAAC with DAD 
> algorithm for this new link local subnet field.

No no - not new creation of SLAAC or DAD; SLAAC spec works ok with IID 
of various lengths; SLAAC is not restricted to 64.  OpenBSD (not 
FreeBSD) implements ok variable length IID for GUA in SLAAC (not LL). 
Linux does not support GUAs SLAACed with a variable length IID, but 
supports variable length IID in LL.

Ideally, one would mix the traits from linux and OpenBSD to get variable 
length IID GUA SLAAC and variable length IID LL.

FreeBSD and RFC4291 would stand apart here (do not allow 54 1 bits).

In the worst case this would happen: linux gets updated to remove OCB 
support and to remove support of variable length IID and Subnet ID in 
LLs (such that RFC4291 is respected).  I do not want this to happen.

> For this draft to be viable Option #2 Is the only way I see it possible.

Probably that is an option too, but I do not know if somebody wants to 
pursue?

For my part, I am afraid about what to put in the src of the RA that 
wants to configure link-local addresses (that src should also be an RA). 
  I just dont know, I dont say no.

Alex

> 
> Gyan
> 
> Gyan
> 
> 
> On Sat, Apr 27, 2019, 1:13 AM Gyan Mishra <[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 20:55:11 +0200

> That doesn’t look like rate limiting to me.

What is the appropriate limit?  and I will follow it.

1 message per day is ok?

Alex

---

From: Tim Chown <[email-masked]>
Date: Sat, 27 Apr 2019 19:03:28 +0000

> On 27 Apr 2019, at 16:03, Alexandre Petrescu <[email-masked]> wrote:
> 

In my auto-filtering folder I see 396 messages of which 152 are from you, in the past three weeks or so.  

Please take note of Brian's email.

Tim

---

From: Bob Hinden <[email-masked]>
Date: Sat, 27 Apr 2019 19:53:18 -0700

Alex,

> On Apr 27, 2019, at 11:55 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

There is no exact number.   But I think it’s clear that the eight emails you sent to the list today is too many.

Increasing the volume of emails is not an effective way to build a consensus around your ideas.  More likely, it will cause most people to stop listening.

Bob

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 28 Apr 2019 11:45:06 +0000

Hello Mikael:

I started an informational draft for 6MAN on WiND (wireless ND) to explain what physical models it serves and how it can be used over several MAC layer abstractions.

WiND is a series of drafts that were initially defined outside 6MAN, but may continue and be maintained in 6MAN. WiND extends IPv6 ND for multiple types of radios and other constrained links that were studied at 6lo.

The draft contains things like what I just posted in this thread, trying to express that on radios the concepts of Broadcast Domains, IP Link and IP subnet do not necessarily overlap

The draft presents to 6MAN the new methods we added to IPv6 ND outside this group to address the physical connectivity and the logical topologies that we build over it. In that process we did not need to change IPv6 addressing model so the draft will *not* contain proposed the changes to link local address schema. 

Still it is usable as a reference to sustain the discussion. And I imagine/hope that 6MAN will take over and manage the future of WiND anyway so it’s good to have an introduction...

All the best,

Pascal

> From: Mikael Abrahamsson <[email-masked]>
> Sent: mercredi 24 avril 2019 07:03
> To: Gyan Mishra <[email-masked]>
> Cc: Brian E Carpenter <[email-masked]>; Pascal Thubert
> (pthubert) <[email-masked]>; 6man WG <[email-masked]>; 神明達哉
> <[email-masked]>; Alexandre Petrescu <[email-masked]>;
> Fernando Gont <[email-masked]>
> I spent non-trivial amount of time yesterday trying to make sense out of all the
> emails that had been sent in the past week. I am not against changing the
> standards if there is a problem that the current standards doesn't address. I
> just want to understand it and the past 50-100 emails has been causing me
> more confusion than clarity.
> 
> --

---

From: Philip Homburg <[email-masked]>
Date: Sun, 28 Apr 2019 20:18:23 +0200

> I started an informational draft for 6MAN on WiND (wireless ND) to
> explain what physical models it serves and how it can be used over
> several MAC layer abstractions.

I read draft-thubert-6man-ipv6-over-wireless-00. I quite like the
description of the issues with wireless media.

There is however one thing I miss: The abstract says "This document describes
how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied
on various abstractions of wireless media."

I'm also interested in *why* WiND should be applied. In particular, Figure 2
shows a complex multi-layered setup.

So my question is, why not use routing and keep subnets restricted to one
link?

I hope there is a clear set of arguments why routing is not sufficient. 
Right now it reads too much like a primitive routing protocol on top of ND.

Another issue that often shows up with registration based systems (such as
quite common with IPv4 and wireless) is what happens if a host has more
addresses than supported by the registration system?

I.e., it might scale better to have lots of point-to-point links and prefix
delegation than to have a single big subnet and a hierarchical registration
system.

---

From: Ole Troan <[email-masked]>
Date: Mon, 29 Apr 2019 10:56:42 +0200

> delegation than to have a single big subnet and a hierarchical registration

That was my thinking too. If you have a set of p2p links, you don't need very little of ND.

Cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Apr 2019 11:08:38 +0000

Hello Ole:

Yes, that's a starting point. I have an answer  on the works but it urned out taking more time than I thought. Will post soon now.

Bottom line is a big ask to 6MAN. Please forget about FR and ATM, and do not use that as a pre-conceived system for wireless. Numbers are different. Links come and go all the time even in fixed deployments. Which can be damn large. Even today. 

Also, if people wish to discuss whether P2P subnets was good enough for FR or whether the NBMA and P2MP models you could find there (e.g. Proteon and IBM) are useful, please use another thread. I may discuss there for the sake of fun and old days - I was on the IBM side at the time. But that thinking is not applicable to wireless and IOT, clean slate.

All the best,

Pascal

> From: Ole Troan <[email-masked]>
> Sent: lundi 29 avril 2019 10:57
> To: Philip Homburg <[email-masked]>
> Cc: 6man WG <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>
> Subject: Re: Wireless ND was: about violation of standards
> 
> > There is however one thing I miss: The abstract says "This document
> > describes how the original IPv6 Neighbor Discovery and Wireless ND
> > (WiND) can be applied on various abstractions of wireless media."
> >
> > I'm also interested in *why* WiND should be applied. In particular,
> > Figure 2 shows a complex multi-layered setup.
> >
> > So my question is, why not use routing and keep subnets restricted to
> > one link?
> >
> > Another issue that often shows up with registration based systems
> > (such as quite common with IPv4 and wireless) is what happens if a
> > host has more addresses than supported by the registration system?
> >
> > I.e., it might scale better to have lots of point-to-point links and
> > prefix delegation than to have a single big subnet and a hierarchical
> > registration system.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Apr 2019 12:18:49 +0000

Hello Phil:

Sure, matching a subnet per P2P link and then route between subnets one way of doing things.  Note that it is a deployment decision, not our decision as std makers or vendors. There are considerations out there like stability of links, capability to configure stuff from a management system and cheer scale that make people go for certain ways or others for their use cases. WiND allows to map subnets on P2P but does not force it, couldn't if we tried. 

There are practical use cases in the wireless world where subnets are not P2P:
-  IEEE std 802.11 infrastructure BSS enables one subnet per AP, and emulates a broadcast domain at L2. Infra ESS extends that and recommends to use an IPv6 ND proxy (per IEEE specs) to coexist with Ethernet connected nodes. WiND incorporates an ND proxy to serve that need and that was missing so far.
-  BlueTooth is hub and spoke at the MAC layer. Should we need to configure a different subnet for each peripheral node (e.g., sensor)? I 'd hope not. Hopefully RFC 7668 allocates a prefix to the central node acting as router (6LR), and each peripheral forms a global address from that same prefix and act as a host (6LN). 
-  Smartgrid networks build route-over subnets of thousands of IPv6 nodes and with such scalability demands, managing a subnet per P2P link is not even considered. Peerings come and go with the dynamics of radio propagation, and only a minimal portion of nodes in range to one another actually peer. The 6TiSCH architecture reflects that model, and generalizes it, e.g., for industrial plants, cars in a parking lot, whatever.

Note: In BLE like in many wireless cases, Link local Addresses need only to be DADed inside the pairs of communicating nodes. In that example, 2 peripherals connected to the same central node can not have the same Link Local Address because the BCEs would collide at the central node and the central node could not talk to both at the same time over the same interface. WiND defines the appropriate DAD operation, but ND does not, because peripherals are no on a same broadcast link. OTOH, Global and ULA are DADed at the Subnet Level.

WiND allows P2P, P2MP hub-and spoke, MAC-level broadcast domain emulation such as mesh-under and Wi-Fi BSS, and route over meshes. There is an intersection where Link and Subnet are congruent and where both ND and WiND could apply. These includes P2P, the MAC emulation of a PHY broadcast domain, and the particular case of always on, fully overlapping physical radio broadcast domain. But even in those cases where both are possible,  WiND is preferable vs. ND because it reduces the need of broadcast, more on that in the intro of https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router.

Is 6MAN ready for this?

About the size of the registrar, the backbone router enables a distribution of it. But really that is a discussion of the past. Routers can have gigs of memory. The registrar is usually push to a redundant server somewhere, e.g., on modern fabrics that often rely on overlays, mapping servers can scale, to the 10^12 I heard claim for the case of LISP MSMR. The real question is how to migrate from the ND reactive model to a version of ND that is more friendly to new usages such as rapid mobility and large overlays. draft-thubert-6lo-unicast-lookup is a beginning of an answer.

And please do not dismiss the efforts that we had to make to enable routing in that space. RPL is not primitive in my book. WiND and RPL brought in a number of concepts that are now adopted in datacenter routing for RIFT, and though only nascent, I call RIFT a modern routing protocol.

All the best;

Pascal

> From: [email-masked] <[email-masked]>
> On Behalf Of Philip Homburg
> Sent: dimanche 28 avril 2019 20:18
> To: [email-masked]
> Cc: Pascal Thubert (pthubert) <[email-masked]>
> I read draft-thubert-6man-ipv6-over-wireless-00. I quite like the description of
> the issues with wireless media.
> 
> how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be
> applied on various abstractions of wireless media."
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 29 Apr 2019 14:21:19 +0200

>> That was my thinking too. If you have a set of p2p links, you don't need very

You need very little of ND. Was what I tried to say.
E.g. address resolution wouldn't be needed.

Cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Apr 2019 12:53:00 +0000

Hello Ole

A radio mesh in our smartgrid deployments has thousands of nodes, each with 10s to 100 others in range. A key problem for the routing protocol is who should this node peer with, because you see, most of the possible peers are no added value and both energy and bandwidth are limited so even talking to them is a bad idea.

Even if we could e.g., by stretching homenet, nobody is willing to spend energy and bandwidth allocating prefixes to all the possible pairs or maintain as many addresses in all nodes.
Renumbering a meter means talking to a central application to indicate a new address. No one wants that either. 
Most nodes are both routers and termination points. And we often use source routing.  ULA/GUA is needed on every node.

For that use case:
- ULA/GUA are needed on all nodes
- one prefix per P2P is not feasible at scale
- one prefix per node is feasible but may consume thousands of /64, hard to justify in large scale. For that model, use the WiND hub and spoke on every node, and routing between them
- people usually go for a /64 per AP/root with nice side effects of compression and mobility so yes they route, but inside the subnet (MLSN). For that model, use the WiND route-over mode.

All the best,

Pascal

> Sent: lundi 29 avril 2019 14:21
> Cc: Philip Homburg <[email-masked]>; 6man WG
> <[email-masked]>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 29 Apr 2019 15:13:23 +0200

> Sure, matching a subnet per P2P link and then route between subnets
> one way of doing things.  Note that it is a deployment decision,
> not our decision as std makers or vendors. There are considerations
> out there like stability of links, capability to configure stuff
> from a management system and cheer scale that make people go for
> certain ways or others for their use cases. WiND allows to map
> subnets on P2P but does not force it, couldn't if we tried.

In general it is good to have clear operational justification to have
more than one way of doing something. Having multiple ways means more work
for implementations, risk of incompatible implementations, training costs,
etc.

I'm not judging against WiND, but it is worth looking at why other approaches
fail.

> About the size of the registrar, the backbone router enables a
> distribution of it. But really that is a discussion of the past.
> Routers can have gigs of memory. 

Some routers have gigs of memory. Some other routers only have a few megs
of memory. Issues with registration systems holding only one address are
real.

> And please do not dismiss the efforts that we had to make to enable
> routing in that space. RPL is not primitive in my book. WiND and
> RPL brought in a number of concepts that are now adopted in datacenter
> routing for RIFT, and though only nascent, I call RIFT a modern
> routing protocol.

So if you have a routing protocol, why not model it as a routing protocol?

Note that I'm interested in why mapping links to subnets fails. I.e., we tried
it and then this is what happened. 

Another issue, should we create big subnets that cannot do multicast?