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

Stig Venaas <Stig.Venaas@uninett.no> Sun, 01 August 2004 18:10 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14068; Sun, 1 Aug 2004 14:10:59 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrKj8-0006Um-3h; Sun, 01 Aug 2004 14:06:30 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrKO4-0007Cr-Nh for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 13:44:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13163 for <dhcwg@ietf.org>; Sun, 1 Aug 2004 13:44:41 -0400 (EDT)
Received: from tyholt.uninett.no ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrKQk-0006Vg-Tz for dhcwg@ietf.org; Sun, 01 Aug 2004 13:47:32 -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 i71HiAV0017729; Sun, 1 Aug 2004 19:44:10 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i71Hi9CE015056; Sun, 1 Aug 2004 19:44:09 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Sun, 01 Aug 2004 19:44:09 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: Pekka Savola <pekkas@netcore.fi>
Message-ID: <20040801174409.GB14995@sverresborg.uninett.no>
References: <Pine.LNX.4.44.0408011802370.31045-100000@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0408011802370.31045-100000@netcore.fi>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu
Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments
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 Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote:
> have RFC3306 or embedded-RP; it is not clear which problem we're solving
> (and which problems remain to be solved).
> In particular, if any host on a link with a /64 prefix could calculate its
> own multicast prefix (unique to that link) on its own, and have 32 bits of
> group-id's to pick from (making sure they don't conflict on that link),
> could one argue that there is no need for central multicast address
> assignment.. but rather a mechanism where the host could pick a group-id in
> such a way it doesn't conflict (a random process should be sufficient, but
> if not, there could be Multicast DAD)?

Yes, I've also thought a bit about this. The 64-bit link-id could be a
starting point too. I think some form of DAD would be nice. It must also
be possible for a host to have multiple groups.

> Similarly, if embedded-RP is used, what you could need is the information
> what is the address of the RP or which prefix one should use for picking the
> multicast addresses.
> So, looking at from a different perspective, it would seem that we don't
> necessarily need DHCPv6 for address assignment itself, but maybe some other
> configuration mechanism to figure out the multicast prefix which belongs on
> the link.

Yes, sounds good. So question then is whether DHCP or something else
should be used. WRT Embedded-RP I think allocating a prefix to the link,
as you suggest, is better than telling the application what the
Embedded-RP address is (applications shouldn't need to know about
Embedded-RP details).

I see some possible issues. There might be a need for giving hosts
different prefixes for different scopes (you could imagine having
one prefix where simply the scope bits are set to whatever scope
is needed). I think there are cases where you might use say
Embedded-RP internally (with small scope) and prefix-based addressing
externally (with larger scope) or vice versa. Or where you may want
different RPs for different scopes.

Well, in short, I also think the fact that we only need uniqueness
per link, should simplify things quite a bit. I would be happy to
work on possible solutions to this.


dhcwg mailing list