> -----Original Message----- > From: Pekka Savola [mailto:pekkas@xxxxxxxxxx] > Sent: Thursday, November 02, 2006 3:42 AM > To: Jeff Haran > Cc: linux-net@xxxxxxxxxxxxxxx > Subject: Re: delay required between configuring and binding to an IPv6 > address? > > > On Wed, 1 Nov 2006, Jeff Haran wrote: > > If I configure an IPv6 address via netlink sockets and then > > immediately run an application that creates an AF_INET6, TCP socket > > and tries to bind to that IPv6 address, bind() fails with > > EADDRNOTAVAIL. > > > > If I insert a 1 second delay between the configuration of the > > address and the attempt to bind(), the same thing happens. > > > > If I insert a 2 second delay, bind() succeeds. > > > > The only difference is the period of the delay. > > > > Is this supposed to be happening? If so, what is the required delay > > period? And why should this be happening? > > After you configure the address, it's in "tentative" state until > duplicate address detection has finished (and should not be > used yet). > This is the likely source of this behaviour. > > -- > Pekka Savola I suspected this might be the cause, but if this is the cause, is this correct behavior? >From my reading of the RFCs (2461 and 2462), this tentative state should apply to link local addresses and addresses obtained through stateless autoconfiguration. But in my test case, I've assigned the address administratively via the NETLINK sockets interface. It's statically configured. If I the admin have told the OS to use this address, why should that be subject to duplicate address detection and the ensuing delay? If I want to hang myself by potentially configuring duplicate addresses, that should be my option shouldn't it? Do the RFCs say that the duplicate address detection protocol should be run for statically configured IPv6 addresses too? Thanks, Jeff Haran Brocade Communcations Products - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
