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

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