Re: [RFC 4861] upper-layer reachability confirmation

Yukiyo Akisada <akisada@tahi.org> Wed, 25 June 2008 05:56 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53BB3A69A7; Tue, 24 Jun 2008 22:56:48 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286213A6994 for <ipv6@core3.amsl.com>; Tue, 24 Jun 2008 22:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599]
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 qC2Poi4GeQTs for <ipv6@core3.amsl.com>; Tue, 24 Jun 2008 22:56:46 -0700 (PDT)
Received: from ns.64translator.com (ns.64translator.com [202.214.123.16]) by core3.amsl.com (Postfix) with ESMTP id 16B653A6998 for <ipv6@ietf.org>; Tue, 24 Jun 2008 22:56:45 -0700 (PDT)
Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id m5P5VHIh074540; Wed, 25 Jun 2008 14:31:17 +0900 (JST) (envelope-from akisada@tahi.org)
Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.6/8.13.6) with SMTP id m5P5t767042814; Wed, 25 Jun 2008 14:55:08 +0900 (JST) (envelope-from akisada@tahi.org)
Date: Wed, 25 Jun 2008 14:54:49 +0900
From: Yukiyo Akisada <akisada@tahi.org>
To: Vlad Yasevich <vladislav.yasevich@hp.com>, Sebastien Roy <Sebastien.Roy@Sun.COM>
Subject: Re: [RFC 4861] upper-layer reachability confirmation
Message-Id: <20080625145449.d5e2fc6a.akisada@tahi.org>
In-Reply-To: <48611985.1040407@hp.com>
References: <20080624180617.c1497dec.akisada@tahi.org> <1214317928.18919.40.camel@strat> <48611985.1040407@hp.com>
Organization: TAHI Project
X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.12; i386-portbld-freebsd4.11)
Mime-Version: 1.0
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi, Sebastien and Vlad.

Thanks for your inputs.

Well, I will get in flexibility of ND.

But having said that,
my concern was also that the Redirect is the same layer in ND,
as Vlad said.

Regards,


On Tue, 24 Jun 2008 11:57:57 -0400
Vlad Yasevich <vladislav.yasevich@hp.com>; wrote:

> Sebastien Roy wrote:
> > On Tue, 2008-06-24 at 18:06 +0900, Yukiyo Akisada wrote:
> >> I have a question about upper-layer reachability confirmation defined in RFC 4861.
> >>
> >> When the neighbor cache state for the default router is STALE
> >> and the host sends a packet to off-link,
> >> the default router sends redirect packet to the host.
> >>
> >> Can the host considers that the default router is REACHABLE?
> >>
> >> Personally, I didn't expected this behavior.
> >> But I found that an implementation behaves like this
> >> when I'm developping the conformance tester.
> >>
> >> How do you think about this behavior?
> > 
> > That seems reasonable to me.  The host sent a packet to the router, and
> > the router responded with one of its own which was received by the host.
> > This is bi-directional reachability.
> > 
> 
> It's reasonable as long as the implementation doing so can correctly identify
> that it sent the packet triggering the redirect.  If the implementation
> can do so, it can assume bi-directional communication.
> 
> Personally, I wouldn't consider this upper layer indication, since Redirect
> is not strictly upper layer.
> 
> -vlad
> 


-- 
Yukiyo Akisada <akisada@tahi.org>;
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------