Re: [Roll] [6lo] RPL artifact compression discussion

The best way I can think of is to show what Wireshark shows:

6LoWPAN
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version,
traffic class, and flow label compressed (0x0003)
        .... .1.. .... .... = Next header: Compressed
        .... ..00 .... .... = Hop limit: Inline (0x0000)
        .... .... 0... .... = Context identifier extension: False
        .... .... .0.. .... = Source address compression: Stateless
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 0... = Multicast address compression: False
        .... .... .... .0.. = Destination address compression: Stateless
        .... .... .... ..11 = Destination address mode: Compressed (0x0003)
        [Source context: fe80:: (fe80::)]
        [Destination context: fe80:: (fe80::)]
    Hop limit: 255
    Source: fe80::ff:fe00:3344 (fe80::ff:fe00:3344)
    Destination: fe80::ff:fe00:1122 (fe80::ff:fe00:1122)
    IPv6 extension header
        1110 .... = Pattern: IPv6 extension header (0x0e)
        .... 000. = Header ID: IPv6 hop-by-hop options (0x00)
        .... ...1 = Next header: Compressed
        Header length: 6
        Data (6 bytes)

0000  63 04 00 01 00 02                                 c.....
    IPv6 extension header
        1110 .... = Pattern: IPv6 extension header (0x0e)
        .... 111. = Header ID: IPv6 header (0x07)
        .... ...0 = Next header: Inline
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version,
traffic class, and flow label compressed (0x0003)
        .... .0.. .... .... = Next header: Inline
        .... ..00 .... .... = Hop limit: Inline (0x0000)
        .... .... 0... .... = Context identifier extension: False
        .... .... .1.. .... = Source address compression: Stateful
        .... .... ..10 .... = Source address mode: 16-bits inline (0x0002)
        .... .... .... 0... = Multicast address compression: False
        .... .... .... .1.. = Destination address compression: Stateful
        .... .... .... ..10 = Destination address mode: 16-bits inline
(0x0002)
        [Source context: 2002:db8:: (2002:db8::)]
        [Origin: 144]
        [Destination context: 2002:db8:: (2002:db8::)]
        [Origin: 144]
    Next header: ICMPv6 (0x3a)
    Hop limit: 63
    Source: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:5566)
    Destination: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122)
Internet Protocol Version 6, Src: fe80::ff:fe00:3344 (fe80::ff:fe00:3344),
Dst: fe80::ff:fe00:1122 (fe80::ff:fe00:1122)
Internet Protocol Version 6, Src: 2002:db8::ff:fe00:5566
(2002:db8::ff:fe00:5566), Dst: 2002:db8::ff:fe00:1122
(2002:db8::ff:fe00:1122)

Not sure if that helps but at least you should be able to work through it.
In essence, in this particular case (ZigBee IP going up the DODAG), it
looks like:

| IPHC outer, NHC = RPI | RPI, NHC = IPV6 | IPHC inner, NH inline | ICMPv6
| Payload |

There is the following text at the end of section 4.2 in RFC6282:

"When the identified next header is an IPv6 Header (EID=7), the NH bit of
the LOWPAN_NHC encoding is unused and MUST be set to zero.  The following
bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3."

This allows IP-in-IP using IPHC compression.

Robert

On 23 March 2015 at 22:48, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>
> Robert Cragie <robert.cragie@gridmerge.com> wrote:
>     > <RCC>There is - it's IPHC. You can use IPHC twice as we discussed in
>     > the recent call.</RCC>
>
> Thank you for your reply, and reminding me that I didn't followup with you
> on
> this question.   So, I'm not really sure how you signal this.
>
> This is what I see at this time:
>
> 15.4 header stuff.
> Dispatch    = LOWPAN_IPHC (0b1110 111N).      (rfc6282. section 4/5)
>             here we want to put another compress header, so N=1.
>             base format, with "NH=1"
>                  NHC_1=0b1110 EID NH      EID=5,NH=1
>             = here we would have RPI
>                  NHC_2=???
>
> Now if NHC_2 = 7, then an IPIP header follows.
> If the NHC_1's NH=0, then an entire byte follows for something that
> doesn't fit into the EID (e.g. IPsec ESP).
>
> I don't know I signal that what follows the RPI isn't an IPv6 header
> (uncompressed), but rather another LOWPAN_IPHC.
>
> Maybe you have a better way of presenting this detail.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>