Yes, thanks ! -----Original Message----- From: Jonathan Hui [mailto:jon...@cisco.com] Sent: Thursday, November 10, 2011 10:58 AM To: Reddy, Joseph Cc: ipv6@ietf.org Subject: Re: draft-ietf-6man-rpl-option questions
Hi Joseph, It is not actually required to use tunneling if the RPL router knows that the destination is within the same RPL Instance. But if the router does not know for sure, then it must use tunneling. Just after sending my proposed text, I had modified the cited portion to the following: Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header (SRH) and MAY include both. When the router is the source of the original packet and the destination is known to be within the same RPL Instance, the router SHOULD include the RPL Option 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 > > Thanks for the clarifiction. > > In your proposed new text, you state > > "...Routers MUST use IPv6-in-IPv6 tunneling, as > specified in [RFC2473] to include a new RPL Option in datagrams that > are sourced by other nodes..." > > Actually, isnt it true that this action ( use of tunnelling to include the > RPL option ) is nececssary for all packets, even for those sourced on the > router node itself ? > Basically, if the source router is not sure that the destination node is > within the RPL Instance, it musts use tunnelllig to include the RPL Option. > > > -Regards, Joseph > > > ------------------------------ > > Message: 5 > Date: Thu, 10 Nov 2011 09:03:01 -0800 > From: Jonathan Hui <jon...@cisco.com> > To: Richard Kelsey <richard.kel...@ember.com> > Cc: ipv6@ietf.org > Subject: Re: draft-ietf-6man-rpl-option questions > Message-ID: <50a9f9c5-8c71-4f5e-b084-a127b7e98...@cisco.com> > Content-Type: text/plain; charset=us-ascii > > > Hi Richard, > > On Nov 10, 2011, at 8:14 AM, Richard Kelsey wrote: > >> In section 4, "Router Behavior" draft-ietf-6man-rpl-option >> says: >> >> Routers MUST use IPv6-in-IPv6 tunneling, as specified in >> [RFC2473] to include a new RPL Option in datagrams that >> are sourced by other nodes. >> >> What destination should be used for the tunnel header? The >> router adding the RPL option may not know if the original >> destination is inside or outside the RPL domain. And if the >> original destination is outside the RPL domain, the router >> may not know the address of the border router that will >> forward the datagram outside. > > The tunnel header's destination should be the next RPL router along the path > towards the destination. If, for example, a router only knows the next-hop > destination (i.e. the DODAG Parent), then the tunnel header's destination > will be the DODAG Parent itself. Note that the original packet may traverse > multiple such tunnels within the same RPL domain in order to reach its > destination. Let me propose the following update to Section 4: > > 4. RPL Router Behavior > > To deliver an IPv6 datagram to its destination, a router may need to > insert a new RPL Option. Routers MUST use IPv6-in-IPv6 tunneling, as > specified in [RFC2473] to include a new RPL Option in datagrams that > are sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures > that the delivered datagram remains unmodified and that ICMPv6 errors > generated by inserting the RPL Option are sent back to the router > that generated the routing header. > > A RPL router chooses the next RPL router that should process the > original packet as the tunnel exit-point. In some cases, the tunnel > exit-point will be the final RPL router along a path towards the > original packet's destination and the original packet will only > traverse a single tunnel. One example is when the final destination > or the destination's attachment router is known to be within the same > RPL domain. > > In other cases, the tunnel exit-point will not be the final RPL > router along a path and the original packet may traverse multiple > tunnels to reach the destination. One example is when a RPL router > is simply forwarding a packet to one of its DODAG Parents. In this > case, the RPL router sets the tunnel exit-point to a DODAG Parent. > When forwarding the original packet hop-by-hop, the RPL router only > makes a determination on the next hop towards the destination. > > A RPL router receiving an IPv6-in-IPv6 packet destined to it > processes the tunnel packet as described in Section 3. of [RFC2473]. > Before IPv6 decapsulation, the RPL router MUST process the RPL Option > if one exists. If the router determines that it should forward the > original packet to another RPL router, it MUST encapsulate the packet > again using IPv6-in-IPv6 tunneling to include the RPL Option. Note > that fields within the RPL Option that do not change hop-by-hop MUST > remain the same as those received from the prior tunnel. > > To avoid fragmentation, it is desirable to employ MTU sizes that > allow for the header expansion (i.e. at least 1280 + 40 (outer IP > header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the > maximum RPL Option header size for a given RPL network. To take > advantage of this, however, the communicating endpoints need to be > aware of the MTU along the path (i.e. through Path MTU Discovery). > Unfortunately, the larger MTU size may not be available on all links > (e.g. 1280 octets on 6LoWPAN links). However, it is expected that > much of the traffic on these types of networks consists of much > smaller messages than the MTU, so performance degradation through > fragmentation would be limited. > >> Also, there are normative statements which use the term "RPL >> domain", such as >> >> Datagrams sent between nodes within a RPL domain MUST include >> a RPL Option or RPL Source Route Header (SRH) and MAY include >> both. >> >> but "RPL domain" is not defined. In particular, if a RPL >> router has a non-RPL-aware host, is the host inside the RPL >> domain? Or is the router then a border router and messages >> to the host need to be tunnelled to it? > > I agree that "RPL domain" is not well defined. But after some thought, I > think replacing with "RPL Instance" may be more appropriate. In particular, > we really want to limit the use of these RPL options/headers to a RPL > Instance, not just a collection of routers that are all operating RPL. > > If you agree to the above, I'll make 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
