Re: [6tisch] Question on draft-ietf-6lo-routing-dispatch-00

[Tengfei Chang <[e-mail]>]

Hi Pascal,

Thanks for the replies! And thanks a lot for the slides! That's exactly the
thing what we are looking for!

The IPv6ExT is IPv6 Extension Header with the value of 7 of EID which
indicate the following IPv6 Header(IPHC).

I misunderstood IPinIP-6LoRH since I saw the first sentence of section 8
where it says: *The IP-in-IP 6LoRH (IPinIP-6LoRH) is an Elective 6LoWPAN
Routing **Header that provides a compressed form for the encapsulating
IPv6 **Header in the case of an IP-in-IP encapsulation.*

This confused me a little bit since it was called Routing Header (I was
thinking the source routing header) but, yes, it explained that it's being
used for compressing form for encapsulating IPv6 Header. Is here any
different concept for routing header?

Anyway, with the reply we are understanding now what IPinIP 6LoRH stands
for. Thanks a lot for the answering!

Cheer,
Tengfei


On Wed, Jan 6, 2016 at 3:46 PM, Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hello TengFei : )
>
>
>
> I hope you’re doing good!
>
>
>
> Please see below:
>
> 1. in section 4.2, second paragraph:
>
> *One or more 6LoRHs MAY be placed in a 6LoWPAN packet and MUST always*
>
> *be placed before the LOWPAN_IPHC [RFC6282].*
>
>
>
> What's the situation when Ip-in-Ip encapsulation structure was used?
>
>
>
> <pascal>
>
> The idea is that the original IPv6 packet that may eventually fly over the
> internet or has come from the Internet should be encoded using RFC6282.
> There may be IP in IP in there but then the RPL routers would not see the
> inner IP.
>
> When that packet traverses the RPL network, headers may need to be added
> or removed. If so, anything that needs to be added or removed in the life
> of the packet by a node that is not source or destination must be placed in
> an IP in IP using 6LoRH
> https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch-00#section-8,
> and the 6LoRH must be placed before the IPHC. There’s no a comprehensive
> study of that here
> https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-02 thanks to
> the efforts of the RPL chairs.
>
> </pascal>
>
>
>
>
>
> 2. section 8: IP-in-IP 6LoRH first paragraph:
>
> *The IP-in-IP 6LoRH (IPinIP-6LoRH) is an Elective 6LoWPAN Routing*
>
> *Header that provides a compressed form for the encapsulating IPv6*
>
> *Header in the case of an IP-in-IP encapsulation.*
>
>
>
> According to the description, it the IPinIP-6LoRH is a combination of
> IPHC+RH3 but in a compressed format?
>
> <pascal>
>
> No, TengFei. The IP in IP 6lorh encodes the outer IP header that must be
> placed to encapsulate. RH3 is encoded as a series of 6Lorhs as described in
> https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch-00#section-6
>
> </pascal>
>
>
>
> For example: following is the format of packet containing routing header
> which defined in old draft using an Ip-in-Ip encapsulation:
>
> MACheader + IPHC + RH3 + IPv6ExT + IPHC + ICMPv6
>
>
>
> If we are using the 6LoRH, will it turns to :
>
> MACheader + Paging Dispatch(page 1) + IPinIP-6LoRH + IPv6ExT + IPHC +
> ICMPv6
>
>
>
> Is this correct? If not, what it should be? Thanks!
>
>
>
>
>
> <pascal>
>
> Not really:
>
> 1)      The RH3 is expressed as a series of 6LoRH after the IP in IP, one
> 6LoRH per group of contiguous addresses that are compressed to the same
> size Please look at slide 10 in
> https://www.ietf.org/proceedings/94/slides/slides-94-6lo-2.pdf
>
> 2)      What is the IPv6Ext? The only header that RPL may add there is
> RPI in HbH, compressed by 6loRH. And Actually I’d place it before the RH.
> Anything that is not compressed by 6LoRH has to be compressed by RFC 6282
> and must be placed after the IPHC
>
>
>
> <pascal>
>
>
>
> You two take care,
>
>
>
> Pascal
>
>
>
>
>
>
>