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

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 18:03:48 +0300 (EEST)

Hi, 

A few comments.

Bigger ones:

 1) I'm concerned whether this is exactly what we need, especially when we
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)?

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.

Remember, we're talking about v6 here which is completely different than v4
multicast address assignment scenarios (address scarcity, centrally managed
pool, etc.)!

 2) I think this approach and its implications could use a bit more
discussion inside mboned (which is why I argue splitting it up makes sense).

In particular, the assignment of addresses is also coupled with service
discovery/announcements, which was decreed out of scope from here.  But as
DHCPv6 servers can even update DNS records, it could be possible to envision
that if they give out v6 multicast addresses as well, they might be capable
of other difficult tasks as well.

(If the document is split, it might make sense to keep sections 1-4 in
mboned, and include new section 5 which would describe different new
approaches to these scenarios -- e.g., various uses of DHCPv6,
multicast-DAD, the embedded-RP communicating the address at which it's
serving (e..g, if on every link, the ::1 one) ...)

3)

   o  DHCPv6 usually has impacts on the kernel (IPv6 unicast addressM
      assignment, DNS address indication...) and the problem ofM
      multicast address assignment is in user space. Are there someM
      problems that could be coming from this ?M

==> this brings out a lurking issue.  As v6 multicast addresses are given
out only temporarily, with lifetime, the question is, who keeps track of
that lifetime and removes the usage as appropriate?

In other words, I assumed that this approach assumes that when an app wants
to use a multicast address, the user/administrator of that application
puts in a request in DHCPv6, and gets a (temporary) address.  (S)he then
configures it in the application, and runs the application.  But then there
is no link with the lifetime of the address.

The other approach would probably be to make it more complex, adding some
kind of API between DHCPv6 and multicast application, but that would
probably be a non-starter due to its complexity.

In any case, it seems the impact of lifetime needs to be considered a bit
more deeply...

semi-substantial
----------------

   option-code: OPTION_IA_MA (21)M

==> have these option codes already been assigned by IANA,
or are you just suggesting to use these?  Should probably be replaced by
TBD's, and noted in IANA Considerations section to be added.

editorial
---------

==> IMHO, the abstract should be a bit longer, maybe 5-10 lines.

   o  This random assignment could also be used with embedded RPM
      addresses if the RP is managing a few number of groupsM

==> as noted above in issue 1), this might not be as straightforward that,
as the host needs to know the RP's Interface-ID (at least) first-- possibly
also which kind of prefix to use..

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M
+M
         |                                                               M
|M
         .                         IA_MA-options                         M
=2EM
         .                                                               M
=2EM
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M

==> this seems to have wrapped, and there are some =2E chars here..

   know exactely the scope it wants to request but has a set of adequatM

==> s/adequat/adequate/

   res: This field is reserved for future use. The 4 bits of this fieldM
      MUST be set to 0M

==> , and MUST be ignored on receipt. (similar elsewhere)

   Security and pricacy considerations of the assignment of IPv6M

==> s/pricacy/privacy/

   o  Split in 2 different drafts: one for the DHC WG with theM
      description of the DHCPv6 options and mechanismsand; the other oneM

==> s/and/ and/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Sun, 1 Aug 2004 19:44:09 +0200

On Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote:
[...]
> 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.

> configuration mechanism to figure out the multicast prefix which belongs on

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.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Aug 2004 01:01:06 +0300 (EEST)

On Sun, 1 Aug 2004, Stig Venaas wrote:
[...]
> different RPs for different scopes.

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.)

Additionally, individual addresses could also be dealt with DHCPv6 or
something, but I personally don't see that as equally attractive.. but
in cases where this is attractive IMHO manual addressing, as it's done
today, is probably typically more lucrative..

---

From: Stig Venaas <[email-masked]>
Date: Mon, 2 Aug 2004 06:48:25 +0200

On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote:
[...]
> the links, but it could be calculated & advertised automatically as 

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.

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

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Mon, 02 Aug 2004 11:35:25 +0200

>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

>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>  
>