source
route does not sound like a good idea.
Thanks
Mukul
- Original Message -
From: "Jonathan Hui (johui)"
To: "robert cragie"
Cc: "Mukul Goyal" , ipv6@ietf.org, "roll"
Sent: Friday, December 23, 2011 12:17:18 PM
Subject: Re: draft-ietf-6man-
>Again, just because you received a message on an interface for which you've
>enabled RPL doesn't mean you know the message came from a router that is
>within the same RPL routing domain. A router not running RPL could have sent
>you that message.
A router not running RPL could have sent me a
>And what information does the SRH provide that indicates what RPL routing
>domain it is coming from? A node now has to know what neighbors are in its
>RPL routing domain?
The simplest option would be for the router to decide before hand which of its
interfaces belong to "the" RPL domain and w
Hi Jonathan
>And by the same logic, when forwarding a message, there is no guarantee that
>all neighboring nodes reachable via an interface belong to the same RPL
>routing domain.
The receiving router could check if it belongs to the RPL domain listed in the
SRH. If not, it can drop the packet
IESG review
>process.
I support this.
Thanks
Mukul
- Original Message -
From: "Jonathan Hui"
To: "Mukul Goyal" , "Jari Arkko"
Cc: "roll WG" , "ipv6"
Sent: Wednesday, December 21, 2011 12:22:11 PM
Subject: Re: draft-ietf-6man-rpl-ro
Hi Jonathan
>It knows whether or not RPL is running on an interface. It could at least
>check that. By the same argument, how do you propose we limit packets to a
>RPL routing domain? If we have no good way of limiting packets, then the
>stated security considerations do not apply.
Just the
Jonathan
I described the problem in the message I sent just now. I think RPL Instance is
not the correct scope for SRH. It has to be a RPL domain to be defined as we
discussed some time back on the ROLL list.
Thanks
Mukul
- Original Message -
From: "Jonathan Hui"
To: &q
Hi Jonathan
I have serious issues with the use of RPL Instance as the domain for SRH.
>>[R Cragie]
>> p7: RPL Instance ID - why is this needed for source routing? RPL is not even
>> used for source routing. This flavors the SRH unnecessarily and the
>> processing does not use it. If the reason
Jonathan
The IESG-approved draft refers to the RPL instance as the scope where the
routing header can be used. How would this routing header be used for general
source routing (across RPL instances) in an LLN? How would a node use this
routing header if it wants to travel along a source route d
