Index: [Article Count Order] [Thread]

Date: Thu, 8 May 2008 13:32:34 +0900
From: Yukiyo Akisada <akisada@tahi.org>
Subject: [users:00712] Re: Invalid Source Address of Router Solicitation
To: "Peter Carney" <pcarney@treck.com>
Cc: users@tahi.org
Message-Id: <20080508133234.5d9e0f64.akisada@tahi.org>
In-Reply-To: <753EF94A8CD3E6439DCD566B99F4D7424EAF2F@ms1.treck.com>
References: <753EF94A8CD3E6439DCD566B99F4D7424EAF2F@ms1.treck.com>
X-Mail-Count: 00712

Hi, Peter.

Sending RS is not verification point of this test,
but using unspecify address as source address is valid by RFC.
Indeed, nd.p2 allows it.

I will update script to keep consictency.

Thanks,


On Fri, 2 May 2008 18:06:08 -0400
"Peter Carney" <pcarney@treck.com> wrote:

> Karsten,
> 
> I have attached the test script (addr.p2/v6LC_3_2_1.seq) and the
> definition for the RS that Tahi is looking for (addr.p2/RA_SAA.def).
> 
> On line 32, there is this line:
> %ret2=vRecv($IF,$SAA::wait_rs,0,0,RS_from_NUT,RS_from_NUT_wSLL);
> 
> 
> 
> RS_from_NUT is defined in (addr.p2/RA_SAA.def) as this:
> 
> FEM_icmp6_rs(RS_from_NUT,_HETHER_nut2allrouters,
>         {   
>          _SRC(nutv6());
>          _DST(v6(_ALLROUTERS_MCAST_ADDR));
>          HopLimit=255;
>         },
>         {
>         }
> )
> 
> When I change the "_SRC(nutv6());" portion of this definition to be "
> _SRC(v6(_UNSPEC_ADDR));", the test passes.
> 
> 
> 
> Thank you,
> 
> Peter Carney
> Development Engineer
> Treck Inc.
> 
> -----Original Message-----
> From: Karsten Keil [mailto:kkeil@suse.de] 
> Sent: Friday, May 02, 2008 3:03 PM
> To: users@tahi.org
> Subject: [users:00706] Re: Invalid Source Address of Router Solicitation
> 
> On Fri, May 02, 2008 at 11:43:31AM -0400, Peter Carney wrote:
> > Karsten,
> > 
> > Thank you for your response.
> > 
> > I apologize, but I am still confused as to why the test thinks that
> the
> > NUT should be using the Link-Local Address for the source address in
> the
> > Router Solicitation.
> > 
> > The test has received a NS for the LLA, which means that the NUT is in
> > the process of performing DAD, but it has not yet completed it.
> > 
> > Is the NUT supposed to use the LLA as the source address of the RS
> even
> > if the NUT has not yet completed DAD for that LLA?
> > 
> 
> No, of course not, you are right here, but after 4 seconds the RS should
> be repeated and at this time the DAD for the LLA should be finished I
> think.
> I think most implementations start sending RS only after successful DAD
> for the LLA, but on the other hand, you are correct, the RFC does allow
> sending RS without any address assigned, so it does not need to wait
> for the LLA DAD to complete.
> 
> I think it would make sense to allow also a RS with the unspecified
> address, maybe a new frame must be defined for this.
> 
> I do not think that not sending RS with src=LLA is the reason why the
> test
> fails, because so far I understand the script of this test, it doesn't
> fail, if it doesn't receive a RS at all.
> 
> Maybe you should attach the 27* files for reference.
> 
> > 
> > 
> > Thank you,
> > 
> > Peter Carney
> > Development Engineer
> > Treck Inc.
> > -----Original Message-----
> > From: Karsten Keil [mailto:kkeil@suse.de] 
> > Sent: Thursday, May 01, 2008 9:00 AM
> > To: users@tahi.org
> > Subject: [users:00701] Re: Invalid Source Address of Router
> Solicitation
> > 
> > On Wed, Apr 30, 2008 at 04:08:40PM -0400, Peter Carney wrote:
> > > Hello,
> > > 
> > >  
> > > 
> > > I am running the IPv6 Self Test version 1.4.14 for hosts and I am
> > having
> > > trouble with test number 27: "Global Address Autoconfiguration and
> DAD
> > > (Host Only)".
> > > 
> > >  
> > > 
> > > In this test (addr.p2/v6LC_3_2_1.seq) the script waits for a Router
> > > Solicitation from the NUT:
> > > 
> > >  
> > > 
> > > #----- RA PHASE
> > > vLog("TN received DAD NS from NUT.");
> > > vLog("OK! Let's go ahead!");
> > 
> > The test did received a DAD (for LLA), so it assumes that
> > the LLA is assigned.
> > 
> > > %ret2=vRecv($IF,$SAA::wait_rs,0,0,RS_from_NUT,RS_from_NUT_wSLL);
> > >  
> > > if ($ret2{status} != 0){
> > >     vLog("Though TN had waited RS from NUT for $SAA::wait_rs,");
> > >     vLog(" NUT seems not to send RS.");
> > >     vLog(" Anyway TN is sending Unsolicited RA (Prefix=Global)");
> > > }else{
> > >     vLog("TN received RS from NUT.");
> > >     vLog("TN is sending RA (Prefix=Global)");
> > > }
> > > 
> > >  
> > > 
> > > The problem that I am seeing is when the NUT sends the Router
> > > Solicitation with an unspecified source address.
> > > 
> > 
> > >  
> > > 
> > > In section 4.1 of RFC 2461 it defines the Source Address of the
> Router
> > > Solicitation to be:
> > > 
> > > "An IP address assigned to the sending interface, or the unspecified
> > > address if no address is assigned to the sending interface."
> > > 
> > 
> > But at this time, you should have a valid address assigned, the Link
> > Local
> > Address, so this address should be used.
> > Before waiting for the RS
> > 
> > >  
> > > 
> > > In 'addr.p2/RA_SAA.def', the 'RS_from_NUT' parameter is defined as:
> > > 
> > > FEM_icmp6_rs(RS_from_NUT,_HETHER_nut2allrouters,
> > > 
> > >         {
> > > 
> > >          _SRC(nutv6());
> > > 
> > >          _DST(v6(_ALLROUTERS_MCAST_ADDR));
> > > 
> > >          HopLimit=255;
> > > 
> > >         },
> > > 
> > >         {
> > > 
> > >         }
> > > 
> > > )
> > > 
> > >  
> > > 
> > > Because of this, the Router Solicitation that the NUT sends that
> uses
> > > the unspecified address is not received and the test fails.
> > > 
> > >  
> > > 
> > > Can you please confirm that this is a bug and provide a patch?
> > > 
> > >  
> > > 
> > > 
> > > 
> > > Thank you,
> > > 
> > > Peter Carney
> > > Development Engineer
> > > Treck Inc.
> > > 
> > >  
> > > 
> > > 
> > > Treck, Inc. - Confidentiality Notice
> > > 
> > > This electronic transmission may contain information that is
> > proprietary or
> > >  confidential. You are hereby notified that any dissemination,
> > >  distribution or duplication of this electronic transmission to some
> > other
> > >  entity, without the expressed written consent of Treck, Inc. is
> > strictly
> > >  prohibited, unless the contents of this electronic transmission
> > >  specifically authorizes you to do so. If your receipt of this
> > electronic
> > >  transmission is in error, please notify the corporate offices of
> > Treck,
> > >  Inc. immediately by calling (513) 528-5732, or by reply to
> > >  this transmission.
> > > 
> > > 
> > 
> > -- 
> > Karsten Keil
> > SuSE Labs
> > ISDN and VOIP development
> > SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus
> Rex,
> > HRB 16746 (AG Nuernberg)
> > 
> > 
> 
> -- 
> Karsten Keil
> SuSE Labs
> ISDN and VOIP development
> SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex,
> HRB 16746 (AG Nuernberg)
> 
> 


-- 
Yukiyo Akisada <akisada@tahi.org>