Re: about violation of standards - fe80::1/128

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> a écrit :

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, 神明達哉 <[e-mail]<mailto:[e-mail]>> wrote:

At Wed, 24 Apr 2019 16:29:59 +0200,
Alexandre Petrescu <[e-mail]<mailto:[e-mail]>> wrote:

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

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