Subject: address selection and DHCPv6

From: James Carlson <[email-masked]>
Date: Tue, 24 Oct 2006 15:52:18 -0400

I've done quite a bit of searching over the archives and over various
web resources, but I haven't seen this issue addressed directly.
Apologies if I've just missed it.

RFC 3484 ("Default Address Selection for Internet Protocol version 6
(IPv6)") section 5 gives a set of ordered comparisons for source
address selection.  However, missing from this list is a distinction
implied by RFCs 2461 and 2462: some systems may have a mix of
addresses acquired by stateless address autoconfiguration, stateful
(DHCPv6) configuration, and manual addressing.  How are these
distinguished?

Rule 7 does address the temporary (RFC 3041) addresses, but what about
these other flavors of addresses?  Are they distinguished only by
scope?

Was this issue addressed and intentionally omitted from the RFC?  (If
so, I don't see it in the archives.)

I suspect that some clients may need to distinguish among the various
flavors here.  I'd suggest amending Rule 7 to read:

   Rule 7:  Prefer stable, public addresses.
   If SA is a manually-configured address and SB is automatic or
   temporary, then prefer SA.  If SA is automatically configured via
   stateful (DHCPv6) methods and SB is automatically configured via
   stateless methods or temporary, then prefer SA.  If SA is
   automatically configured via stateless methods and SB is temporary,
   prefer SA.

   Similarly, if SB is a manually-configured address and SA is not,
   then prefer SB.  If SB is stateful and SA is stateless or
   temporary, prefer SB.  If SB is stateless and SA is temporary,
   prefer SB.

   When the application has the "prefer temporary address" flag
   enabled, all temporary addresses are (within this rule) elevated in
   preference above manually-configured addresses.  The other
   preferences are unaltered.  (In other words, the preference order
   with this flag set becomes temporary first, then manual, stateful,
   and stateless last.)

... or, to simplify, defining a "stability_of_address(A)" function
that can work 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

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

---

From: Lawrence Zou <[email-masked]>
Date: Wed, 25 Oct 2006 10:02:13 +0800

I don't think we should amending rule 7 in such a way.
 in fact , i think this will make the rule 8 unworkable.
according to RFC3484,when at last we have two source address
available,both can pass rule1-rule7,then,the rule 8 
will chose the longest match prefix.but if we amend rule 7 and prefer
manul-configured address,some thing changed,for example:
address A is autoconfigured  and belong to ISP1,host use it to access
network of ISP1.
address B is manuconfigured and belong to ISP2,host use it to access
network of ISP2.
then if we prefer manuconfigured address ,we will chose address B as
source when we access ISP1,that maybe refused by the PE router of ISP1
for the reason of soure address filter.

Best regards,

Lawrence  

>-----Original Message-----
>From: James Carlson [mailto:[email-masked]] 
>Sent: Wednesday, October 25, 2006 3:52 AM
>To: [email-masked]
>Subject: address selection and DHCPv6
>
>I've done quite a bit of searching over the archives and over 
>various web resources, but I haven't seen this issue addressed 
>directly.
>(IPv6)") section 5 gives a set of ordered comparisons for 
>source address selection.  However, missing from this list is 
>a distinction implied by RFCs 2461 and 2462: some systems may 
>have a mix of addresses acquired by stateless address 
>autoconfiguration, stateful
>Rule 7 does address the temporary (RFC 3041) addresses, but 
>what about these other flavors of addresses?  Are they 
>distinguished only by scope?
>
>Was this issue addressed and intentionally omitted from the 
>RFC?  (If so, I don't see it in the archives.)
>
>I suspect that some clients may need to distinguish among the 
>various flavors here.  I'd suggest amending Rule 7 to read:
>
>... or, to simplify, defining a "stability_of_address(A)" 
>function that can work here.
>
>--

---

From: Su Thunder <[email-masked]>
Date: Wed, 25 Oct 2006 13:17:28 +0800

For example,an interface has two an addresses, automatic-configured 1000::1/65 and manually-configured 2000::1/64,and 1000::2/64 is the on-link neighbour of the interface.We send a packet, for example and ICMPv6 echo, with a destination address of 1000::2 from the interface,then the source address would be 2000::1because it is manually-configured.Then the destination address of the ICMPv6 echo reply would be 2000::1,in the worse case,the sender of the ICMPv6 echo reply does not have a route to 2000::0/64.The sender of ICMPv6 echo would not receive an echo reply, though it had sent a packet to it's on-link neighbour.
The mainly porpuse of source address is two-way communication,it has nothing to do with the way it is configured.

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 25 Oct 2006 10:06:55 -0400

> these other flavors of addresses?  Are they distinguished only by

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...

Temporary addresses are a privacy subset of autoconfigured addresses,
and are thus spelled out in the document.

-vlad

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Oct 2006 10:22:46 -0400

Vlad Yasevich writes:
> addresses?

In some deployments, DHCP-derived and manually configured addresses
may have attributes that statelessly autoconfigured addresses do not,
such as useful DNS entries.  Stateless autoconfiguration _can_ (though
of course usually does not) lead to address instability over time as
well, where stateful methods are more stable.

>  If they are all of the same scope, then the longest prefix

If they're of the same scope and in the same prefix, then what?

An alternative might be a new "rule 9" that compares address
stability as a final tie-breaker.  Would that be more acceptable?

> and are thus spelled out in the document.

I would think that if the scope and prefix rules alone were sufficient
to distinguish DHCPv6 addresses from the others, then those same rules
would be enough to distinguish temporary addresses, at least for the
default (non-preferred) case.  The mechanisms that create both are
similar.

In any event, it's a good thing that the operator behind the question
(Alain Durand) is on the list.  I hope he can follow up with specifics
of the deployment problem he faces.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 30 Oct 2006 16:02:51 +0900

(I've read the other messages in this thread, but I was not sure which
one is the most appropriate to follow up to, so I'm going to reply to
the original question...)

>>>>> On Tue, 24 Oct 2006 15:52:18 -0400, 
>>>>> James Carlson <[email-masked]> said:

> so, I don't see it in the archives.)

I don't remember a discussion about this point, but in any case, I
personally don't think we should try to distinguish these different
types of addresses for several reasons.

First, I don't think a mixture of different types of addresses is so
common, especially addresses of the same scope - assuming ULAs are
categorized in a different "scope" than that of other global addresses
in this context.  For example, if I were a site administrator who
wants to configure end host addresses by DHCPv6 for centrally
controlled allocation, I would disable stateless address
autoconfiguration by setting the A bit for global prefixes in RAs.

Of course, we may see a mixed address configuration by accident e.g.,
due to misconfigured routers, but I don't think it's in the scope of
**default** address selection rules.  (note that other rules in
RFC3484 basically deal with cases that are normally expected to
happen: we normally have addresses of different scopes, a mobile node
normally has both home and care-of addresses, a privacy-conscious host
will normally have both temporary and public addresses, etc).

Secondly, if the reason for distinguishing these addresses in address
selection is to prefer a "stabler" address, I don't think the
stability is so obvious from how the address is configured (via DHCPv6
or SAAC or manual config, etc), as others pointed out.

Third (which is less substantial), since DHCPv6 can also allocate a
temporary address, the additional rule covering addresses configured
via DHCPv6 will make selection complicated.  For example, we'll need
to clarify whether a public address configured via stateless
autoconfiguration should be preferred to a temporary address
configured via DHCPv6, etc.  I'm not sure if we can find a reasonable
"default" rule here.

Overall, it seems to me this issue (if we want to handle it in normal
operation) is a matter of policy and beyond the scope of *default*
selection rule.  For example, if we really want to mix addresses
configured vi DHCPv6 and addresses configured via SAAC, and want to
prefer (e.g.) the former to the latter, (again, as others pointed out)
we could differentiate the prefixes for these addresses and control
the preference by distributing the policy table via (e.g.) a DHCPv6
option proposed in draft-fujisaki-dhc-addr-select-opt-00.  Or,
espically in case of DHCPv6, we may even do that without separating
the prefixes by specifying the allocated address itself as a /128
"prefix" for the address selection policy DHCPv6 option.  This way, we
can use the same DHCPv6 message(es) to allocate the address with the
address selection preference.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]