Re: ICMP6 redirect

Andrew McGregor <> Tue, 24 July 2012 04:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF09611E8118 for <>; Mon, 23 Jul 2012 21:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pAKTMsergk-2 for <>; Mon, 23 Jul 2012 21:39:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1F3A211E8109 for <>; Mon, 23 Jul 2012 21:39:38 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so12363562pbc.31 for <>; Mon, 23 Jul 2012 21:39:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=yG2UUtEwB5/TU9+iZV89KCUT9XJTG/Znypf/p9ZsEGk=; b=LoBvXspP1GXrUI5hbxKSpFQ4VyjwLpcKASnAKAj/X9L8aPF2WxIiHEYsSFhZpRGtRJ 87ei0cz/TA8tEtdXBSIDY0YyEzrmDx4ZbPG1PKqYfimSBEhXq51Xn74tz+9HF71jnXfb UfvxrMKLqMmRo97Uyt/UsFCRVQE4r4WBIbLFvRkX+35wUq5bnHxCu5UYIkLBqgyu8Mr/ CSR6Ph5bf0XQX+itpeFrUPWT/QPsN8SGOShfm77KUZe54pOUI6G/yVrylKL2pO9rxa5S /z90gQ1yFrCFN0DcpWJe/+ysbaN7oFS6dLrsM6qr31yr1Obgi0lC86TQLFSIVxvRLqQC X3YQ==
Received: by with SMTP id ki5mr41363436pbc.10.1343104777894; Mon, 23 Jul 2012 21:39:37 -0700 (PDT)
Received: from ( []) by with ESMTPS id ny4sm11333781pbb.57.2012. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 21:39:37 -0700 (PDT)
Subject: Re: ICMP6 redirect
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_D92F7A67-30A8-439F-AC01-35ED48E03CC3"; protocol="application/pkcs7-signature"; micalg=sha1
From: Andrew McGregor <>
In-Reply-To: <>
Date: Tue, 24 Jul 2012 16:39:33 +1200
Message-Id: <>
References: <>
To: Hesham Soliman <>
X-Mailer: Apple Mail (2.1278)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jul 2012 04:39:39 -0000

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

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

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.