Neighbor Unreachability Detection..
Somasundaram Selvaraj <ietf.interest@gmail.com> Sun, 29 April 2012 12:54 UTC
Return-Path: <ietf.interest@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DCC21F8540 for <ipv6@ietfa.amsl.com>; Sun, 29 Apr 2012 05:54:53 -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 EAdlS3c5ch5a for <ipv6@ietfa.amsl.com>; Sun, 29 Apr 2012 05:54:52 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5CCE21F8531 for <ipv6@ietf.org>; Sun, 29 Apr 2012 05:54:52 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1200609ghb.31 for <ipv6@ietf.org>; Sun, 29 Apr 2012 05:54:52 -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=mc3KN7E1VV/jUim13QBC7MMHhIWFMRDChbyRKTldNUw=; b=ba374ZvxKA895qb+7DorhEnEC/SIXY0Ah6Y1JH5+QyeHOH9HqDN23XytYpGO+c1YU5 tZkxM+5e2tlI9eg5A7pZuBkQX7d8SlLbg3PJGhHD94y9WcZXOwk3WazxCHDnv8C2ryji vlQV0Qk/LSmwgaTJFTMgRUgka6C+cJx5InbTBBe8IY3MywMqA7AB1r4rZS1hedEdlX1B Tsqj6cTPyiWeuF7dq1OmwT0CllfFvBvYdV7zYbMSqwTvuxc4AyQRUssSyrbfn18SBHgC 3CWnVq18wiwGG6vPqzO86z7s8VCQ1Tee9+g3/FYZ6l85cOBw8Rt20D53JCammmqmjK8q hFsQ==
MIME-Version: 1.0
Received: by 10.236.73.195 with SMTP id v43mr18591297yhd.78.1335704092325; Sun, 29 Apr 2012 05:54:52 -0700 (PDT)
Received: by 10.146.112.18 with HTTP; Sun, 29 Apr 2012 05:54:52 -0700 (PDT)
Date: Sun, 29 Apr 2012 18:24:52 +0530
Message-ID: <CALOzrYeJeWAsiNQD1VdFqsnTFBjTWSMHiqnu23G8UmxC_gcviw@mail.gmail.com>
Subject: Neighbor Unreachability Detection..
From: Somasundaram Selvaraj <ietf.interest@gmail.com>
To: ipv6@ietf.org
Content-Type: multipart/alternative; boundary="20cf300512f2f2b91604bed0d71f"
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Apr 2012 12:54:53 -0000
All I went through RFC 4861 and found the section on "Neighbor Unreachablity Detection" to be of less signifance especially on the links between Router. Reason is that, while there are failure detection protocols already available to detect a liveliness of the neighbor I dont understand effectivenss of such a mechanism within IpV6. Moreover, whenever the neighborstate is not in "Reachable state", there is a bunch of packets that gets trapped to the CPU to invoke IPV6 to send NeighborSolicitaion message to detect the liveliness of the neighbor. And Interestingly, the implementations continue to forward to the neighbor irrespective of what the "Nbr state is" and then trap the (copy of the packets)packets to cpu to do a Neighbor Unreachablity Detection check (for the sake of sticking to the standard). I didnt like Router Doing this especially on the Router-Router link. Here are my opinion on handling the above issues. 1: Why to go through all the NeighborStates (Incomplete->Reachable->Stale->Delay->Probe) when Protocols like BFD are already present to check the liveliness of the neighbor (On a Router-Router link). Cant we avoid "Neighbor unreachablity detection" completely? 2: Simplify the NeighborState Machine.Just mainitain two states in the Neighbor cache when the neighbor is a router. The states would be "Incomplete and Reachable". Enhancement as follows: Initially the Neighbor state would be marked "Incomplete" and a NeighborSolicitation message would be originated to determine the link layer address.Once it receives a response move the neighbor state to "Reachable". Just maintain an ageout timer like the one meant for ARP (no more complications) to flush an entry from neighbor Cache. Please share your thoughts. Regards Somasundaram
- Neighbor Unreachability Detection.. Somasundaram Selvaraj
- Re: Neighbor Unreachability Detection.. Erik Nordmark