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

From: "Dave Thaler" <[email-masked]>
Date: Tue, 3 Aug 2004 13:36:38 -0700

Two technical issues on this draft (larger issues sent in separate
email):

1) One of the things that both the API and the MADCAP protocol provide
is
allocation of ranges (not "several", but a large number of addresses,
like
a block of 400).  This requirement came from applications which want a
larger range to use with things like 
a) hashing resource ids into groups (I can't remember the specific
examples here, but IANA often gets requests for blocks of space, and I
believe many of them are for this reason.  Dave Meyer can probably
correct me :),
b) assignment to areas inside virtual worlds (from customers in the DIS
industry), 
etc.  

These sorts of applications are also the ones most in need of IPv6
multicast instead of IPv4 multicast, and so the requirement is probably
even more compelling in IPv6.

2) Another thing that both the API and the MADCAP protocol provide is
the ability to enumerate scopes (specifically, human readable names for
them,
and TTLs/HopCounts to use with them).  The names for scopes are also
useful
in other contexts besides multicast address allocation.  (E.g., see
discussion of
http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options-
01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come
up in MMUSIC, etc.)  Hence this capability should be retained.

-Dave

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

---

From: Jerome Durand <[email-masked]>
Date: Wed, 04 Aug 2004 15:00:31 +0200

> b) assignment to areas inside virtual worlds (from customers in the DIS

I don't beleive we really need this feature. A company that wants plenty 
of addresses can be allocated manually for example a block. But can be 
added to the specs. (prefix delegation for IPv6 multicast address could 
be the answer)

> up in MMUSIC, etc.)  Hence this capability should be retained.

Could be added in information-requests for example. I think this is useful.

Jerome

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 10 Aug 2004 13:23:45 +0200

> even more compelling in IPv6.

I agree with the needs above. I'm not sure a complex DHCP solution
that fully replaces MADCAP is the way to go. I would rather argue for
a simplest possible DHCP solution (well, it must be simple but still
useful) and say that MADCAP is the alternative if one has additional
requirements.

> the ability to enumerate scopes (specifically, human readable names for

I'm not sure how important that is for IPv6, if the scoping is to
strictly follow the scoping defined by the 4-bit scope field. Or do
you want to allow for scopes defined in other ways? I can see some
reasons for locally defined names though if the user is to choose
which scope to use based on the names.

> and TTLs/HopCounts to use with them).  The names for scopes are also

Do we really need to specify hopcount for IPv6 multicast? For IPv6 we
have a large number of well defined scopes, shouldn't scope rather than
TTL be used to limit the distribution?

> up in MMUSIC, etc.)  Hence this capability should be retained.

Stig