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? >> 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 <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 --------------------------------------------------------------------
