Subject: ICMP6 redirect

From: Andrew McGregor <[email-masked]>
Date: Tue, 24 Jul 2012 15:46:04 +1200

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

---

From: Karl Auer <[email-masked]>
Date: Tue, 24 Jul 2012 14:09:21 +1000

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 ([email-masked])
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

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 24 Jul 2012 14:15:38 +1000

>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
>possible without a spec change?

=> You mean multiple LLA's for the same link? The MAC address is not
relevant here, it's about the LLA used on that link.

Hesham

>
>
>Andrew McGregor
>Allied Telesis 
>Labs--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 24 Jul 2012 16:33:22 +1200

> link-local address on the receiving interface"?

The latter.

Andrew

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 24 Jul 2012 16:39:33 +1200

> => You mean in 4861 or ICMPv6?

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

> 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 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?

> relevant here, it's about the LLA used on that link.

I mean multiple LLAs for the same link.  VRRPv3 was suggesting that the destination MAC address might help work out which LLA the host was using.

Andrew

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 24 Jul 2012 14:45:59 +1000

>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

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 25 Jul 2012 19:11:53 +1200

> 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

---

From: Philipp Kern <[email-masked]>
Date: Wed, 25 Jul 2012 11:19:08 +0200

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

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 25 Jul 2012 22:38:18 +1200

> segment? (But that's possibly an ops question.)

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

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 25 Jul 2012 21:08:56 +1000

>>>> that message reliably. If it uses the same address it uses for its
>>>>RAs,
>>>> it
>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. 

> and therefore you should not send redirects if you are not sending RAs?
>That works as a resolution for me, in terms of specs.

=> Yes. I don't think it implies that if you're forwarding you must send
RA's though :). They're two separate issues.
Anyone, that's my opinion given the way the spec is written. It's not
explicitly mentioned in 4861 that you can't send redirects unless you're
also sending RAs, but that seems implicit to me.

>
>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?

=> Well, knowing that someone's on-link is based on knowing that the
prefix is on-link. They all seem to be related to information communicated
in the RA. So it makes sense to me to tie this function to a router that
sends RAs. 

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

=> I don't know how common this is honestly. So I'll take your word with
caution. 

Hesham

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Jul 2012 10:36:10 -0700

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 
the destination ever move off-link. That issue is that the prefix 
information in the RAs time out based on the preferred/valid lifetime, 
and NUD doesn't affect that. Thus if the destination is no longer 
off-link, either the routers have to detect that and send a fake RA with 
the prefix with onlink=0, or communication will be broken until the 
valid lifetime of the prefix expires.

Redirects don't have that issue; NUD knows to ignore/discard the 
redirects when it doesn't get responses to the probes.

    Erik