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

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 <brian.e.carpenter@gmail.com> wrote:
>      >>> On Jun 15, 2018, at 5:12 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> 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?

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 