Dear Pascal, thanks for your answer this is very clear, but could we address stateless address compression if the inner and outer source addresses share the same IID? I can think in cases where we do not have a context but we can infer the IID of the source in the inner header from the IID of the source in the outer header.
regards, Xavi 2016-02-04 13:12 GMT+01:00 Pascal Thubert (pthubert) <[email protected]>: > Hello Xavi: > > > > Let me propose the following update to the draft to clarify this: > > > > “ > > > > > > > > Inner LOWPAN_IPHC Compression > > > > 6LoWPAN ND {{RFC6282}} is designed to support more than one IPv6 address > > per node and per Interface Identifier (IID), an IID being typically derived > > from a MAC address to optimize the LOWPAN-IPHC compression. > > > > Link local addresses are compressed with stateless address compression > (S/DAC=0). > > The other addresses are derived from different prefixes and they can be > compressed > > with stateful address compression based on a context (S/DAC=1). > > > > But stateless compression is only defined for the specific link-local > prefix as > > opposed to the prefix in an encapsulating header. And with stateful > compression, > > the compression reference is found in a context, as opposed to an > encapsulating > > header. > > > > It results that in the case of an IP-in-IP encapsulation, it is possible to > > compress an inner source (respectively destination) IP address in a > LOWPAN_IPHC > > based on the encapsulating IP header only if stateful (context-based) > compression > > is used. The compression will operate only if the IID in the source > (respectively > > the destination) IP address in the outer and inner headers match, which > usually > > means that they refer to the same node . This is encoded as S/DAC = 1 and > S/AM=11. > > It must be noted that the outer destination address that is used to > compress the > > inner destination address is the last entry in the last RH3-6LoRH header. > > > > “ > > > > Is that any clearer now? > > > > Take care, > > > > Pascal > > > > *From:* 6lo [mailto:[email protected]] *On Behalf Of *Pascal Thubert > (pthubert) > *Sent:* jeudi 4 février 2016 11:10 > *To:* Xavier Vilajosana <[email protected]>; [email protected] > *Cc:* [email protected] > *Subject:* Re: [6lo] [6tisch] 6LoRH: compression of the inner destination > > > > Hello Xavi: > > > > Yes, this deserves more clarification, thanks for pointing it out. > > > > Your question applies so source and destination, and is really whether we > can compress the address in the IPHC based on what is found in a 6LoRH > header. > > > > The short answer > > > > a) you cannot do that statelessly (damn sad, need to fix), and > > b) you can do a little something statefully if > > 1) you have a **context** and > > 2) the source (and / or destination) in the inner IP header and that in > the outer header refer to **the same node**, in which case the source > (and / or destination) in the inner header can be fully compressed. > > > > I can add text if that helps. > > > > The long answer: > > > > > > RFC6282 is geared to support more than one IPv6 addresses, one that is > link local (S/DAD=0) for use within radio range, and then several ones > derived from different prefixes using context information (S/DAC=1). All > these address are expected to have with a same IID, derived from the MAC > address (twice that if you have a short and a long MAC address). This > compression allows for a node to be the destination of an outer IP > encapsulation with one prefix, and the destination of an inner IP header > with another prefix, both addresses based on the same IID. This can make > sense for a LLN border router, for instance. > > > > Sadly RFC6282 does not allow stateless compression based the encapsulating > IP header. IOW, stateless only works with the link-local prefix as opposed > to the prefix in the encapsulating header. Since encapsulating a link-local > address is useless, we could have specified stateless a bit differently, > e.g. that the implicit prefix is the FE80:: if and only if IPHC is used for > an outermost IP header, and that it is the prefix from the encapsulation > otherwise. But that is another discussion, since it involves an update of > RFC6282 which would have to be a separate document. If we want to pursue > that other discussion we’ll have to follow up as a different thread / draft > at 6lo. Let me know if you think there is interest there (I do). > > > > So: with the current specs, you can compress an inner (source/destination) > IP address in the LOWPAN_IPHC **based on the encapsulating IP header**** > in a 6LoRH-encoded header if and only if the address is: > > - an exact match with a context entry for the prefix length > associated with that context, > > - and then the remainder from the corresponding > (source/destination) IP address in the encapsulating header matches that of > the encapsulated header, which in 6LoWPAN networks can be interpreted as > “same node” though in the IPv6 theory it does not have to be. > > > > So for now the only thing you can do is have a context. One context would > be for the root. > > > > An example: If all the addresses in the LLN derive from the prefix of the > root with a /112 and the short MAC address. If there is a context where > that prefix/length is encoded, and that is signaled implicitly or > explicitly in the LOWPAN_IPHC. If there is an IP-in-IP encapsulation > encoded with IP-in-IP-6LoRH, and the final destination in the IPHC is the > same as the last entry in the last RH3-6LoRH, then the destination address > in the IPHC can be fully elided by using DAC=1 and DAM=11. The packet will > reach the destination in the encapsulated form, and then the packet will be > decapsulated before going up the stack. > > > > I hope this helps : ) > > > > Pascal > > > > PS This discussion leverages RFC 6282 says this: > > > > SAM: Source Address Mode: > > > > If SAC=1: > > > > <...> > > > > 11: 0 bits. The address is fully elided and is derived using > > context information and the encapsulating header (e.g., > > 802.15.4 or IPv6 source address). Bits covered by context > > information are always used. Any IID bits not covered by > > context information are computed from the encapsulating > > header as specified in Section 3.2.2 > <https://tools.ietf.org/html/rfc6282#section-3.2.2>. Any remaining bits > > are zero. > > > > > > <...> > > > > DAM: Destination Address Mode: > > > > <...> > > > > If M=0 and DAC=1: > > > > > > 11: 0 bits. The address is fully elided and is derived using > > context information and the encapsulating header (e.g. > > 802.15.4 or IPv6 destination address). Bits covered by > > context information are always used. Any IID bits not > > covered by context information are computed from the > > encapsulating header as specified in Section 3.2.2 > <https://tools.ietf.org/html/rfc6282#section-3.2.2>. Any > > remaining bits are zero. > > > > > > > > Cheers, > > > > Pascal > > > > *From:* 6tisch [mailto:[email protected] <[email protected]>] *On > Behalf Of *Xavier Vilajosana > *Sent:* mercredi 3 février 2016 11:49 > *To:* Pascal Thubert (pthubert) <[email protected]>; [email protected] > *Subject:* [6tisch] 6LoRH: compression of the inner destination > > > > Dear Pascal, > > > > There is something it is not clear to me. > > How do we compress the inner header destination address assuming we have > 6LoRH RH3. > > > > could you please clarify that? > > > > regards, > > X >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
