Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22

[Brian E Carpenter <[e-mail]>]

On 17/06/2018 05:28, Alexandre Petrescu wrote:
> 
> 
> Le 16/06/2018 à 15:02, Michael Richardson a écrit :
>> [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT DANGEREUSES]
>>
>> Ce message contient des pieces jointes potentiellement dangereuses car susceptibles de contenir des virus. Pour lutter contre l'expansion de ce type d'attaque, les documents [null] ont ete retires du message original ci-dessous. Pour les documents Office, le CEA recommande l'usage exclusif des formats plus recents exempts de macros comme DOCX, XLSX, PPTX, merci de le signaler a votre expediteur.
>>
>> Pour de plus amples informations ou pour connaitre les mecanismes de mise en quarantaine, vous pouvez vous rapprocher de votre service informatique ou consulter le site USCIpedia - rubrique PureMessage.
>>
>> ----------------MESSAGE ORGINAL ci-dessous------------------
>>
>>
>> Brian E Carpenter <[e-mail]> wrote:
>>      >>> On Jun 15, 2018, at 5:12 AM, Alexandre Petrescu <[e-mail]> wrote:
>>      >>>
>>      >>> But, we do not know whether a regular android smartphone can work in OCB mode.
>>      >>>
>>      >>> That is a key point of ND over OCB.
>>      >>
>>      >>
>>      >> Why are we blocking progress due to one implementation?
>>
>>      > Well, the fact that the explanation of how ND and SLAAC actually work
>>      > on OCB is incomplete is really what's blocking progress. Alexandre
>>      > has said that ND has been observed to work (he didn't mention SLAAC,
>>      > but I guess it must have worked too). But I still can't reconcile that
>>      > with the explanation that OCB nodes missing packets is a normal, rather
>>      > than exceptional, situation. How does ND work when there's a radio-frequency
>>      > barrier between two nodes?
>>
>> It sounds like they need to profile RFC6775 or
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/
> 
> If we want to profile something, we would need first to have a problem. 
> What is the problem?

How does ND work when there's a radio-frequency barrier between two nodes?
 
   Brian


> 
> As a side note, for my part I do not approach RFC6775 "Registration 
> Extensions for 6LoWPAN Neighbor Discovery" because OCB is not 6lowPAN.
> 
> These two technologies are very much different: different frequencies, 
> ranges, application goals and more.  Nobody thinks of using 6lowpan to 
> communicate between moving cars.  You could if you wanted to play, but 
> not sure why.  It's like working on ATM and somebody points rather to FDDI.
> 
> Ironical: of course, we could also block an RFC because it does not 
> refer to all other RFCs.  Irony ended.
> 
> Alex
> 
>>
>> They solve ND when broadcast is not complete.
>> However, they depend upon having a deice to keep track of things.
>> That it turn is facilitated (but not required) by having a routing protocol
>> that creates an DAG and creates an up direction which makes it obvious
>> where the DAR/DAC packets go to/come-from.
>>
>> This might be a problem in a regularly changing convoy, but shouldn't be a
>> problem within a vehicle.
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>   -= IPv6 IoT consulting =-
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>