Re: disagreement on which OS should change

[Alexandre Petrescu <[e-mail]>]

Le 27/04/2019 à 09:54, Brian Carpenter a écrit :
> 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,

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.

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

mouse?

Alex

> 
> On Sat, 27 Apr 2019, 17:13 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
>      > --------------------------------------------------------------------
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>