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

[Pekka Savola <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg