Re: about violation of standards

[Alexandre Petrescu <[e-mail]>]

Le 18/04/2019 à 22:36, Kerry Lynn a écrit :
> On Thu, Apr 18, 2019 at 4:13 PM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>      > 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.
> 
>     Thank you for the suggestion.
> 
>     In another foo (not 6LoWPAN) some nodes agree with fe80:1::.  This does
>     not disturb 6lowpan links.
> 
> 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 ;-)

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.

>     In this sense, I think it can not be said that fe80:1::/32 violates
>     anything in 6lowpan.
> 
> My point is simply don't expect to use the LOWPAN dispatch header or
> 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

> 
> Kerry
> 
>     This is why I do not understand the suggestion.
> 
>     Alex
> 
>      >
>      > Kerry
>