RE: address selection and DHCPv6
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: address selection and DHCPv6
> -----Original Message-----
> From: Vlad Yasevich [mailto:vladislav.yasevich at hp.com]
> Sent: Wednesday, October 25, 2006 10:07 AM
> To: James Carlson
> Cc: ipv6 at ietf.org
> Subject: Re: address selection and DHCPv6
> Why do you want to distinguish between DHCP, manual, and
> autoconfigured addresses? If they are all of the same scope,
> then the longest prefix match _should_ give you the best one
> to use. If they are of different scopes, the scope rule will
> select the better address.
>
> Method of configuration doesn't really play any role here...
Yes, they do, especially when different types of addreses
are configured on the same Interface/prefix.
For example, you can have a host with mannually configured
address 2001:db8:1:1::1 and a stateless autoconf address
within the same prefix: 2001:db8:1:1:aaaa:aaaa:aaaa:aaaa
As the manualy configured ones are supposed to be more stable
than the autoconf ones (they do not depend on a piece of hardware)
you might want to use them in access list, firewalls,...
They might also be the only one populated in the reverse DNS tree...
So, yes, there is a reason to prefer a configured address over a
stateless
autoconf one. Same argument applies with DHCPv6 configured addresses.
I know you can play with the A bit in the RA to prevent hosts from
doing stateless autoconf, but this is a prefix wide directive, it lacks
the host (or group of hosts) granularity. On some OS you can disable
stateless autoconf, but this can be cumbersome.
What is proposed here is essentially a fail safe mechanism that
will make sure that if you combined the different address configuration
types on a subnet, the basic mode of operation is predictible.
- Alain.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.