Subject: DHCPv6

From: "timothy enos" <[email-masked]>
Date: Wed, 09 Mar 2005 09:51:59 -0500

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 9 Mar 2005 10:14:36 -0500

Hi Timothy,
      The deprecation of site-local addresses only applies to unicast.
The multicast scoping is still valid and used in various ways.  So,
there is no need to change the site-scoped multicast address used
by DHCPv6.

Regards,
Brian

On Mar 9, 2005, at 9:51, timothy enos wrote:

> Good morning all. I know I missed last call on 
> ‘draft-ietf-ipv6-addr-arch-v4-01.txt’, so decided to start another 
> thread. RFC 3315 (section 5.1) defines a site-scoped address 
> (FF05::1:3, by which relay agents communicate with servers… either to 
> communicate with all servers or if the unicast address of the servers 
> is unknown). RFC 3513 (section 2.7) defines each potential value of 
> the ‘scop’ field, with a value of ‘5’ being used to signify a 
> multicast address with site scope, and ‘8’ being used to signify a 
> multicast address with organization scope (spans multiple sites 
> belonging to an organization). FWIW, it seems both of these should be 
> removed from ‘draft-ietf-ipv6-addr-arch-v4-01.txt’.
>
> Although RFC 3879 (section 1) does state “the formal deprecation 
> allows existing usage of site-local addresses to continue until the 
> replacement is standardized and implemented.”, it also acknowledges 
> that:
>
> -       “As currently defined, site local addresses are ambiguous” 
> (section 2)
>  -       local address “does not contain any indication of the site to 
> which it belongs” (section 2)
>
> Regarding the concept of ‘site’ itself: “The current definition of 
> scopes follows an idealized “concentric scopes” model” (section 2.5)… 
> ultimately concluding “the current concept of site is naïve, and does 
> not map to operational requirements”. It seems that this informs the 
> removal of any reference to any site-scoped address, including the 
> aforementioned one in RFC 3315 (All_DHCP_Servers). What would replace 
> the All_DHCP-Servers multicast address in the revision of 3315 
> (whenever that might be), and how would said replacement impact 
> present implementations?

---

From: "timothy enos" <[email-masked]>
Date: Wed, 09 Mar 2005 23:52:18 -0500

---

From: Brian Haberman <[email-masked]>
Date: Thu, 10 Mar 2005 09:57:03 -0500

In-line...

On Mar 9, 2005, at 23:52, timothy enos wrote:

>
>
> -----Original Message-----
> From: Brian Haberman [mailto:[email-masked]]
> 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

---

From: "timothy enos" <[email-masked]>
Date: Thu, 10 Mar 2005 23:46:17 -0500