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

From: Laurent Toutain <[email-masked]>
Date: Mon, 30 Jun 2014 11:41:45 +0200

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: <[email-masked]>
Date: Fri, Jun 27, 2014 at 11:12 AM
Subject: New Version Notification for
draft-toutain-6lo-local-extensions-00.txt
To: Laurent Toutain <[email-masked]>

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.

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
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Jun 2014 09:56:16 +0000

Hi Laurent:

I love the idea of separating the LLN artifacts from the end to end packet. With the proposal
You LE looks very much like the routing dispatch that would be the RPL pendant to the mesh dispatch.

This proposal can help solve 3 problems:
- one is the cost of the HbH header (plus encaps) for which I have a proposal based on flow label
- the second is the compression of the routing header in non-storing mode
- the third is the independent routing of 6LoWPAN fragments, since the L3 destination can be placed in the LE with every datagram.

I hope the proposal progresses and hope you can present in Toronto : )

Cheers,

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Laurent Toutain
Sent: lundi 30 juin 2014 11:42
To: [email-masked]
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: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Jun 27, 2014 at 11:12 AM
Subject: New Version Notification for draft-toutain-6lo-local-extensions-00.txt
To: Laurent Toutain <[email-masked]<mailto:[email-masked]>>

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:

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
| [email-masked]<mailto:[email-masked]>         | [email-masked]<mailto:[email-masked]>    |
+--------------------------+----------------------------------------+

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 30 Jun 2014 15:53:12 +0000

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 [[email-masked]]
Sent: Monday, June 30, 2014 5:41 AM
To: [email-masked]
Subject: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-extensions-00.txt

Hi,

Thanks

Laurent

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Jun 27, 2014 at 11:12 AM
Subject: New Version Notification for draft-toutain-6lo-local-extensions-00.txt
To: Laurent Toutain <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

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.