Subject: RE: DHCPv6

From: "timothy enos" <[email-masked]>
Date: Mon, 14 Mar 2005 23:47:53 -0500

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-----
From: timothy enos [mailto:[email-masked]] 
Sent: Thursday, March 10, 2005 11:46 PM
To: 'Brian Haberman'
Cc: 'IPv6 WG'
Subject: RE: DHCPv6

Brian,

            Thank you. This is much more like it. In-line...

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Thursday, March 10, 2005 9:57 AM
To: timothy enos
Cc: 'IPv6 WG'
Subject: Re: DHCPv6

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.

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------