RE: DHCPv6, IPv6 net tools

From: Jeff Haran
Date: Mon Feb 05 2007 - 19:17:10 EST


> -----Original Message-----
> From: linux-net-owner@xxxxxxxxxxxxxxx
> [mailto:linux-net-owner@xxxxxxxxxxxxxxx] On Behalf Of Jeroen Massar
> Sent: Monday, February 05, 2007 2:57 PM
> To: David W. Hankins
> Cc: linux-net@xxxxxxxxxxxxxxx
> Subject: Re: DHCPv6, IPv6 net tools
>
> David W. Hankins wrote:
> [..]
> >> While I'm asking on this subject, DHCPv6 introduces the
> concept of a
> >> 'preferred' lifetime. The objective is to encourage
> applications to
> >> move from an old address to a new one over a grace period
> before the
> >> old address fully expires.
> >>
> >> Have either the linux kernel or net-tools folks spent any time
> >> thinking about how this will be implemented and signalled?
> I'm not
> >> seeing anything related in the ifconfig manpage.
>
> The address which is the 'most preferred' will be used when
> creating a new outbound connection when the application
> didn't forcefully bind to a specific address.
>
> When an address becomes deprecated it just keeps on being
> used by the application. No transition to another address is
> done. Only thing is that it won't be used for creating new
> connections.
>
> Afaik there is indeed no signaling for this yet. But it is
> tricky anyway to have new-interface/address detection in a
> unix-wide way. One tends to end up listening to routing
> messages of the kernel interface; which IMHO is a bit much to
> ask from applications.
>
> From that perspective, for C, there should have been a layer
> between the normal BSD socket calls and the application user
> ages ago which handled these scenarios.

I've found that if an application tries to bind() to an IPv6 address
that is still tentative, bind() returns an error. That makes sense given
that its still tentative.

By the same token, if the goal of the expiration of the preferred timer
is to encourage applications to get off of an old address and onto a new
one, shouldn't attempts to bind() to a valid but not preferred address
also fail? And shouldn't calls to accept() on a socket that had been
bound to an IPv6 address that was preferred at the time but that has
just transitioned from preferred to valid also return failure? Both of
these would encourage applications to rebind to a new preferred address
and the only additional signalling necessary would be the value of errno
returned on the occurrence of the bind() and accept() errors. I guess
trying to connect() on a socket that had been bound to a preferred
adddress that has since gone valid should also fail, though the chances
of this happening seem much thinner.

BTW, I haven't actually tried any of these latter scenarios so maybe
they already work like this.

Jeff Haran
Brocade Communications Systems
-
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