joe mcfar | 7 May 23:49 2012
Picon

VRRPv3 IPv6 RFC-5798 checksum

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?

 

Thanks,

Joe McFarland

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Tomoyuki Sahara | 10 May 05:04 2012
Picon

Re: VRRPv3 IPv6 RFC-5798 checksum

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

kura | 15 May 04:41 2012
Picon

Re: RFC5798 - clarification on checksum calculation

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

Hermin Anggawijaya | 15 May 23:17 2012
Picon

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

Nair, Anoop Govindan | 17 May 06:13 2012
Picon

Re: Fwd: RFC5798 - clarification on checksum calculation

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

Alexey Razuvaev | 17 May 16:10 2012
Picon

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
Tim Harrison | 22 May 16:11 2012

Re: RFC 5798 - ipv6 link-local configuration


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


Gmane