[VRRP] VRRPv3 IPv6 RFC-5798 checksum

joe mcfar <jrtcmcfar@gmail.com> Mon, 07 May 2012 21:49 UTC

Return-Path: <jrtcmcfar@gmail.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E131721F846A for <vrrp@ietfa.amsl.com>; Mon, 7 May 2012 14:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZQb1hPN48uFx for <vrrp@ietfa.amsl.com>; Mon, 7 May 2012 14:49:48 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1C20F21F843E for <vrrp@ietf.org>; Mon, 7 May 2012 14:49:47 -0700 (PDT)
Received: by lagj5 with SMTP id j5so4323165lag.31 for <vrrp@ietf.org>; Mon, 07 May 2012 14:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=m0nSYnXPZcYQOLAMZxOle5P6jFIrbWUucbMDthDoQFs=; b=l6Fm4omQdk96TB6LSiahPjO53cg5EYnnNcakJEaTzWdjtkJrCHK4RY5+/6AQHEnh63 3orzXkE7B1sTP0tCvXq2Xki0TFXcKS528x9SA+5TsqeTpIA1nXwFOcAT70VNrnApKod8 I/9LCGYESS3XQ8EuN782LVEiENxQ1CNz04fufUM8xB2GSnA9qFffWp2LM5cgvnXFm7QM BoMjogNTqq1NgKZnUZrU1nTWHZ3ucW7I4WhznMZkenXTT9QhVu3UhHteBJbPNyZE2ceJ w5k9XukmcJ2DnB3x9sw1ur4SPrDDip5kpr1IjnU0Zwvh92F3AI2omybqy27V/pLtiFBo Jkag==
MIME-Version: 1.0
Received: by with SMTP id a9mr2573151lbk.102.1336427387031; Mon, 07 May 2012 14:49:47 -0700 (PDT)
Received: by with HTTP; Mon, 7 May 2012 14:49:46 -0700 (PDT)
Date: Mon, 7 May 2012 16:49:46 -0500
Message-ID: <CALsBhU9meNgbmh4vcXNHxeLNLxX6ER8-fQkbB-=Uu3fo2HGQyA@mail.gmail.com>
From: joe mcfar <jrtcmcfar@gmail.com>
To: vrrp@ietf.org
Content-Type: multipart/alternative; boundary=e0cb4efe2ee4ac106604bf793fb8
X-Mailman-Approved-At: Wed, 09 May 2012 08:46:06 -0700
Subject: [VRRP] VRRPv3 IPv6 RFC-5798 checksum
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
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, 07 May 2012 21:57:13 -0000

I am testing interoperability with one major vendor’s VRRPv3 IPv6
implementation and was surprised to  find that the vendor’s unit does not
include an IPv6 pseudo-header along with the VRRPv3 packet data when
calculating the checksum.   The current version of Wireshark (1.6.7) also
shows the VRRPv3 checksum as incorrect.  This would probably only be an
issue when trying to interoperate with another vendor’s implementation.

I’m interpreting RFC-5798 section 5.2.8 to say to calculate the checksum
over both the VRRPv3 packet data starting with the version field, AND over
the IPv6 pseudo-header (source, destination IPv6 addresses, upper layer
packet length, zero field, and next header of 112 for VRRP.)

Can someone on this mailing list verify my interpretation?


Joe McFarland