Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473)

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Jul 2010 14:48:58 +0300

Both of the new 6man drafts needed by RPL are requiring the use of RFC2473 IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has anyone thought out how this is going to work over a 6LoWPAN with HC?  

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Jul 2010 13:51:56 +0200

Hi Zach: 

You're right. 
It would make sense to make the slight update to compress when the inner
and outer source or destination are identical.
I do not think that this would cause any trouble with the last call that
passed already, would it?
What about making that change and pushing to IESG?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zach Shelby
> Sent: Tuesday, July 06, 2010 1:49 PM
> To: 6lowpan
> Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473)
> 
> Both of the new 6man drafts needed by RPL are requiring the use of
RFC2473
> IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has anyone
thought
> out how this is going to work over a 6LoWPAN with HC?
> 
> Zach
> 
> --
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Mark Townsley <[email-masked]>
Date: Tue, 06 Jul 2010 14:34:57 +0200

What exactly are they using the tunneling for, and is it envisioned for
a substantial amount of traffic? Enough that warrants a new compression
mode?

- Mark

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Jul 2010 14:45:02 +0200

Hi Mark:

RPL is taking the direction of IP in IP in order to insert source route
and hop by hop headers, for use within the RPL network between ingress
and egress routers. 
If the termination in the RPL side is a RPL aware node, then the outer
and the inner header would have the same address for that node and could
be compressed.
The change in HC would be very minimum, since we already have the
support for next header.

There's a consensus call at 6MAN to adopt the associated drafts
(draft-hui-6man-rpl-option and draft-hui-6man-rpl-routing-header).  

Cheers,

Pascal

> Behalf Of Mark Townsley (townsley)
> Sent: Tuesday, July 06, 2010 2:35 PM
> To: [email-masked]
> Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473)
> 
> 
> What exactly are they using the tunneling for, and is it envisioned
for a
> substantial amount of traffic? Enough that warrants a new compression
> mode?
> 
> - Mark
> 
> > It would make sense to make the slight update to compress when the
> > inner and outer source or destination are identical.
> > I do not think that this would cause any trouble with the last call
> > that passed already, would it?

Subject: Consensus call for adoption of draft-hui-6man-rpl-option anddraft-hui-6man-rpl-routing-header
From: "Brian Haberman" <[email-masked]>
To: "IPv6 WG Mailing List" <[email-masked]>
Date: Mon, 14 Jun 2010 22:17:03 +0200

All,
     This is a consensus call to determine if there is interest in
having 6MAN adopt the two RPL drafts (draft-hui-6man-rpl-option and
draft-hui-6man-rpl-routing-header).  Please state your opinion on the
mailing list by June 25th, 2010.

Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 06 Jul 2010 13:57:08 +0100

Zach and Pascal,

The outer header can be compressed using the context based compression 
scheme in 6lowpan-hc-07.

However, I think it is safer if the header of the tunnelled (inner) 
packet is uncompressed, rather than using 6LowPAN compression on it. 
This avoids potential problems with compression extending beyond the 
first fragment.

For the same reason, I also think that carrying the routing header's 
type and length in line is safer, rather than using the extension header 
compression in 4.2 of 6lowpan-hc-07.

Pascal's proposed inner header compression is independent of 
6lowpan-hc-07 and could be added to the rpl-routing-header draft.

Rather than compressing only if the inner / outer source / dest fully 
match, a scheme similar to that of the addresses within the routing 
header could be used.  A field similar to the Compr field could be used 
to match octets of the inner header src/dest against the outer header. 
This would provide good compression inside the LowPAN where all 
addresses bear the same /64 or /112 prefix.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Jul 2010 15:01:34 +0200

> passed already, would it?

Change in content => We need to WGLC it again.
Maybe we can do it quicker than in a half year this time, though.
Like in a week.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Jul 2010 15:04:48 +0200

On Jul 6, 2010, at 14:57, Daniel Gavelle wrote:

> However, I think it is safer if the header of the tunnelled (inner) packet is uncompressed, rather than using 6LowPAN compression on it. This avoids potential problems with compression extending beyond the first fragment.

Hi Daniel,

I must admit I don't get this kind of safety.

There are no "potential problems with compression extending beyond the first fragment", there simply is no support for that right now.
So don't do it.

Whether you program your implementation so that it never even tries to or whether you use the space if it is sufficient is a quality of implementation issue.

Gruesse, Carsten