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

[Stig Venaas <[e-mail]>]

On Wed, Aug 04, 2004 at 10:25:54AM -0700, Ted Lemon wrote:
[...]
> The proposal on the table is simpler than MADCAP, not more complicated. 
>   It might be possible to implement even if there is low demand, where 
> MADCAP, which is a bit fancier, isn't going to get implemented unless 
> there is high demand.   So the way I would frame this issue is, if we 
> implement the proposal, does that prevent deployment of MADCAP later 
> when there's enough demand to support widespread implementation of 
> MADCAP.   I think the answer is no.  And does implementing this help 
> people who are trying to solve the real problems in the multicast world 
> to make forward progress?  Apparently some think yes - I have no 
> opinion since I'm not a multicast guy myself.   Finally, is it likely 
> that people could justify implementing this who can't yet justify 
> implementing MADCAP?   TBF, I don't know.   It does look easier to me, 
> but it still requires significant code changes.

It should be easier to implement, and easy to deploy IMO. A DHCP
solution should be made as simple as possible, and I don't think it
prevents later deployment of MADCAP either.

> Following this line of reasoning, I have to say that I'm tempted to ask 
> the authors to consider whether or not they can make this even simpler. 
>   Do we really need a new IA type, or can we do this with a regular IA 
> and an option?   The reason I ask is that picking which address 
> allocation pool to use based on an option is well-understood technology 
> - I think probably every DHCP server vendor already knows how to do 
> this.   And I don't think there are any particularly special 
> constraints on how address allocation will be done for multicast 
> addresses - you still just pick one out of a pool.   So I think you can 
> go cheaper on this, and maybe it would feel less like we were trying to 
> come up with another MADCAP, which doesn't seem like the right thing to 
> do.

Yes, I believe regular IA and option is fine. I would suggest an even
simpler approach though. I think it's sufficient for the server to
specify which prefix the client should pick the group address from.
With prefix based addressing (RFC 3306), including Embedded-RP, you can
get a /96-prefix from DHCP server. All clients can get the same /96-
prefix. The client would then pick the remaining 32 bits at random. The
chances of a collision are minimal, but one could possibly in the future
consider some form of DAD or some other way to ensure uniqueness.

If not using prefix based addressing, one can still give client a prefix
from which it should pick group address, e.g. ff0e::/96.

If a client knew that prefix based addressing was used (but not
embedded-RP) it could use its own unicast prefix to compute the
multicast prefix, but I think the administrator should be able to
choose which method should be used. When using embedded-RP, I think
it's much cleaner to simply tell application what prefix to use, than
to tell it the RP address and require application to compute the prefix.

Giving the client a prefix rather than an address allows for several
simplifications.

First, DHCP server can be stateless, client uses "stateless DHCP".

Second, and perhaps more importantly, one doesn't need to hand out
addresses to applications. The multicast prefix to be used, could
be given to the system together with other DHCP info. It's still a
question how applications can learn which prefix to use though. And
the DHCP client may not know which scopes an application may want.

I would expect a site to only use multicast prefixes from a few
scopes though, so one could give the client prefixes for all the
scopes. One could also imagine giving the client one prefix, and
say which scopes it can be used for. That is, client e.g. receives
the prefix "ff3e:40:1234:5678:9abc:def0::/96" and the scope list
"5,8,e", meaning that the prefixes ff35:40:1234:5678:9abc:def0::/96,
ff38:40:1234:5678:9abc:def0::/96 and ff3e:40:1234:5678:9abc:def0::/96
are to be used for the respective scopes. In this case, the scope
used in the prefix itself is ignored. Perhaps there also should be
some way to say that a prefix can be used for all scopes.

There are some interesting issues wrt handing out addresses to
applications. I think either applications must speak DHCP, or
there must be some sort of API for applications to communicate
with some DHCP middleware...

Stig

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