[VRRP] Clarification of link-local functionality with VRRPv3.

"Tim Harrison" <Tim.Harrison@Q9.com> Mon, 26 April 2010 19:27 UTC

Return-Path: <Tim.Harrison@Q9.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D1C3A6A9E for <vrrp@core3.amsl.com>; Mon, 26 Apr 2010 12:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gLKdYK+Mgjt for <vrrp@core3.amsl.com>; Mon, 26 Apr 2010 12:27:25 -0700 (PDT)
Received: from mx3.q9.com (mx3.q9.com [216.220.35.252]) by core3.amsl.com (Postfix) with ESMTP id B83253A689D for <vrrp@ietf.org>; Mon, 26 Apr 2010 12:27:24 -0700 (PDT)
Received: from leopard.zoo.q9networks.com (unknown [10.220.34.6]) by mx3.q9.com (Postfix) with ESMTP id 19CE1131 for <vrrp@ietf.org>; Mon, 26 Apr 2010 15:27:00 -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: Mon, 26 Apr 2010 15:27:11 -0400
Message-ID: <413FEEF1743111439393FB76D0221E4816695920@leopard.zoo.q9networks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Clarification of link-local functionality with VRRPv3.
thread-index: Acrldngm3GsJDRxTSQelIz94T+/1fA==
From: Tim Harrison <Tim.Harrison@Q9.com>
To: vrrp@ietf.org
Subject: [VRRP] Clarification of link-local functionality with VRRPv3.
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 26 Apr 2010 19:27:26 -0000

Good afternoon (EST) all,

I apologise if these questions have been answered before, but I'd like to seek some clarification for implementations of RFC 5798.

1.  Can the virtual link-local be generated using VR MACs converted to EUI-64 IIDs?

Section 7.4 states:

   IPv6 routers running VRRP MUST create their Interface Identifiers in
   the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet
   Networks" [RFC2464]).  They MUST NOT use the virtual router MAC
   address to create the Modified Extended Unique Identifier (EUI)-64
   identifiers.

Is this a blanket statement to prohibit the VRRP router's interface link-local address from being created using a virtual router MAC address?  Or, less generally, is this a statement prohibiting the creation of a virtual router link-local address with an interface identifier generated from a virtual router MAC address?


2.  Which link-local address is to be used in IPv6_Addresses.

Section 6.1 states:

   IPv6_Addresses              One or more IPv6 addresses associated
                               with this virtual router.  Configured
                               item with no default.  The first address
                               must be the Link-Local address associated
                               with the virtual router.

Does this refer specifically to a virtual link-local address associated with the VRID, or does it consider the VRRP router's interface link-local to be associated with the virtual router?


3.  Which link-local is used to source ND NAs/RAs during init/state changes?

Sections 6.4.1(130) and 6.4.2(395) state:

            (130) * For each IPv6 address associated with the virtual
            router, send an unsolicited ND Neighbor Advertisement with
            the Router Flag (R) set, the Solicited Flag (S) unset, the
            Override flag (O) set, the target address set to the IPv6
            address of the virtual router, and the target link-layer
            address set to the virtual router MAC address.

This doesn't appear to indicate which link-local address is used to source the ND packets.

Also, Section 7.2 indicates that when transmitting VRRP packets:

         + Set the source MAC address to virtual router MAC Address
         + Set the source IPv6 address to interface link-local IPv6 address

This indicates that the VRRP router's interface link-local address is used to source VRRP packets, but nowhere have I seen any reference to the virtual link-local address that most implementations require the operator to manually configure.  In fact, in some cases, you must manually configure the VRRP router's interface link-local, as well.

Is the virtual router's link-local address used to source any packets, or to respond to any packets?


Finally, the crux of my theoretical question:

When implementing VRRPv3, is it possible to allow the VRRP router's interface link-local, which was automatically configured upon enabling IPv6 on the interface, to remain and source all VRRP packets from that address?  If so, what is the purpose of the virtual link-local address(es) configured in the virtual routers, and why do implementations require them to be manually configured rather than allowing them to be automatically generated via the same process that the EUI-64 IID was created on the VRRP router's physical interface?

Thanks kindly.

---

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