Subject: Re: [6tisch] parenthesis IPv6-over-11b (was: Removing the 'e' in the charter)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 May 2015 19:26:32 +0200

On 30/04/2015 17:37, Pascal Thubert (pthubert) wrote:
[...]
> This proved useful for Ethernet; too much maybe since we were fooled
> into extending IP over Ethernet to Wi-Fi...

I take advantage of this note from Pascal, to extend a parenthesis.

IPv6-over-Ethernet is specified in RFC2464.

IPv6-over-WiFi is not specified.  There are differences in the formats
of headers between Ethernet and WiFi, noticed by wireshark.

IPv6 works ok over WiFi because there is an adaptation in place in all
stacks which convert the 802.11 Data Header and the LLC Header into an
Ethernet II header; IPv6 works only on this latter.

This adaptation is worth documenting.  If so it may help other needs
like IPv6-over-80211p, 11ac and 11ad.

Alex

>
> Cheers,
>
> Pascal
>
>> Le 30 avr. 2015 à 07:50, Michael Richardson
>> <[email-masked]> a écrit :
>>
>>
>> Pascal Thubert (pthubert) <[email-masked]> wrote:
>>> Today, undated and without the 'e', IEEE802.15.4 means 2011 plus
>>> all the amendments.
>>
>> Given that we can't run on 802.15.4-2011, this is why I'm
>> concerned about referencing "802.15.4".
>>
>>> So, a reference to IEEE Std 802.3 (without year) today is
>>> identical to the 2012 dated reference, but when the current
>>> revision is approved (expected this year), a reference to the
>>> 2012 revision would not include the maintenance changes included
>>> in the current revision, nor any of the amendments likely to be
>>> approved soon after the revision is approved.
>>
>> How does an outsider know when the reference was made?  Is it by
>> the date of the document making the reference?
>>
>> If the IETF writes a document in 2014, but it doesn't get
>> published in Jan. 2015, what IEEE document would "802.15.4"
>> reference?
>>
>> Robert suggests text like:
>>
>>> In development of this RFC, IEEE Std 802.99 documents considered
>>> included IEEE Std 802.99-2016 and P802.99/D8.
>>
>> and so if we can do this, then I'm happy.
>>
>>
>>
>>
>> -- Michael Richardson <[email-masked]>, Sandelman Software
>> Works -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________ 6tisch mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/6tisch
>
> _______________________________________________ 6tisch mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/6tisch
>

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com

---

From: Kris Pister <[email-masked]>
Date: Fri, 01 May 2015 10:48:16 -0700

> IPv6-over-Ethernet is specified in RFC2464.

Exactly.  That's one of the shortest RFCs.  Send these bytes, in this order,
and everyone will be able to interoperate.

ksjp

On 5/1/2015 10:26 AM, Alexandru Petrescu wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 02 May 2015 17:52:24 +0200

Le 01/05/2015 19:48, Kris Pister a écrit :
> Exactly.  That's one of the shortest RFCs.  Send these bytes, in
> this order, and everyone will be able to interoperate.

Well yes, that is right.  The document is good and one can say that it
has been deployed largely.  One of the reasons of success is that the
underlying layers (MACs) have exposed interfaces to behave like Ethernet
does.

That compatibility direction is not necessarily always good.

For example, that RFC2464 still considers important one particular U/L
bit somewhere in the Interface ID.  But recently that bit became
irrelevant by RFC7136 "significance of IIDs".

In that sense, that importance of fields in the IID, and supposedly the
IID itself, may be something which may not be appropriate to IoT
devices.

Moreover, assuming that Internet operators often deliver reachability
for /64 prefixes to end users, and not shorter, and assuming that every
IoT device tries to be 64bit-IID, SLAAC can not be used beyond one
router at the edge.  Surprisingly enough many IoT devices dont really
need IIDs of length 64 (can use less, like 7bits for NFC).

That's why I think that trying to be compatible to RFC2464 is a good
thing and a bad thing at the same time.

Alex

>> On 30/04/2015 17:37, Pascal Thubert (pthubert) wrote: [...]
>>> This proved useful for Ethernet; too much maybe since we were
>>> fooled into extending IP over Ethernet to Wi-Fi...
>>
>> IPv6-over-WiFi is not specified.  There are differences in the
>> formats of headers between Ethernet and WiFi, noticed by
>> wireshark.
>>
>> IPv6 works ok over WiFi because there is an adaptation in place in
>> all stacks which convert the 802.11 Data Header and the LLC Header
>> into an Ethernet II header; IPv6 works only on this latter.
>>
>> This adaptation is worth documenting.  If so it may help other
>> needs like IPv6-over-80211p, 11ac and 11ad.
>>
>> Alex
>>
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>>> Today, undated and without the 'e', IEEE802.15.4 means 2011
>>>>> plus all the amendments.
>>>>
>>>>> 2012 revision would not include the maintenance changes
>>>>> included in the current revision, nor any of the amendments
>>>>> likely to be approved soon after the revision is approved.
>>>>
>>>> How does an outsider know when the reference was made?  Is it
>>>> by the date of the document making the reference?
>>>>
>>>>> In development of this RFC, IEEE Std 802.99 documents
>>>>> considered included IEEE Std 802.99-2016 and P802.99/D8.
>>>>
>>>> -- Michael Richardson <[email-masked]>, Sandelman
>>>> Software Works -= IPv6 IoT consulting =-
>>>>
>>>>
>>>>
>>>> _______________________________________________ 6tisch mailing
>>>> list [email-masked]
>>> _______________________________________________ 6tisch mailing
>>> list [email-masked]
>> --- L'absence de virus dans ce courrier électronique a été
>> vérifiée par le logiciel antivirus Avast. http://www.avast.com
>>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 May 2015 21:11:56 -0400

> of headers between Ethernet and WiFi, noticed by wireshark.

Actually, that's not true.

Wireshark notices the difference because wireshark (and whatever OS you are
running it on), provides an interface that lets you see below the Ethernet
compatibility layer.

Some years ago (before wireshark), if you ran tcpdump on a wifi interface,
you would see only ethernet, as the ethernet-compatibility part of 802.11
was all that was exposed to the operation system by the firmware in the
wifi card.  In Linux, it's only since much of the 802.11 logic moved from
the firmware in the PCMCIA card into the Linux kernel that it became possible
to see what was below 802.3.

This is akin to seeing IPv6, but not 6lowpan below.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 May 2015 11:23:07 +0200

> running it on), provides an interface that lets you see below the Ethernet

Right.  And if so it means that there is an Ethernet compatibility 
layer.  And that Ethernet compatibility layer (supposedly making 11b 
layers look like Ethernet, to IP) is not specified as far as I know.  Is 
there a specification of that Ethernet compatibility layer?

         +--------------------+-------------+-------------+---------+
         | 802.11 Data Header | LLC Header  | IPv6 Header | Payload |
         +--------------------+-------------+-------------+---------+

                                            ^
                                            |
                          802.11-to-Ethernet Compatibility Layer
                                            |
                                            v

                      +---------------------+-------------+---------+
                      | Ethernet II Header  | IPv6 Header | Payload |
                      +---------------------+-------------+---------+

> to see what was below 802.3.

I didnt know that.

> This is akin to seeing IPv6, but not 6lowpan below.

I agree.

Speaking of which - we do have a specification of  what 6lowpan 
adaptation layer does.

Alex