Subject: Redirected Header (Forwarded/Originating Packet)

From: Timothy Winters <[email-masked]>
Date: Tue, 9 Aug 2016 09:14:15 -0400

Hello,

The UNH-IOL has seen several different implementations with varied
interpretations the following line from RFC 4861 Section 8.2 regarding what
should be included in the Redirect Header of an ICMPv6 Redirect message.

"Redirected Header: as much of the forwarded packet as can
             fit without the redirect packet exceeding the minimum MTU
             required to support IPv6 as specified in [IPv6]."

My interpretation has been that the redirected header should be the
forwarded packet, not the originating packet.   Recently we've seen Linux
based routers use   the originating packet.

My guess is they read this line from RFC 4861 Section 4.6.3
The original packet truncated to ensure that the
                     size of the redirect message does not exceed the
                     minimum MTU required to support IPv6 as specified
                     in [IPv6]."

The reason that I'm asking is we have seen host that don't process the
Redirect message unless it's the forwarding packet.   I want to make sure
that we are telling implementations the correct behavior.

~Tim

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Philip Homburg <[email-masked]>
Date: Tue, 09 Aug 2016 16:18:42 +0200

>that we are telling implementations the correct behavior.

Am I correct to assume that only difference is the hlim field?

I'm really curious why those hosts do the check and to some extend how they can
tell. It means going back to the original packet and checking that the one in
the error ICMP has its hlim reduced.

Though I have to check my own implementation. It's too easy to get this wrong.

---

From: Timothy Winters <[email-masked]>
Date: Tue, 9 Aug 2016 10:25:57 -0400

Hi Philip,

You are correct is the hop limit field is decremented.   I have no idea why
the host are choosing to check that field, but my best guess is that they
want to confirm it's being forwarded by the next-hop router?   As opposed
to anyone sending them Redirect?

~Tim

--

---

From: Philip Homburg <[email-masked]>
Date: Tue, 09 Aug 2016 16:38:27 +0200

>to anyone sending them Redirect?

Well, the redirect has to come from an onlink node. So you have to rely on L2
filtering anyhow to prevent rogue RA/NA.

But I can understand going the extra mile and checking the redirected packet.
But in that case, I would check fields that are hard to guess, for example TCP
seqence numbers. Checking hlim, which is more or less constant for most stacks
and only 8 bit if you want to brute force sounds like a waste of time.

---

From: Hemant Singh <[email-masked]>
Date: Tue, 9 Aug 2016 11:02:25 -0400

Section 8.1 of RFC 4861 clarifies this confusion.

(a) The IP Source Address is the router link-local address.  A packet with
a link-local source is not a forwarded packet.
(b) The IP Hop Limit is 255, i.e., the packet is not a forwarded packet.

Hemant

---

From: Philip Homburg <[email-masked]>
Date: Tue, 09 Aug 2016 17:07:27 +0200

>(b) The IP Hop Limit is 255, i.e., the packet is not a forwarded packet.

We were discussing the hlim field in the redirected header, i.e. the copy of the
packet that triggered the redirect, not the outer IPv6 header of the redirect
ICMP itself.

---

From: Hemant Singh <[email-masked]>
Date: Tue, 9 Aug 2016 11:56:29 -0400

Tim,

Sorry, I missed the inner hlim in the email.

The Redirect is a message generated by the router and thus the Redirect is
not really a forwarded packet.  An implementation has no business to change
the hlim IP header of the copied packet.   For reference, please check what
do ICMPv6 Error messages from RFC 4443 do for the inner hlim field; these
messages also have to include a copy of the packet.   We should have
consistent behavior for all such ICMPv6 messages.

Hemant

---

From: Timothy Winters <[email-masked]>
Date: Tue, 9 Aug 2016 12:59:17 -0400

Hi Hemant,

So my question is which packet that triggers the Redirect.  A redirect is
only transmitted after you forward the packet.  The issue is which packet
gets copied into the Redirect message.  The originating packet or the
forwarded packet?

~Tim

--

---

From: Hemant Singh <[email-masked]>
Date: Tue, 9 Aug 2016 15:22:27 -0400

Hi Tim,

Got it.   I agree the text in section 4.6.3 is inconsistent with the text
in section 8.2.   Section 8.2 is correct for text because the router has
completed the layer-3 forwarding lookup and it's during the layer-2
forwarding lookup, the IPv6 ND Neighbor Cache and the Destination cache are
available.  These caches tell the router the packet source is on-link and
the packet IP destination is not destined to the router nor is the packet
IP destination a multicast destination.  Thus, the router knows a Redirect
has to be issued.  At this juncture, the router has access only to the
forwarded packet.  The router copies the packet before forwarding and uses
the copy in the Redirect.

Hemant

On Tue, Aug 9, 2016 at 12:59 PM, Timothy Winters <[email-masked]>
wrote:

> Now offering testing for SDN applications and controllers in our SDN
> switch test bed. Learn more today http://bit.ly/SDN_IOLPR
>

---

From: [email-masked]
Date: Wed, 10 Aug 2016 10:29:09 +0200

Tim,

I think it is implementation dependent.
It depends on where in the forwarding path the redirect check is done in relation to the hop limit decrement.

Best regards,
Ole

> On 09 Aug 2016, at 15:14, Timothy Winters <[email-masked]> wrote:
> 
> Hello,
> 
> The UNH-IOL has seen several different implementations with varied interpretations the following line from RFC 4861 Section 8.2 regarding what should be included in the Redirect Header of an ICMPv6 Redirect message.
> 
> My interpretation has been that the redirected header should be the forwarded packet, not the originating packet.   Recently we've seen Linux based routers use   the originating packet.
> 
> The reason that I'm asking is we have seen host that don't process the Redirect message unless it's the forwarding packet.   I want to make sure that we are telling implementations the correct behavior.
> 
> ~Tim
> 
> --
> Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Timothy Winters <[email-masked]>
Date: Wed, 10 Aug 2016 07:12:49 -0400

Hi Ole,

If this is true, either packet is ok to put in the Redirected Header from
the router point of view.   Based on that Host receiving redirects
shouldn't be dropping them depending on what's in the Redirected Header?

~Tim

--

---

From: [email-masked]
Date: Wed, 10 Aug 2016 13:20:03 +0200

Tim,

> If this is true, either packet is ok to put in the Redirected Header from the router point of view.   Based on that Host receiving redirects shouldn't be dropping them depending on what's in the Redirected Header?

indeed.
it is not specified in any RFC that the host receiving the redirect should check the hop limit of the inner packet. for good reason.

I don't see what checking that would achieve either, compared to the already described checks in the RFC.

Cheers,
Ole