Hello,
This is all a matter of being consistent with the Advanced IPv6 API, and
with the established practice in POSIX world. Pretty much every
setsockopt uses int, unless it has very peculiar reason not to do so.
Using something else will only confuse people, and add a (minor) extra
Hello,
I have one quick question about RIPng.
Section 2.4.1 of RFC2080 says as follows:
The Request is processed entry by entry. [...
...] Examine the list of RTEs in the Request one by one.
For each entry, look up the destination in the router's routing
database and, if there is a
Julien Laganier wrote:
Hi Vlad,
On Wednesday 25 October 2006 18:22, Vlad Yasevich
wrote:
So, yes, there is a reason to prefer a configured
address over a stateless autoconf one. Same
argument applies with DHCPv6 configured addresses.
[...]
Also, this preference really depends on the
-Original Message-
From: Vlad Yasevich [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 9:58 AM
To: Julien Laganier
Cc: ipv6@ietf.org; Durand, Alain
Subject: Re: address selection and DHCPv6
The concept that a DHCP address is more stable then
EUI64 base address is
Adding a little detail to Alain's comments - all three flavors of DUID are,
in fact, defined in RFC 3315 to be stable for the lifetime of the host,
independent of any changes to MAC addresses. Therefore, address assignment
via DHCPv6 can be controlled by the DHCPv6 server to assign a stable
Hi folks (sorry for popping up),
FYI, based on comments I have very much simplified
the humid draft. You can find it here until it
appears in the I-D rep.:
http://www.freewebs.com/pmutaf/draft-mutaf-ipv6humid-02.txt
Usage scenario is ad-hoc network now.
All references to infrastructure DNS,
Vlad Yasevich writes:
The concept that a DHCP address is more stable then
EUI64 base address is flawed in my opinion. Both depend
on a piece of hardware that can fail or be changed.
That's incorrect. See RFC 3315 -- DUIDs are required to be stable,
even if the hardware is changed.
I guess
Whatever technique you use will likely never guarantee a completely
stable address.
Manually assigned is just as good (or bad) as DHCPv6 because both depend
on some type of stable storage (so yes there is hardware associated with
it). (Well, I guess you could always rely on a human to type in the
Bernie Volz (volz) writes:
Whatever technique you use will likely never guarantee a completely
stable address.
Manually assigned is just as good (or bad) as DHCPv6 because both depend
on some type of stable storage (so yes there is hardware associated with
it). (Well, I guess you could
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.
- Alain.
-Original Message-
From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED]
Sent: Thursday,
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
Alain,
Please see my clarification question below...
--
Eric
-- -Original Message-
-- From: Durand, Alain [mailto:[EMAIL PROTECTED]
-- Sent: Thursday, October 26, 2006 3:00 PM
-- To: Bernie Volz (volz); James Carlson; Vlad Yasevich
-- Cc: ipv6@ietf.org
-- Subject: RE: address
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
Gray, Eric writes:
-- 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.
When you say highest likelihood of stability - is what
you really mean
Bernie Volz (volz) wrote:
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
But, in these cases both addresses are stateless so using how the
address was assigned would still not resolve the issue.
So, that is a related, but separate issue?
Probably the only solution to that is to have some stickiness factor
where a host continues to favor that address for a period of
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
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
Bernie Volz (volz) writes:
I would think that how an address is assigned shouldn't enter into this.
I can't see that it matters.
It matters only in that different assignment mechanisms have different
inherent stabilities:
manual: forever
DHCPv6: until the lifetime expires and
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
It matters only in that different assignment mechanisms have different
inherent stabilities:
manual: forever
DHCPv6: until the lifetime expires and the server refuses to
renew
stateless: until the network interface hardware is swapped
There is no
21 matches
Mail list logo
