Re: disagreement on which OS should change

[Alexandre Petrescu <[e-mail]>]

Le 27/04/2019 à 20:10, Gyan Mishra a écrit :
> 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.

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?

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

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.

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

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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
>     <[e-mail] <mailto:[e-mail]>>
>     wrote:
>      >
>      >
>      >
>      >> Le 25/04/2019 à 18:09, 神明達哉 a écrit :
>      >> At Thu, 25 Apr 2019 09:41:35 +0200,
>      >> Alexandre Petrescu <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >> > >  > 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;
>      >> >
>      >> > 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?
>      >> 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
>      >> 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
>      >
>      > --------------------------------------------------------------------
>      > IETF IPv6 working group mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>      > --------------------------------------------------------------------
>