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

On Tue, Aug 03, 2004 at 01:36:38PM -0700, Dave Thaler wrote:
> 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.

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.

> 2) Another thing that both the API and the MADCAP protocol provide is
> the ability to enumerate scopes (specifically, human readable names for
> them,

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?

> 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

Stig

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