Re: [RFC 4861] upper-layer reachability confirmation

[Yukiyo Akisada <akisada at tahi.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 at 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 thFrom ipv6-bounces at ietf.org  Tue Jun 24 22:56:48 2008
Return-Path: <ipv6-bounces at ietf.org>
X-Original-To: ipv6-archive at megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive at 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 at core3.amsl.com
Delivered-To: ipv6 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 286213A6994
	for <ipv6 at 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 at 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 at 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 at 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 at tahi.org)
Date: Wed, 25 Jun 2008 14:54:49 +0900
From: Yukiyo Akisada <akisada at tahi.org>
To: Vlad Yasevich <vladislav.yasevich at hp.com>, Sebastien Roy
	<Sebastien.Roy at Sun.COM>
Subject: Re: [RFC 4861] upper-layer reachability confirmation
Message-Id: <20080625145449.d5e2fc6a.akisada at tahi.org>
In-Reply-To: <48611985.1040407 at hp.com>
References: <20080624180617.c1497dec.akisada at tahi.org>
	<1214317928.18919.40.camel at strat> <48611985.1040407 at 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 at ietf.org
X-BeenThere: ipv6 at 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 at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces at ietf.org
Errors-To: ipv6-bounces at 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 at 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 impleme 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 at tahi.org>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


entation
> 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 at tahi.org>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------