Hi Vishwas
Thanks for all the useful comments
On Jun 9, 2010, at 7:43 PM, Vishwas Manral wrote:
Hi Jonathan,
The draft looks a lot refined now.
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.
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?
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.
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.
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.
3. Source routing should allow multiple address of the same device
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?
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
Thanks,
Vishwas
On Wed, Jun 9, 2010 at 9:32 AM, Jonathan Hui <[email protected]>
wrote:
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 protected]>
Date: June 9, 2010 8:48:30 AM PDT
To: [email protected]
Cc: [email protected],[email protected]
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
