Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-extensions-00.txt

Hello Richard:

I agree with the general idea of the draft but share your concerns on its current form.

This certainly needs more work, and in particular I agree that the outer header must be present as specified in 6554.

In fact, even in the transport mode where the packet stays inside the LLN and the HbH is part of the original packet, the draft would need the header in the new dispatch, but then it could elide it completely in the classical dispatch.

What I like in the draft is the clear demarcation between the LLN artifacts and the end-to-end packet so we can play with the LLN artifact and not change the packet. Also, the draft could allow to repeat the compressed IP header on every 6LoWPAN fragment and route them individually. In that this new draft has the potential to lead to an alternate solution (to my draft!) to the known problem of routing 6LoWPAN fragments.

The final work could describe more clearly the compression of HbH and of the list of RH, again a known problem and again an alternate to a draft of mine.

OTOH there's a potential hit on frame size, since we add new stuff there's a cost associated. In particular the new header before each fragment reduces the space for the fragment - vs. my draft that uses a stateful label swap technique for the next frags to follow the first.

Cheers,

Pascal

> -----Original Message-----
> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Richard Kelsey
> Sent: lundi 30 juin 2014 17:53
> To: Laurent Toutain; 6lo@ietf.org
> Subject: Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-
> extensions-00.txt
> 
> From the draft:
> 
>    [RFC6554] defines in figure following encapsulation:
> 
>    +--------+---------+--------+-------------//-+
>    | Outer  | Source  | Inner  | IPv6           |
>    | IPv6   | Routing | IPv6   | Payload        |
>    | Header | Header  | Header |                |
>    +--------+---------+--------+-------------//-+
>                        <--- Original Packet --->
>     <---          Tunneled Packet           --->
> 
>                         Figure 1: Packet tunneling
> 
>    Outer header carries LoWPAN IP addresses of a LOWPAN node and a
>    border router and Inner header contains the source and destination.
>    This encapsulation is sub-optimal since two IP headers are needed and
>    the inner one cannot be compressed since Next Header in the Source
>    Routing header contains the IPv6 protocol as defined in [rfc2460]; no
>    reference to a 6LoWPAN dispatch is possible.
> 
> I do not think that this is true.  Section 4.2 of RFC6282 defines LOWPAN_NHC
> encodings specifically to handle this case.  You can use them to encapsulate
> the routing header and then compress the inner IPv6 header.  RFC6282
> works well enough that the adding the outer header often increases the size
> of the compressed headers by only a few bytes.
> 
> I worry about messing with RFC2460 in this way for the sake of those bytes.
> That outer IPv6 header is needed.  For example, what happens to the hop
> limit if there is no outer IPv6 header?  Does the inner header's hop limit get
> decremented?  Also, section 4.1 of RFC6554
> says:
> 
>    Using IPv6-in-IPv6 tunneling ensures that the delivered datagram
>    remains unmodified and that ICMPv6 errors generated by an SRH are
>    sent back to the router that generated the SRH.
> 
> With no outer header, where do SRH ICMPv6 errors get sent?
> 
>     -Richard Kelsey
> 
> ________________________________________
> From: Laurent Toutain [Laurent.Toutain@telecom-bretagne.eu]
> Sent: Monday, June 30, 2014 5:41 AM
> To: 6lo@ietf.org
> Subject: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-
> extensions-00.txt
> 
> Hi,
> 
> I've submitted a draft on local extensions. The goal is to avoid IPv6
> tunnelling in LoWPAN by introducing a new dispatch value which will
> describe IPv6 extensions. I would like to know if there is an interest from the
> working group for such approach and a possibility to present it at Toronto.
> 
> Thanks
> 
> Laurent
> 
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
> Date: Fri, Jun 27, 2014 at 11:12 AM
> Subject: New Version Notification for draft-toutain-6lo-local-extensions-
> 00.txt
> To: Laurent Toutain <laurent.toutain@telecom-
> bretagne.eu<mailto:laurent.toutain@telecom-bretagne.eu>>
> 
> 
> 
> A new version of I-D, draft-toutain-6lo-local-extensions-00.txt
> has been successfully submitted by Laurent Toutain and posted to the IETF
> repository.
> 
> Name:           draft-toutain-6lo-local-extensions
> Revision:       00
> Title:          6LoWPAN Local Extensions
> Document date:  2014-06-27
> Group:          Individual Submission
> Pages:          5
> URL:            http://www.ietf.org/internet-drafts/draft-toutain-6lo-local-
> extensions-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-toutain-6lo-local-
> extensions/
> Htmlized:       http://tools.ietf.org/html/draft-toutain-6lo-local-extensions-00
> 
> 
> Abstract:
>    [RFC2460] defines an extension mechanism to add functionalities to
>    the basic IPv6 header.  On LoWPAN networks, some extensions are
>    required to extend routing capabilities.  These specific extensions
>    should not leak in the global internet.  To optimize encapsulation, a
>    6LoWPAN dispatch to carry local extensions is defined.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org<http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> 
> 
> 
> --
> Laurent Toutain
> +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
> | Tel: +33 2 30 96 6312    | Tel: + 33 2 99 12 7026                 | Visit :
> | Mob: +33 6 800 75 900    |                                        |
> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
> http://class.touta.in
> | Laurent@Touta.in         | Laurent.Toutain@Telecom-Bretagne.eu    |
> +--------------------------+----------------------------------------+
> This email and any attachments may be confidential. If so, do not distribute
> or forward this email or any attachments without the sender’s
> authorization. If you are not the intended recipient, please delete this email
> and notify the sender. Email transmissions cannot be guaranteed to be
> error-free or virus-free and Silicon Labs accepts no liability for such
> transmissions. Silicon Labs does not intend or authorize emails to act as
> legally binding contracts.
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo