Re: [Tsv-art] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Alexandre Petrescu <[e-mail]>]

Le 27/06/2019 à 18:38, Joerg Ott via Datatracker a écrit :
[...]
> App. E: why would high mobility affect encapsulation"?

The paragraph in question is this:
> 
> Appendix E.  Design Considerations
> 
> The networks defined by 802.11-OCB are in many ways similar to other 
> networks of the 802.11 family.  In theory, the encapsulation of IPv6 
> over 802.11-OCB could be very similar to the operation of IPv6 over 
> other networks of the 802.11 family.  However, the high mobility, 
> strong link asymmetry and very short connection makes the 802.11-OCB 
> link significantly different from other 802.11 networks.  Also, the 
> automotive applications have specific requirements for reliability, 
> security and privacy, which further add to the particularity of the 
> 802.11-OCB link.

There a huge list of Design Considerations in the main matter.  More and
more reviews led to skinning it to just one paragraph, depicted above.

Let me try to answer to the question of why would high mobility affect 
encapsulation.

First, the word encapsulation seems to have captured your attention.  I 
hope it is for a good reason, but frankly speaking I do not know the 
reason why it attracted it.  To clarify, let me say that the word 
'encapsulation' was used to signify 'carrying' IPv6 datagrams on 
802.11-OCB.  One expects IPv6 to be carried over OCB as over WiFi. 
('encapsulation' was not used to mean IPv6-in-IPv6 encapsulation and 
friends).

The high mobility in OCB is contrasted to low (or no) mobility in WiFi - 
it means that in WiFi users are near a fixed Access Point and dont move 
much.  But in OCB there are no access points and cars move a lot.

High mobility in OCB may need to avoid potential interference in order
to ensure safety.  TO achieve that, it may be possible that QoS concents
become more mandatory on OCB links (than on WiFi; on WiFi the QoS
concepts are almost absent in implementations).  Thus, there may be a
need of some mapping between IPv6 QoS-specific fields and 802.11-OCB 
QoS-specific fields.  There may be need of other  QoS-specific fields.

So, whereas an IPv6-over-WiFi spec (which does not exist, btw) has no 
mapping of QoS fields of how  IPv6 is 'carried' (encapsulated) on WiFi, 
an IPv6-over-OCB would need some mapping of this sort, so that IPv6 is 
better 'carried' over OCB.  Because of mobility.

QoS is just an example of why encapsulating (carrying) IPv6 on OCB may 
need more than just what is needed by carring IPv6 on WiFi.

There are other examples: IPv6 addressing in OCB links requires human 
intervention often - it's not as plug and play as IPv6 over WiFi.  That 
needs easy to remember and subnet-specific link local addresses, like 
fe80:1::1/32.  These addresses dont exist on IPv6 altogher, let alone 
IPv6-over-WiFi.

There are more examples.

Remark my own difficulty  of speculating on something which does not 
exist: IPv6 over WiFi specification.

Alex