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]] On Behalf Of Xavier Vilajosana
Sent: mercredi 3 février 2016 11:49
To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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
