I see TengFei: The text means a header that is used for the purpose of routing, not necessarily a source route header like an IPv6 RH…
Take care, Pascal From: Tengfei Chang [mailto:[email protected]] Sent: mercredi 6 janvier 2016 16:43 To: Pascal Thubert (pthubert) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Question on draft-ietf-6lo-routing-dispatch-00 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) <[email protected]<mailto:[email protected]>> 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
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
