[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.194.9.101 with SMTP id y5mr2536143wja.86.1371245900844; Fri, 14 Jun 2013 14:38:20 -0700 (PDT)
Received: by 10.216.139.193 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
Hi, 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 interface). 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 interface. 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 interface. Rgds Amit