Virtual Router Redundancy Protocol (vrrp)

headers joe mcfar | 7 May 2012 23:49

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Hi,

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

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
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

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 <at> iij.ad.jp>

From: sahara <at> 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 <at> gmail.com>
> To: Tomoyuki Sahara <sahara <at> 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 <at> surt.net> wrote:
> > Hi,
> > 
> > On Thu, Mar 29, 2012 at 4:29 PM, Hermin Anggawijaya
> > <hermin.anggawijaya <at> 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
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

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

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,  <kura <at> 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 <at> iij.ad.jp>
>
>
> From: sahara <at> 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 <at> gmail.com>
>> To: Tomoyuki Sahara <sahara <at> 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 <at> surt.net> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 29, 2012 at 4:29 PM, Hermin Anggawijaya
>> > <hermin.anggawijaya <at> 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
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

My interpretation of the specification is that for IPv4 checksum is calculated without pseudo-header.

It would be nice if RFC authors can clarify.

Regards,

-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Hermin Anggawijaya
Sent: Wednesday, May 16, 2012 2:47 AM
To: vrrp <at> 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 family.

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,  <kura <at> 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 <at> iij.ad.jp>
>
>
> From: sahara <at> 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 <at> gmail.com>
>> To: Tomoyuki Sahara <sahara <at> 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 <at> surt.net> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 29, 2012 at 4:29 PM, Hermin Anggawijaya
>> > <hermin.anggawijaya <at> 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
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

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 <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Alexey Razuvaev
Sent: May 17, 2012 10:11
To: vrrp <at> 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.
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

1	April 2013
4	March 2013
19	February 2013
1	November 2012
5	September 2012
2	August 2012
7	May 2012
2	April 2012
3	March 2012
3	February 2012
1	December 2011
1	September 2011
5	June 2011
9	April 2011
1	March 2011
4	February 2011
8	January 2011
1	December 2010
4	October 2010
4	September 2010
1	August 2010
7	July 2010
4	June 2010
1	April 2010
9	March 2010
2	February 2010
3	January 2010
5	December 2009
5	November 2009
20	October 2009
25	July 2009
5	April 2009
6	March 2009
2	February 2009
1	January 2009
3	December 2008
45	November 2008
18	October 2008
3	September 2008
10	August 2008
12	July 2008
6	June 2008
4	April 2008
7	March 2008
23	January 2008
4	December 2007
6	November 2007
14	October 2007
3	September 2007
15	August 2007
10	July 2007
5	June 2007
3	May 2007
30	April 2007
23	March 2007
11	February 2007
5	January 2007
1	December 2006
10	October 2006
10	September 2006
8	July 2006
6	June 2006
4	May 2006
2	April 2006
12	March 2006
5	February 2006
7	January 2006
11	December 2005
13	October 2005
4	September 2005
1	August 2005
10	July 2005
4	June 2005
10	May 2005
13	April 2005
10	March 2005
31	February 2005
12	January 2005
2	November 2004
6	October 2004
8	September 2004
1	August 2004
8	July 2004
12	June 2004
14	May 2004
11	April 2004
1	March 2004
13	February 2004
1	January 2004
5	December 2003
35	November 2003
20	October 2003
42	September 2003
38	August 2003
22	July 2003
9	June 2003
28	May 2003
4	April 2003
17	March 2003
15	February 2003
7	January 2003
35	December 2002
30	November 2002
19	October 2002
12	September 2002
10	August 2002
4	June 2002
5	May 2002
1	April 2002

VRRPv3 IPv6 RFC-5798 checksum

Re: VRRPv3 IPv6 RFC-5798 checksum

Re: RFC5798 - clarification on checksum calculation

Fwd: RFC5798 - clarification on checksum calculation

Re: Fwd: RFC5798 - clarification on checksum calculation

RFC 5798 - ipv6 link-local configuration

Re: RFC 5798 - ipv6 link-local configuration

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31