[VRRP] vrrpv3 IPv4 pseudoheader

Manuel Mausz <manuel-vrrp@mausz.at> Mon, 26 May 2014 13:17 UTC

Return-Path: <manuel-vrrp@mausz.at>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CE11B1A0157 for <vrrp@ietfa.amsl.com>; Mon, 26 May 2014 06:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.167
X-Spam-Level: *
X-Spam-Status: No, score=1.167 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4mNT_50hBD6r for <vrrp@ietfa.amsl.com>; Mon, 26 May 2014 06:17:56 -0700 (PDT)
Received: from shell.clan-server.at (clan-server.at []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1821A0156 for <vrrp@ietf.org>; Mon, 26 May 2014 06:17:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shell.clan-server.at; h= message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=beta; bh=I07DxvyA4CLFUS5a5nsQJR5ep KNRaywTUti4GIomOXU=; b=R06G+3/KP0X7l5mH0v3wK1JQ4ElLb7j3zlv+8TSH1 XAa449yayFR9rQlMYDgYy+qNy+H95crLA11QjPV7kezqci1sX/4X43Vj53nWMJhH v8NwEaOOejMGnHZ2kaX0yz9ivAREnWgFb4W0cX1Bmv+qb4nb7iotU/JAIzwrKuTB Qw=
Received: (qmail 10806 invoked by uid 89); 26 May 2014 15:17:53 +0200
Received: from unknown (HELO xps14.lan) (manuel@mausz.at@ by shell.clan-server.at with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 May 2014 15:17:53 +0200
Message-ID: <53833EFC.9010100@mausz.at>
Date: Mon, 26 May 2014 15:17:48 +0200
From: Manuel Mausz <manuel-vrrp@mausz.at>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: vrrp@ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/vrrp/JpcDJfTJ5vBOJ3reW4iIQ28PqwM
Subject: [VRRP] vrrpv3 IPv4 pseudoheader
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp/>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 13:17:58 -0000

Hi list,

we recently run into an interoptability issue with two different vendors
using VRRP v3 with IPv4. The issue is: vendor #1 is calculating the
checksum with, vendor #2 without IPv4 pseudoheader.

The RFC isn't exactly clear about the IPv4 case. Section 5.2.8 mainly
cares about IPv6 ("next header field") and the reference is about IPv6 only.

There has already been some discussion about this ambiguity in 2012.
Sadly without any clear outcome. The discussion can be found at:

I've already contacted one of the vendors and as you might already guess
they fail to see any RFC violation.

Also the wireshark developers don't really know which checksum is
correct. They started to calculate the checksum with IPv4 pseudoheader
but recently added a knob to support both possible interpretations:

Calculating the checksum without IPv4 pseudoheader results in exactly
the same paket as using VRRP v2. The only difference is the version
field. At least as long you don't do any VRRP v2 authentication.

It would be nice if there can finally be some clarification.