Subject: RE: address selection and DHCPv6

From: "Durand, Alain" <[email-masked]>
Date: Wed, 25 Oct 2006 11:47:53 -0400

> -----Original Message-----
> From: Vlad Yasevich [mailto:[email-masked]] 
> Sent: Wednesday, October 25, 2006 10:07 AM
> To: James Carlson
> Cc: [email-masked]
> 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 25 Oct 2006 12:22:35 -0400

> autoconf one. Same argument applies with DHCPv6 configured addresses.

Well, here you depend on another piece of hardware, but that's not
an issue.

Also, this preference really depends on the usage cases.  I can see
scenarios, where I would rather use autoconfigured address over the DHCP
or manually assigned one.

> types on a subnet, the basic mode of operation is predictible.

The concern I have is someone else may find the above preference backwards
and may want to always prefer autoconf addresses over DHCP or statically
configured.  This is a policy matter and you are proposing to encode it
into the rules without ability to change.

The rule set are basic postulates that enable best available communication.
As an additonal step, the policy table is provided that allows for specific
preferences.  Is it flexible enough for you want?

-vlad

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Oct 2006 12:51:14 -0400

> or manually assigned one.

Can you describe these?

> into the rules without ability to change.

Yes, that is indeed a concern.  It looks like it's actually a concern
with the existing rule set, as there's no guarantee that (say) best
prefix match is what the user really wanted.

> preferences.  Is it flexible enough for you want?

The policy table is searched by prefix match, so I don't quite see how
that suffices unless administrators have the foresight to avoid both
stateless and stateful on the same prefix, and the policy table is
kept in sync with DHCPv6 allocation pools (via
draft-fujisaki-dhc-addr-select-opt-02.txt, I would assume).

I think it's that lack of foresight that may be part of the underlying
concern here.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Julien Laganier <[email-masked]>
Date: Thu, 26 Oct 2006 05:52:03 +0200

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 usage 
> cases.  I can see scenarios, where I would rather use
> autoconfigured address over the DHCP or manually
> assigned one. 
> 
> [...]
>
> The concern I have is someone else may find the
> above preference backwards and may want to always
> prefer autoconf addresses over DHCP or statically
> configured.  This is a policy matter and you are
> proposing to encode it into the rules without
> ability to change.

Would privacy be the reason why such someone would 
prefer autoconf addresses over DHCP or statically 
configured addresses?

Would adding to the proposed new rule a statement 
similar to those of Source Address Selection Rule 4 
(Prefer home addresses) and 7 (Prefer public 
addresses) as below solve your concern?

Implementations SHOULD/MUST provide a mechanism 
allowing an application to reverse the sense of this 
preference [...] (e.g., via appropriate API 
extensions). Use of the mechanism should only affect 
the selection rules for the invoking application [...] 
Implementations for which [insert reason here] MAY 
reverse the sense of this rule [...]

Best,

--julien

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 26 Oct 2006 09:58:28 -0400

> prefer autoconf addresses over DHCP or statically 

In a sense, yes.  I was thinking of a well known server
with a manually configured address and autoconf. A potential
policy would be to prefer outgoing connections to use
autoconfigured address.

> reverse the sense of this rule [...]

That would certainly address this concern.  This is
all rather hypothetical though.

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.
I guess manually configured addresses are a bit more
stable.

Additionally, the address preference would completely
depend on a deployment scenario.  In Alain's case, he
would prefer DHCP/manual addresses over Autoconf.  In
someone else's deployment, that many not be the case.

The rules as specified now tend to be agnostic more or
less.  They would work no matter how things are set up.
(there are exceptions, such as ULA). 

Of course, implementations may override Rule 8 (longest
prefix match) with something better/different.  I wouldn't
object as strongly to something like this:

   Rule 8 may be superseded if the implementation has other means of
   choosing among source addresses.  For example, if the implementation
   somehow knows which source address will result in the "best"
   communications performance or knows relative stability of addresses
   and wants to select a more stable one.

Regards
-vlad

---

From: James Carlson <[email-masked]>
Date: Thu, 26 Oct 2006 12:30:38 -0400

> 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 manually configured addresses are a bit more

Indeed.

> (there are exceptions, such as ULA). 

More or less?  I don't think the temporary address decision is a small
matter, and I do think this issue is related to that one.

>    and wants to select a more stable one.

I'm no longer quite convinced that this sort of thing is right.
Placing it above rule 8 means that prefix routing issues are ignored.

It seems to want to go below rule 8 in priority order.  But I guess I
could still go along with that as a compromise.