Subject: [Roll] Comments on RPL packets (from wireshark dumps)

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2010 17:53:03 +0200

Comments on RPL packets (from wireshark dumps).

Generally speaking I support implementations and this kind of dump to 
get reflected in the spec.

- wireshark shows RPL packets as:
   "RPL Control Message (DODAG Information ...)"

- Packets in wireshar-rpl-dio-prefix.pcap contain the following
   distinct headers:

   Ethernet
   IPv4
   UDP
   ZigBee Encapsulation Protocol
   IEEE 802.15.4 Data
   6LoWPAN IPHC
   IPv6 base header
   ICMPv6 (type 155 RPL control message)

   This means this might be an RPL emulator running above UDPv4?

   Hop Limit field is 255, but the RPL-12 spec does
   not specify a value for this field - I think the spec should specify
   a value for the Hop Limit field.

   Additionally, the RPL-12 spec specifies that the Hop Limit field must
   be decremented when forwarding: do we witness forwarding here or
   not?  If not, then non decrementing the Hop Limit is ok, but we
   should say that this RPL is _not_ forwarding.

- Packets in rpl_11.pcap show as a stacking:

   Ethernet II
   IEEE 802.15.4 Data
   6LoWPAN IPHC Header
   IPv6 base header
   ICMPv6 Type 155 RPL Control message

   This looks less of an emulator.

   It is strange to see an Ethernet II header preceding the IEEE
   802.15.4 Data.  To see fake MAC addresses in
   the Ethernet II header ("af:ab:ac:ad:ae:af") and the Unknown Ethernet
   II Type 0x809a: it should be 0x86dd for IPv6.  These doubts make
   think this is still an emulator(?)

   There is a DODAG Information Solicitation whose dst address is a link
   local unicast address (fe80::ff:fe00:1122); but the RPL-12 spec says
   that the dst address of a DODAG Info Sol is a multicast address.  Who
   should be right?

   (besides, as I discover RPL-12 changed the rule of all RPL-11
    messages being link-local multicast - its _only_ exception is
    DAO/DAOAck.)

    RPL-11 says the DIS (DODAG IS) message has an 8bit Flags field, but
    this dump doesn't seem to have this Flags field.

    The timeline of packets in this dump shows the packets happen very
    quickly, every 500ms or so; this gives an idea of time scale.

There are many other aspects in this dump that I would like to comment on.

Alex

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 6 Oct 2010 17:25:13 +0100

Hi Alexandru,

The dumps there do not reflect the true RPL-12 state, they were more just
examples to demonstrate the Wireshark dissectors. So they could have been
generated illegally with the sole intention of making packets which exercise
the dissectors. 

In both cases they are true captures. The lower layer stuff is just ways of
getting packets into Wireshark. So for the second example (rpl_11.pcap) the
capture hardware is jamming raw 802.15.4 packets into Ethernet solely so
Wireshark can pick up on them. The special ethtype is used by Wireshark to
pick off these packets. The actual IPv6 stuff is reconstructed from the
6lowpan dissectors.

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: October 6, 2010 4:53 PM
To: ROLL WG
Subject: [Roll] Comments on RPL packets (from wireshark dumps)

   Ethernet
   IPv4
   UDP

   Ethernet II
   IEEE 802.15.4 Data
   6LoWPAN IPHC Header
   IPv6 base header

Alex

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2010 18:43:35 +0200

Le 06/10/2010 18:25, Colin O'Flynn a écrit :
> Hi Alexandru,
>
> The dumps there do not reflect the true RPL-12 state, they were more
> just examples to demonstrate the Wireshark dissectors. So they could
> have been generated illegally with the sole intention of making
> packets which exercise the dissectors.
>
> In both cases they are true captures. The lower layer stuff is just
> ways of getting packets into Wireshark. So for the second example
> (rpl_11.pcap) the capture hardware is jamming raw 802.15.4 packets
> into Ethernet solely so Wireshark can pick up on them. The special
> ethtype is used by Wireshark to pick off these packets. The actual
> IPv6 stuff is reconstructed from the 6lowpan dissectors.

Do you mind if one sets the Hop Limit 254 in RPL packets?  Spec doesn't
tell what number to put there, and these dumps use 255.

Alex

>
> -Colin
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> October 6, 2010 4:53 PM To: ROLL WG Subject: [Roll] Comments on RPL
> packets (from wireshark dumps)
>
> - wireshark shows RPL packets as: "RPL Control Message (DODAG
> Information ...)"
>
> Ethernet IPv4 UDP ZigBee Encapsulation Protocol IEEE 802.15.4 Data
> 6LoWPAN IPHC IPv6 base header ICMPv6 (type 155 RPL control message)
>
> Hop Limit field is 255, but the RPL-12 spec does not specify a value
> for this field - I think the spec should specify a value for the Hop
> Limit field.
>
> be decremented when forwarding: do we witness forwarding here or not?
> If not, then non decrementing the Hop Limit is ok, but we should say
> that this RPL is _not_ forwarding.
>
>
> Ethernet II IEEE 802.15.4 Data 6LoWPAN IPHC Header IPv6 base header
> 802.15.4 Data.  To see fake MAC addresses in the Ethernet II header
> ("af:ab:ac:ad:ae:af") and the Unknown Ethernet II Type 0x809a: it
> should be 0x86dd for IPv6.  These doubts make think this is still an
> emulator(?)
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>