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

Stig Venaas <Stig.Venaas@uninett.no> Fri, 20 August 2004 11:42 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06219; Fri, 20 Aug 2004 07:42:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7Wl-0007lw-PG; Fri, 20 Aug 2004 07:25:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7Dr-0003dC-Aq for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:06:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04659 for <dhcwg@ietf.org>; Fri, 20 Aug 2004 07:06:07 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7KN-0004mw-QB for dhcwg@ietf.org; Fri, 20 Aug 2004 07:13:01 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KB5a2M008925; Fri, 20 Aug 2004 13:05:36 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KB5ZsK014847; Fri, 20 Aug 2004 13:05:35 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Fri, 20 Aug 2004 13:05:35 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: Dave Thaler <dthaler@windows.microsoft.com>
Subject: Re: [dhcwg] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
Message-ID: <20040820110535.GB14315@sverresborg.uninett.no>
References: <C9588551DE135A41AA2626CB645309370A9FC1FC@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C9588551DE135A41AA2626CB645309370A9FC1FC@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

On Fri, Aug 13, 2004 at 04:54:02PM -0700, Dave Thaler wrote:
> Stig Venaas writes:
> > If we instead used the stateless prefix announcement solution we may
> > need to solve the DAD issue, but there are some advantages.
> > 
> > o For link-local multicast, it would be possible to generate link
> >   unique multicast addresses with no need for DHCP servers or routers.
> 
> Right.  This is what 
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04
> .txt
> does.

Yes, so we have a good solution for that already I think.

> > o For unicast-prefix-based addressing (RFC 3306) you can generate a
> >   /96 multicast prefix from the links unicast /64 prefix and then
> >   using RNG plus possibly DAD you can come up with prefixes to use on
> >   the link. This can be done without DHCP.
> 
> Right.
> 
> > o For Embedded-RP the application will need to learn the prefix from
> >   somewhere. But the system could learn the prefix once (from DHCP,
> >   from config file or whatever) and all the applications use the same.
> >   You can perhaps compare it to how applications use resolv.conf on
> >   unix and how it might be configured from DHCP or other systems.
> 
> And you need a DAD mechanism for address selection within the prefix,
> as with 3306 addresses.

Yes.

I'm not sure it's a good idea, but have you considered whether LLMNR
could be used for multicast DAD? I think it could be done easily, but
it's perhaps a bit ugly since since it uses LLMNR for something it
isn't designed for perhaps.

Another option could be to use or copy the unicast ND DAD mechanism.
I'm sure it would work. You could possibly use ND DAD as it is, with
some standardized way of mapping group addresses to interface id's.
That feels wrong to me, but you could copy the mechanism, and perhaps
add new "multicast group solicit" and "multicast group advertise"
messages that work exactly like todays unicast solicit and advertise.

Well, just some ideas, not sure how good they are...

Stig

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg