Greetings all,
I believe it is better to update RFC 3484, as well as decide how to best
distribute address selection policies derived there from. Speaking of
source address selection, note that in section 3.1:
'Use of the source address selection algorithm in the presence
of multicast destination addresses requires the comparison of a
unicast address scope with a multicast address scope... we map
unicast site- local to multicast site-local... For example, unicast
site-local is equal to multicast site-local... This mapping implicitly
conflates
unicast site boundaries and multicast site boundaries'
Unicast site-local addresses were formally deprecated in RFC 3879.
Presuming the concept of site for multicast to be well enough defined so
as to not be deprecated, it doesn't seem logical to still conflate it
with something that has been. At the very least, this is the case with
new implementations (as in initial implementation being post-RFC 3879).
Regarding destination address selection, please note in section 3.2:
'IPv4 private addresses... are assigned site-local scope.'
These are unicast addresses, for which the ill-defined (concept of)
site-local has been deprecated. In a post-RFC 3879 implementation, this
also seems illogical.
Continuing on to section 4, regarding candidate source addresses:
'For site-local destination addresses, the set of candidate
source addresses MUST only include addresses assigned to interfaces
belonging to the same site as the outgoing interface.'
Given RFC 3879, there is no compelling case for what constitutes a site
in the unicast address space. Therefore, we seemingly cannot meet the
aforementioned MUST condition. (Yes, I know that site-local multicast
addresses have not been deprecated.) Moving on to section 5 (source
address selection), it is possible that a site-local unicast address
could be chosen by Rule 2. In section 6 (destination address selection),
Rule 2 is more definitive (a site-local unicast address could be chosen
here as well).
RFC 4007 seems to bolster the argument for updating of RFC 3484, given
RFC 3879. See section 1:
'Though the current address architecture specification [1]
defines
unicast site-local addresses, the IPv6 working group decided to
deprecate the syntax and the usage [5] and is now investigating
other
forms of local IPv6 addressing.'
Since both the syntax and the usage of unicast site-local addresses has
been deprecated, this is a case for updating RFC 3484 (RFC 3513 is about
to be updated: see draft-ietf-ipv6-addr-arch-v4-04.txt). Please also
note the beginning of section 10 (routing):
'Note that as unicast site-local addresses are deprecated, and
link-
local addresses do not need routing, the discussion in this
section
only applies to multicast scoped routing.'
It is difficult to route to/through something that effectively no longer
exists. There is also the matter of IPv4-compatible addresses being
deprecated (draft-ietf-ipv6-addr-arch-v4-04.txt is in the RFC Editor
queue; section 2.5.5.1 of this document delineates the deprecation).
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Stig Venaas
> Sent: Monday, August 08, 2005 3:44 PM
> To: ipv6@ietf.org
> Subject: Distribution of RFC 3484 address selection policies
>
> RFC 3484, and implementations thereof, allows for a sysadmin to
> configure address selection policy on a single host. I think this is
> useful, and I suppose also the wg since the RFC was published. One
> typical example might be preferring IPv4 over IPv6.
>
> If I as a site administrator want all the hosts at my site to prefer
> IPv4 over IPv6, I need to distribute that policy to all of them. I
> hope you can understand the need for that.
Yes.
> In that case, I think we
> should try to look for possible solutions. Some applications might
> want to specify their own particular behaviour, but I see several
> reasons why an administrator may want to specify a default.
>
> Using DHCP may be one solution. The only alternative available today,
> is to log into every single host and run each host's OS specific
> commands to change the policy. This might work for hosts that are
> centrally administrated at that site. It would not work for hosts
> visiting that network or under different management.
A possibility for the future (realizing it does not presently exist)
seems to be the creation of a new Router Advertisement option. This
could be something that would be received and used by clients of both
DHCPv6 and SLAC.
Using DHCP to distribute RFC 3484 address selection policies would seem
to work for DHCP clients, yet not for SLAC clients.
>
> Do you agree this is something that should be solved?
Yes.
> It's probably
> a good idea to discuss that before going into particular solutions.
>
> Stig
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
Best regards,
Tim Enos
1Sam16:7
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
