RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

"Dave Thaler" <> Wed, 04 August 2004 17:52 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA23406; Wed, 4 Aug 2004 13:52:38 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BsPsm-0007Pd-Dn; Wed, 04 Aug 2004 13:48:56 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BsPjz-0005qy-IR for; Wed, 04 Aug 2004 13:39:51 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA22155 for <>; Wed, 4 Aug 2004 13:39:50 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BsPnG-0004S5-Q9 for; Wed, 04 Aug 2004 13:43:18 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.196); Wed, 4 Aug 2004 10:39:26 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 10:38:59 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
Date: Wed, 4 Aug 2004 10:39:09 -0700
Message-ID: <>
Thread-Topic: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
thread-index: AcR6SBfZhgW4MGcfTVezxeInAQhuCgAAFRfA
From: "Dave Thaler" <>
To: "Ted Lemon" <>
X-OriginalArrivalTime: 04 Aug 2004 17:38:59.0513 (UTC) FILETIME=[ECAC4290:01C47A49]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: quoted-printable

Ted Lemon writes:
> Dave, I think probably the overriding issue that's prevented there
> being more widespread implementation of MADCAP is that the internet
> routing infrastructure doesn't support multicast.   So there aren't
> customers.   So nobody comes banging on our door asking for MADCAP.
> So there's minimal implementation of MADCAP.

Right.  That's my point precisely.  The blocker is not really the
complexity of the protocol, that's a secondary issue.

> I would say that it was a chicken-and-egg problem except that I think
> that if there were routing infrastructure, people would do multicast
> even if there were no MADCAP.   So this isn't really an obstacle to
> implementation - it's something that would be nice to have if only
> there were a place to use it.


> The proposal on the table is simpler than MADCAP, not more

We're in complete agreement here (for IPv6), I said the same thing in my

>    It might be possible to implement even if there is low demand,
> MADCAP, which is a bit fancier, isn't going to get implemented unless
> there is high demand.   So the way I would frame this issue is, if we
> implement the proposal, does that prevent deployment of MADCAP later
> when there's enough demand to support widespread implementation of
> MADCAP.   I think the answer is no.  

Agree, although I think there's little reason to implement MADCAP for
IPv6 if you implement DHCPv6 for multicast.

> And does implementing this help
> people who are trying to solve the real problems in the multicast
> to make forward progress?  Apparently some think yes - I have no
> opinion since I'm not a multicast guy myself. 

This is the part I'm pushing on.  This proposal only solves a problem if
you have V6-only multicast (which is indeed the case in the research
network which motivated this proposal).  I'm asking the WGs whether
there's real
customer demand for any-source multicast, which was the issue at the top
of this email, as well as whether the demand would be for v6-only or for
v4/v6 both.  If folks want a v4 solution as well, they'll do MADCAP, in
which case
the incremental complexity of adding IPv6 support is negligible.

Just making a simpler solution that's IPv6-only doesn't necessarily mean
anyone will use it, and I believe we should only spend IETF cycles on
things that people will use.


> Finally, is it likely
> that people could justify implementing this who can't yet justify
> implementing MADCAP?   TBF, I don't know.   It does look easier to me,
> but it still requires significant code changes.
> Following this line of reasoning, I have to say that I'm tempted to
> the authors to consider whether or not they can make this even
>    Do we really need a new IA type, or can we do this with a regular
> and an option?   The reason I ask is that picking which address
> allocation pool to use based on an option is well-understood
> - I think probably every DHCP server vendor already knows how to do
> this.   And I don't think there are any particularly special
> constraints on how address allocation will be done for multicast
> addresses - you still just pick one out of a pool.   So I think you
> go cheaper on this, and maybe it would feel less like we were trying
> come up with another MADCAP, which doesn't seem like the right thing
> do.

dhcwg mailing list