Re: [NDP] Router autoconfiguration with RS/RA
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NDP] Router autoconfiguration with RS/RA
Silviu VLASCEANU wrote:
> I thank you both for the quick reaction. I generally agree. However, I
> have some inline comments.
>
> 2008/6/6 Hemant Singh (shemant) <shemant at cisco.com
> <mailto:shemant at cisco.com>>:
>
> Silviu,
>
> A router can receive an RA on the router's upstream and use this RA
> to autoconfigure the ipv6 address on interface(s) of the router.
> Such a router interface configuration is no different from how a
> host interface statelessly autoconfigures as per ND RFC 4861 and 4862.
>
>
> I agree and I also thought that this shFrom ipv6-bounces at ietf.org Fri Jun 6 14:21:21 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 99F8B3A6D52;
Fri, 6 Jun 2008 14:21:21 -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 331713A6DAC
for <ipv6 at core3.amsl.com>; Fri, 6 Jun 2008 14:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.587
X-Spam-Level:
X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012,
BAYES_00=-2.599, 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 VySb1D0mQtup for <ipv6 at core3.amsl.com>;
Fri, 6 Jun 2008 14:21:14 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com
[216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 30F643A68B7
for <ipv6 at ietf.org>; Fri, 6 Jun 2008 14:19:55 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu at gmail.com
X-Msg-Ref: server-10.tower-119.messagelabs.com!1212787204!25950946!1
X-StarScan-Version: 5.5.12.14.2; banners=.,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 23314 invoked from network); 6 Jun 2008 21:20:04 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102)
by server-10.tower-119.messagelabs.com with SMTP;
6 Jun 2008 21:20:04 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m56LK4ec015730;
Fri, 6 Jun 2008 14:20:04 -0700 (MST)
Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245])
by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m56LK38H020666;
Fri, 6 Jun 2008 16:20:03 -0500 (CDT)
Received: from [127.0.0.1] ([10.129.40.2])
by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m56LK1P1020650;
Fri, 6 Jun 2008 16:20:01 -0500 (CDT)
Message-ID: <4849AA00.7030407 at gmail.com>
Date: Fri, 06 Jun 2008 23:20:00 +0200
From: Alexandru Petrescu <alexandru.petrescu at gmail.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Silviu VLASCEANU <silviu.vlasceanu at gmail.com>
Subject: Re: [NDP] Router autoconfiguration with RS/RA
References: <3a44f430806060528o3ab46c73k863537e53e62275b at mail.gmail.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41CDA at xmb-rtp-20e.amer.cisco.com>
<3a44f430806060801n43fc7771wf55577ef643ecc25 at mail.gmail.com>
In-Reply-To: <3a44f430806060801n43fc7771wf55577ef643ecc25 at mail.gmail.com>
X-Antivirus: avast! (VPS 080605-1, 05/06/2008), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
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
Silviu VLASCEANU wrote:
> I thank you both for the quick reaction. I generally agree. However, I
> have some inline comments.
>
> 2008/6/6 Hemant Singh (shemant) <shemant at cisco.com
> <mailto:shemant at cisco.com>>:
>
> Silviu,
>
> A router can receive an RA on the router's upstream and use this RA
> to autoconfigure the ipv6 address on interface(s) of the router.
> Such a router interface configuration is no different from how a
> host interface statelessly autoconfigures as per ND RFC 4861 and 4862.
>
>
> I agree and I also thought that this should be ould be possible.
What do you mean it _should_? Do you want to write an implementation
that should do it? DO you want to modify the rfc?
> However, ND RFC's do not mandate what does a router implementation
> do for sending RA, configuring network prefixes in the router
> downstream direction - these are conceptual variables that a router
> vendor is left to do what they want to do.
>
>
> Noticed that too :)
Well I think RFCs tell very well how a router should send RAs, and they
also say clearly a router shouldn't use the received RA to
auto-configure a global address bases on the prefix in it.
Or has this changed recently?
> As to answering your question which was:
>
> "Why wouldn't a router be authorized to send Router Sollicitation
> messages?"
>
>
> My question was related to sending Router Sollicitations on the upstream
> interface.
What does the RFC say? Can a router send an RS?
> here is my reply.
>
> As far as the interface on the router has no RA configured, and the
> interface is configuring an IPv6 address using stateless
> autoconfiguration or even manual configuration, this interface is OK
> to send an RS in the router downstream.
>
>
> As I understand, a router could configure its "downstream" interfaces by
> RAs received from other routers in the "downstream". Is it correct?
I don't think it's correct.
> This way, the notion of up/downstream would loose its sense.
I think RFCs don't use the terms up/downstream at all, no distinguishing
between them usually.
Alex
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
possible.
What do you mean it _should_? Do you want to write an implementation
that should do it? DO you want to modify the rfc?
> However, ND RFC's do not mandate what does a router implementation
> do for sending RA, configuring network prefixes in the router
> downstream direction - these are conceptual variables that a router
> vendor is left to do what they want to do.
>
>
> Noticed that too :)
Well I think RFCs tell very well how a router should send RAs, and they
also say clearly a router shouldn't use the received RA to
auto-configure a global address bases on the prefix in it.
Or has this changed recently?
> As to answering your question which was:
>
> "Why wouldn't a router be authorized to send Router Sollicitation
> messages?"
>
>
> My question was related to sending Router Sollicitations on the upstream
> interface.
What does the RFC say? Can a router send an RS?
> here is my reply.
>
> As far as the interface on the router has no RA configured, and the
> interface is configuring an IPv6 address using stateless
> autoconfiguration or even manual configuration, this interface is OK
> to send an RS in the router downstream.
>
>
> As I understand, a router could configure its "downstream" interfaces by
> RAs received from other routers in the "downstream". Is it correct?
I don't think it's correct.
> This way, the notion of up/downstream would loose its sense.
I think RFCs don't use the terms up/downstream at all, no distinguishing
between them usually.
Alex
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
