From jrtcmcfar@gmail.com  Mon May  7 14:49:48 2012
Return-Path: <jrtcmcfar@gmail.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) 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-Level: 
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.215.44]) 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 10.112.37.201 with SMTP id a9mr2573151lbk.102.1336427387031; Mon, 07 May 2012 14:49:47 -0700 (PDT)
Received: by 10.112.30.167 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

--e0cb4efe2ee4ac106604bf793fb8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I am testing interoperability with one major vendor=92s VRRPv3 IPv6
implementation and was surprised to  find that the vendor=92s 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=92s implementation.



I=92m 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?



Thanks,

Joe McFarland

--e0cb4efe2ee4ac106604bf793fb8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



<p class=3D"MsoNormal">I am testing interoperability with one major vendor=
=92s VRRPv3
IPv6 implementation and was surprised to =A0find that the vendor=92s unit d=
oes
not include an IPv6 pseudo-header along with the VRRPv3 packet data when
calculating the checksum.=A0 =A0The current version of Wireshark (1.6.7)
also shows the VRRPv3 checksum as incorrect.=A0 This would probably only be
an issue when trying to interoperate with another vendor=92s implementation=
.</p>

<p class=3D"MsoNormal">=A0</p>

<p class=3D"MsoNormal">I=92m interpreting RFC-5798 section 5.2.8 to say to =
calculate
the checksum over both the VRRPv3 packet data starting with the version fie=
ld,
AND over the IPv6 pseudo-header (source, destination IPv6 addresses, upper
layer packet length, zero field, and next header of 112 for VRRP.) </p>

<p class=3D"MsoNormal">=A0</p>

<p class=3D"MsoNormal">Can someone on this mailing list verify my interpret=
ation?</p>

<p class=3D"MsoNormal">=A0</p>

<p class=3D"MsoNormal">Thanks,</p>

<p class=3D"MsoNormal">Joe McFarland</p>


--e0cb4efe2ee4ac106604bf793fb8--

From tomosann@gmail.com  Wed May  9 20:04:30 2012
Return-Path: <tomosann@gmail.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32EE9E8006 for <vrrp@ietfa.amsl.com>; Wed,  9 May 2012 20:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YzYQkFu1IVUK for <vrrp@ietfa.amsl.com>; Wed,  9 May 2012 20:04:30 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6AD21F8471 for <vrrp@ietf.org>; Wed,  9 May 2012 20:04:23 -0700 (PDT)
Received: by bkty8 with SMTP id y8so980102bkt.31 for <vrrp@ietf.org>; Wed, 09 May 2012 20:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OWDb8AKwrFnI4w5MlAo/fS68NI0JY0ZAPrFGH/p/0RY=; b=ERLlUXT0Bx0gV4GBnod2FAJ/zTc6XZlK4K4JFId8I47PtBC/TgOJtjsxIBkMcrfbpt JQAfZW7bHtnKIDVJcNBqlt8Y90EAfdoPxCp0hgP04PYgYA9iyCJCVo470YGRXUMU2y4x 1FltZfZYShVQ5BPRVToKb3YrT6+x3+brT4LVErIhYArS8Ple6pFxFaoizNVJEDmThaWA 0grWSibjc6ETo4QTmIclKo9ZIPxdwJc/4G6GAG4GcPdS7fjo2Ysch95zex9bgjiTfxUq zVLz63RKufP9Yimd+8UdJ/q/0gnginUs1W3dEsl/gUEK5md1LqXEzyAfo3Mbdxh18ArP qn0g==
MIME-Version: 1.0
Received: by 10.204.157.144 with SMTP id b16mr987706bkx.12.1336619062474; Wed, 09 May 2012 20:04:22 -0700 (PDT)
Sender: tomosann@gmail.com
Received: by 10.204.179.129 with HTTP; Wed, 9 May 2012 20:04:22 -0700 (PDT)
In-Reply-To: <CALsBhU9meNgbmh4vcXNHxeLNLxX6ER8-fQkbB-=Uu3fo2HGQyA@mail.gmail.com>
References: <CALsBhU9meNgbmh4vcXNHxeLNLxX6ER8-fQkbB-=Uu3fo2HGQyA@mail.gmail.com>
Date: Thu, 10 May 2012 12:04:22 +0900
X-Google-Sender-Auth: FAab4xb7ucAMYYgi-wMVQVSwRd8
Message-ID: <CAH=tA5t0z=7cD8miX8BRBFebYx6KiVyHkDs+oERVPvuLYtpS9w@mail.gmail.com>
From: Tomoyuki Sahara <sahara@surt.net>
To: joe mcfar <jrtcmcfar@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: vrrp@ietf.org
Subject: Re: [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: Thu, 10 May 2012 03:04:31 -0000

Hi,

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

Our implementation calculates the checksum with IPv6 pseudo-header as
described in RFC5798.  IMHO that vendor's implementation does not conform
to RFC5798 and so it is not interoperable with RFC5798 implementations.


Thanks,
Tomoyuki

From kura@iij.ad.jp  Mon May 14 19:41:51 2012
Return-Path: <kura@iij.ad.jp>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF69E8006 for <vrrp@ietfa.amsl.com>; Mon, 14 May 2012 19:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.32
X-Spam-Level: **
X-Spam-Status: No, score=2.32 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 AF7nspeLYqMf for <vrrp@ietfa.amsl.com>; Mon, 14 May 2012 19:41:51 -0700 (PDT)
Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE59E8004 for <vrrp@ietf.org>; Mon, 14 May 2012 19:41:50 -0700 (PDT)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=From:To: Subject:Mime-Version:Content-Type:Message-Id:Date; i=kura@iij.ad.jp; s=omgo1; t= 1337049709; x=1338259309; bh=qkP1vwPZsmyU4Xg2EqFIF3NFVMdtrqclzGKeCnauZdk=; b=gx/ hgvuxzGpSnN/Z4beCJeNMzO421yGxD/CtQA4+kfZIiP8FQi6wR6HokTFLkTwcunpdgIZ4vyT421e/ gq1pWjqa14Si5/FrNEYtsiu5QmQyRCG1waipimbb1c84pxOIi47JUnWrR9C/tAE2Lm2axFaPNxd6G xBZqUWHLo3gK0M=;
Received: by omgo.iij.ad.jp (mo30) id q4F2fnVG019726; Tue, 15 May 2012 11:41:49 +0900
Received: by melchior.iij.ad.jp (Postfix) id 38FF8108E26; Tue, 15 May 2012 11:41:48 +0900 (JST)
From: kura@iij.ad.jp
To: vrrp@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Mailer: mnews [version 1.22PL7] 2003-09/29(Mon)
Message-Id: <20120515024148.38FF8108E26@melchior.iij.ad.jp>
Date: Tue, 15 May 2012 11:41:48 +0900 (JST)
Subject: Re: [VRRP] RFC5798 - clarification on checksum calculation
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: Tue, 15 May 2012 02:41:51 -0000

Hello list,

Has there been any progress with regard to this topic?
I know that in an implementation of VRRPv3 for IPv4 the checksum
is calculated without pseudo-header currently, but I believe that
pseudo-header should be involved in the calculation as same as
IPv6 case.

Regards,
-- 
Tomohiko Kurahashi <kura@iij.ad.jp>


From: sahara@surt.net
Date: Mon Apr 02 2012 20:41:51 JST
>
> Forwarded.
> Any other VRRPv3/IPv4 implementation?
> 
> 
> Thanks,
> Tomoyuki
> 
> 
> Date: Mon, 2 Apr 2012 03:26:15 +0200
> Subject: Re: [VRRP] RFC5798 - clarification on checksum calculation
> From: Hermin Anggawijaya <hermin.anggawijaya@gmail.com>
> To: Tomoyuki Sahara <sahara@surt.net>
> 
> Sahara-san
> 
> Thanks for your input.
> 
> Anyone else with either/other interpretation of the clause ?
> 
> 
> Thanks
> 
> On Mon, Apr 2, 2012 at 1:48 AM, Tomoyuki Sahara <sahara@surt.net> wrote:
> > Hi,
> > 
> > On Thu, Mar 29, 2012 at 4:29 PM, Hermin Anggawijaya
> > <hermin.anggawijaya@gmail.com> wrote:
> >> Would someone be able to help clarifying RFC5798 Sec. 5.2.8 on
> >> checksum for me please...
> >> 
> >> It says that
> >> 
> >>  "The checksum is the 16-bit one's complement of the one's complement
> >>   sum of the entire VRRP message starting with the version field and a
> >>   "pseudo-header" as defined in Section 8.1 of [RFC2460].  The next
> >>   header field in the "pseudo-header" should be set to 112 (decimal)
> >>   for VRRP.  For computing the checksum, the checksum field is set to
> >>   zero.  See RFC1071 for more detail [RFC1071]."
> >> 
> >> My interpretation of the above clause is, for IPv4 VRRP the checksum would be
> >> defined as:
> >> 
> >> "The checksum is the 16-bit one's complement of the one's complement
> >>  sum of the entire VRRP message starting with the version field"
> >> 
> >> as per RFC 3768, instead of involving "pseudo header" (as defined in
> >> Section 8.1 of [RFC2460]).
> > 
> > My understanding is only reference text ("as defined in Section 8.1 of
> > [RFC2460]") is irrelevant for IPv4.  Our implementation calculates checksum
> > including pseudo header as for TCP/UDP/DCCP.
> > 
> >> If my interpretation is correct, would it be useful to change the text to
> >> reflect specific checksum detail for IPv4 ?
> > 
> > My interpretation is different from yours but clarification should be
> > very useful.
> > It's vital for interoperable implementations of VRRPv3/IPv4.
> > 
> > 
> > Thanks,
> > Tomoyuki

From hermin.anggawijaya@gmail.com  Tue May 15 14:17:27 2012
Return-Path: <hermin.anggawijaya@gmail.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797CC21F863C for <vrrp@ietfa.amsl.com>; Tue, 15 May 2012 14:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 GME5ubEKvApK for <vrrp@ietfa.amsl.com>; Tue, 15 May 2012 14:17:26 -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 B237321F8703 for <vrrp@ietf.org>; Tue, 15 May 2012 14:17:26 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so161641pbc.31 for <vrrp@ietf.org>; Tue, 15 May 2012 14:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=aqIwnANOJ5a3uEOvgxU9zE7DSDmO8htBlP2twf0BEIE=; b=gq917P0l1trtvGfjrdw53WZgadmEE/r1b9RKFKjj6n6rNPDGGHGB/m1/gouU0/2W7h 3O4fvkp9el/gS6vnS/6c78UTC2inkysa5VEcqC2I1b/fb0VVSwbXJDpazukQAO/tBy2C KXO7HppKkQXNWKViVhDqEMzJCAAEuxkuLZEqtBFb4G8YtdsrDN1nhJ0fsB9SPrtg40H4 djQ47Rzgn3DWdF5bwsPYszoK/1wogRRcKfCMuri+ATDMxML118UGl01ivLXyyfDnHSAl sguYsoin6Q0A3omWNZSXywW/o81xLbg4kPxM96DX4cLPan8KnSUhW1711f4XIdBTK/ge 9UDg==
MIME-Version: 1.0
Received: by 10.68.129.131 with SMTP id nw3mr9418423pbb.150.1337116646216; Tue, 15 May 2012 14:17:26 -0700 (PDT)
Received: by 10.143.58.21 with HTTP; Tue, 15 May 2012 14:17:25 -0700 (PDT)
In-Reply-To: <CAJgsEzXL5iRqwGuea0OEpa9cUYOQtA=rv957bGh+NzYb4c8bgg@mail.gmail.com>
References: <20120515024148.38FF8108E26@melchior.iij.ad.jp> <CAJgsEzXL5iRqwGuea0OEpa9cUYOQtA=rv957bGh+NzYb4c8bgg@mail.gmail.com>
Date: Wed, 16 May 2012 09:17:25 +1200
Message-ID: <CAJgsEzWTSsc2=O3=93mAuhn+ETcHn8LgHfikbrZOLSAq3S7WGA@mail.gmail.com>
From: Hermin Anggawijaya <hermin.anggawijaya@gmail.com>
To: vrrp@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [VRRP] Fwd:  RFC5798 - clarification on checksum calculation
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: Tue, 15 May 2012 21:17:27 -0000

Hello

I am thinking of submitting an errata for RFC 5798 Sec. 5.2.8 to make
it more precise in describing the checksum calculation for each address fam=
ily.

But reading a few responses here, I gathered that there is no general
agreement as to the original intention of the text,
I believe that for IPv4, the checksum is calculated without
pseudo-header so that it is backward compatible with RFC 3768.

Any other opinions - particularly from original authors ?


Kind Regards

Hermin Anggawijaya



On Tue, May 15, 2012 at 2:41 PM, =A0<kura@iij.ad.jp> wrote:
> Hello list,
>
> Has there been any progress with regard to this topic?
> I know that in an implementation of VRRPv3 for IPv4 the checksum
> is calculated without pseudo-header currently, but I believe that
> pseudo-header should be involved in the calculation as same as
> IPv6 case.
>
> Regards,
> --
> Tomohiko Kurahashi <kura@iij.ad.jp>
>
>
> From: sahara@surt.net
> Date: Mon Apr 02 2012 20:41:51 JST
>>
>> Forwarded.
>> Any other VRRPv3/IPv4 implementation?
>>
>>
>> Thanks,
>> Tomoyuki
>>
>>
>> Date: Mon, 2 Apr 2012 03:26:15 +0200
>> Subject: Re: [VRRP] RFC5798 - clarification on checksum calculation
>> From: Hermin Anggawijaya <hermin.anggawijaya@gmail.com>
>> To: Tomoyuki Sahara <sahara@surt.net>
>>
>> Sahara-san
>>
>> Thanks for your input.
>>
>> Anyone else with either/other interpretation of the clause ?
>>
>>
>> Thanks
>>
>> On Mon, Apr 2, 2012 at 1:48 AM, Tomoyuki Sahara <sahara@surt.net> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 29, 2012 at 4:29 PM, Hermin Anggawijaya
>> > <hermin.anggawijaya@gmail.com> wrote:
>> >> Would someone be able to help clarifying RFC5798 Sec. 5.2.8 on
>> >> checksum for me please...
>> >>
>> >> It says that
>> >>
>> >> =A0"The checksum is the 16-bit one's complement of the one's compleme=
nt
>> >> =A0 sum of the entire VRRP message starting with the version field an=
d a
>> >> =A0 "pseudo-header" as defined in Section 8.1 of [RFC2460]. =A0The ne=
xt
>> >> =A0 header field in the "pseudo-header" should be set to 112 (decimal=
)
>> >> =A0 for VRRP. =A0For computing the checksum, the checksum field is se=
t to
>> >> =A0 zero. =A0See RFC1071 for more detail [RFC1071]."
>> >>
>> >> My interpretation of the above clause is, for IPv4 VRRP the checksum =
would be
>> >> defined as:
>> >>
>> >> "The checksum is the 16-bit one's complement of the one's complement
>> >> =A0sum of the entire VRRP message starting with the version field"
>> >>
>> >> as per RFC 3768, instead of involving "pseudo header" (as defined in
>> >> Section 8.1 of [RFC2460]).
>> >
>> > My understanding is only reference text ("as defined in Section 8.1 of
>> > [RFC2460]") is irrelevant for IPv4. =A0Our implementation calculates c=
hecksum
>> > including pseudo header as for TCP/UDP/DCCP.
>> >
>> >> If my interpretation is correct, would it be useful to change the tex=
t to
>> >> reflect specific checksum detail for IPv4 ?
>> >
>> > My interpretation is different from yours but clarification should be
>> > very useful.
>> > It's vital for interoperable implementations of VRRPv3/IPv4.
>> >
>> >
>> > Thanks,
>> > Tomoyuki
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp

From anoop.g@hp.com  Wed May 16 21:16:14 2012
Return-Path: <anoop.g@hp.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D9311E808E for <vrrp@ietfa.amsl.com>; Wed, 16 May 2012 21:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 dzsUtTRRf5CT for <vrrp@ietfa.amsl.com>; Wed, 16 May 2012 21:16:13 -0700 (PDT)
Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfa.amsl.com (Postfix) with ESMTP id DA4E911E8089 for <vrrp@ietf.org>; Wed, 16 May 2012 21:16:12 -0700 (PDT)
Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 13E6414715; Thu, 17 May 2012 04:16:10 +0000 (UTC)
Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 17 May 2012 04:13:25 +0000
Received: from GVW1105EXC.americas.hpqcorp.net ([16.230.34.94]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Thu, 17 May 2012 05:13:25 +0100
From: "Nair, Anoop Govindan" <anoop.g@hp.com>
To: Hermin Anggawijaya <hermin.anggawijaya@gmail.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Thu, 17 May 2012 05:13:21 +0100
Thread-Topic: [VRRP] Fwd:  RFC5798 - clarification on checksum calculation
Thread-Index: Ac0y4ChGqFPlRYRfQ/WGVb4k5amguQBAu0qQ
Message-ID: <D1917596EC5A6045810BC9BDA0B0E16244C9D3D4EE@GVW1105EXC.americas.hpqcorp.net>
References: <20120515024148.38FF8108E26@melchior.iij.ad.jp> <CAJgsEzXL5iRqwGuea0OEpa9cUYOQtA=rv957bGh+NzYb4c8bgg@mail.gmail.com> <CAJgsEzWTSsc2=O3=93mAuhn+ETcHn8LgHfikbrZOLSAq3S7WGA@mail.gmail.com>
In-Reply-To: <CAJgsEzWTSsc2=O3=93mAuhn+ETcHn8LgHfikbrZOLSAq3S7WGA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VRRP] Fwd:  RFC5798 - clarification on checksum calculation
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: Thu, 17 May 2012 04:16:14 -0000

My interpretation of the specification is that for IPv4 checksum is calcula=
ted without pseudo-header.

It would be nice if RFC authors can clarify.

Regards,

-----Original Message-----
From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Her=
min Anggawijaya
Sent: Wednesday, May 16, 2012 2:47 AM
To: vrrp@ietf.org
Subject: [VRRP] Fwd: RFC5798 - clarification on checksum calculation

Hello

I am thinking of submitting an errata for RFC 5798 Sec. 5.2.8 to make
it more precise in describing the checksum calculation for each address fam=
ily.

But reading a few responses here, I gathered that there is no general
agreement as to the original intention of the text,
I believe that for IPv4, the checksum is calculated without
pseudo-header so that it is backward compatible with RFC 3768.

Any other opinions - particularly from original authors ?


Kind Regards

Hermin Anggawijaya



On Tue, May 15, 2012 at 2:41 PM, =A0<kura@iij.ad.jp> wrote:
> Hello list,
>
> Has there been any progress with regard to this topic?
> I know that in an implementation of VRRPv3 for IPv4 the checksum
> is calculated without pseudo-header currently, but I believe that
> pseudo-header should be involved in the calculation as same as
> IPv6 case.
>
> Regards,
> --
> Tomohiko Kurahashi <kura@iij.ad.jp>
>
>
> From: sahara@surt.net
> Date: Mon Apr 02 2012 20:41:51 JST
>>
>> Forwarded.
>> Any other VRRPv3/IPv4 implementation?
>>
>>
>> Thanks,
>> Tomoyuki
>>
>>
>> Date: Mon, 2 Apr 2012 03:26:15 +0200
>> Subject: Re: [VRRP] RFC5798 - clarification on checksum calculation
>> From: Hermin Anggawijaya <hermin.anggawijaya@gmail.com>
>> To: Tomoyuki Sahara <sahara@surt.net>
>>
>> Sahara-san
>>
>> Thanks for your input.
>>
>> Anyone else with either/other interpretation of the clause ?
>>
>>
>> Thanks
>>
>> On Mon, Apr 2, 2012 at 1:48 AM, Tomoyuki Sahara <sahara@surt.net> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 29, 2012 at 4:29 PM, Hermin Anggawijaya
>> > <hermin.anggawijaya@gmail.com> wrote:
>> >> Would someone be able to help clarifying RFC5798 Sec. 5.2.8 on
>> >> checksum for me please...
>> >>
>> >> It says that
>> >>
>> >> =A0"The checksum is the 16-bit one's complement of the one's compleme=
nt
>> >> =A0 sum of the entire VRRP message starting with the version field an=
d a
>> >> =A0 "pseudo-header" as defined in Section 8.1 of [RFC2460]. =A0The ne=
xt
>> >> =A0 header field in the "pseudo-header" should be set to 112 (decimal=
)
>> >> =A0 for VRRP. =A0For computing the checksum, the checksum field is se=
t to
>> >> =A0 zero. =A0See RFC1071 for more detail [RFC1071]."
>> >>
>> >> My interpretation of the above clause is, for IPv4 VRRP the checksum =
would be
>> >> defined as:
>> >>
>> >> "The checksum is the 16-bit one's complement of the one's complement
>> >> =A0sum of the entire VRRP message starting with the version field"
>> >>
>> >> as per RFC 3768, instead of involving "pseudo header" (as defined in
>> >> Section 8.1 of [RFC2460]).
>> >
>> > My understanding is only reference text ("as defined in Section 8.1 of
>> > [RFC2460]") is irrelevant for IPv4. =A0Our implementation calculates c=
hecksum
>> > including pseudo header as for TCP/UDP/DCCP.
>> >
>> >> If my interpretation is correct, would it be useful to change the tex=
t to
>> >> reflect specific checksum detail for IPv4 ?
>> >
>> > My interpretation is different from yours but clarification should be
>> > very useful.
>> > It's vital for interoperable implementations of VRRPv3/IPv4.
>> >
>> >
>> > Thanks,
>> > Tomoyuki
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

From alxrazuvaev@gmail.com  Thu May 17 07:11:12 2012
Return-Path: <alxrazuvaev@gmail.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6921621F86AA for <vrrp@ietfa.amsl.com>; Thu, 17 May 2012 07:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 X+64lhXkFNfE for <vrrp@ietfa.amsl.com>; Thu, 17 May 2012 07:11:11 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19521F86A5 for <vrrp@ietf.org>; Thu, 17 May 2012 07:11:11 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1849360bkt.31 for <vrrp@ietf.org>; Thu, 17 May 2012 07:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/vcBrgWDbluqcSDs7mT8eDPAWUVZVxZVRqS6e1oqRlk=; b=L9H5tyuePbKDlid5B6JdnilmNT+Rgjl+b08XzUtuEFIPM4YE1VHY9DG+btNWbyYNgW k1UF/xYfGoWBhr8Ta6gFWByxQ5KBHTe0ZU+HOUnLCtm1mg1+PnuRA/sbDgxvjBwI2n3b mS0vx6mZQMqOzLA7pB03dEESpfLCD3oof8Q+rFljlKCw5yKr2gTbBOSsiLFT3fcKb6nW 4vsn/pcLAZEvLYrH3XtzntvX11E9HEYHi9vktVd6n8WMrRy2zqf5Hb1HyB19V8Jb45dA cKgM/h49TZJk5F1JX9G1t4WE+wp2w6ejFDl0MD7cM9+3T++Gr7avfjp0eNG6xYLFUxiB MREw==
Received: by 10.204.153.21 with SMTP id i21mr2472079bkw.38.1337263869539; Thu, 17 May 2012 07:11:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.112.75 with HTTP; Thu, 17 May 2012 07:10:49 -0700 (PDT)
From: Alexey Razuvaev <alxrazuvaev@gmail.com>
Date: Thu, 17 May 2012 10:10:49 -0400
Message-ID: <CADvgzaEkTDoxAYAGvD9HkzhO7aW8=jzhLKxXEBrsAdz3m6j76A@mail.gmail.com>
To: vrrp@ietf.org
Content-Type: multipart/alternative; boundary=0015175cd100ea353704c03c01f8
Subject: [VRRP] RFC 5798 - ipv6 link-local configuration
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: Thu, 17 May 2012 14:11:12 -0000

--0015175cd100ea353704c03c01f8
Content-Type: text/plain; charset=ISO-8859-1

Hi,
VRRPv3 for IPv6 specifies that the first address should be a link-local
address. If that is configured by an operator and not generated by
software, how do we make sure that there are no collisions with existing
link local addresses? Since the protocol spec does not mention any
link-local address range dedicated to VRRP, how do
current implementations make sure that it doesn't collide with anyone else
on the network? I understand that IPv4 has similar issues, but in IPv4 case
the network would be statically configured, unlike in IPv6 case where
link-local addresses are generated from MAC.

Additionally what is the reasoning behind not allowing to use Virtual MAC
address to generate link-local address? It seems like it would simplify the
set up, but I think I am missing some crucial detail.

Also, if I were to allow global IPv6 to be configured for virtual router, I
would have to force the operator to also configure a link-local address,
correct?

Thanks,
Alexey.

--0015175cd100ea353704c03c01f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div>VRRPv3 for IPv6 specifies that the first address should be a link-l=
ocal address. If that is configured by an operator and not generated by sof=
tware, how do we make sure that there are no collisions with existing link =
local addresses? Since the protocol spec does not mention any link-local ad=
dress range dedicated to VRRP, how do current=A0implementations=A0make sure=
 that it doesn&#39;t collide with anyone else on the network? I understand =
that IPv4 has similar issues, but in IPv4 case the network would be statica=
lly configured, unlike in IPv6 case where link-local addresses are generate=
d from MAC.</div>

<div><br></div><div>Additionally what is the reasoning behind not allowing =
to use Virtual MAC address to generate link-local address? It seems like it=
 would simplify the set up, but I think I am missing some crucial detail.</=
div>

<div><br></div><div>Also, if I were to allow global IPv6 to be configured f=
or virtual router, I would have to force the operator to also configure a l=
ink-local address, correct?</div><div><br></div><div>Thanks,</div><div>

Alexey.</div>

--0015175cd100ea353704c03c01f8--

From Tim.Harrison@Q9.com  Tue May 22 07:11:22 2012
Return-Path: <Tim.Harrison@Q9.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9F21F85A3 for <vrrp@ietfa.amsl.com>; Tue, 22 May 2012 07:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level: 
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865]
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 EZeApfMJQnM8 for <vrrp@ietfa.amsl.com>; Tue, 22 May 2012 07:11:22 -0700 (PDT)
Received: from mx3.q9.com (mx3.q9.com [IPv6:2001:4818:0:300::1000:3]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B321F857F for <vrrp@ietf.org>; Tue, 22 May 2012 07:11:21 -0700 (PDT)
Received: from leopard.zoo.q9networks.com (unknown [10.220.34.6]) by mx3.q9.com (Postfix) with ESMTP id 2B4EE23AE78; Tue, 22 May 2012 10:11:21 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 May 2012 10:11:20 -0400
Message-ID: <413FEEF1743111439393FB76D0221E481F37F9AC@leopard.zoo.q9networks.com>
In-Reply-To: <CADvgzaEkTDoxAYAGvD9HkzhO7aW8=jzhLKxXEBrsAdz3m6j76A@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [VRRP] RFC 5798 - ipv6 link-local configuration
Thread-Index: Ac00NuwyS13iRCjzQlCqUexlPmFg7wD6R9RQ
References: <CADvgzaEkTDoxAYAGvD9HkzhO7aW8=jzhLKxXEBrsAdz3m6j76A@mail.gmail.com>
From: "Tim Harrison" <Tim.Harrison@Q9.com>
To: "Alexey Razuvaev" <alxrazuvaev@gmail.com>, <vrrp@ietf.org>
Subject: Re: [VRRP] RFC 5798 - ipv6 link-local configuration
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: Tue, 22 May 2012 14:11:22 -0000

Alexey,

Current implementations for IPv6 (of which I'm aware) do force the =
operator to manually configure a link-local address along with the =
global unicast address, which can lead to some hassles - particularly in =
a multivendor environment.  For example, certain vendors require a hard =
coded link-local on the interface as well as in the virtual router =
config; certain vendors utilise the same command for the global unicast =
and link-local within the VRRP configuration, etc.

We've been working with multiple vendors to find a way to implement =
auto-generated link-local addresses based on the virtual MAC as an =
option.  There has been some traction and I haven't heard of any major =
showstoppers thus far; however, I could be out of the loop on the =
investigation or progress (or lack thereof).  The big problem is getting =
a solution that is standarised (if you will) across vendors.

Hopefully there can be some discussion about this particular topic here.

---

Tim Harrison
Manager, Network Engineering
Q9 Networks Inc.
http://www.q9.com/
416-848-3250

-----Original Message-----
From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of =
Alexey Razuvaev
Sent: May 17, 2012 10:11
To: vrrp@ietf.org
Subject: [VRRP] RFC 5798 - ipv6 link-local configuration

Hi,
VRRPv3 for IPv6 specifies that the first address should be a link-local =
address. If that is configured by an operator and not generated by =
software, how do we make sure that there are no collisions with existing =
link local addresses? Since the protocol spec does not mention any =
link-local address range dedicated to VRRP, how do current =
implementations make sure that it doesn't collide with anyone else on =
the network? I understand that IPv4 has similar issues, but in IPv4 case =
the network would be statically configured, unlike in IPv6 case where =
link-local addresses are generated from MAC.

Additionally what is the reasoning behind not allowing to use Virtual =
MAC address to generate link-local address? It seems like it would =
simplify the set up, but I think I am missing some crucial detail.

Also, if I were to allow global IPv6 to be configured for virtual =
router, I would have to force the operator to also configure a =
link-local address, correct?

Thanks,
Alexey.