Hi Vishwas,
But by specifying a RH4_MIN_MTU, we avoid the need for tunnels.
Without tunnels, I'm not sure there's a good use case for ICMP errors
caused by RH4 headers to go back to the inserting node rather than the
source. If the packet can't be delivered because the source route is
bad, that's not any different than a routing failure. If the packet
can't be delivered because it is too big, then a packet too big
message with MTU set to RH4_MIN_MTU - MAX_RH4_SIZE should be sent to
the source. Are there specific ICMP errors you have in mind that
should be sent to the inserting node rather than the source?
--
Jonathan Hui
On Jun 4, 2010, at 8:21 AM, Vishwas Manral wrote:
Hi Jonathan,
If an intermediate device fiddles with a packet, it should get the
ICMP message. So if the ICMP message states error in RH4 header the
ingress may not be able to do much.
In a tunnel case the following happens:
It is possible that one of the routers along the tunnel interior
might encounter an error while processing the datagram, causing it
to
return an ICMP [RFC-792] error message to the encapsulator at the IP
Source of the tunnel. Unfortunately, ICMP only requires IP routers
to return 8 bytes (64 bits) of the datagram beyond the IP header.
This is not enough to include the entire encapsulated header. Thus,
it is not generally possible for an encapsulating router to
immediately reflect an ICMP message from the interior of a tunnel
back to the originating host.
However, by carefully maintaining "soft state" about its tunnels,
the
encapsulator can return accurate ICMP messages in most cases.
You can have the same behavior for ICMP in your case too is what I
have been trying to say.
Thanks,
Vishwas
On Fri, Jun 4, 2010 at 8:16 AM, Jonathan Hui <[email protected]>
wrote:
Hi Vishwas,
If we go down the route of specifying a RH4_MIN_MTU, I'm not so
sure we want
to send the ICMP message to any place other than the source.
Destination
unreachable messages should go to the source. Packet too big
messages
should also go back to the source (after the RPL edge router does
its magic
to remove any side effects of RH4 headers).
Sending the ICMP message back to the source would maintain the same
prevalent behavior within IP today.
--
Jonathan Hui
On Jun 3, 2010, at 10:40 PM, Vishwas Manral wrote:
Hi JP,
The approach is good, we however still need to solve the ICMP
message
being sent to the source not the edge of the RPL network.
We can probably use the addr[0] approach which was discussed
earlier.
Thanks,
Vishwas
On Thu, Jun 3, 2010 at 10:35 PM, JP Vasseur <[email protected]> wrote:
Thanks again for the feed-back. Does the WG support this approach ?
Thanks.
JP.
On Jun 4, 2010, at 6:30 AM, Jonathan Hui wrote:
Hi Erik,
On Jun 3, 2010, at 2:10 AM, Erik Nordmark wrote:
On 06/ 3/10 01:03 AM, JP Vasseur wrote:
We can use the outlined approach as long as we can require such
media
to
support a MTU for IP packets that is slightly larger than 1280.
Thus we'd need a maximum size for the amount the ROLL ingress
would add
to the packet (RH4 and the HBH), and then require that the ROLL
links
support at least 1280 plus that max. Essentially a ROLL_MIN_MTU.
That would ensure that the ROLL ingress would never need to
fragment a
1280 byte packet. And for packets larger than 1280, the
rewriting of
the
ICMP errors at the ROLL boundary would make path MTU discovery
work.
But if we can't mandate such a ROLL_MIN_MTU, then the sensible
approach
would seem to be to do IP in IP encapsulation at the ROLL
ingress.
Thanks for all your thoughts on this subject. The two options are
clear.
Of the two choices, I prefer to specify a ROLL_MIN_MTU and avoid
IP in
IP
encapsulation just to support routing. The former approach
seems to be
less
onerous on resource constrained nodes that are expected within a
RPL
network. It avoids one possible source of IP-layer
fragmentation. Of
course, as you noted, the edge router must not allow any side
effects of
RH4
to escape the RPL network, which is really the intended use of RH4
anyway.
It's also important that we include the rpl-option overhead in
ROLL_MIN_MTU, so we'll have to specify a maximum for both the
rpl-option
and
rpl-routing-header (as you noted in the Anaheim meeting).
In 6LoWPAN networks, while RFC 4944 indicates a MTU of 1280
bytes, the
fragmentation mechanism does support up to 2048 bytes so that is
comforting.
So far, I'm not aware of any existing links intended for use
with RPL
that
cannot support an MTU that is a bit larger than 1280 bytes.
If people think specifying a ROLL_MIN_MTU is reasonable, we'll
submit an
update to the rpl-routing-header draft that incorporates these
changes
and
the several other ones brought up over the past week.
--
Jonathan Hui
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/
ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
