Subject: [6lo] #11 (routing-dispatch): RH3 6LoRH not recoverable

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:24:08 -0000

#11: RH3 6LoRH not recoverable

 Point made by Simon and then Anand:

 Simon:

 From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert
 (pthubert)
 Sent: vendredi 22 janvier 2016 18:04
 To: [email-masked]
 Subject: [6tisch] Minutes, 22 January 2016 interim, 6TiSCH WG

 •  [07.04] Meeting starts
 • [07.07] Administrivia [2min]
 • Approval agenda
 • Simon: about slide 11 removing addresses as you go is good. But how
 interoperable with RFC6554? all addresses are in RFC6554? Would expect
 from 6LoRH to compress existing 6554 headers.
 • Pascal: you can reconstruct an RH3 from 6LoRH, but it will not be the
 same one as if you
 • Michael: important for efficiency. It's possible to deploy nodes with
 6LoRH but not turn it on (manageable)
 • why does it matter?
 • Simon: in the routing header, the addresses are not consumed

 Anand:

 From: S.V.R.Anand [mailto:[email-masked]]
 Sent: samedi 23 janvier 2016 09:36
 To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
 Cc: [email-masked]; Routing Over Low power and Lossy networks
 <[email-masked]>
 Subject: Re: [6tisch] Proposed improvement in RH3-6LoRH

 Hi Pascal,

 The source routing optimization done by dropping the addresses on the way
 certainly has benefits. However, there could be loss of a natural
 "symmetric"
 property that one might want to enforce between communicating end nodes in
 the
 routing path. By symmetry I mean using the same path in both the
 directions of
 communication. Policy based routing, centralized routing, for instance,
 could
 be potential users of this property. May be this does not represent a
 common
 use case. But nevertheless, we have to be aware of this side effect which
 RFC6554
 swapping process does not have.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-6lo-routing-
  [email-masked]     |  [email-masked]
     Type:  defect       |     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/11>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:24:52 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

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

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

---

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:25:56 -0000

Comment (by [email-masked]):

 Proposed addition:

 5.2.  The Design Point of Popping Entries

    In order to save energy and to optimize the chances of transmission
    success on lossy media, it is a design point for this specification
    that the entries in the RH3 that have been used are removed from the
    packet.  This creates a discrepancy from the art of IPv6 where
    Routing Header are mutable but recoverable.

    With this specification, the packet can be expanded at any hop into a
    valid IPv6 packet, including a RH3, and compressed back.  But the
    packet as decompressed along the way will not carry all the consumed
    addresses that packet would have if it had been forwarded in the
    uncompressed form.

    It is noted that:

       The value of keeping the whole RH in an IPv6 header is for the
       receiver to reverse it to use the symmetrical path on the way
       back.

       It is generally not a good idea to reverse a routing header.  The
       RH may have been used to stay away from the shortest path for some
       reason that is only valid on the way in (segment routing).

       There is no use of reversing a RH in the present RPL
       specifications.

       P2P RPL reverses a path that was learned reactively, as a part of
       the protocol operation, which is probably a cleaner way than a
       reversed echo on the data path.

       Reversing a header is discouraged by [RFC2460] for RH0 unless it
       is authenticated, which requires an Authentication Header (AH).
       There is no definition of an AH operation for RH3, and there is no
       indication that the need exists in LLNs.

       It is noted that AH does not protect the RH on the way.  AH is a
       validation at the receiver with the sole value of enabling the
       receiver to reversing it.

       A RPL domain is usually protected by L2 security and that secures
       both RPL itself and the RH in the packets, at every hop.  This is
       a better security than that provided by AH.

    In summary, the benefit of saving energy and lowering the chances of
    loss by sending smaller frames over the LLN are seen as overwhelming
    compared to the value of possibly reversing the header.

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