Subject: [Roll] 6LoRH type in useofRPLinfo

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jul 2019 14:06:33 +0000

Dear all

Reviewing again https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25 I think we made a mistake in Fig 3:

The format of RFC 8138 compressed packet is presented as:

   +--+-----+---+--------------+-----------+-----------+-----------+
   |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI-6LoRH |LOWPAN IPHC|
   +--+-----+---+--------------+-----------+-----------+-----------+

But it should really be as fig 20 in RFC 8138, meaning the RPI is before the IP-in-IP:

+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...

 |11110001|SRH-6LoRH| RPI-  | IP-in-IP | NH=1      |11110CPP| UDP | UDP

 |Page 1  |Type1 S=2| 6LoRH |  6LoRH   |LOWPAN_IPHC| UDP    | hdr |Payld

 +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...

            <-8bytes->                  <-        RFC 6282<https://tools.ietf.org/html/rfc6282>      ->

                                                No RPL artifact

               Figure 20: Example Compressed Packet with SRH

Data is removed from the left as consumed. Removing the IP-in-IP removes everything left of it including RPI.
What gets forwarded to the unaware leaf starts at the LOWPAN_IPHC.
What's worth noting is that in Storing Mode the SRH contains the address of the 6LR that decapsulates.
IOW the SRH encodes the destination of IP-in-IP, whereas the root is the source so the encapsulator in the IP-in-IP 6LoRH is elided...

All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jul 2019 14:14:35 +0000

Dear all

Actually since there is only one entry in the SRH the drawing in fig 20 of RFC 8138 must be adapted for a size of 0 (meaning 1 entry) and a total length of 4 octets.

 |Page 1  |Type1 S=0| 6LoRH |  6LoRH   |LOWPAN_IPHC| UDP    | hdr |Payld

          <-4bytes->                    <-        RFC 6282<https://tools.ietf.org/html/rfc6282>      ->

                                                No RPL artifact

All the best,

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 2 juillet 2019 16:07
To: 'Routing Over Low power and Lossy networks' <[email-masked]>
Subject: 6LoRH type in useofRPLinfo

Dear all

                                                No RPL artifact

All the best,

Pascal

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 3 Jul 2019 14:58:38 -0700

Pascal:

We’re already at version -30.  Please take a look at the text there — the
figure in the corresponding section (§4.3) now looks like this:

 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...
 |11110001| RPI-  | IP-in-IP | NH=1        |11110CPP| Compressed | UDP
 |Page 1  | 6LoRH |  6LoRH   | LOWPAN_IPHC | UDP    | UDP header | Payld
 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...

Is that correct?  If not, please provide an update.

I am getting ready to approve this document.  I am changing the state
to “Revised-ID Needed” — let me know if a change is not needed.

Thanks!

Alvaro.

On July 2, 2019 at 10:14:53 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

Dear all

Actually since there is only one entry in the SRH the drawing in fig 20 of
RFC 8138 must be adapted for a size of 0 (meaning 1 entry) and a total
length of 4 octets.

          <-4bytes->                    <-        RFC 6282
<https://tools.ietf.org/html/rfc6282>      ->

                                                No RPL artifact

All the best,

Pascal

*From:* Pascal Thubert (pthubert)
*Sent:* mardi 2 juillet 2019 16:07
*To:* 'Routing Over Low power and Lossy networks' <[email-masked]>
*Subject:* 6LoRH type in useofRPLinfo

Dear all

Reviewing again https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25
I think we made a mistake in Fig 3:

But it should really be as fig 20 in RFC 8138, meaning the RPI is before
the IP-in-IP:

            <-8bytes->                  <-        RFC 6282
<https://tools.ietf.org/html/rfc6282>      ->

                                                No RPL artifact

Data is removed from the left as consumed. Removing the IP-in-IP removes
everything left of it including RPI.

What’s worth noting is that in Storing Mode the SRH contains the address of
the 6LR that decapsulates.

IOW the SRH encodes the destination of IP-in-IP, whereas the root is the
source so the encapsulator in the IP-in-IP 6LoRH is elided…

All the best,

Pascal

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

---

From: Ines Robles <[email-masked]>
Date: Thu, 4 Jul 2019 16:17:30 +0300

Dear all,

Version 31 adds more clarification on this item.

Thank you very much Pascal for improving the document.

Best regards,

Ines.

On Tue, Jul 2, 2019 at 5:07 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Dear all
>
>
>
> Reviewing again
> https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25 I think we
> made a mistake in Fig 3:
>
>
>
>             <-8bytes->                  <-        RFC 6282 <https://tools.ietf.org/html/rfc6282>      ->
>
>                                                 No RPL artifact
>
>
>
> What’s worth noting is that in Storing Mode the SRH contains the address
> of the 6LR that decapsulates.
>