Hi Viswhas,
Thanks for the comments again.
On Jun 9, 2010, at 10:22 AM, Vishwas Manral wrote:
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.
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.
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?
--
Jonathan Hui
Thanks,
Vishwas
On Wed, Jun 9, 2010 at 9:32 AM, Jonathan Hui <j...@archrock.com>
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 <idsubmiss...@ietf.org>
Date: June 9, 2010 8:48:30 AM PDT
To: j...@archrock.com
Cc: j...@cisco.com,cul...@cs.berkeley.edu
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
