Re: [ipwave] RFC8505 and 802.11 headers - the value in publishing IPv6-over-OCB

[Alexandre Petrescu <[e-mail]>]

Pascal,

One of the key values of this document is in the title itself: it says 
to run IPv6 over OCB.

Probably you are not aware, but at 5.9GHz few people think we should do 
IP, but rather other non-IP things (CAM-over-GeoNetworking, and others).

The poorness gained from not publishing this document is even more lack 
of support of IP deployment on OCB at 5.9GHz.

Le 09/04/2019 à 08:02, Pascal Thubert a écrit :
> Hello Alexandre
> 
> Like I said I liked the appendixes.

Good to know.

> But most of your list above is not all is paraphrasing other 
> specifications, as opposed to specifying anything new, isn't it?

No. The list of distinctive features in IP-over-OCB is not only about 
referring to other specifications.

As far as I know, the Ethernet Adaptation Layer (EAL) is not specified 
in any other specification.  The 802.11-2016 document does not describe 
how to make Ethernet II packets out of 802.11 packets.  The 802.1d 
document is about bridging between Ethernet and Ethernet.

The use of QoS fields in 802.11 headers to transmit IPv6 data at 5.9GHz
is not described anywhere else.

> e.g., I do not see the point of paraphrasing the IEEE in what you 
> called an adaptation layer.

Pascal, to me it seems you think IEEE already describes in an IEEE
document what I describe as a layer.  And you seem to say I just give a
new name to something already existing at IEEE document.

I disagree.

To further this point, I would like to point that making Adaptation 
Layers is common at IETF.

Second, to clarify if I am wrong, I asked you this in private meeting 
face-to-face, I asked you on private email; I now ask you publicly: 
please provide me an IEEE document that describes something akin to what 
our EAL does: make 802.11 headers out of Ethernet II headers and 
vice-versa.  It is not a challenge, it is just a key that may solve an 
issue.

(I have already asked this in the past several IEEE knowledgeable
people; I have no answer.  Maybe the question is wrong, or maybe not.)

(I have searched myself in the 802.11-2016 document the string
'bridg' to find something akin to EAL; maybe my searches are too biased 
to give answers I like, or maybe not).

> The operation that your are summarizing appears to be present in 
> pretty much any 802.11 device where it is easier to do that than 
> apply IPv6 directly on .11.

True.

> I have not seen that it is any different in OCB. If there is a
> difference, then it is of interest to note it;

 From IP perspective, the difference between 802.11 and 802.11 in OCB 
mode is at least in the QoS field:
> the value of the Traffic Identifier (TID) sub-field of the QoS
> Control field of the 802.11 header MUST be set to binary 001 (i.e.
> User Priority 'Background', QoS Access Category 'AC_BK').

Only in OCB mode, only at 5.9GHz and only with IPv6 must the value in 
that field is a MUST.  In non-OCB mode (ad-hoc mode, AP mode), or at 
other frequencies, that value can be absent.

> On the same line, privacy addresses are not specific to OCB. 

Well, indeed, privacy addresses are not specific to OCB.  They are 
important to all 802.11 and 802.15.4 and all other links on which IPv6 runs.

There are many kinds of privacy addresses and many documents.

The generation of MAC addresses is not described anywhere, and this 
document does.

Further, this is probably the only single document where a mix of 
existing MAC-in-IID addresses, MAC address generation (virtual MAC) and 
opaque IDs are described in a single document.

For example, there is no other document that describes how to make IP 
addresses by still using MAC addresses, but generate them instead of 
getting them from manufacturer.

There is no other document that tells to continue to use the existing 
MAC-based IP addresses with MACs from manufacturer, for a while 
(transition time).

> 3333 is 20+ years old.

3333 is 20+ years old but recently somebody asked what does "0 0 1 1 0 0 
1 1 0 0 1 1 0 0 1 1" mean in the picture of rfc2464.

So we clarified what it means.  That bit string means 3333.  3333 is 
clarified in RFC7042, which is more recent.  And we refer to it.

Do you think that clarification is not worth making?

Alex

> 
> cheers,
> 
> Pascal
> 
> Le lun. 8 avr. 2019 à 21:08, Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> 
> a écrit :
> 
> 
> 
> Le 08/04/2019 à 03:55, Pascal Thubert a écrit :
>> +ONE
>> 
>> note that if we really take ND off then the resulting document
> would be
>> rather empty. Which raises the question of the value of
> publishing it.
> 
> There is value in publishing it, albeit not as high as you seem to 
> fear.
> 
> The document specifies more than saying that ND works ok.
> 
> The document specifies new things compared to existing art 
> (IPv6-over-Ethernet, 6lo RFCs): - the Ethernet Adaptation Layer -
> the QoS values to set in 802.11 headers - the IID formation and
> privacy - some clarifications, like '3333'
> 
> It also has extensive Appendices explaining what is OCB, examples of
>  packet formats, and other guides to implementation.
> 
> Alex
> 
> 
> 
> -- Pascal