[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
- [VRRP] Clarification of link-local functionality … Tim Harrison