Andrew McGregor | 24 Jul 2012 05:46
Picon

ICMP6 redirect

I've come across what looks like a bug in the ICMPv6 spec. Specifically, RFC 4861 says that "A host MUST
silently discard any received Redirect message that does not satisfy all of the following validity
checks" amongst which is "The IP source address of the Redirect is the same as the current first-hop router
for the specified ICMP Destination Address."

Unfortunately, there is no way that a router can reliably generate that response, if it has more than one
link-local address, because the message that caused the redirect does not actually contain the router's
own address, and the router cannot know the content of the host's route table.

The VRRPv3 spec suggests that the destination MAC address for the packet causing the redirect is a
sufficient cue, but that cannot be true in the presence of multiple link-local addresses, which is
guaranteed to happen in VRRP (in some cases).

What is the correct method of constructing ICMPv6 redirects in the presence of multiple link-locals for
the same MAC address? Is it even possible without a spec change?

I have an (untested) idea that one might be able to construct a router advertisement that achieves the same
goal as a redirect to an onlink address, which should be processed and does not require guessing which link
local is appropriate.

We have tested various of our own and other vendors products, and nobody reliably gets this right
(unsurprising, as it is inherently impossible).

I will be at IETF 84 if face-to-face discussion would help.

Andrew McGregor
Allied Telesis Labs
Attachment (smime.p7s): application/pkcs7-signature, 2330 bytes
--------------------------------------------------------------------
(Continue reading)

Karl Auer | 24 Jul 2012 06:09
Picon

Re: ICMP6 redirect

On Tue, 2012-07-24 at 15:46 +1200, Andrew McGregor wrote:
> Unfortunately, there is no way that a router can reliably generate
> that response, if it has more than one link-local address

Do you mean "has more than one link-local address" or "has more than one
link-local address on the receiving interface"?

Regards,K.

--

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer <at> biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Andrew McGregor | 24 Jul 2012 06:33
Picon

Re: ICMP6 redirect


On 24/07/2012, at 4:09 PM, Karl Auer wrote:

> On Tue, 2012-07-24 at 15:46 +1200, Andrew McGregor wrote:
>> Unfortunately, there is no way that a router can reliably generate
>> that response, if it has more than one link-local address
> 
> Do you mean "has more than one link-local address" or "has more than one
> link-local address on the receiving interface"?
> 
> Regards,K.

The latter.

Andrew

Attachment (smime.p7s): application/pkcs7-signature, 2330 bytes
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Hesham Soliman | 24 Jul 2012 06:15

Re: ICMP6 redirect


>I've come across what looks like a bug in the ICMPv6 spec.

=> You mean in 4861 or ICMPv6?

>Specifically, RFC 4861 says that "A host MUST silently discard any
>received Redirect message that does not satisfy all of the following
>validity checks" amongst which is "The IP source address of the Redirect
>is the same as the current first-hop router for the specified ICMP
>Destination Address."
>
>Unfortunately, there is no way that a router can reliably generate that
>response, if it has more than one link-local address, because the message
>that caused the redirect does not actually contain the router's own
>address, and the router cannot know the content of the host's route table.

=> The router doesn't need to know the host's route table, it knows which
address it included in its RAs, which is what the host records.
I'm not sure why you think that there is no way the router can construct
that message reliably. If it uses the same address it uses for its RAs, it
can construct the message.

>
>The VRRPv3 spec suggests that the destination MAC address for the packet
>causing the redirect is a sufficient cue, but that cannot be true in the
>presence of multiple link-local addresses, which is guaranteed to happen
>in VRRP (in some cases).
>
>What is the correct method of constructing ICMPv6 redirects in the
>presence of multiple link-locals for the same MAC address? Is it even
(Continue reading)

Andrew McGregor | 24 Jul 2012 06:39
Picon

Re: ICMP6 redirect


On 24/07/2012, at 4:15 PM, Hesham Soliman wrote:

> 
>> I've come across what looks like a bug in the ICMPv6 spec.
> 
> => You mean in 4861 or ICMPv6?

That's what I'm trying to work out, and I could see two potential solutions.

> 
>> Specifically, RFC 4861 says that "A host MUST silently discard any
>> received Redirect message that does not satisfy all of the following
>> validity checks" amongst which is "The IP source address of the Redirect
>> is the same as the current first-hop router for the specified ICMP
>> Destination Address."
>> 
>> Unfortunately, there is no way that a router can reliably generate that
>> response, if it has more than one link-local address, because the message
>> that caused the redirect does not actually contain the router's own
>> address, and the router cannot know the content of the host's route table.
> 
> => The router doesn't need to know the host's route table, it knows which
> address it included in its RAs, which is what the host records.
> I'm not sure why you think that there is no way the router can construct
> that message reliably. If it uses the same address it uses for its RAs, it
> can construct the message.

Ah.  Well, that will certainly help, but consider a situation where there are no RAs, or the host has a manual
static route.  Arguably misconfigured, I know, but if we have that situation a router cannot know what
(Continue reading)

Hesham Soliman | 24 Jul 2012 06:45

Re: ICMP6 redirect

>>
>>=> The router doesn't need to know the host's route table, it knows which
>> address it included in its RAs, which is what the host records.
>> I'm not sure why you think that there is no way the router can construct
>> that message reliably. If it uses the same address it uses for its RAs,
>>it
>> can construct the message.
>
>Ah.  Well, that will certainly help, but consider a situation where there
>are no RAs, 

=> Where is that situation possible/deployed? It's hard to consider
something that is against the spec you're commenting on :)

>or the host has a manual static route.  Arguably misconfigured, I know,
>but if we have that situation a router cannot know what address the host
>was sending to, only that it is one of its own.  For that matter, there
>may be many RAs being generated through that interface, and do we
>necessarily know which it was that caused the host/peer to route through
>us?

=> Well, it depends on your implementation I guess. If your router
randomly assigns src addresses to RAs with arbitrary prefixes then I can
see where it would get confusing very quickly. But if they're doing it in
a structured way it will work.

That's why I raised a comment against your premise of "no way to do it
reliably". There is definitely a way to do it reliably.

Hesham
(Continue reading)

Andrew McGregor | 25 Jul 2012 09:11
Picon

Re: ICMP6 redirect


On 24/07/2012, at 4:45 PM, Hesham Soliman wrote:

>>> 
>>> => The router doesn't need to know the host's route table, it knows which
>>> address it included in its RAs, which is what the host records.
>>> I'm not sure why you think that there is no way the router can construct
>>> that message reliably. If it uses the same address it uses for its RAs,
>>> it
>>> can construct the message.
>> 
>> Ah.  Well, that will certainly help, but consider a situation where there
>> are no RAs, 
> 
> => Where is that situation possible/deployed? It's hard to consider
> something that is against the spec you're commenting on :)

Sure, it is not a situation contemplated by the ND spec.  So, do you mean to say it is incorrect configuration
for a router to have forwarding on and not be sending RAs, and therefore you should not send redirects if you
are not sending RAs?  That works as a resolution for me, in terms of specs.

However, if it is not a misconfiguration, and you wish to redirect traffic that has a better first hop, or is
on-link but the host for whatever reason does not know that, is that possible?  Should it be?

I suspect it is a common situation, no matter that it's completely broken.

Andrew
Attachment (smime.p7s): application/pkcs7-signature, 2330 bytes
--------------------------------------------------------------------
(Continue reading)

Philipp Kern | 25 Jul 2012 11:19
Picon

Re: ICMP6 redirect

Andrew,

am Wed, Jul 25, 2012 at 07:11:53PM +1200 hast du folgendes geschrieben:
> However, if it is not a misconfiguration, and you wish to redirect traffic
> that has a better first hop, or is on-link but the host for whatever reason
> does not know that, is that possible?  Should it be?

I still wonder how the devices should figure out that there's a better first
hop apart from network misdesigns[1].

Are people really diverging from "one subnet per VLAN" with two routers
connected to a segment and routing the traffic to the other router over that
segment? (But that's possibly an ops question.)

Kind regards
Philipp Kern

[1] http://www.cymru.com/gillsr/documents/icmp-redirects-are-bad.pdf
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Andrew McGregor | 25 Jul 2012 12:38
Picon

Re: ICMP6 redirect


On 25/07/2012, at 9:19 PM, Philipp Kern wrote:

> Andrew,
> 
> am Wed, Jul 25, 2012 at 07:11:53PM +1200 hast du folgendes geschrieben:
>> However, if it is not a misconfiguration, and you wish to redirect traffic
>> that has a better first hop, or is on-link but the host for whatever reason
>> does not know that, is that possible?  Should it be?
> 
> I still wonder how the devices should figure out that there's a better first
> hop apart from network misdesigns[1].
> 
> Are people really diverging from "one subnet per VLAN" with two routers
> connected to a segment and routing the traffic to the other router over that
> segment? (But that's possibly an ops question.)
> 
> Kind regards
> Philipp Kern

This originally came in the context of VRRP v3. If you want to run some dynamic routing protocol at the same
time as VRRP on the same VLAN, you need another link-local address to talk to your routing peers with, since
there's no way for the non-master routers to use the VRRP address.  So, you have two (or more) link locals on
the same VLAN.  Ideally only the VRRP one should be used for sending RAs, of course.

I totally agree that RAs should take care of this, and in fact I think one way to resolve the conundrum is to
craft an RA to specifically tell the host it is onlink with that exact destination, rather than a redirect,
since as I read the RA processing rules, it does not matter what source address the router uses in that case.

Andrew
(Continue reading)

Erik Nordmark | 25 Jul 2012 19:36
Picon
Favicon

Re: ICMP6 redirect

On 7/25/12 3:38 AM, Andrew McGregor wrote:

> This originally came in the context of VRRP v3. If you want to run
> some dynamic routing protocol at the same time as VRRP on the same
> VLAN, you need another link-local address to talk to your routing
> peers with, since there's no way for the non-master routers to use
> the VRRP address.  So, you have two (or more) link locals on the same
> VLAN.  Ideally only the VRRP one should be used for sending RAs, of
> course.

Agreed.
Sounds like that is a small implementation matter in the router software.

> I totally agree that RAs should take care of this, and in fact I
> think one way to resolve the conundrum is to craft an RA to
> specifically tell the host it is onlink with that exact destination,
> rather than a redirect, since as I read the RA processing rules, it
> does not matter what source address the router uses in that case.

I guess I don't understand the problem you want to solve. Can you clarify?

I thought the problem  was that the 1st hop was suboptimal, and the 1st 
hop router wants to send a redirect to tell the host to use a different 
1st hop router to get to the offlink destination.
You can't do that by faking an RA.

But above it sounds like the destination is on-link. Is that the problem 
you want to solve?

While you can fake an RA for that, it runs into a issue with NUD should 
(Continue reading)

Hesham Soliman | 25 Jul 2012 13:08

Re: ICMP6 redirect

>
>
>
>>>> 
>>>> => The router doesn't need to know the host's route table, it knows
>>>>which
>>>> address it included in its RAs, which is what the host records.
>>>> I'm not sure why you think that there is no way the router can
>>>>construct
>>>> that message reliably. If it uses the same address it uses for its
>>>>RAs,
>>>> it
>>>> can construct the message.
>>> 
>>> Ah.  Well, that will certainly help, but consider a situation where
>>>there
>>> are no RAs, 
>> 
>> => Where is that situation possible/deployed? It's hard to consider
>> something that is against the spec you're commenting on :)
>
>Sure, it is not a situation contemplated by the ND spec.  So, do you mean
>to say it is incorrect configuration for a router to have forwarding on
>and not be sending RAs,

=> This sentence should not imply the following words after "therefore". I
think a router can be forwarding without sending RAs.
But I also think that if you're going to send redirects, you must have
sent an RA. 

(Continue reading)


Gmane