ICMP6 redirect

Andrew McGregor <andrewmcgr@gmail.com> Tue, 24 July 2012 03:46 UTC

Return-Path: <andrewmcgr@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2375A11E8104 for <ipv6@ietfa.amsl.com>; Mon, 23 Jul 2012 20:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl6A4AWRqIBx for <ipv6@ietfa.amsl.com>; Mon, 23 Jul 2012 20:46:10 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6634411E810E for <ipv6@ietf.org>; Mon, 23 Jul 2012 20:46:10 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so12293311pbc.31 for <ipv6@ietf.org>; Mon, 23 Jul 2012 20:46:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=0v+7YcsB2Cc77dX1TFcyHoIPBJEGqOn5Oz4AKD7/TY8=; b=lJxWtRZS+DveM8n4i/p7/C3ZWumsT9Q/fVImy10rkM+ruddTSiBF6VZzu3hXPjyu11 2aP6dkOnXIC1xglhC4dF+QpcIJevzOr3hEyjotvfTNCFRpjCxlfZVjx79UAwdRSj8dL8 YENCBvMnXpDIOEGfktKGRXSJTfdQCuMwGnJpeuCfUB/mxmynp+vDnQjXPDqEfLgjSCdv u0EbsY7KNlx1nV5A80xbzmt32VKNQysa3R4JSBNNfjLaci8+UtrcnhRvy7wb4cs9rBT3 hCM8Up9VLnkSyWUZzYasnlfVuNAFr9JNHsxYoiyvotx3lzzWeRhvgBiArWe27/+4l9HE 9NWQ==
Received: by 10.68.220.39 with SMTP id pt7mr41975322pbc.40.1343101570154; Mon, 23 Jul 2012 20:46:10 -0700 (PDT)
Received: from andrewm-lo.ws.atlnz.lc (gate1.alliedtelesyn.co.nz. [202.49.72.36]) by mx.google.com with ESMTPS id ql3sm11239178pbc.72.2012.07.23.20.46.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 20:46:09 -0700 (PDT)
From: Andrew McGregor <andrewmcgr@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6630FE46-C777-47AE-B6E7-23011799542B"; protocol="application/pkcs7-signature"; micalg=sha1
Subject: ICMP6 redirect
Date: Tue, 24 Jul 2012 15:46:04 +1200
Message-Id: <CD189A44-4258-42D9-81AB-28296A7BC4C1@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2012 03:46:11 -0000

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