VRRPv3 IPv6 RFC-5798 checksum

joe mcfar <jrtcmcfar <at> gmail.com>
2012-05-07 21:49:46 GMT

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

Re: VRRPv3 IPv6 RFC-5798 checksum

Tomoyuki Sahara <sahara <at> surt.net>
2012-05-10 03:04:22 GMT

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

RFC 5798 - ipv6 link-local configuration

Alexey Razuvaev <alxrazuvaev <at> gmail.com>
2012-05-17 14:10:49 GMT

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?

Re: RFC 5798 - ipv6 link-local configuration

Tim Harrison <Tim.Harrison <at> Q9.com>
2012-05-22 14:11:20 GMT

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