In-line...
On Mar 9, 2005, at 23:52, timothy enos wrote:
-----Original Message----- From: Brian Haberman [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 10:15 AM To: timothy enos Cc: 'IPv6 WG' Subject: Re: DHCPv6
Hi Brian, I am actually aware that RFC 3879 only applies to deprecation of site-local unicast addresses (first sentence in section 4 makes that clear). It was rather the ill-defined concept of 'site', called out by 3879, that prompted my reference to it. I agree with the statements in RFC 3879 concerning the concept of 'site', and am hoping for some clarification. Please understand that the following questions are NOT rhetorical; I do no t know, and honestly seek answers. Why are site-scoped multicast addresses (e.g. ff05::1:3) still considered valid, when the concept of 'site' does not seem to be?
The term 'site' refers to an administrative/operational area. Each network
operator can define a site as he/she sees fit.
Exactly what is a 'site' in terms of site-scoped (and
organization-scoped) multicast addresses? How far can data destined for
a site-scoped multicast address be routed before it inherently cannot be
routed anymore?
Have you read draft-ietf-ipv6-scoping-arch-02.txt? It covers the areas of interest with respect to scoped addresses. Section 4 of that document discusses the relationship between the multicast scopes. Sections 5 & 6 deal with the topics of Scope Zones and Zone Indices.
That the present multicast scoping is being used in various ways
does not inherently impute unconditional validity to it. Some
implementations are still using site-local unicast addressing. Given RFC
3879, this obviously does not unconditionally validate their use (it
does say that "Existing implementations and deployments MAY continue to
use this prefix.", but it also says "The specific behavior of this
prefix MUST no longer be supported in new implementations.")
This is all typical of deprecation. We can't force someone to change existing function.
My understanding is that site-local means the same thing in unicast as it does in multicast addressing (as also with interface-local, link-local, and global). How is it that the concept of site is valid in multicast addressing (the original example being the All_DHCP_Servers address) when it is not in unicast addressing? It is not clear to me, based upon your original answer, why there would be no need to change the site-scoped multicast address used by DHCPv6.
The use of scopes in multicast is an evolution beyond the way IPv4
multicast utilized TTL scoping to limit areas of multicast use. It is also
more rigidly defined than the IPv4 scoped multicast range 239/8.
In order for an operator to use the ALL_DHCP_SERVERS address, the network must be configured to restrict the forwarding of site-scoped multicast addresses to some administrative boundary. So, the routing and forwarding engines within that network must have knowledge of the perimeter of the area that the operator has deemed a 'site'.
Regards, Brian
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
