Subject: Fwd: I-D Action:draft-hui-6man-rpl-routing-header-00.txt

From: JP Vasseur <[email-masked]>
Date: Sat, 29 May 2010 07:52:32 +0200

Dear all,

Let me share a bit of context about this ID. As some of you many know,  
the ROLL WG
(http://datatracker.ietf.org/wg/roll/charter/)
is specifying a new routing protocol called RPL in Low power and Lossy  
Networks (LLNs:
also referred to as Sensor Networks), where nodes are usually  
constrained in terms of
memory, processing power, ... and are interconnected with lossy links  
(links flapping,
high error rates, ...). The base specifications of RPL (http://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ 
)
is maturing with the aim to Last Call it in July. Some of these  
networks comprise nodes
that are highly constrained and cannot even store routing tables, in  
which case, it is
necessary to perform source routing (as a matter of fact, several of  
the proprietary
solutions deployed so far are using source routing for this kind of  
environment). So the
whole point of this simple ID is to propose a new Routing Header. The  
proposal (RH4)
is in many ways similar to the RH0 (minus the security issues since  
RH4 can only be
used within LLNs) and we added a very simple compression scheme too.

Comments/suggestions/... would be extremely welcome since this RH is  
critical for ROLL.

Thanks.

JP.

Begin forwarded message:

> From: [email-masked]
> Date: May 26, 2010 8:45:02 PM CEDT
> To: [email-masked]
> Subject: I-D Action:draft-hui-6man-rpl-routing-header-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : A Source Routing Header for RPL
> 	Author(s)       : J. Hui, et al.
> 	Filename        : draft-hui-6man-rpl-routing-header-00.txt
> 	Pages           : 13
> 	Date            : 2010-05-26
>
> 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.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hui-6man-rpl-routing-header-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 30 May 2010 07:56:31 -0700

The draft says:
    A RPL Router MAY insert a Type 4 Routing header if one does not
    already exist.  The conditions for inserting a Type 4 Routing header
    are out of scope of this document.

Having routers insert headers in packets they forward is know to be 
problematic in general, since it breaks path MTU discovery.
Taking an example of a host which sends a packet which is 1500 bytes, 
and then receives an ICMP packet too big error saying "please limit 
packets to 1500 bytes", will not change the host's behavior. But that 
can happen if some router grows the packet to be more than 1500 bytes.

Thus in general, the only safe way to insert headers in a packet is to 
have the "inserter" put an extra IP header, with itself as a source, 
then the inserted header, and then the original packet.
That extra IP header ensures that any ICMP error go back to the 
"inserter", which can then compensate for its insertion before sending 
the ICMP error towards the sender of the original packet.

Thus I think there is a question for 6man whether we think the 
constrained environment of ROLL is such that we can relax this. But it 
does require that all the routers at the edge of the ROLL network adjust 
the ICMP errors they forward to compensate for any inserted RH4 headers.

    Erik

---

From: culler <[email-masked]>
Date: Mon, 31 May 2010 09:06:06 -0700

Since we route WITHIN a RPL network, rather than THROUGH a RPL  
network, it would seem that the case mentioned does not arise.  Right?

On May 30, 2010, at 7:56 AM, Erik Nordmark wrote:

> Taking an example of a host which sends a packet which is 1500  
> bytes, and then receives an ICMP packet too big error saying "please  
> limit packets to 1500 bytes", will not change the host's behavior.  
> But that can happen if some router grows the packet to be more than  
> 1500 bytes.
>
> Thus in general, the only safe way to insert headers in a packet is  
> to have the "inserter" put an extra IP header, with itself as a  
> source, then the inserted header, and then the original packet.
> "inserter", which can then compensate for its insertion before  
> sending the ICMP error towards the sender of the original packet.
>
> constrained environment of ROLL is such that we can relax this. But  
> it does require that all the routers at the edge of the ROLL network  
> adjust the ICMP errors they forward to compensate for any inserted  
> RH4 headers.
>
>   Erik
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 11:03:21 -0700

Hi Erik,

The first thing is IPv6 MTU discovery is optional and the only
requirement is that the Minimum MTU is satisfied.

Also in cases like LLN the Routing paths may change so even after
discovery the Packet too big may come anyway. Besides PMTU issues you
mention are no different than a lot of cases such as tunnelling and
transition mechanisms.

For MTU discovery in cases when padding is done, the right MTU will be
found as the data packets will undergo the same behavior as the PMTU
discovery message.

Thanks,
Vishwas

On Sun, May 30, 2010 at 7:56 AM, Erik Nordmark <[email-masked]> wrote:
> Taking an example of a host which sends a packet which is 1500 bytes, and
> then receives an ICMP packet too big error saying "please limit packets to
> 1500 bytes", will not change the host's behavior. But that can happen if
> some router grows the packet to be more than 1500 bytes.
>
> Thus in general, the only safe way to insert headers in a packet is to have
> the "inserter" put an extra IP header, with itself as a source, then the
> inserted header, and then the original packet.
> That extra IP header ensures that any ICMP error go back to the "inserter",
> which can then compensate for its insertion before sending the ICMP error
> towards the sender of the original packet.
>
> Thus I think there is a question for 6man whether we think the constrained
> environment of ROLL is such that we can relax this. But it does require that
> all the routers at the edge of the ROLL network adjust the ICMP errors they
> forward to compensate for any inserted RH4 headers.
>
>   Erik
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 11:14:01 -0700

Hi JP,

Besides the issues I have raised. Here is another thing I encountered
when I wrote the RH4 draft.

RFC2460 said:

  If, while processing a received packet, a node encounters a Routing
  header with an unrecognized Routing Type value, the required
  behavior of the node depends on the value of the Segments Left field,
  as follows:

   -   If Segments Left is non-zero, the node must discard the packet
      and send an ICMP Parameter Problem, Code 0, message to the
      packet's Source Address, pointing to the unrecognized Routing
      Type.

This means that packets will be dropped when a new header is encountered.

Also in your particular case we are adding the header mid-way the
reply should be probably sent to the RPL Border node as it added the
header. We may want to add that field into the RH4 header too.

Thanks,
Vishwas

On Fri, May 28, 2010 at 10:52 PM, JP Vasseur <[email-masked]> wrote:
> Dear all,
> Let me share a bit of context about this ID. As some of you many know, the
> ROLL WG
> also referred to as Sensor Networks), where nodes are usually constrained in
> terms of
> memory, processing power, ... and are interconnected with lossy links (links
> flapping,
> high error rates, ...). The base specifications of RPL
> (http://datatracker.ietf.org/doc/draft-ietf-roll-rpl/)
> is maturing with the aim to Last Call it in July. Some of these networks
> comprise nodes
> that are highly constrained and cannot even store routing tables, in which
> case, it is
> necessary to perform source routing (as a matter of fact, several of the
> proprietary
> is in many ways similar to the RH0 (minus the security issues since RH4 can
> only be

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 31 May 2010 11:35:02 -0700

Hi Vishwas,

> This means that packets will be dropped when a new header is  

This should be OK for our intended usage of RH4 since it is  
constrained to a RPL routing domain.  The current RPL specification  
requires all RPL routers to implement the source routing mechanism we  
are trying to specify.

> header. We may want to add that field into the RH4 header too.

Yes, we realized this after submitting the draft.  One way is simply  
to include the inserting nodes' address as Address[0] and set Segments  
Left to n-1.  Doing so will make the inserting node a part of the  
"record route" functionality given by the first "Segments Left"  
entries in a RH4.  Do you think that is sufficient?

Thanks.

--
Jonathan Hui

>> constrained in
>> networks
>> RH4 can

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 31 May 2010 14:03:38 -0500

Vishwas,

It's not a question of what's optional or not.  Erik gave a clear
example of an operational issue which is if a host sends a packet with
size equal to MTU of the link and if such a packet arrives at a router1
in such a network and router1 slaps its RH on the packet, the packet
size grows larger than the max MTU.  Now router1 forwards the packet to
router2 who issues an ICMPv6 Too Big error to the host.  The host stands
totally confused because the host did not exceed the link MTU.  

Also, tunneling used by transition mechanisms is orthogonal to this
operational issue discussion.  For tunneling with no use of RH, there is
well-defined behavior for not exceeding the MTU in RFC 2473.  

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vishwas Manral
Sent: Monday, May 31, 2010 2:03 PM
To: Erik Nordmark
Cc: [email-masked]; culler Culler
Subject: Re: Fwd: I-D Action:draft-hui-6man-rpl-routing-header-00.txt

Hi Erik,

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 12:05:14 -0700

Hi Jonathan,

> This should be OK for our intended usage of RH4 since it is constrained to a
> RPL routing domain.  The current RPL specification requires all RPL routers
> to implement the source routing mechanism we are trying to specify.

This is great.

> Yes, we realized this after submitting the draft.  One way is simply to
> include the inserting nodes' address as Address[0] and set Segments Left to
> n-1.  Doing so will make the inserting node a part of the "record route"
> functionality given by the first "Segments Left" entries in a RH4.  Do you
> think that is sufficient?
This cannot work in all cases. If a node does not know the header it
may not know that the address[0] is the inserting node address.

One thing that needs evaluated is are we ok sending a wrong
information versus the case of filtering at the edge of RPL and not
letting the wrong infromation propagate at all.

Also do we intend to have only one node doing the insertion or not?

Thanks,
Vishwas

>>> the
>>> (links
>>> which

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 12:07:03 -0700

Hi Hemant,

When we do IP in IP tunneling, in that case too the packet size
increases at an intermediate node. It is no different than this case.

Thanks,
Vishwas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 31 May 2010 14:22:22 -0500

>From: Vishwas Manral [mailto:[email-masked]] 
>Sent: Monday, May 31, 2010 3:07 PM
>To: Hemant Singh (shemant)
>Cc: Erik Nordmark; [email-masked]; culler Culler

>increases at an intermediate node. It is no different than this case.

What intermediate node are we talking about for a tunneled packet?  If
the tunnel ingress point has followed RFC 2473, the packet goes to the
egress without any MTU problems.  See section 7-7.2 of RFC 2473.  My
recommendation is to focus the discussion to the operational issue that
Erik raised and ascertain if the issue is a valid issue for the RPL
network or not.  I see David Culler has already replied to Erik.   

Hemant

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 31 May 2010 12:34:11 -0700

Hi Vishwas,

On May 31, 2010, at 12:05 PM, Vishwas Manral wrote:

>> constrained to a

If the node does not know the header when processing it, then it can't  
utilize any information included in RH4.  Did you have something else  
in mind when you said "We may want to add that field into the RH4  
header too" in an earlier mail?

> letting the wrong infromation propagate at all.

We really intend the routing header to only be used within a RPL  
routing domain hence the filtering rolls.  So far, we are trying to  
stay very focused on the needs of RPL.  If there are other good use  
cases for RH4, that's fine too - unless it adds complexity.

> Also do we intend to have only one node doing the insertion or not?

I would like to focus on the case where there is only one RH4 in the  
datagram at a time.

--
Jonathan Hui

>>>> constrained
>>>> in
>>>> is in many ways similar to the RH0 (minus the security issues  
>>>> since RH4
>>>> can
>>>> only be

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 31 May 2010 14:40:38 -0500

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
culler
>Sent: Monday, May 31, 2010 12:06 PM
>To: Erik Nordmark
>Subject: Re: I-D Action:draft-hui-6man-rpl-routing-header-00.txt

>network, it would seem that the case mentioned does not arise.  Right?

David,

I will let Erik reply.  For now, I am trying to understand RPL. 

What do you mean by route WITHIN a RPL network?  Sorry I am not familiar
with the RPL network topology.  However, let me try and understand.  If
the RPL network is a mesh of nodes where the mesh has ONLY one IPv6
router (besides the router at the edge of the RPL and non-RPL network
boundary), then, say, such a router adds an RH on receiving a packet
with size equal to link MTU and forwards the packet.  Since there is no
other router in the mesh (besides the one that added the RH), what node
exists in the RPL domain to send an ICMPv6 Too Big error message to the
sender?  Only a router can issue an ICMPv6 error message.  But if the
RPL mesh has more than one IPv6 router, then Erik seems to have a valid
operational issue to be addressed. 

I think it will help folks in 6man, if we have one person from the roll
WG present roll at the next IETF in Maastricht. The presentation,
amongst other things, should explain basic IPv6 data forwarding of the
RPL network.  Or has such a presentation been already made to 6man in an
earlier IETF?  I know at the last IETF in Anaheim, the 6lowpan folks
presented their core document in 6man. 

Thanks,

Hemant

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 12:46:47 -0700

Hi Jonathan,

There are two cases, where a node knows about the header but does not
support its processing (Security or whatever reason). In that case we
can add information like you said. Also in case we assume all RPL
nodes have the stack as we define in the spec, we can assume the
behavior.

So we can add the information you said but we should assume thatwe
still may have cases where the behavior is not supported.

Let us discuss the design offline and not burden the WG list with all
possible options.

We can focus the discussion on only one node adding the RH4 header. If
we want to make that a constraint we should make that clear in the
draft.

Let us take this discussion offline.

Thanks,
Vishwas

On Mon, May 31, 2010 at 12:34 PM, Jonathan Hui <[email-masked]> wrote:
> utilize any information included in RH4.  Did you have something else in
> mind when you said "We may want to add that field into the RH4 header too"
> in an earlier mail?
>
> We really intend the routing header to only be used within a RPL routing
> domain hence the filtering rolls.  So far, we are trying to stay very
> focused on the needs of RPL.  If there are other good use cases for RH4,
> that's fine too - unless it adds complexity.
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 12:49:08 -0700

Hi Hemant,

Sorry if I was not clear earlier.

Now that you agree that tunnelling/ transition mechanisms add headers
and the MTU problem is solved for them. Think of a similar solution
for the RH4 cases too.

Thanks,
Vishwas