Re: [VRRP] RFC 5798 - ipv6 link-local configuration
"Tim Harrison" <Tim.Harrison@Q9.com> Tue, 22 May 2012 14:11 UTC
Return-Path: <Tim.Harrison@Q9.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9F21F85A3 for <vrrp@ietfa.amsl.com>; Tue, 22 May 2012 07:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level:
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZeApfMJQnM8 for <vrrp@ietfa.amsl.com>; Tue, 22 May 2012 07:11:22 -0700 (PDT)
Received: from mx3.q9.com (mx3.q9.com [IPv6:2001:4818:0:300::1000:3]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B321F857F for <vrrp@ietf.org>; Tue, 22 May 2012 07:11:21 -0700 (PDT)
Received: from leopard.zoo.q9networks.com (unknown [10.220.34.6]) by mx3.q9.com (Postfix) with ESMTP id 2B4EE23AE78; Tue, 22 May 2012 10:11:21 -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: Tue, 22 May 2012 10:11:20 -0400
Message-ID: <413FEEF1743111439393FB76D0221E481F37F9AC@leopard.zoo.q9networks.com>
In-Reply-To: <CADvgzaEkTDoxAYAGvD9HkzhO7aW8=jzhLKxXEBrsAdz3m6j76A@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [VRRP] RFC 5798 - ipv6 link-local configuration
Thread-Index: Ac00NuwyS13iRCjzQlCqUexlPmFg7wD6R9RQ
References: <CADvgzaEkTDoxAYAGvD9HkzhO7aW8=jzhLKxXEBrsAdz3m6j76A@mail.gmail.com>
From: Tim Harrison <Tim.Harrison@Q9.com>
To: Alexey Razuvaev <alxrazuvaev@gmail.com>, vrrp@ietf.org
Subject: Re: [VRRP] RFC 5798 - ipv6 link-local configuration
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 22 May 2012 14:11:22 -0000
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@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Alexey Razuvaev Sent: May 17, 2012 10:11 To: vrrp@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] RFC 5798 - ipv6 link-local configuration Alexey Razuvaev
- Re: [VRRP] RFC 5798 - ipv6 link-local configurati… Tim Harrison