|
Good evening all. This is merely a reposting of my original mails from last week. Having used SMIME, evidently many were not able to read them.
Best regards,
Tim Enos 1Sam16:7
-----Original Message-----
Brian, Thank you. This is much more like it. In-line...
-----Original Message-----
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.
Got it, that is different than in the unicast world…
> 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.
Not as yet, but it’s now on my list. Hope I have not missed last call on it.
> 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.
That deprecation works that way is clear. Not sure anyone is making the case that we can force (or should if we could) someone to change an existing implementation. Had just meant to address a point you seemed to have made in your original reply (that one reason we would not deprecate the use of site-scoped multicast addresses was that it was being used…).
> 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'.
Got it. This gives network operators a lot of latitude. In general, thanks again Brian.
Regards, Brian
Tim 1Sam16:7 |
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
