Re: [VRRP] RFC5798 requires usage of RAs?

Stephen Nadas <stephen.nadas@ericsson.com> Thu, 28 April 2011 15:36 UTC

Return-Path: <stephen.nadas@ericsson.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 3B71AE070C for <vrrp@ietfa.amsl.com>; Thu, 28 Apr 2011 08:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edu4yiii7k4m for <vrrp@ietfa.amsl.com>; Thu, 28 Apr 2011 08:36:55 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0C9E0685 for <vrrp@ietf.org>; Thu, 28 Apr 2011 08:36:55 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3SFapfP006102; Thu, 28 Apr 2011 10:36:53 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 28 Apr 2011 11:36:45 -0400
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: Daniel Roesen <dr@cluenet.de>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Thu, 28 Apr 2011 11:36:44 -0400
Thread-Topic: [VRRP] RFC5798 requires usage of RAs?
Thread-Index: AcwFaj37M9QqFuWcSXWSfZnlCKprzgAT1/og
Message-ID: <450AE4BEC513614F96969DDA34F35934192892832D@EUSAACMS0701.eamcs.ericsson.se>
References: <20110415085709.GA3742@srv03.cluenet.de>
In-Reply-To: <20110415085709.GA3742@srv03.cluenet.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VRRP] RFC5798 requires usage of RAs?
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, 28 Apr 2011 15:36:56 -0000

Hi Daniel, 

Sorry for the delay.  I think the spec language could be better- 
(630) etc probably should have said something more like 

"if ND RAs are in use, MUST send ND Router Advertisements for the virtual router. 

Thanks,
Steve 

-----Original Message-----
From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Daniel Roesen
Sent: Friday, April 15, 2011 4:57 AM
To: vrrp@ietf.org
Subject: [VRRP] RFC5798 requires usage of RAs?

Hi,

JUNOS (Juniper router firmware) issues warnings when committing config changes, noting that RAs are not configured for an interface where VRRP for IPv6 is configured:

vrrpd[15299]: %CONFLICT-0-WARNING: 'router-advertisement' is not configured for interface ge-9/2/2.662

RFC5798 states:

6.4.3.  Master
...
         (630) ++ MUST send ND Router Advertisements for the virtual
         router.

That makes no sense to us when RAs are generally not used on the segment, and hosts are manually configured to point to the VRRP virtual address as default gateway. We do not want to use RAs in some scenarios at all.

I've found an older posting on this list, where someone raised the same question (Q-2):
http://www.ietf.org/mail-archive/web/vrrp/current/msg00763.html

John Cruz' answer seems to clarify, but noone seemed to have envisioned that the spec lingo actually motivates vendors to assume RAs as being mandatory when implementing VRRPv6... :-/

RFC5798 states in the introductory section about IPv6 (1.3):

   IPv6 hosts on a LAN will usually learn about one or more default
   routers by receiving Router Advertisements sent using the IPv6
   Neighbor Discovery (ND) protocol [RFC4861].

Given that it says "usually", it recognizes that there are scenarios where RAs are NOT being used. Unfortunately several bits of language in the RFC doesn't reflect that, so I would like to suggest changing specifically rule 630 and section 8.2.3 to reflect no-RA scenarios.

Best regards,
Daniel

_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp