(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 PROTECTED]> said:

> 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 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 PROTECTED]

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

Reply via email to