[VRRP] Please clear draft-ietf-vrrp-unified-spec
Stephen Nadas <stephen.nadas@ericsson.com> Fri, 02 October 2009 12:04 UTC
Return-Path: <stephen.nadas@ericsson.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E3028C0F9 for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 05:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4XL9FEf9WFa for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 05:04:35 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 2A66A28C0E3 for <vrrp@ietf.org>; Fri, 2 Oct 2009 05:04:35 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n92C5vmo017946; Fri, 2 Oct 2009 07:05:58 -0500
Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:05:40 -0500
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:05:40 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 2 Oct 2009 08:05:39 -0400
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: Jari Arkko <jari.arkko@piuha.net>
Date: Fri, 02 Oct 2009 08:05:38 -0400
Thread-Topic: Please clear draft-ietf-vrrp-unified-spec
Thread-Index: AcpDWKgEuXlEx+ApQoq1FJ4aLAAW9Q==
Message-ID: <450AE4BEC513614F96969DDA34F3593497639A3A@EUSAACMS0701.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639A3AEUSAACMS0701eam_"
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Oct 2009 12:05:40.0415 (UTC) FILETIME=[A8F2D4F0:01CA4358]
Cc: "Radia.Perlman@Sun.COM" <Radia.Perlman@Sun.COM>, "vrrp@ietf.org" <vrrp@ietf.org>
Subject: [VRRP] Please clear draft-ietf-vrrp-unified-spec
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 02 Oct 2009 12:04:36 -0000
Hi Jari, Regarding your comment - will the below actions clear it? Thanks, Steve Requirement to send router advertisements is in 6.4.2 but not in 6.4.3, why? Oversight, added @ (630) In Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch of the code, is this correct? (650) is outside of v4/v6 if condition, so is checked regardless In Section 6.4.3, I don't understand how there's first a MUST statement on responding to Neighbor Solicitations, and then two steps later a conditional statement based on the value of Accept_Mode, again on the the same thing, responding to NSes. I think the need to accept some packets regardless of the setting of accept_mode is what was trying to be expressed by (635). My proposed fix is to move (635) in between (615) and (620). I am also considering: (618) ++ (even) if Accept_mode is False: MUST NOT drop IPv6 Neighbor Solicitations and Neighbor Advertisements. 6.4.3. Master While in the {Master} state the router functions as the forwarding router for the IPvX address(es) associated with the virtual router. Note that in the Master state the Preempt_Mode Flag is not considered. (600) While in this state, a VRRP router MUST do the following: (605) - If the protected IPvX address is an IPv4 address: (610) + MUST respond to ARP requests for the IPv4 address(es) associated with the virtual router. (615) - else // ipv6 (620) + MUST be a member of the Solicited-Node multicast address for the IPv6 address(es) associated with the virtual router. (625) + MUST respond to ND Neighbor Solicitation message for the IPv6 address(es) associated with the virtual router. (630) ++ MUST send ND Router Advertisements for the virtual router. (635) ++ if Accept_mode is False: MUST NOT drop IPv6 Neighbor Solicitations and Neighbor Advertisements. (640) +-endif // ipv4? (645) +- MUST forward packets with a destination link layer MAC address equal to the virtual router MAC address. (650) - MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, MUST NOT accept these packets. [rest of 6.4.3]
- [VRRP] Please clear draft-ietf-vrrp-unified-spec Stephen Nadas