Subject: Re: address selection and DHCPv6

From: "Durand, Alain" <[email-masked]>
Date: Thu, 26 Oct 2006 18:16:37 -0400

I've been thinking some more about Bernie's point. In theory it should not, but in pratical operation, it does matter where the config information is coming from.
The ops people in charge of routers are not the same as the one in charge of servers (DHCP included) ... and the last thing I'd like to see hapening is the source address selected by a server to change if one team changes a lifetime without noticing the other...

   - Alain.

----- Original Message -----
From: Bernie Volz (volz) <[email-masked]>
To: Manfredi, Albert E <[email-masked]>; Durand, Alain
Cc: [email-masked] <[email-masked]>
Sent: Thu Oct 26 16:03:26 2006
Subject: RE: address selection and DHCPv6

I would think that how an address is assigned shouldn't enter into this.
I can't see that it matters.

What really matters is the lifetimes associated with the address. The
longest lifetime address is probably the best to use since it is the
most stable. [Ignoring privacy and other related issues.]

Perhaps this gets at what you want anyway, since manually assigned
addresses would presumable have the longest lifetime? 

- Bernie 

-----Original Message-----
From: Manfredi, Albert E [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 3:06 PM
To: Durand, Alain
Cc: [email-masked]
Subject: RE: address selection and DHCPv6

Except that from what others have said, that might not be the desired
goal. Perhaps for privacy or other reasons, a most stable address choice
might not be optimal.

I originally thought that would be the best choice, but ...

Bert

> -----Original Message-----
> From: Durand, Alain [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 2:00 PM
> To: Bernie Volz (volz); James Carlson; Vlad Yasevich
> Cc: [email-masked]
> Subject: RE: address selection and DHCPv6
> 
> The question is not to get an absolutely stable address,
> but to make sure that in case multiple addresses are defined,
> the one with the highest likelyhood of stability is selected.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Oct 2006 18:35:29 -0400

There is an operational issue - anecdotal, perhaps not of interest - that
I've heard of.  It's related to Alain's observation of who runs routers and
who runs the DHCP server.

Anyway, the issue is that, in the case of router misconfiguration, it may be
the case that hosts unexpectedly take on new addresses, that may take 2
hours to flush from their interfaces.  DHCP would avoid that particular
problem.  Note that I'm not claiming DHCP is less prone to
misconfiguration...

- Ralph

On 10/26/06 6:16 PM, "Durand, Alain" <[email-masked]> wrote:

> I've been thinking some more about Bernie's point. In theory it should not,
> but in pratical operation, it does matter where the config information is
> coming from.
> The ops people in charge of routers are not the same as the one in charge of
> servers (DHCP included) ... and the last thing I'd like to see hapening is the
> source address selected by a server to change if one team changes a lifetime
> without noticing the other...
> 
>    - Alain.
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Oct 2006 16:09:48 -0700

I have a question about on-link determination for IPv6 ND.
(RFC2461(bis), Section 2.1) has the following definition
for on-link:

  "on-link - an address that is assigned to an interface on a
             specified link. A node considers an address to be on-
             link if:

           - it is covered by one of the link's prefixes, or

           - a neighboring router specifies the address as
             the target of a Redirect message, or

           - a Neighbor Advertisement message is received for
             the (target) address, or

           - any Neighbor Discovery message is received from
             the address."

Clauses 1 and 2 seem to be the same considerations as for IPv4,
but clauses 3 and 4 seem to imply that IPv6 ND implementations
"snoop" on ND messages and "remember" the addresses of neighbors
heard from on the link, e.g., even for multicast ND messages that
are unsolicited or in response to a third party's solicitations.
This is independent of any prefixes assigned on an interface and
also seems to be independent of any neighbor cache entries, since
receipt of ND messages does not necessarily result in neighbor
cache entries being created.

So my question is, for how long will an implementation remember
the addresses of on-link neighbors discovered from snooping on
ND messages - forever? (The spec doesn't seem to provide guidance
on this?) And, what happens when a neighbor that was previously
on-link departs? Will the node try indefinitely to reach the
now-departed neighbor on the local link even if more up-to-date
information is received, e.g., from a routing protocol? The spec
seems to be ambiguous on these points - am I missing something?

Fred
[email-masked]