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

[Richard Kelsey <[e-mail]>]

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 [[e-mail]]
Sent: Monday, June 30, 2014 5:41 AM
To: [e-mail]
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: <[e-mail]<mailto:[e-mail]>>
Date: Fri, Jun 27, 2014 at 11:12 AM
Subject: New Version Notification for draft-toutain-6lo-local-extensions-00.txt
To: Laurent Toutain <[e-mail]<mailto:[e-mail]>>



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: [phone]    | Tel: + 33 2 99 12 7026                 | Visit :
| Mob: [phone]    |                                        |
| Fax: [phone]    | Fax: [phone]                  |  http://class.touta.in
| [e-mail]         | [e-mail]    |
+--------------------------+----------------------------------------+
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.