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

Jean-Jacques Pansiot <Jean-Jacques.Pansiot@crc.u-strasbg.fr> Mon, 02 August 2004 11:09 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 HAA29693; Mon, 2 Aug 2004 07:09:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BraeU-0007gu-NX; Mon, 02 Aug 2004 07:06:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrZE8-0005Og-TM for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 05:35:29 -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 FAA25957 for <dhcwg@ietf.org>; Mon, 2 Aug 2004 05:35:27 -0400 (EDT)
Received: from ns1.u-strasbg.fr ([130.79.200.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrZGx-0002Rm-QU for dhcwg@ietf.org; Mon, 02 Aug 2004 05:38:25 -0400
Received: from crc.u-strasbg.fr (crc6.u-strasbg.fr [IPv6:2001:660:2402:1001::1]) by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i729ZPvY099300 ; Mon, 2 Aug 2004 11:35:25 +0200 (CEST)
Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i729ZOmg008944 ; Mon, 2 Aug 2004 11:35:25 +0200 (CEST)
Message-ID: <410E0ADD.4050505@crc.u-strasbg.fr>
Date: Mon, 02 Aug 2004 11:35:25 +0200
From: Jean-Jacques Pansiot <Jean-Jacques.Pansiot@crc.u-strasbg.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stig Venaas <Stig.Venaas@uninett.no>
References: <20040801174409.GB14995@sverresborg.uninett.no> <Pine.LNX.4.44.0408020051210.6499-100000@netcore.fi> <20040802044825.GA16941@sverresborg.uninett.no>
In-Reply-To: <20040802044825.GA16941@sverresborg.uninett.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [IPv6:2001:660:2402::1]); Mon, 02 Aug 2004 11:35:25 +0200 (CEST)
X-Antivirus: scanned by sophos at u-strasbg.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 02 Aug 2004 07:06:45 -0400
Cc: dhcwg@ietf.org, Pekka Savola <pekkas@netcore.fi>, 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
Content-Transfer-Encoding: 7bit

Stig Venaas wrote:

>On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote:
>[...]
>  
>
>>Well, one obvious way to achieve all of this is to add a Multicast
>>Prefix Information option (a tailed down version of PI option), to
>>RFC2461/RFC2462 Route Advertisements, and specification of multicast
>>DAD (possibly with a flag in the MPI whether it's needed or not).
>>
>>With that, multiple prefixes could be advertised, but typically one
>>would be enough.
>>
>>(The "good news" here is that a good implementation would not need to 
>>require the router admin to specify the prefix to be advertised on all 
>>the links, but it could be calculated & advertised automatically as 
>>well.)
>>    
>>
>
>The prefixes to use could also be announced by DHCP. You could easily
>use stateless DHCP. In addition to this some form of DAD would be good.
>I don't care that much how the client picks the last 32 bits, it could
>be random, from interface id somehow, or specified by the user. The
>main thing is making sure it's unique.
>  
>
One useful feature of DHCP  is the notion of  a lease for some amount of 
time.
Assume that I want to start a videoconference tomorrow at 9am.  It might 
be useful
to reserve an address NOW (in order to publish it) although applications 
(senders and
receivers) will be launched only to morrow.It seems that we have 3 
solutions :
1)  use some kind of centralized registry on the link (could be dhcp?)
2)  have a local registry on each host, could be similar to a 
dhclient.leases file,
  but then it might need a new daemon to respond to multicast DAD ?
   this should be persistent across crashes and  reboot
3)  do a multicast  DAD now and hope it will  still work tomorrow ?
What do you think ?

Note that mechanism 2 could be useful also for SSM : it allows a user to 
reserve
a channel without conflict with other node-local users/applications

Jean-Jacques


>So, I think there are basically two issues that can be solved
>independently. One is prefix to use, the other is link uniqueness.
>
>The former might be done with RAs or stateless DHCP. The second
>should probably be done using some link-local multicast ICMP, but I
>need to think more about that. One issue is that one needs to allow
>multiple sources for a group in some cases. So I think DAD should
>just be offered as a service, whether an application should use the
>group in case of duplicates should be up to the application.
>
>Stig
>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>  
>



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