[VRRP] RFC 5798 - ipv6 link-local configuration
Alexey Razuvaev <alxrazuvaev@gmail.com> Thu, 17 May 2012 14:11 UTC
Return-Path: <alxrazuvaev@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 6921621F86AA for <vrrp@ietfa.amsl.com>; Thu, 17 May 2012 07:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 X+64lhXkFNfE for <vrrp@ietfa.amsl.com>; Thu, 17 May 2012 07:11:11 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19521F86A5 for <vrrp@ietf.org>; Thu, 17 May 2012 07:11:11 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1849360bkt.31 for <vrrp@ietf.org>; Thu, 17 May 2012 07:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/vcBrgWDbluqcSDs7mT8eDPAWUVZVxZVRqS6e1oqRlk=; b=L9H5tyuePbKDlid5B6JdnilmNT+Rgjl+b08XzUtuEFIPM4YE1VHY9DG+btNWbyYNgW k1UF/xYfGoWBhr8Ta6gFWByxQ5KBHTe0ZU+HOUnLCtm1mg1+PnuRA/sbDgxvjBwI2n3b mS0vx6mZQMqOzLA7pB03dEESpfLCD3oof8Q+rFljlKCw5yKr2gTbBOSsiLFT3fcKb6nW 4vsn/pcLAZEvLYrH3XtzntvX11E9HEYHi9vktVd6n8WMrRy2zqf5Hb1HyB19V8Jb45dA cKgM/h49TZJk5F1JX9G1t4WE+wp2w6ejFDl0MD7cM9+3T++Gr7avfjp0eNG6xYLFUxiB MREw==
Received: by 10.204.153.21 with SMTP id i21mr2472079bkw.38.1337263869539; Thu, 17 May 2012 07:11:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.112.75 with HTTP; Thu, 17 May 2012 07:10:49 -0700 (PDT)
From: Alexey Razuvaev <alxrazuvaev@gmail.com>
Date: Thu, 17 May 2012 10:10:49 -0400
Message-ID: <CADvgzaEkTDoxAYAGvD9HkzhO7aW8=jzhLKxXEBrsAdz3m6j76A@mail.gmail.com>
To: vrrp@ietf.org
Content-Type: multipart/alternative; boundary="0015175cd100ea353704c03c01f8"
Subject: [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: Thu, 17 May 2012 14:11:12 -0000
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