Subject: [6lo] EtherType for LOWPAN_IPHC?

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 18:11:57 +0200

Hello participants to 6lo,

What is the EtherType for carrying LOWPAN_IPHC headers in Ethernet frames?

When an Ethernet frame carries an IPv6 Base Header the EtherType is 
"0x86DD".

The 802.15.4 wireshark capture in "dao_with_targetdesc.pcap" (an ICMPv6 
packet) features "0x809a"  in the Type field of the EthernetII header. 
But I cant seem to find 0x809a in the list of EtherTypes - 0x809a seems 
unassigned?  Maybe the capture is wrong?

The capture "wireshark-rpl-prefix.pcap" says "0x0800" which is IPv4, 
fine.  But I look for IPv6.

http://svn.tools.ietf.org/svn/wg/6lowpan/packets/

Alex

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Jun 2015 18:25:22 +0200

> What is the EtherType for carrying LOWPAN_IPHC headers in Ethernet frames?

802.15.4 does not have Ethertypes.

6LoWPAN uses the first byte of the MAC payload (the "dispatch" byte) to
indicate the type of frame.  See Figure 2 of RFC 4944.

> unassigned?  Maybe the capture is wrong?

The pcaps we have were captured using a variety of methods.  These often
left somewhat intesting chains of headers around the 6LoWPAN data.
Don't take those too seriously.

> fine.  But I look for IPv6.

Ditto.

We probably should be adding some descriptive text to those samples.

Grüße, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 19:01:30 +0200

Hi Carsten,

> 802.15.4 does not have Ethertypes.

I did not know that?

But in the captures I see the EthernetII header carrying an 802.15.4 
Data header does have a Type.  I am asking about that type.  What should 
be its value?

The packet I am talking about looks like this:
EthernetII
IEEE 802.15.4 Data
6LoWPAN
IPv6 Base Header
ICMPv6

it's on the website you referred to earlier.

> indicate the type of frame.  See Figure 2 of RFC 4944.

Ok, noted.  But that is not shown in the packet capture: there is no 
Dispatch byte in these captures.  I guess the spec is right but there 
are no packet captures available?

> Don't take those too seriously.

I need captures that I can take seriously.  And I can provide captures 
that one can take seriously.

I think what we do here should be done seriously, I suppose, or at least 
so I think?

> We probably should be adding some descriptive text to those samples.

There is a readme file in there... I am already happy such place exists, 
we can understand better, although it can be improved.

Alex

---

From: Robert Cragie <[email-masked]>
Date: Mon, 22 Jun 2015 16:40:20 +0100

Hi Alex,

Comments inline, bracketed by <RCC></RCC>

Robert

On 18 June 2015 at 18:01, Alexandru Petrescu <[email-masked]>
wrote:

> But in the captures I see the EthernetII header carrying an 802.15.4 Data
> header does have a Type.  I am asking about that type.  What should be its
> value?
>

<RCC>As Carsten said, the 802.15.4 network adapters use a variety of means
to wrap packets. In some cases, the wrapping of the 802.15.4 frame is done
directly using an EthernetII frame as you show above. In this case, there
is a field in the Wireshark 802.15.4 preferences called "802.15.4 Ethertype
(in hex)", which can be set appropriately and (I think) is 0x809a by
default. There are other ways of wrapping the frame, including something
called "ZEP". In all cases, you can ignore these outer wrappers (I presume
this is what Carsten meant by "not taking them seriously"); the ZEP wrapper
contains some additional info like channel and LQI</RCC>

> Dispatch byte in these captures.  I guess the spec is right but there are
> no packet captures available?

<RCC>It should be. If you dissect the 6LoWPAN part of the packet you should
see it as the first byte.</RCC>

> that one can take seriously.

<RCC>See my earlier comment.</RCC>

> we can understand better, although it can be improved.

<RCC>
That may be using the ZEP encapsulation protocol, which wraps like:

EthernetII(EtherType 0x8000)[IPv4[UDP[ZEP[802.15.4]]]]
</RCC>

Alex
>
>
>
>> Grüße, Carsten
>>
>>
>>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Jun 2015 12:42:23 +0200

Hi Robert,

Thanks for the reply.

Le 22/06/2015 17:40, Robert Cragie a écrit :
> On 18 June 2015 at 18:01, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Carsten,
>
>     Data header does have a Type.  I am asking about that type.  What
>     should be its value?
>
> <RCC>As Carsten said, the 802.15.4 network adapters use a variety of
> means to wrap packets. In some cases, the wrapping of the 802.15.4 frame
> is done directly using an EthernetII frame as you show above. In this
> case, there is a field in the Wireshark 802.15.4 preferences called
> "802.15.4 Ethertype (in hex)", which can be set appropriately and (I
> think) is 0x809a by default.

0x809a is an unallocated EtherType and should not be used other than for 
experimenting locally in a lab.  This is another aspect making any 
document using it be EXPERIMENTAL.

> There are other ways of wrapping the frame,
> including something called "ZEP". In all cases, you can ignore these
> outer wrappers (I presume this is what Carsten meant by "not taking them
> seriously"); the ZEP wrapper contains some additional info like channel
> and LQI</RCC>

I didnt know ZEP.

I would like to make sure that wrappers dont take too much space, 
because they'd negate the advantage of comressing headers in the first 
place.

Is it possible to carry 6lowpan headers without wrapping them? (like 
EthernetII carries IPv6 Base Headers).

>     Dispatch byte in these captures.  I guess the spec is right but
>     there are no packet captures available?
>
>
> <RCC>It should be. If you dissect the 6LoWPAN part of the packet you
> should see it as the first byte.</RCC>
>
>
>
>     I need captures that I can take seriously.  And I can provide
>     captures that one can take seriously.
>
>

If wrappers are there their bytecount is obviously there too.  So we 
must consider them when calculating how much 6lowpan header compression 
gains.

>     I think what we do here should be done seriously, I suppose, or at
>     least so I think?
>
>     There is a readme file in there... I am already happy such place
>     exists, we can understand better, although it can be improved.
>
>
> <RCC>

Ok.  But this is obviously many headers.

Is there a way to carry 6lowpan packets without involving wrappers?

Wouldnt it be better to do:

802.15.4Header|LLC Header|IPv6BaseHeader
which would further be adapted by an Adaptation Layer towards

EthernetII|IPv6BaseHEader.

In this case, even if the 802.15.4Header does not use an EtherType, the 
LLCHeader does use 0x86dd EtherType for IPv6.  And this EtherType is put 
in the EtherType field of the EthernetII header.

Or it could be:
802.15.4Header|LLC Header|LOWPAN_HC header
with a newly allocated EtherType in the LLC Header.

Alex

>     [email-masked] <mailto:[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 23 Jun 2015 12:53:22 +0100

Hi Alex,

Further comments inline, bracketed by <RCC2></RCC2>. The part you are
missing is that these extra headers are never on the wire/ether. They are
added by the network adapter ("dongle") simply for Wireshark's (and other
network analysers) convenience. So there is no consequence for packet sizes
on the wire/ether.

Robert

On 23 June 2015 at 11:42, Alexandru Petrescu <[email-masked]>
wrote:

> experimenting locally in a lab.  This is another aspect making any document
> using it be EXPERIMENTAL.

<RCC2>It is never sent out on the wire/ether - it is added by the network
adapter to make it easy for Wireshark to use. The packet originator did not
use it. So whilst I agree with you in principle, I don't think it
matters.<RCC2>

> I would like to make sure that wrappers dont take too much space, because
> they'd negate the advantage of comressing headers in the first place.
>

<RCC2>The part you are missing is that these extra headers never go out on
the wire/ether. In the 802.15.4 packet example, what is on the ether is an
802.15.4 packet. The network adapter then wraps that packet in these extra
headers to make it easier for Wireshark to use. So all the extra headers
you see above 802.15.4 don't exist on the ether.<RCC2>

> If wrappers are there their bytecount is obviously there too.  So we must
> consider them when calculating how much 6lowpan header compression gains.

<RCC2>Again - they are not on the wire/ether. They are simply added by the
network adapter for convenience</RCC2>

> LLCHeader does use 0x86dd EtherType for IPv6.  And this EtherType is put in
> the EtherType field of the EthernetII header.
>
> Or it could be:

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Jun 2015 14:30:43 +0200

Hi Robert,

Le 23/06/2015 13:53, Robert Cragie a écrit :
>  missing is that these extra headers are never on the wire/ether.

What is the bytecount of wrapping headers put on the wire?  Zero?

> They are added by the network adapter ("dongle") simply for
> Wireshark's (and other network analysers) convenience.
 >
 >
> So there is no consequence for packet sizes on the wire/ether.

It's meaningless to claim advantages of header compression when below us 
there are headers of size unknown.  (cutting the branch below our feet).

> On 23 June 2015 at 11:42, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>
> Hi Carsten,
>
> The packet I am talking about looks like this: EthernetII IEEE
> 802.15.4 Data 6LoWPAN IPv6 Base Header ICMPv6
>
> means to wrap packets. In some cases, the wrapping of the 802.15.4
> frame is done directly using an EthernetII frame as you show above.
> In this case, there is a field in the Wireshark 802.15.4 preferences
> called "802.15.4 Ethertype (in hex)", which can be set appropriately
> and (I think) is 0x809a by default.
>
>
> 0x809a is an unallocated EtherType and should not be used other than
> for experimenting locally in a lab.  This is another aspect making
> any document using it be EXPERIMENTAL.
>
> <RCC2>It is never sent out on the wire/ether - it is added by the
> network adapter to make it easy for Wireshark to use. The packet
> originator did not use it. So whilst I agree with you in principle, I
>  don't think it matters.<RCC2>

The 0x809a is an EtherType which must not be used - do you agree?

If you agree to that then we can discuss.

Alex

>
>
>
> There are other ways of wrapping the frame, including something
> called "ZEP". In all cases, you can ignore these outer wrappers (I
> presume this is what Carsten meant by "not taking them seriously");
> the ZEP wrapper contains some additional info like channel and
> LQI</RCC>
>
>
> I didnt know ZEP.
>
> because they'd negate the advantage of comressing headers in the
> first place.
>
> <RCC2>The part you are missing is that these extra headers never go
> out on the wire/ether. In the 802.15.4 packet example, what is on the
> ether is an 802.15.4 packet. The network adapter then wraps that
> packet in these extra headers to make it easier for Wireshark to use.
> So all the extra headers you see above 802.15.4 don't exist on the
> ether.<RCC2>
>
>
>
> 6LoWPAN uses the first byte of the MAC payload (the "dispatch" byte)
> to indicate the type of frame.  See Figure 2 of RFC 4944.
>
>
> The 802.15.4 wireshark capture in "dao_with_targetdesc.pcap" (an
> ICMPv6 packet) features "0x809a"  in the Type field of the EthernetII
> header. But I cant seem to find 0x809a in the list of EtherTypes -
> 0x809a seems unassigned?  Maybe the capture is wrong?
>
>
> The pcaps we have were captured using a variety of methods. These
> often left somewhat intesting chains of headers around the 6LoWPAN
> data. Don't take those too seriously.
>
>
> must consider them when calculating how much 6lowpan header
> compression gains.
>
>
> <RCC2>Again - they are not on the wire/ether. They are simply added
> by the network adapter for convenience</RCC2>
>
>
>
> <RCC> That may be using the ZEP encapsulation protocol, which wraps
> like:
>
> EthernetII(EtherType 0x8000)[IPv4[UDP[ZEP[802.15.4]]]] </RCC>
>
>
> 802.15.4Header|LLC Header|IPv6BaseHeader which would further be
> adapted by an Adaptation Layer towards
>
> In this case, even if the 802.15.4Header does not use an EtherType,
> the LLCHeader does use 0x86dd EtherType for IPv6.  And this EtherType
> is put in the EtherType field of the EthernetII header.
>
> Or it could be: 802.15.4Header|LLC Header|LOWPAN_HC header with a
> newly allocated EtherType in the LLC Header.
>
> Alex
>
>
>
> Alex
>
>
>
> Grüße, Carsten
>
>
>
> _______________________________________________ 6lo mailing list
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/6lo
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2015 13:50:52 -0400

So, the PCAP file format has a type for 802.15.4:
    LINKTYPE_IEEE802_15_4

see: http://www.tcpdump.org/linktypes.html

There is a document at draft-tuexen-opsawg-pcapng-00.txt which
considers whether to make this more than an defacto (open source)
industry standard... Note that we have also discussed the need
when doing 15.4 captures to record things like channel/frequency numbers,
etc.

(aka [email-masked])

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

---

From: Robert Cragie <[email-masked]>
Date: Tue, 23 Jun 2015 20:05:18 +0100

Hi Alex,

Further comments inline, bracketed by <RCC3></RCC3>

Robert

> What is the bytecount of wrapping headers put on the wire?  Zero?

<RCC3>Yes. Zero.</RCC3>

> there are headers of size unknown.  (cutting the branch below our feet).

<RCC3>They aren't "below" us at all. These headers simply wrap the incoming
packet from the radio to make it more convenient to be processed by
Wireshark. They have absolutely nothing to do with header compression
occurring in the payload of 802.15.4 frames.</RCC3>

[snip]

> The 0x809a is an EtherType which must not be used - do you agree?

<RCC3>
1) On the ether/wire: Must not be used
2) In an Ethernet frame wrapping a packet from a network adapter for a
specific purpose: As long as that purpose is understood, it seems OK to me
but as others have pointed out, it would be good to document these specific
purposes.
<RCC3>

Robert

> If you agree to that then we can discuss.

<RCC3>Again, it is not going on the ether/wire therefore we are not
breaking any rules.</RCC3>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 11:26:33 +0200

Le 23/06/2015 21:05, Robert Cragie a écrit :
> On 23 June 2015 at 13:30, Alexandru Petrescu

Ok, zero bytes on the wire of 'wrapping' headers.

But zero bytes on the wire below the 6lowpan header?

>     It's meaningless to claim advantages of header compression when
>     below us there are headers of size unknown.  (cutting the branch
>     below our feet).
>
>
> <RCC3>They aren't "below" us at all. These headers simply wrap the
> incoming packet from the radio to make it more convenient to be
> processed by Wireshark. They have absolutely nothing to do with header
> compression occurring in the payload of 802.15.4 frames.</RCC3>

I understand the need to add various headers for local processing only,
not to put on the wire. It is the case with radiotap headers, EthernetII
header and more. And there is an adaptation layer.

But, in more detail, and in this case in particular: do you mean on the
wire there is no header below the 6lowpan header?

> 1) On the ether/wire: Must not be used

Ok.

> specific purpose: As long as that purpose is understood, it seems OK to
> me but as others have pointed out, it would be good to document these
> specific purposes.
> <RCC3>

In a sense I agree - document such that software can be reused between
different parties and dont block when somebody puts a 0x86dd there.

In another sense I disagree - an Internet Draft wouldn't claim an
EtherType that IEEE does not allocate. The ethertypes are under the
control of IEEE. IANA maintains a list to reflect it, for historical
reasons. But ethertypes are not assigned by IANA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 11:36:23 +0200

The term 'ethertype' is widely used in common conversation to mean very 
particular things.  Ethertypes are under the _control_ of IEEE and for 
historical reasons listed by IANA as well, as an 'echo' if you wish. 
IETF and IANA dont _control_ nor allocate ethertypes.

I am not sure whether tcpdump's linktype means the same thing as 
'ethertype'?  (I never heard of 'linktype'?).

> see: http://www.tcpdump.org/linktypes.html

What is the value of LINKTYPE_IEEE802_15_4?  Is it 0x809a?

Maybe the tcpdump people should ask for it from IEEE?  There is a 
procedure for that.  It is simple.

> industry standard...

Well ok, they can make the pcap format a defacto standard because IEEE 
would not veto capture formats.

Their IANA section is TBD, so I dont think they'd request ethertypes.

  Note that we have also discussed the need
> when doing 15.4 captures to record things like channel/frequency numbers,

An idea is to use radiotap headers for that on 15.4 captures.  In 
addition to channel numbers, it should include power levels as well.
Surely, there is some work to do to have it done.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jun 2015 09:59:37 -0400

> (I never heard of 'linktype'?).

No, it's a value for a file format to indicate what kind of thing
is inside.  It says what kind of layer-2 was captured.
Ethernet is one of the options, in which case ethertype has further meaning
to indicate the layer-3-ish thing.  15.4 is another format, completely
seperate from ethertype.

    > What is the value of LINKTYPE_IEEE802_15_4?  Is it 0x809a?

No, and that's not the point.

The point is that there are other ways to present 802.15.4 packets
in captures.

The use of 0x809a in a fake ethernet layer is just the choice of *one*
wireshark 802.15.4 capture interface, and it is done as a private
interface between two private components.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 16:17:20 +0200

Le 24/06/2015 15:59, Michael Richardson a écrit :
> No, it's a value for a file format to indicate what kind of thing is
> inside.  It says what kind of layer-2 was captured. Ethernet is one
> of the options, in which case ethertype has further meaning to
> indicate the layer-3-ish thing.  15.4 is another format, completely
> seperate from ethertype.

Ok, that is file formats, not packet formats.  I agree with you about
file formats and software writers are free to define linktypes.

> The point is that there are other ways to present 802.15.4 packets in
> captures.
>
> The use of 0x809a in a fake ethernet layer is just the choice of
> *one* wireshark 802.15.4 capture interface, and it is done as a
> private interface between two private components.

I agree in that case.

My point is about packet headers carrying 6lowpan headers.  It's these
packet headers which should have an EtherType, if they are in the IEEE
class.

But hold on a second - do you agree there is on the wire a header below
a 6lowpan header?  Or are all the headers that we see in these captures
below 6lowpan just fake?

Alex

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

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Jun 2015 19:09:35 +0100

I think we need to clarify things further. Let's take a packet trace from
Wireshark using the Ubisys 802.15.4 Wireshark dongle. The example captured
packet is a CoAP packet going over a 6LoWPAN mesh network. This is the list
of framing, outermost first:

1) Frame 27: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits)
on interface 0
2) Ethernet II, Src: UbisysTe_00:01:63 (00:1f:ee:00:01:63), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
3) Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst:
255.255.255.255 (255.255.255.255)
4) User Datagram Protocol, Src Port: 17754 (17754), Dst Port: 17754 (17754)
5) ZigBee Encapsulation Protocol, Channel: 18, Length: 52
6) IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x0400
7) 6LoWPAN
8) Internet Protocol Version 6, Src: fd00:db8::ff:fe00:400
(fd00:db8::ff:fe00:400), Dst: fd00:db8::ff:fe00:0 (fd00:db8::ff:fe00:0)
9) User Datagram Protocol, Src Port: 19789 (19789), Dst Port: 19789 (19789)
10) Constrained Application Protocol, Confirmable, MID:101, POST

So, to be clear, [10] is encapsulated in [9], [9] in [8] and so on. With
6LoWPAN fragmentation, this can look different but in this case it all fits
into one 802.15.4 data frame.

As we all know, encapsulation/layering can be represented as follows:

[Outer Header, Outer Payload[Inner Header, Inner Payload, Inner Footer],
Outer Footer]

So the above can be summarised more or less like the following (I have
assumed no footers to try to simplify the illustration)

[1H,1P:[2H,2P:[3H,3P:[4H,4P:[5H,5P:[6H,6P:[7H,7P:[8H,8P:[9H,9P:[10H,10P[CoAP
payload]]]]]]]]]]]

Note this is not exactly correct as will be made clearer later but is a
good enough illustration at this stage. Crucially, in the above *only 6 to
10 is on the ether*, i.e.:

6) IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x0400
7) 6LoWPAN
8) Internet Protocol Version 6, Src: fd00:db8::ff:fe00:400
(fd00:db8::ff:fe00:400), Dst: fd00:db8::ff:fe00:0 (fd00:db8::ff:fe00:0)
9) User Datagram Protocol, Src Port: 19789 (19789), Dst Port: 19789 (19789)
10) Constrained Application Protocol, Confirmable, MID:101, POST

All the other encapsulating frames are added by the network adapter:

1) Frame 27: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits)
on interface 0
2) Ethernet II, Src: UbisysTe_00:01:63 (00:1f:ee:00:01:63), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
3) Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst:
255.255.255.255 (255.255.255.255)
4) User Datagram Protocol, Src Port: 17754 (17754), Dst Port: 17754 (17754)
5) ZigBee Encapsulation Protocol, Channel: 18, Length: 52

As Carsten pointed out, we don't really care about (1) to (5). So lets take
framing (6) to (10) on the ether one by one:

6) IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x0400

This is the 802.15.4 MAC data frame and these are the bytes you will see on
the ether. The MAC header shows it going from 0x0400 to 0x0000 layer 2
addresses. The payload (aka MAC SDU) is the 6LoWPAN frame. There is also a
MAC footer in this case; the 16-bit CRC.

7) 6LoWPAN

This is the 6LoWPAN IPHC header followed by the data which in total
comprises the compressed version of the IPv6 packet

8) Internet Protocol Version 6, Src: fd00:db8::ff:fe00:400
(fd00:db8::ff:fe00:400), Dst: fd00:db8::ff:fe00:0 (fd00:db8::ff:fe00:0)

This is the only place where Wireshark deviates somewhat, as (8) is the
uncompressed IPv6 representation of (7), where the IPHC compressed fields
have been expanded into the full IPv6 header. This means (8) is not
actually the payload of (7).

9) User Datagram Protocol, Src Port: 19789 (19789), Dst Port: 19789 (19789)

The UDP datagram is the payload of the IPv6 packet

10) Constrained Application Protocol, Confirmable, MID:101, POST

The CoAP message is the payload of the UDP datagram.

I hope this makes it clearer what is one the ether and what isn't. With
regard to the original point, the EthernetII frame (2) is *not* on the
ether.

Robert

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 11:51:13 +0200

Robert,

Thank you very much.  I find it very valuable overall.

I have however a few comments.

Le 24/06/2015 20:09, Robert Cragie a écrit :
> I think we need to clarify things further. Let's take a packet trace
> from Wireshark using the Ubisys 802.15.4 Wireshark dongle. The example
> captured packet is a CoAP packet going over a 6LoWPAN mesh network. This
> is the list of framing, outermost first:
>
> 1) Frame 27: 126 bytes on wire (1008 bits), 126 bytes captured (1008
> bits) on interface 0
> 2) Ethernet II, Src: UbisysTe_00:01:63 (00:1f:ee:00:01:63), Dst:
> Broadcast (ff:ff:ff:ff:ff:ff)

I see the headers in the same manner. Some emulators of other protocols
act that way as well, encapsulating everything in IPv4. But yes, that
encapsulation is local just to have a transport for testing the main
protocol.

> 6LoWPAN fragmentation, this can look different but in this case it all
> fits into one 802.15.4 data frame.
>

Yes, it is good to assume no footers in some cases because some carriers
dont put footers (IPv6 has no footers/trailers, although IPv6 ESP tunnel
mode does feature such).

> good enough illustration at this stage. Crucially, in the above *only 6
> to 10 is on the ether*, i.e.:
>

Ok, so the 15.4 header is on the wire. I tend to agree with you.

> 1) Frame 27: 126 bytes on wire (1008 bits), 126 bytes captured (1008
> bits) on interface 0
> 2) Ethernet II, Src: UbisysTe_00:01:63 (00:1f:ee:00:01:63), Dst:
> Broadcast (ff:ff:ff:ff:ff:ff)
> As Carsten pointed out, we don't really care about (1) to (5). So lets
> take framing (6) to (10) on the ether one by one:
>
> This is the 802.15.4 MAC data frame and these are the bytes you will see
> on the ether. The MAC header shows it going from 0x0400 to 0x0000 layer
> 2 addresses. The payload (aka MAC SDU) is the 6LoWPAN frame. There is
> also a MAC footer in this case; the 16-bit CRC.

YEs, and deployers of IPv6-over-15.4 must be able to use MAC src and dst
addresses other than 0x0. That 0x0 is wrong.

The MAC src and dst addresses have very strong relationship with the
link-local and multicast IPv6 addresses (e.g. MAC address 33::1
corresponds to ff02::1, and vice-versa). One can't have ff02::1 in the
IP dst address field and 0 in the MAC dst field, it's incompatible.

I suggest we at least try to come up with MAC addresses to use in the
15.4 header.

> uncompressed IPv6 representation of (7), where the IPHC compressed
> fields have been expanded into the full IPv6 header. This means (8) is
> not actually the payload of (7).

This deviation is because the programmer does not know how to do. So she
hacks something.

> I hope this makes it clearer what is one the ether and what isn't.

YEs it does, thanks for the clarification.

I suggest to insert an additional LLC header between the 15.4 header and
the 6lowpan header. And that header to carry an EtherType. That
EtherType could be requested new for 6lowpan, as an option. So people
who want to use 6lowpan compressed headers will be able to use it. They
will gain in reducing header sizes.

I also suggest if someone does not want to use 6lowpan compressed
headers - use that same LLC header but with EtherType 0x86dd (IPv6 Base
Header). They will gain in end-to-end connectivity to the IPv6 Internet,
end-to-end IPsec, etc.

What do you think?

IMHO there are some advantages in putting an LLC over 15.4 in terms of
compatibility, bridging, link-layer security. This (setting an LLC over
15.4) would be some work to do at IEEE, not at IETF, but
that's a matter of interfacing. At IETF we could formulate requirements.

Another advantage of that LLC is that it would work over the 802.11ah
headers as well (there's an IPv6/802.11ah draft in this group) and over
Bluetooth as well.

> With regard to the original point, the EthernetII frame (2) is *not*
> on the ether.

I agree. That EthernetII is in some implementation (here) to make it
easier for the IPv6 stack. It is not on the ether.

If we add an LLC header over the 15.4 header then a widely-implemented
Adaptation Layer will transform the 15.4 header and the LLC header into
an EthernetII header, locally, to make it easier for the IPv6 stack
wireshark programmers.

Alex

>
> Robert
>
> On 24 June 2015 at 15:17, Alexandru Petrescu
>         Alexandru Petrescu <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         -- Michael Richardson <[email-masked]
>         <mailto:[email-masked]>>, Sandelman Software

---

From: Robert Cragie <[email-masked]>
Date: Thu, 25 Jun 2015 17:02:00 +0100

Hi Alex,

Robert

> dont put footers (IPv6 has no footers/trailers, although IPv6 ESP tunnel

<RCC>It is purely for illustration</RCC>

[snip]

> addresses other than 0x0. That 0x0 is wrong.

<RCC>It isn't wrong - 0x0000 is a perfectly legal 16-bit MAC address. This
is simply an example frame; of course other addresses can be used.</RCC>

> I suggest we at least try to come up with MAC addresses to use in the

<RCC>I have no idea what you are talking about here. 0x0000 is a unicast
MAC address so has nothing to do with ff02::/64, which is a multicast
address. It isn't ff02::1 in the destination field anyway, it is
fd00:db8::ff:fe00:0 as shown below. In other words, an IPv6 SLAAC address
of 0x0000 using a 6LoWPAN context according to RFC6282.</RCC>

> This deviation is because the programmer does not know how to do. So she

<RCC>You are entitled to your opinion but I wouldn't call it a hack as it
is difficult to imagine how else it would be displayed. Also, Wireshark is
a large community of developers so hardly a lone programmer.</RCC>

> will gain in reducing header sizes.

<RCC>I can't see the need for 802.15.4 but I agree there are potentially
many other target MAC/PHYs for 6LoWPAN type header compression and indeed
that is the main focus of the work of the 6lo group. There are already
numerous other adaptations out there.</RCC>

> Header). They will gain in end-to-end connectivity to the IPv6 Internet,

<RCC>Maybe you should submit a draft?</RCC>

> that's a matter of interfacing. At IETF we could formulate requirements.

<RCC>There used to be a SSCS for an IEEE 802.2 Type 1 LLC in 802.15.4-2006
(Annex A) but this was removed in the latest spec (802.15.4-2011). I am not
sure why but the IEEE must have had good reason to remove it.</RCC>

> easier for the IPv6 stack. It is not on the ether.

<RCC>It makes it easier to produce a dongle which looks like a proper
network adapter and can use e.g. RNDIS driver</RCC>

> an EthernetII header, locally, to make it easier for the IPv6 stack

<RCC>That may well happen for certain 802.15.4 network adapters and would
seem to be the case in the first example you gave right at the beginning of
this thread (
http://svn.tools.ietf.org/svn/wg/6lowpan/packets/dao_with_targetdesc.pcap).
Also, to reiterate: This would not go over the ether and is simply an
adaptation wrapper around the 802.15.4 frame. So using any EtherType seems
OK to me as it is simply a configuration item between the stack and the
network adapter and again it might be useful if everyone did agree on a
value to use in this case.</RCC>

>> is

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 18:42:23 +0200

Hi Robert,

Le 25/06/2015 18:02, Robert Cragie a écrit :
> On 25 June 2015 at 10:51, Alexandru Petrescu

Ok, it is a good illustration.

> <RCC>It isn't wrong - 0x0000 is a perfectly legal 16-bit MAC address.
> This is simply an example frame; of course other addresses can be
> used.</RCC>

Uh?

Some doc says that a 0x0 16-bit MAC address is valid?  Because a 48bit 
MAC address 0x0 can only be used by Xerox whereas the hardware of this 
dump seems to be Ubisys.

Anyways, my point is that there should be a relationship between the MAC 
address and the IP address.  Whereas this relationship is exhibited by 
this particular packet is maybe not important.  But the relationship 
should be there.

If one sends an RA on a 15.4 link then the dst MAC address of that RA 
must be a MAC multicast address, in relationship with the IPv6 multicast 
address.  (I think you agree that one can send an RA on a 15.4 link 
without a 6lowpan header?)

> fd00:db8::ff:fe00:0 as shown below. In other words, an IPv6 SLAAC
> address of 0x0000 using a 6LoWPAN context according to RFC6282.</RCC>

Ok, I conflated multicast - sorry, but now SLAAC is conflated into 
discussion.

My point is that there is a relationship between the MAC addresses and 
the IPv6 addresses ("address mapping") which needs to be there.

> <RCC>You are entitled to your opinion but I wouldn't call it a hack as
> it is difficult to imagine how else it would be displayed. Also,
> Wireshark is a large community of developers so hardly a lone
> programmer.</RCC>

I agree.

> many other target MAC/PHYs for 6LoWPAN type header compression and
> indeed that is the main focus of the work of the 6lo group. There are
> already numerous other adaptations out there.</RCC>

No, I am not saying that.

Yes - many MAC/PHYs may take advantage of 6lowpan headers.

But also yes - many MAC/PHYs for constrained networks can run IPv6 
without 6lowpan headers.

> <RCC>Maybe you should submit a draft?</RCC>

Yes.

> <RCC>There used to be a SSCS for an IEEE 802.2 Type 1 LLC in
> 802.15.4-2006 (Annex A) but this was removed in the latest spec
> (802.15.4-2011). I am not sure why but the IEEE must have had good
> reason to remove it.</RCC>

Is SSCS for 802.2 Type 1 LLC the same as the LLC we see for WiFi?

Why there is no LLC for 802.15.4?

> <RCC>That may well happen for certain 802.15.4 network adapters and
> would seem to be the case in the first example you gave right at the
> beginning of this thread
> (http://svn.tools.ietf.org/svn/wg/6lowpan/packets/dao_with_targetdesc.pcap).
> adaptation wrapper around the 802.15.4 frame. So using any EtherType
> seems OK to me as it is simply a configuration item between the stack
> and the network adapter and again it might be useful if everyone did
> agree on a value to use in this case.</RCC>

I tend to agree.

Just one detail: that pcap you refer to above does not contain an LLC 
header, and hence no EtherType.  It contains a 6lowpan header between an 
apparently uncompressed (but compressed in reality) IPv6 Base Header and 
an ICMPv6 header.

What would be needed is an LLC header on top of 15.4, and below an 
uncompressed IPv6 Base Header:

(no EthernetII)
802.15.4 Data
LLC Header
IPv6 Base Header
payload

What do you think?

Alex

>         <mailto:[email-masked]>
>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>>, Sandelman Software
>         <mailto:[email-masked]>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 25 Jun 2015 18:56:12 +0100

Hi Alex,

Further comments inline, bracketed by <RCC2></RCC2>. I think you should
take some time and use Wireshark to carefully analyse the packets in the
examples you pointed to (http://svn.tools.ietf.org/svn/wg/6lowpan/packets/)
then it should become clearer.

Robert

[snip]

> Uh?
>
> Some doc says that a 0x0 16-bit MAC address is valid?

<RCC2>Table 1 in 802.15.4-2011.</RCC2>

> address and the IP address.  Whereas this relationship is exhibited by this
> particular packet is maybe not important.  But the relationship should be
> there.
>

<RCC2>The relationship is there. Prefix is fd00:db8::/64 (context ID 0).
IID is based on 16-bit address of 0x0000 according to RFC 6282</RCC2>

>
> If one sends an RA on a 15.4 link then the dst MAC address of that RA must
> be a MAC multicast address, in relationship with the IPv6 multicast
> address.  (I think you agree that one can send an RA on a 15.4 link without
> a 6lowpan header?)

<RCC2>Not if you are using 6LoWPAN. RA is an ICMPv6 packet, therefore has a
6LoWPAN header. I can give you an example from ZigBee IP if you want,
although we tended to use it unicast there as specified in RFC 6775</RCC2>

> My point is that there is a relationship between the MAC addresses and the
> IPv6 addresses ("address mapping") which needs to be there.

<RCC2>See earlier comment</RCC2>

[snip]

> But also yes - many MAC/PHYs for constrained networks can run IPv6 without
> 6lowpan headers.

<RCC2>I thought you were talking about a potential Ethertype for 6LoWPAN so
am a bit confused now.</RCC2>

[snip]

> Why there is no LLC for 802.15.4?

<RCC2>I don't know why it was removed - I wasn't participating in IEEE at
the time</RCC2>

[snip]

> apparently uncompressed (but compressed in reality) IPv6 Base Header and an
> ICMPv6 header.
>

<RCC2>
That's not right. Let's analyse what Wireshark shows:

1) Frame 1: 69 bytes on wire (552 bits), 69 bytes captured (552 bits)
2) Ethernet II, Src: 3a:3b:3c:3d:3e:3f (3a:3b:3c:3d:3e:3f), Dst:
IPv6mcast_3c:3d:3e:3f (33:33:3c:3d:3e:3f)
--------
3) IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x3344
4) 6LoWPAN
5) Internet Protocol Version 6, Src: fe80::ff:fe00:3344
(fe80::ff:fe00:3344), Dst: ff02::1a (ff02::1a)
6) Internet Control Message Protocol v6

Again, to be clear, *(1) and (2) are not in the ether* (hence the
separator).

(1) Frame 1: 69 bytes on wire (552 bits), 69 bytes captured (552 bits)

Simply what Wireshark sees as a frame capture - no need to discuss further

2) Ethernet II, Src: 3a:3b:3c:3d:3e:3f (3a:3b:3c:3d:3e:3f), Dst:
IPv6mcast_3c:3d:3e:3f (33:33:3c:3d:3e:3f)

This is the EthernetII frame added by the network adapter. As discussed at
length, this is used to make it easier to interface to the network adapter.
The MAC addresses are not really relevant, except that the destination is a
multicast, which ties in with the lower 802.15.4 frame. The EtherType (not
shown in the summary) is 0x809a.

3) IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x3344

MAC data frame from 0x3344 to 0xffff (i.e, broadcast) *in the ether*

4) 6LoWPAN

6LoWPAN IPHC header

5) Internet Protocol Version 6, Src: fe80::ff:fe00:3344
(fe80::ff:fe00:3344), Dst: ff02::1a (ff02::1a)

I think this maybe where the confusion is. As explained earlier, (5) is NOT
the payload of (4) but the uncompressed IPv6 representation of (4). It is
equivalent full IPv6 packet which comes from the expansion of the 6LoWPAN
IPHC header.

6) Internet Control Message Protocol v6

RPL control message; a DAO with 3 RPL options (RPL Target, RPL Target
Descriptor and Transit Information)

</RCC2>

> uncompressed IPv6 Base Header:

<RCC2>
That is not right at all. You still seem to be missing the point that the
EthernetII frame is simply added by the network adapter and is not on the
wire/ether. You also seem to have lost the 6LoWPAN header which is what
adapts IPv6 to 802.15.4.

Please take the time to use Wireshark to carefully analyse the packets in
details to see the structure and where the bytes fit in then it should all
become clear.
</RCC2>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Jun 2015 16:26:48 +0200

Hi Robert,

Le 25/06/2015 19:56, Robert Cragie a écrit :
> examples you pointed to
> (http://svn.tools.ietf.org/svn/wg/6lowpan/packets/) then it should
> become clearer.
>
> Robert
>
>     [snip]
>
>     Uh?
>
>     Anyways, my point is that there should be a relationship between the
>     MAC address and the IP address.  Whereas this relationship is
>     exhibited by this particular packet is maybe not important.  But the
>     relationship should be there.
>
>

That is one kind of relationship.  This kind of relationship should be 
optional - one must have an option of deriving, or not deriving, an IPv6 
address from a MAC address.  That is for privacy protection against 
attackers who make associations.

But I meant another kind of relationship - the address mapping.  The 
'address mapping' is described in sections 6 and 7 of RFC2464 (unicast 
and mc).

For example, RFC2464 section 6 gives an encoding format of a 48bit MAC 
address into a Source or Target ll address (these are used in ND).  Or, 
RFC6282 defines 16bit MAC addresses yet it does not give a means to 
encode a 16bit MAC address into a Source or Target ll address.  Why so?

>     If one sends an RA on a 15.4 link then the dst MAC address of that
>     RA must be a MAC multicast address, in relationship with the IPv6
>     multicast address.  (I think you agree that one can send an RA on a
>     15.4 link without a 6lowpan header?)
>
>
> <RCC2>Not if you are using 6LoWPAN. RA is an ICMPv6 packet, therefore
> has a 6LoWPAN header.

No, I disagree with this logic.  An ICMPv6 packet should be - optionally 
- carried by an IPv6 Base Header.  In some 15.4 deployments it may  be 
carried by a 6lowpan header but in other 15.4 deployments it may be 
carried by an IPv6 Base Header.

> I can give you an example from ZigBee IP if you
> want, although we tended to use it unicast there as specified in RFC
> 6775</RCC2>

I dont understand.  Now we bring RFC6775 "ND for 6lowpans" in the 
picture.  If you want my oppinion - that RFC6775 also requires header 
compression and I disagree mandating it.  I think ND can run on 15.4 and 
other low-power links - optionally - without header compression.

That RFC ignores too that a Source/Target LL address is needed - 
optionally - for ND and it does not encode the 16bit MAC addresses.

[...]
> <RCC2>I thought you were talking about a potential Ethertype for 6LoWPAN
> so am a bit confused now.</RCC2>

YEs - EtherType for LOWPAN_IPHC.  This EtherType should be in a field of 
an LLC header.  This LLC header could sit on top of a 15.4 header or on 
top of a 802.11DataHeader.

How can I clarify?

> <RCC2>I don't know why it was removed - I wasn't participating in IEEE
> at the time</RCC2>

How can we find out?

And, do you think that LLC could play the role of an LLC header on top 
of a 15.4 header?

> [snip]
>
>     Just one detail: that pcap you refer to above does not contain an
>     LLC header, and hence no EtherType.  It contains a 6lowpan header
>     between an apparently uncompressed (but compressed in reality) IPv6
>     Base Header and an ICMPv6 header.
>
>
> <RCC2>

I am saying in the capture above there is no LLC header between 3 and 4. 
  Do you agree?

I am not talking about what is put on the ether or not.  I am talking 
about the absence of an LLC header between 3 (15.4) and 4 (6LoWPAN).

> This is the EthernetII frame added by the network adapter. As discussed
> at length, this is used to make it easier to interface to the network
> adapter. The MAC addresses are not really relevant, except that the
> destination is a multicast, which ties in with the lower 802.15.4 frame.
> The EtherType (not shown in the summary) is 0x809a.

Agree with the description but I disagree they use 0x809a.  Even if it 
is not put in the wire, this use creates a local incompatibility between 
processes on the same machine.

It's as if I use 193.23.23.1 on my laptop because I know it is not 
allocated to somebody else even though it is not allocated to me either.

> MAC data frame from 0x3344 to 0xffff (i.e, broadcast) *in the ether*

Here we can discuss.  That 0xffff is agreed by IEEE to be a broadcast 
address?

Is IEEE agreeing that broadcast is the right way to work in constrained 
networks, or should it rather be multicast?

I am asking because earlier IEEE decided that 48bit-MAC broadcast 
addresses 0xffffff were not the right way to work on (at that time) 
constrained devices and came up with 48bit-MAC multicast addresses and 
MAC multicast concepts.

A 16bit-MAC multicast address would look like this: 0x3301 for 
all-nodes, 0x3302 for all-hosts, 0x3303 for all-routers.  Do these 16bit 
multicast addresses exist at IEEE?  If yes, we could propose mappings 
between these and IPv6 multicast addresses.  If no, we could request 
IEEE to make them first and then we do the mappings.

> I think this maybe where the confusion is. As explained earlier, (5) is
> NOT the payload of (4) but the uncompressed IPv6 representation of (4).

I agree.  That 5 is an uncompressed representation of 4.

> It is equivalent full IPv6 packet which comes from the expansion of the
> 6LoWPAN IPHC header.

I agree.

What I mean is when there is no IPHC header, there should be an option 
to run uncompressedIPv6BaseHEader on LLC on 15.4.

> Descriptor and Transit Information)

Yes, I agree.

> That is not right at all. You still seem to be missing the point that
> the EthernetII frame is simply added by the network adapter and is not
> on the wire/ether.

No I dont miss this.  Indeed EthernetII header is simply added by the 
network adapter and is not on the ether.  That's why I said up there "no 
EthernetII".

> You also seem to have lost the 6LoWPAN header which
> is what adapts IPv6 to 802.15.4.

In some cases it is good to adapt IPv6 to 15.4 by involving a 6lowpan 
header.

But I claim in other cases that may be complex compared to simpler and 
has some negative influence on end-to-end reachability, 
neighbor-to-neighbor communicatin, retro-compatibility and security.

> Please take the time to use Wireshark to carefully analyse the packets
> in details to see the structure and where the bytes fit in then it
> should all become clear.

Yes, I am taking all necessary time to analyze packets.

In return, would you take the time to tell what _would_ you think of 
this header stack if 6lowpan header were optional?

(no EthernetII)
802.15.4 Data
LLC Header
IPv6 Base Header
payload

Alex

---

From: Robert Cragie <[email-masked]>
Date: Fri, 26 Jun 2015 18:01:17 +0100

Hi Alex,

Further comments inline, bracketed by <RCC3></RCC3>. I don't think we are
making a lot of progress on this thread and the other thread which Paul
Duffy started is probably more worthwhile. So I'll blink first - in other
words, this is my last post in this thread.

Robert

On 26 June 2015 at 15:26, Alexandru Petrescu <[email-masked]>
wrote:

> 'address mapping' is described in sections 6 and 7 of RFC2464 (unicast and
> mc).
>
> RFC6282 defines 16bit MAC addresses yet it does not give a means to encode
> a 16bit MAC address into a Source or Target ll address.  Why so?

<RCC3>Firstly - RFC2464 is "Transmission of IPv6 Packets over Ethernet
Networks". We are looking at Transmission of IPv6 Packets over IEEE
802.15.4 Networks", i.e. the title of RFC4944 (6LoWPAN). This document has
been updated by RFC6282, which describes in section 3.2.2. how you form an
IID. This is then used to form an IPv6 address as described in
RFC4862</RCC3>

> No, I disagree with this logic.  An ICMPv6 packet should be - optionally -
> carried by an IPv6 Base Header.  In some 15.4 deployments it may  be
> carried by a 6lowpan header but in other 15.4 deployments it may be carried
> by an IPv6 Base Header.

<RCC3>Maybe but our example uses the 6LoWPAN standard. Even if you really
wanted to carry an IPv6 packet verbatim (i.e. without header compression)
in an IEEE 802.15.4 network, it would be sensible to precede it with the
6LoWPAN IPv6 dispatch byte as defined in RFC4944. To my knowledge, RFC4944
and its updating documents is the only IETF-endorsed way to carry IPv6
packets over an IEEE 802.15.4 network. Of course anyone could come up with
something different but there doesn't seem to be much point in doing
so.<RCC3>

> other low-power links - optionally - without header compression.

<RCC3>Of course it can, as explained above, but you will be wasting a lot
of bytes, which is normally pretty costly on these sort of networks - which
is why we do the header compression in the first place.</RCC3>

> optionally - for ND and it does not encode the 16bit MAC addresses.

<RCC3>See RFC6282</RCC3>

> an LLC header.  This LLC header could sit on top of a 15.4 header or on top
> of a 802.11DataHeader.
>
> How can I clarify?

<RCC3>EtherType for LOWPAN_IPHC would sit on top of, er, LOWPAN_IPHC? Not
802.15.4. Maybe we have our tops and bottoms the wrong way up :-). "On top"
to me means "encapsulates". Anyway, not much point in discussing this
further.</RCC3>

>> <RCC2>I don't know why it was removed - I wasn't participating in IEEE

<RCC3>You could ask the current SCMaint chair, Pat Kinney (
[email-masked])</RCC3>

>
> And, do you think that LLC could play the role of an LLC header on top of
> a 15.4 header?

<RCC3>It was a SSCS for 802.2, i.e. a convergence sublayer, so I doubt
it.</RCC3>

> about the absence of an LLC header between 3 (15.4) and 4 (6LoWPAN).

<RCC3>I agree - there is no LLC header. Why would there be? It is not
mentioned in 6LoWPAN. Now there may be some sense in adapting 6LOWPAN_IPHC
to take advantage of other MAC/PHYs using some sort of LLC - and that is
being discussed on the other thread. But that is a different discussion as
far as I can see.</RCC3>

> Agree with the description but I disagree they use 0x809a.  Even if it is
> not put in the wire, this use creates a local incompatibility between

<RCC3>I don't think it really matters as explained before.</RCC3>

> networks, or should it rather be multicast?

<RCC3>802.15.4 only supports broadcasting. We did consider proper multicast
at one point but it was never put in the spec.</RCC3>

> constrained devices and came up with 48bit-MAC multicast addresses and MAC
> multicast concepts.
>
> A 16bit-MAC multicast address would look like this: 0x3301 for all-nodes,
> 0x3302 for all-hosts, 0x3303 for all-routers.  Do these 16bit multicast
> addresses exist at IEEE?  If yes, we could propose mappings between these
> and IPv6 multicast addresses.  If no, we could request IEEE to make them
> first and then we do the mappings.#

<RCC3>You are getting confused with 802.3 networks. 802.15.4 is not an
802.3 network</RCC3>

[snip]

> I agree.
>
> What I mean is when there is no IPHC header, there should be an option to
> run uncompressedIPv6BaseHEader on LLC on 15.4.

<RCC3>There is an option to do this using 6LoWPAN and IPV6 dispatch byte
(0x41). No need for any LLC.</RCC3>

> But I claim in other cases that may be complex compared to simpler and has
> some negative influence on end-to-end reachability, neighbor-to-neighbor
> communicatin, retro-compatibility and security.

<RCC3>Feel free to write another draft. If there is already a standard, I
prefer the "don't re-invent the wheel" approach rather than the
http://xkcd.com/927/ approach</RCC3>

> In return, would you take the time to tell what _would_ you think of this
> header stack if 6lowpan header were optional?
>
> (no EthernetII)
> 802.15.4 Data
> LLC Header
> IPv6 Base Header
> payload
>

<RCC3>Already covered by 6LoWPAN as explained above - replace "LLC Header"
with "IPv6 dispatch byte"</RCC3>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jun 2015 10:10:47 +0200

Hi Robert,

Thank you for reply.

YEs, progress seems slow.  I will not bother with further comments. 
Maybe best is to sit down and write draft.

I agree that 6lowpan header compression is ok.

The rfc4944 dispatch type in absence of 6lowpan - maybe, depending on 
what IEEE LLC may want to do.

IID formation from RFC6282 - I didnt know it.  Yes, I discover it does 
provide a means to form an IID out of the 16bit short MAC address.  No, 
it does not provide a means to map 16bit multicast MAC addresses (they 
dont exist, IEEE must make them) into IPv6 multicast addresses.

Pat Kinney - I will ask him the situation of a speculative LLC for 15.4, 
thanks for the pointer.

Why multicast 15.4 was not in the spec?  Multicast is a well-known means 
to reduce power consumption.

802.3 is not a 802.15.4 - yes.  And neither are 802.11, LTE, USB, 
Bluetooth4.0 to name a few that I know well - yet there are adaptation 
layers for each towards EthernetII headers.  Why is 802.15.4 different?

Dispatch byte 0x41 of Dispatch Type and Header of RFC4944 - I dont find 
it in the dumps of http://svn.tools.ietf.org/svn/wg/6lowpan/packets/

The other thread - let's see.

Yours,

Alex

Le 26/06/2015 19:01, Robert Cragie a écrit :
> Hi Alex,
>
> Further comments inline, bracketed by <RCC3></RCC3>. I don't think we
> are making a lot of progress on this thread and the other thread which
> Paul Duffy started is probably more worthwhile. So I'll blink first - in
> other words, this is my last post in this thread.
>
> Robert
>
> On 26 June 2015 at 15:26, Alexandru Petrescu
>     That is one kind of relationship.  This kind of relationship should
>     be optional - one must have an option of deriving, or not deriving,
>     an IPv6 address from a MAC address.  That is for privacy protection
>     against attackers who make associations.
>
>     'address mapping' is described in sections 6 and 7 of RFC2464
>     (unicast and mc).
>
>     For example, RFC2464 section 6 gives an encoding format of a 48bit
>     MAC address into a Source or Target ll address (these are used in
>     ND).  Or, RFC6282 defines 16bit MAC addresses yet it does not give a
>     means to encode a 16bit MAC address into a Source or Target ll
>     address.  Why so?
>
>
> 802.15.4 Networks", i.e. the title of RFC4944 (6LoWPAN). This document
> has been updated by RFC6282, which describes in section 3.2.2. how you
> form an IID. This is then used to form an IPv6 address as described in
> RFC4862</RCC3>
>
>
>
>     No, I disagree with this logic.  An ICMPv6 packet should be -
>     optionally - carried by an IPv6 Base Header.  In some 15.4
>     deployments it may  be carried by a 6lowpan header but in other 15.4
>     deployments it may be carried by an IPv6 Base Header.
>
>
> <RCC3>Maybe but our example uses the 6LoWPAN standard. Even if you
> really wanted to carry an IPv6 packet verbatim (i.e. without header
> compression) in an IEEE 802.15.4 network, it would be sensible to
> precede it with the 6LoWPAN IPv6 dispatch byte as defined in RFC4944. To
> my knowledge, RFC4944 and its updating documents is the only
> IETF-endorsed way to carry IPv6 packets over an IEEE 802.15.4 network.
> Of course anyone could come up with something different but there
> doesn't seem to be much point in doing so.<RCC3>
>
>
>
>     picture.  If you want my oppinion - that RFC6775 also requires
>     header compression and I disagree mandating it.  I think ND can run
>     on 15.4 and other low-power links - optionally - without header
>     compression.
>
>
> <RCC3>Of course it can, as explained above, but you will be wasting a
> lot of bytes, which is normally pretty costly on these sort of networks
> - which is why we do the header compression in the first place.</RCC3>
>
>
>     YEs - EtherType for LOWPAN_IPHC.  This EtherType should be in a
>     field of an LLC header.  This LLC header could sit on top of a 15.4
>     header or on top of a 802.11DataHeader.
>
>     How can I clarify?
>
>
> <RCC3>EtherType for LOWPAN_IPHC would sit on top of, er, LOWPAN_IPHC?
> Not 802.15.4. Maybe we have our tops and bottoms the wrong way up :-).
> "On top" to me means "encapsulates". Anyway, not much point in
> discussing this further.</RCC3>
>
>
>
>         [snip]
>
> <RCC3>You could ask the current SCMaint chair, Pat Kinney
> ([email-masked]
> <mailto:[email-masked]>)</RCC3>
>
>
>     And, do you think that LLC could play the role of an LLC header on
>     top of a 15.4 header?
>
>
>     I am saying in the capture above there is no LLC header between 3
>     and 4.  Do you agree?
>
>     I am not talking about what is put on the ether or not.  I am
>     talking about the absence of an LLC header between 3 (15.4) and 4
>     (6LoWPAN).
>
>
> mentioned in 6LoWPAN. Now there may be some sense in adapting
> 6LOWPAN_IPHC to take advantage of other MAC/PHYs using some sort of LLC
> - and that is being discussed on the other thread. But that is a
> different discussion as far as I can see.</RCC3>
>
>
>
>     Agree with the description but I disagree they use 0x809a.  Even if
>     it is not put in the wire, this use creates a local incompatibility
>     between processes on the same machine.
>
>     Here we can discuss.  That 0xffff is agreed by IEEE to be a
>     broadcast address?
>
>     Is IEEE agreeing that broadcast is the right way to work in
>     constrained networks, or should it rather be multicast?
>
>
> <RCC3>802.15.4 only supports broadcasting. We did consider proper
> multicast at one point but it was never put in the spec.</RCC3>
>
>
>     constrained devices and came up with 48bit-MAC multicast addresses
>     and MAC multicast concepts.
>
>     all-nodes, 0x3302 for all-hosts, 0x3303 for all-routers.  Do these
>     16bit multicast addresses exist at IEEE?  If yes, we could propose
>     mappings between these and IPv6 multicast addresses.  If no, we
>     could request IEEE to make them first and then we do the mappings.#
>
>
>     What I mean is when there is no IPHC header, there should be an
>     option to run uncompressedIPv6BaseHEader on LLC on 15.4.
>
>
>     In some cases it is good to adapt IPv6 to 15.4 by involving a
>     6lowpan header.
>
>     But I claim in other cases that may be complex compared to simpler
>     and has some negative influence on end-to-end reachability,
> <RCC3>Feel free to write another draft. If there is already a standard,
> I prefer the "don't re-invent the wheel" approach rather than the
> <RCC3>Already covered by 6LoWPAN as explained above - replace "LLC
> Header" with "IPv6 dispatch byte"</RCC3>
>