is to define the scope based on interfaces. That is
not the same as limiting the scope to a collection of RPL routers.
--
Jonathan Hui
On Dec 23, 2011, at 10:07 AM, Robert Cragie robert.cra...@gridmerge.com
wrote:
Hi Jonathan,
Some comments and questions below.
Robert
On 22/12/2011 6:02
requires a little more thought. Can you propose the exact processing rules
that would clearly limit a routing header to a RPL routing domain?
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
invalidate the Security Considerations
section.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
: In the above scenario, datagrams travel from S to D through LBR - In
the above scenario, datagrams travel from S to D through the RPL Border
Router LBR (referred to as LBRs in [I-
D.ietf-roll-terminology]). Reason for change: Clarify what LBR is.
Agree.
Thanks again.
--
Jonathan Hui
process.
Jari, would you support reverting the scope of the RPL SRH to a RPL routing
domain rather than a RPL Instance?
Thanks.
--
Jonathan Hui
On Dec 21, 2011, at 9:26 AM, Mukul Goyal wrote:
Jonathan
I described the problem in the message I sent just now. I think RPL Instance
definition is the tuple (RPLInstanceID, DODAGID)
uniquely identifies a DODAG.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
(this time applying
case 2 or 3). RPL can support a hierarchy of RPL routing topologies.
Does that help?
--
Jonathan Hui
On Dec 16, 2011, at 8:55 AM, Park, Kundok wrote:
Hi, Jonathan,
I have a question on the following text on version 6, on page 8.
2. Datagrams destined elsewhere
. In this case, the outer-most header now refers to TunnelB. If the
RPL router is not the exit-point for TunnelB, it applies either Case 2 or 3.
This is typically how nested tunnels are handled in IPv6.
--
Jonathan Hui
On Dec 16, 2011, at 3:21 PM, Park, Kundok wrote:
Hi, Jonathan,
Thanks for your
the changes in my updates to address the
LC comments.
Thanks.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
directly within the original packet. Otherwise, routers MUST use
IPv6-in-IPv6 tunneling [RFC2473] to include a new RPL Option in
datagrams that are sourced by other nodes.
Does this address your concern?
--
Jonathan Hui
On Nov 10, 2011, at 10:23 AM, Reddy, Joseph wrote:
Hi Jonathan
pseudocode to match the text on sending back a
parameter problem error.
- Recommend that non-RPL devices drop packets with SRH by default.
- Clarify packet structure figures.
- State that checking for cycles represents significant per-packet processing.
--
Jonathan Hui
Begin forwarded message:
From
SHOULD to MUST.
- Specify RPL Border Router operations in terms of forwarding decision outcomes.
- Expand security section.
--
Jonathan Hui
Begin forwarded message:
From: internet-dra...@ietf.org
Date: October 11, 2011 10:17:15 PM PDT
To: i-d-annou...@ietf.org
Cc: ipv6@ietf.org
Subject: I-D
., state upfront that
it requires significant per-packet processing. Then the issue would at least
not be a surprise to anyone. Thoughts?
I think it is reasonable to call out the costs up front. We will make this
change in the next revision unless there are alternative ideas.
Thanks.
--
Jonathan
.
OK
Thanks.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
actually right as far as 11.2 goes, because it contains
tons of MUSTs and SHOULDs. Perhaps you want to fix that in AUTH48...
Right.
Thanks.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
needs to be done to directly insert the extension header in the packet
(and the risks involved with doing so). Note that this draft has expired. Is
there interest to revive it?
--
Jonathan Hui
On Apr 21, 2011, at 9:15 AM, Reddy, Joseph wrote:
( resending as original post didn’t go through
Hi Erik,
On Jun 11, 2010, at 2:36 AM, Erik Nordmark wrote:
On 06/10/10 12:31 PM, Jonathan Hui wrote:
So a packet sent by R1 that will be forwarded outside of the ROLL
network will have a outer IPv6 header whose destination is the BR?
That is where we started. Draft-01 does have a line
On Jun 10, 2010, at 12:21 PM, Erik Nordmark wrote:
On 06/10/10 12:06 PM, Jonathan Hui wrote:
On Jun 10, 2010, at 11:35 AM, Erik Nordmark wrote:
When IPv6-in-IPv6 tunneling is used, what is the destination IP
address in the outer header? Normally it would be the router that
would strip
at a border router, but
it shouldn't process/maintain an existing RH4 across a RPL domain
boundary.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman
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
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
and destination can only be elided on the first and last hops,
respectively).
If you don't think the mechanism in 6lowpan-hc is effective in
compressing IP-in-IP datagrams, then we should discuss that on the
6lowpan ML.
--
Jonathan Hui
when processing the header.
Thanks.
--
Jonathan Hui
On May 30, 2010, at 11:18 PM, Vishwas Manral wrote:
Hi Jonathan,
I read your draft. As I have not read RPL I have to say the draft by
itself was not self contained so was a bit hard to figure out what can
be done in the RPL option.
After
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
Thanks,
Vishwas
On Fri, May 28, 2010 at 10:52 PM, JP Vasseur j...@cisco.com wrote:
Dear all,
Let me share a bit
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
Thanks,
Vishwas
Thanks,
Vishwas
On Fri, May 28, 2010 at 10:52 PM, JP Vasseur j...@cisco.com wrote:
Dear all,
Let me share a bit of context
not satisfy this
fundamental requirement. Section 2.1 of RFC 2711 states that the
option must not change en route.
--
Jonathan Hui
On May 30, 2010, at 1:46 PM, Hemant Singh (shemant) wrote:
If RFC 2711 already defines a Router Alert Option to use, why do we
need
a new option in the Hop
information you'd typically obtain through such a service.
--
Jonathan Hui
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Submission
Number_of_pages: 6
Abstract:
The RPL protocol requires data-plane datagrams to carry RPL routing
information that is processed by RPL routers when forwarding those
datagrams. This document describes the RPL option for use within a RPL
domain.
--
Jonathan Hui
, but some
environments with physical and environmental constraints can't afford to
do so.
--
Jonathan Hui
Pascal Thubert (pthubert) wrote:
Hi Jim:
All I can say is that at least one Wireless Sensor Network standard under
development will not use IPSec. ISA100.11a
(http://www.isa.org
interested in working through this more in detail to do the study of
whether IPsec is a viable option and would like to solicit help from
those that have more expertise in this space. If anyone is interested,
let me know.
--
Jonathan Hui
Bound, Jim wrote:
It all comes down to is IPsec capable
, and the 6lowpan
effort within the IETF has set out to bring IPv6 to this new class. I'd
be disappointed if we couldn't come to an agreement on how we can
appropriately bring this new class into the IP framework.
--
Jonathan Hui
IETF IPv6
32 matches
Mail list logo
