Subject: [6lo] #16 (routing-dispatch): Behaviour with encapsulated LOWPAN_IPHC

From: "6lo issue tracker" <[email-masked]>
Date: Thu, 04 Feb 2016 11:56:34 -0000

#16: Behaviour with encapsulated LOWPAN_IPHC

 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.  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.  Any
             remaining bits are zero.

 Cheers,

 Pascal

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

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-6lo-routing-
  [email-masked]     |  [email-masked]
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:
Component:  routing-     |    Version:
  dispatch               |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/16>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Thu, 04 Feb 2016 11:56:59 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]
 * status:  new => assigned

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  enhancement         |      Status:  assigned
 Priority:  major               |   Milestone:
Component:  routing-dispatch    |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/16#comment:1>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Thu, 04 Feb 2016 13:38:26 -0000

Comment (by [email-masked]):

 From: Pascal Thubert (pthubert)
 Sent: jeudi 4 février 2016 13:11
 To: Xavier Vilajosana <[email-masked]>; [email-masked]
 Cc: [email-masked]
 Subject: RE: [6tisch] 6LoRH: compression of the inner destination

 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

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/16#comment:2>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Sun, 07 Feb 2016 14:56:03 -0000

* status:  assigned => closed
 * resolution:   => fixed

Comment:

 From: Pascal Thubert (pthubert)
 Sent: dimanche 7 février 2016 15:55
 To: 'Xavier Vilajosana' <[email-masked]>
 Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
 Subject: RE: [6tisch] 6LoRH: compression of the inner destination

 We could and probably should, Xavi,

 but this will take a different (quick) draft that updates RFC6282.

 Let us start one and see if the group likes the idea.

 In the meantime I gather that I can close ticket 16 with the text below…

 Take care,

 Pascal

 From: [email-masked] [mailto:[email-masked]] On Behalf Of
 Xavier Vilajosana
 Sent: samedi 6 février 2016 05:55
 To: Pascal Thubert (pthubert) <[email-masked]>
 Cc: [email-masked]; [email-masked]
 Subject: Re: [6tisch] 6LoRH: compression of the inner destination

 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-masked]>:
 Hello Xavi:

 “

 “

 Is that any clearer now?

 Take care,

 Pascal

 From: 6lo [mailto:[email-masked]] On Behalf Of Pascal Thubert
 (pthubert)
 Sent: jeudi 4 février 2016 11:10
 To: Xavier Vilajosana <[email-masked]>; [email-masked]
 Cc: [email-masked]
 Subject: Re: [6lo] [6tisch] 6LoRH: compression of the inner destination

 Hello Xavi:

 The short answer

 The long answer:

 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.

 I hope this helps : )

 Pascal

 If SAC=1:

 <...>

 <...>

 <...>

 If M=0 and DAC=1:

 Cheers,

 Pascal

 Dear Pascal,

 regards,
 X

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  enhancement         |      Status:  closed
 Priority:  major               |   Milestone:
Component:  routing-dispatch    |     Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/16#comment:3>
6lo <https://tools.ietf.org/6lo/>