[VRRP] Regarding virtual link local usage for ipv6 VRs

Amit Mandal <amit.mandal@gmail.com> Fri, 14 June 2013 21:38 UTC

Return-Path: <amit.mandal@gmail.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 53AD421F9B13 for <vrrp@ietfa.amsl.com>; Fri, 14 Jun 2013 14:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Lx95rnrzIZcL for <vrrp@ietfa.amsl.com>; Fri, 14 Jun 2013 14:38:22 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8921F9AE2 for <vrrp@ietf.org>; Fri, 14 Jun 2013 14:38:21 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id w56so912042wes.11 for <vrrp@ietf.org>; Fri, 14 Jun 2013 14:38:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DbLnkdnoGaueoIIXaZiRjCB4wMzd0ac5ck7T/Tf/g7c=; b=MgMNNV1H1w0cZH0ZRtYhpibRUFd7hdeAIo+kyoXT+iY8pBLbyCmE+UiNhEJX8zcGbf chWjux/+mvh6zueDcxJDvrSGVQWLCA/Ld3WJEJEMyaMWN1BNtw/U50YTK4/U7oGlYuRm NZ8/Iv0kBI4EjjZCpCgjdlsTpuHb8Wa03AgOgQkXoidg9xeQetr2Q/6chGZFOBU+/QWT zS3gmzTq3HO7vPthhByYpr4q/jDTbHIOHFKcwAlMkfV78XbCa0GBWz5Ok31b/gOhughX KqIz6kip+EwlARkUkrgk7vCxZkyHBSos/8HY19HxqcoOl+NdObX5wwgaBXLBjWBI6NhL 8O8g==
MIME-Version: 1.0
X-Received: by with SMTP id y5mr2536143wja.86.1371245900844; Fri, 14 Jun 2013 14:38:20 -0700 (PDT)
Received: by with HTTP; Fri, 14 Jun 2013 14:38:20 -0700 (PDT)
Date: Sat, 15 Jun 2013 03:08:20 +0530
Message-ID: <CAPFVTieMw=NnFM3uJVmVE5W7rD1_MP_v5jO=_a7avXhBEcYhsA@mail.gmail.com>
From: Amit Mandal <amit.mandal@gmail.com>
To: vrrp@ietf.org
Content-Type: multipart/alternative; boundary=047d7b5d5058d1d6f204df2410f6
Subject: [VRRP] Regarding virtual link local usage for ipv6 VRs
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: Fri, 14 Jun 2013 21:38:23 -0000


The idea of auto-generating a virtual link local address is good (as
supported by quite a few vendors), but there's one problem about this
 approach that I needed some clarification on.

In RFC 5798, the address owner is defined as

    'The VRRP router that has the virtual router's IPvX address(es) as
real interface address(es).'

Only the owner is allowed to respond to control packets for the virtual
address (unless accept_mode is true).

Now if the auto-generated link-local is used as a virtual IP on a VR, then
by definition there can't be any owner for this address (since its not on
any real interface) and hence using priority 255 for this address doesn't
seem to agree with the RFC very well. Also, there won't be any system who
will respond to the pings to this address, which doesn't look like such a
good idea either.

This same constraint applies to manually configured virtual link-local
address (unless the user decides to have the same link-local address on the

My understanding is that a virtual IP(v6) address is supposed to be in the
same network as a real interface to allow dynamic routing to be seamless in
the event of VRRP switchover.

If this understanding is correct, then this consideration doesn't apply for
IPv6 link-local addresses and they don't necessarily be present on a real

Hence, I think the term 'owner' needs a special consideration for the
link-local addresses to allow for cases of auto-generated virtual
link-local addresses and manually configured link-local addresses not
present on real interfaces.

 For link-local address the 'owner' can be simply defined as the node
with priority 255, and these addresses may or may not be on a real