Subject: Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-01

From: Jonathan Hui <[email-masked]>
Date: Wed, 9 Jun 2010 09:32:27 -0700

We have updated both draft-hui-6man-rpl-routing-header as well as  
draft-hui-6man-rpl-option-header based on feedback from Anaheim as  
well as discussions on the ML.

Summary of changes:
- Specify a maximum size for header/option so that it is possible to  
avoid MTU issues within a RPL domain
- IP-in-IP tunneling is used when a header/option must be inserted  
into an existing packet
- Expanded text on requirements and checks on RH4 processing needed to  
avoid amplification attacks

Comments/feedback appreciated as always.

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: June 9, 2010 8:48:30 AM PDT
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for  draft-hui-6man-rpl-routing- 
> header-01
>
>
> A new version of I-D, draft-hui-6man-rpl-routing-header-01.txt has  
> been successfully submitted by Jonathan Hui and posted to the IETF  
> repository.
>
> Filename:	 draft-hui-6man-rpl-routing-header
> Revision:	 01
> Title:		 An IPv6 Routing Header for Source Routes with RPL
> Creation_date:	 2010-06-09
> WG ID:		 Independent Submission
> Number_of_pages: 16
>
> Abstract:
> In Low power and Lossy Networks (LLNs), memory constraints on routers
> may limit them to maintaining at most a few routes.  In some
> configurations, it is necessary to use these memory constrained
> routers to deliver datagrams to nodes within the LLN.  The Routing
> for Low Power and Lossy Networks (RPL) protocol can be used in some
> deployments to store most, if not all, routes on one (e.g. the
> Directed Acyclic Graph (DAG) root) or few routers and forward the
> IPv6 datagram using a source routing technique to avoid large routing
> tables on memory constrained routers.  This document specifies a new
> IPv6 Routing header type for delivering datagrams within a RPL
> domain.
>
>
>
> The IETF Secretariat.
>
>

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 9 Jun 2010 10:22:00 -0700

Hi Jonathan,

I just skimmed through the draft. Just one major comment the first one
and other comments:

1. Is there a reason if the RH is added by a router not the initiator
we do not add the IP-in-IP tunnelling? I do not see a problem with
adding that and it just simplifies decapsulation of the outer IP.

2. That said some checks we can add are:
    i. Strict source routing only.
    ii. for two routers A---B in the RPL domain, we can have RH4
header like A1, A2, A3, B1, B2, B3, but not as A1, B1, A2, B2, A3, B3.

3. Source routing should allow multiple address of the same device
multiple times as we had discussed earlier.

You can look at the former RH4 draft for details.

Thanks,
Vishwas

On Wed, Jun 9, 2010 at 9:32 AM, Jonathan Hui <[email-masked]> wrote:
> draft-hui-6man-rpl-option-header based on feedback from Anaheim as well as
> discussions on the ML.
>
> Summary of changes:
> - Specify a maximum size for header/option so that it is possible to avoid
> MTU issues within a RPL domain
> - IP-in-IP tunneling is used when a header/option must be inserted into an
> existing packet
> - Expanded text on requirements and checks on RH4 processing needed to avoid
> amplification attacks
>
>> Subject: New Version Notification for
>>  draft-hui-6man-rpl-routing-header-01
>>
>>
>> A new version of I-D, draft-hui-6man-rpl-routing-header-01.txt has been
>> successfully submitted by Jonathan Hui and posted to the IETF repository.
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 9 Jun 2010 10:37:10 -0700

Hi Viswhas,

Thanks for the comments again.

> adding that and it just simplifies decapsulation of the outer IP.

The draft does specify use of IP-in-IP in your particular case.  The  
case where IP-in-IP tunneling is not needed is if the RPL router  
itself originates a packet.  In a LLN network, it is common for RPL  
routers to originate datagrams as they often serve as application end- 
points as well.

> header like A1, A2, A3, B1, B2, B3, but not as A1, B1, A2, B2, A3, B3.

The checks above are specified in the draft.  Although for point (ii)  
the draft does not currently allow multiple addresses assigned to the  
same node.

> multiple times as we had discussed earlier.

This makes sense as long as they are consecutive.

> You can look at the former RH4 draft for details.

I did look at your former RH4 draft, but all I could find that relate  
to points 2.ii and 3 was the following:
"Compare the addresses in the Routing Header to check that none of the  
address belong to the routers self address"

Are there other details you were referring to?

--
Jonathan Hui

>> into an
>>> been

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 9 Jun 2010 10:43:37 -0700

Hi Jonathan,

The draft looks a lot refined now.

> The draft does specify use of IP-in-IP in your particular case.  The case
> where IP-in-IP tunneling is not needed is if the RPL router itself
> originates a packet.  In a LLN network, it is common for RPL routers to
> originate datagrams as they often serve as application end-points as well.

That sounds reasonable. Can we then instead have the condition that in
case the packet is originated and terminated in the same RPL domain we
do not do IP-in-IP?

> The checks above are specified in the draft.  Although for point (ii) the
> draft does not currently allow multiple addresses assigned to the same node.
Yes, I understand. The point here is that we do not check against one
address in the RH4 header, but any of my other addresses. If they are
there we should drop the packet. If the condition is that only 1
address will ever be used on a node using this header we can make that
more explicit.

> I did look at your former RH4 draft, but all I could find that relate to
> points 2.ii and 3 was the following:
This again comes into picture if there can be multiple IPv6 address on a device.

Let me get back with other details over the weekend.

Thanks,
Vishwas

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Jun 2010 23:51:34 +0200

On Jun 9, 2010, at 19:37, Jonathan Hui wrote:

> The case where IP-in-IP tunneling is not needed is if the RPL router itself originates a packet.  In a LLN network, it is common for RPL routers to originate datagrams as they often serve as application end-points as well.

Jonathan,

do we know how to compress this IP-RH4-IP-UDP stack?
(The first IP header compresses reasonable well; I'm worrying about the second.)
Or did RPL just become a lot less useful in a LoWPAN with hosts?

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 9 Jun 2010 19:13:41 -0700

Carsten,

> Or did RPL just become a lot less useful in a LoWPAN with hosts?

Section 4.2 of the 6lowpan-hc-07 draft does define a LOWPAN_NHC  
encoding for IPv6 headers as well as the IPv6 Extension headers  
defined in RFC 2460.  This should allow 6lowpan-hc to compress both  
outer and inner IPv6 headers of an IP-in-IP datagram.  I think that in  
many cases, 6lowpan-hc makes IP-in-IP possible with very little  
overhead.  The outer IP header is compressed to just a few bytes  
(prefixes are elided using contexts, at least one IID is elided due to  
strict source route).  The inner IP header is compressed as if there  
were no outer IP header (prefixes are elided using contexts, IID of  
source and destination can only be elided on the first and last hops,  
respectively).

If you don't think the mechanism in 6lowpan-hc is effective in  
compressing IP-in-IP datagrams, then we should discuss that on the  
6lowpan ML.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jun 2010 08:27:26 +0200

On Jun 10, 2010, at 04:13, Jonathan Hui wrote:

> If you don't think the mechanism in 6lowpan-hc is effective in compressing IP-in-IP datagrams, then we should discuss that on the 6lowpan ML.

Indeed, let's do that, best with actual examples.

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Thu, 10 Jun 2010 09:26:51 +0200

Hi Vishwas

Thanks for all the useful comments

> case the packet is originated and terminated in the same RPL domain we

Yes - this is what we represented here:

   To deliver a datagram, a router MAY specify a source route to reach
    the destination using a RH4.  If the router is the original source  
of
    the datagram, it SHOULD include the RH4 directly within the datagram
    itself.  This case applies to any datagram sourced by a RPL router  
to
    any destination inside or outside the RPL domain, as shown in the
    following examples:

                 ------------------------
                 |                      |
                 |  (R1) -------> (R2)  |
                 |                      |
                 ------------------------
                        RPL Domain

                 ------------------------
                 |                      |
                 |  (R1) -----------> (BR1) -----------> (D)
                 |                      |
                 ------------------------
                        RPL Domain

    R1 and R2 are RPL routers, BR1 is a RPL Border Router, and D is a
    destination outside the RPL domain.

    If the router is not the original source of the datagram, it MUST  
use

Hui, et al.             Expires December 11, 2010               [Page 4]

Internet-Draft           RPL Source Route Header               June 2010

    IPv6-in-IPv6 tunneling, as specified in [RFC2473], and serve as a
    tunnel entry point for the datagram.

Thanks.

JP.

>>>> draft-hui-6man-rpl-option-header based on feedback from Anaheim  
>>>> as well
>>>> as
>>>> discussions on the ML.
>>>>
>>>> Summary of changes:
>>>> - IP-in-IP tunneling is used when a header/option must be  
>>>> inserted into
>>>> an
>>>> existing packet

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 10 Jun 2010 09:52:06 -0700

Hi Carsten/ Jonathan,

One thing I can see is that in RPL cases we will have the inner and
outer header destination IPv6 address the same (for packets from
outside the domain). We can easily compress that. In some cases the
inner and outer IPv6 source address may be the same (For packets
originated within the domain going outside the domain).

You can use that property for your HC draft (so when you say inner
header IP ou can instead say inner header IP source same, inner heade
IP destination same).

Thanks,
Vishwas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2010 11:35:48 -0700

On 06/ 9/10 09:32 AM, Jonathan Hui wrote:
> draft-hui-6man-rpl-option-header based on feedback from Anaheim as well
> as discussions on the ML.
>
> Summary of changes:
> - IP-in-IP tunneling is used when a header/option must be inserted into
> an existing packet

When IPv6-in-IPv6 tunneling is used, what is the destination IP address 
in the outer header? Normally it would be the router that would strip 
the outer header and RH4. Is that the case here as well?

It wasn't clear to me whether you are proposing IPv6-in-IPv6 tunneling 
for packets that come in via a border router.

    Erik

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 10 Jun 2010 12:01:35 -0700

Hi Erik,

> When IPv6-in-IPv6 tunneling is used, what is the destination IP address in
> the outer header? Normally it would be the router that would strip the outer
> header and RH4. Is that the case here as well?
>
> It wasn't clear to me whether you are proposing IPv6-in-IPv6 tunneling for
> packets that come in via a border router.
Your understanding is correct.

Thanks,
vishwas

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 10 Jun 2010 12:06:01 -0700

On Jun 10, 2010, at 11:35 AM, Erik Nordmark wrote:

> When IPv6-in-IPv6 tunneling is used, what is the destination IP  
> address in the outer header? Normally it would be the router that  
> would strip the outer header and RH4. Is that the case here as well?

Yes, that is what we intended.

> It wasn't clear to me whether you are proposing IPv6-in-IPv6  
> tunneling for packets that come in via a border router.

Not sure I'm clear on your use case, but the restrictions in the draft  
are intended to prohibit the case where an RH4 cross a RPL domain  
boundary.  A RH4 may be added and/or removed at a border router, but  
it shouldn't process/maintain an existing RH4 across a RPL domain  
boundary.

--
Jonathan Hui

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2010 12:21:48 -0700

> Yes, that is what we intended.

So a packet sent by R1 that will be forwarded outside of the ROLL 
network will have a outer IPv6 header whose destination is the BR?

> boundary. A RH4 may be added and/or removed at a border router, but it
> shouldn't process/maintain an existing RH4 across a RPL domain boundary.

Understood. My question is when the BR adds RH4, does it also 
encapsulate in an outer header?

Thus is the only case when there is RH4 without IPv6-in-IPv6 when both 
the source *and* the destination is a router in the ROLL network?

   Erik

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 10 Jun 2010 12:31:30 -0700

> network will have a outer IPv6 header whose destination is the BR?

That is where we started.  Draft-01 does have a line or two about the  
possibility of exempting the last entry in a RH4 from the strict  
source route rule, thus allowing R1 to send a packet without an outer  
IP header but this idea still needs to be fleshed out.  It would  
require the BR to strip the RH4 and update the IPv6 Payload Length  
accordingly.  Are there any implications with this idea?

>>> tunneling
>> it

Yes, that is the case with draft-01.

> Thus is the only case when there is RH4 without IPv6-in-IPv6 when  
> both the source *and* the destination is a router in the ROLL network?

Certainly the source must be within the ROLL network.  Whether or not  
the destination has to be depends on whether it is acceptable for the  
border router to strip RH4 headers that have have a Segments Left = 0  
after processing.

Thoughts?

--
Jonathan Hui

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2010 02:36:22 -0700

On 06/10/10 12:31 PM, Jonathan Hui wrote:

> possibility of exempting the last entry in a RH4 from the strict source
> route rule, thus allowing R1 to send a packet without an outer IP header
> but this idea still needs to be fleshed out. It would require the BR to
> strip the RH4 and update the IPv6 Payload Length accordingly. Are there
> any implications with this idea?

The first problem is that the draft isn't clear what it is saying on 
this point. Hence my clarifying question and the need to clarify the draft.

For the technical point see below.

> Certainly the source must be within the ROLL network. Whether or not the
> destination has to be depends on whether it is acceptable for the border
> router to strip RH4 headers that have have a Segments Left = 0 after
> processing.
>
> Thoughts?

It seems quite asymmetrical to have the packets from R1 via BR to some 
non-ROLL destination not use IPv6-in-IPv6, while packets in the reverse 
direction must use IPv6-in-IPv6.

That begs the question whether the same asymmetry is there for packets 
from R1 to a host that is directly attached to a the ROLL router R2. 
Thus would R2 strip RH4 and update the payload length for packets from 
R1 via R2 destined to the host, while the packets from the host via R2 
to R1 would be IPv6-in-IPv6 encapsulated by R2?

    Erik

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 14 Jun 2010 10:50:16 -0700

Hi Erik,

On Jun 11, 2010, at 2:36 AM, Erik Nordmark wrote:

>> source

We just posted version -02 of the draft that hopefully makes the draft  
more clear on how RH4 is used.  I agree that the optimization to  
insert RH4 into an existing IP header may have been premature and was  
asymmetric, so that has been removed.  The rule now is that a RH4 only  
specifies the strict source route between the tunnel end-points.

http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-02

--
Jonathan Hui