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

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

I'll put the larger meta issues in this message, and the specific
technical comments on the draft in a separate message. I pretty much
agree with Pekka's comments.

We have a proposed standard protocol (MADCAP) that does everything this
draft can, but is more complex.  The main question is whether there is
sufficient justification to create another slightly better way of doing
the same thing?

Two types of issues that are not relevant:
* Config issues, since MADCAP admin can be (and is)
integrated with DHCP, and the set of things to configure/administer
is unchanged in this proposal.
* Application API issues, since this is again the same between MADCAP
and this draft.

Complexity issues ARE relevant.  MADCAP was designed to be able to
share database-type code with a DHCP implementation, but 
parsing-type code is different.  This draft doesn't require 
parsing-type code to be different (other than a couple new 
options).

Let's first recall a bit of history to see where we're at today:

From minutes of December 1998 IETF
(http://www.icir.org/malloc/minutes.98.12.html), there was a survey of
DHCP implementers, regarding MADCAP (formerly known as MDHCP):
	5 DHCP implementors responded. 

	Do you think that you might implement an MDHCP client or server?

	3 Yes, 1 will accept mods, 1 if there's demand 

	If you were to do so, would you attempt to share code with your
DHCP
	client or server? 
	3 Yes, 1 Maybe, 1 Little 

	Do you think that we should continue to maintain a similarity
	between MDHCP and DHCP? 
	3 Yes, 1 No Opinion, 1 Do The Right Thing

Now we have at least 2 implementations of MADCAP (Windows and Linux) for
IPv4, but no implementations of MADCAP that I'm aware of for IPv6 (yes
the RFC covers both).  However, although there have been deployments, we
have not seen lots of deployments of it.  If there were major blocking
issues specific to the protocol, one would think the current
implementers would be aware of them.  Instead, there is just lack of
customer demand.  

Next, what has changed in the world between 1998 and 2004?
1) We have SSM, and the majority of the application drivers of multicast
usage fit into that model.  This reduces the need for anything new in
this space, since both MADCAP and this draft are specific to ASM.
2) The expectation that interdomain multicast will become ubiquitous has
gone down somewhat.  Again this reduces the need for anything in this
space.
3) We have Unicast-Prefix-Based Multicast Addresses for IPv6.  This
reduces 
again the need for server-based allocation, since techniques on a LAN
may be used instead (like random allocation, or perhaps something like
ZMAAP).
4) Because multicast connectivity is not ubiquitous, application-layer
multicast solutions and infrastructures are now common.  This again
reduces the demand for IP multicast to cases with efficiency issues,
such as those with a huge number of receivers, which is often the same
class of applications wanting SSM.
5) MADCAP implementations are available.
6) DHCPv6 implementations are available.

Is there anything above that would suggest that creating another
solution  would be sufficient to generate more customer demand?  At the
moment, I'm not seeing it, even taking #6 into account, and so this is
the first question that needs to be answered before committing to invest
significant effort.  Are we just hoping that if the widget is painted
green instead of red, that people will buy it because green is a nicer
color and green means go?  Or is the color not that important because
it's still just a widget?  

Next question: do we expect ASM to be deployed in a given network
a) not at all
b) only for IPv6
c) for both IPv4 and IPv6
d) only for IPv4

If (a) or (d), then this draft is moot.  
If (b), then this draft is nice.
If (c), then there's one argument that the same solution should be used
for both IPv4 and IPv6 to provide consistency and ease of management
(admins don't have to learn two different things).  MADCAP was designed
for this, whereas DHCPv4 can't be used.  Hence this argues that MADCAP
is a better fit for (c).

Final high-level point: the draft states that DHCPv6 is expected to be
widely deployed, which I agree with.  However, the use of DHCPv6 for
address allocation will be less widely deployed.  In an environment
using stateless addr conf for address allocation, some of the reasons
why the DHCPv6 solution is desirable go away, since the mechanism will
be new to the admins regardless of whether one uses existing MADCAP or
new DHCPv6 stuff. 

-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:05:00 +0200

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Aug 2004 14:08:07 +0200

On Tue, Aug 10, 2004 at 09:45:36AM -0700, Ted Lemon wrote:
> Stig, maybe you can explain for me how it is less complicated to supply 
> multicast prefixes than it is to do stateful allocation - I don't get 
> it.   With multicast prefixes, the client either has to take its 

OK, I'll try.

> chances with the possibility of a collision, which seems quite likely 
> (random number generators are usually deterministic, not random, and 
> getting one that uses any real source of entropy is difficult, not 
> easy), or it has to do some kind of duplicate address detection, which 
> also seems difficult, not easy.

I don't have a clue what the likelihood is. But just to make it clear,
we're talking of a 32-bit number. So question is how likely is it for
two hosts/applications on the same link to pick the same 32-bit value.
I agree that some form of DAD could be needed, and I agree it's not
easy. I've been wondering slightly if the DAD in Neighbor Discovery
could be reused, but anyway, it's a big complication, I agree.

> In contrast, while stateful address allocation requires slightly more 
> work on the server side (in the sense that the server has to remember 
> which address it allocated), it's much easier on the client side - the 
> client gets a specific address, doesn't need a good RNG, and doesn't 
> need to do multicast DAD.   The additional complexity of remembering 
> which IP address we gave to the client is well-understood technology, 
> requiring no innovations and risking no accidental DoS attacks from 
> broken clients.

The stateful approach introduces some other complexity on the client
that I'm concerned about.

The main issue, is that it's the application that needs the
addresses. You need some additional infrastructure/middleware on the
host. Either the application needs to act as DHCP client (there are
big issues with that) or the application needs some standardized way
of communicating with the DHCP client. Basically the application will
need to signal to the DHCP client that it needs an address, and that
must be returned back to the client. Also, while the application is
running, the DHCP client must renew the address on behalf of the
application. I've been trying to think through how to actually
implement this, and it's not easy.

I must say though, that coming up with a general solution to how
applications can interact with DHCP might be interesting.

If we instead used the stateless prefix announcement solution we may
need to solve the DAD issue, but there are some advantages.

o For link-local multicast, it would be possible to generate link
  unique multicast addresses with no need for DHCP servers or routers.

o For unicast-prefix-based addressing (RFC 3306) you can generate a
  /96 multicast prefix from the links unicast /64 prefix and then
  using RNG plus possibly DAD you can come up with prefixes to use on
  the link. This can be done without DHCP.

o For Embedded-RP the application will need to learn the prefix from
  somewhere. But the system could learn the prefix once (from DHCP,
  from config file or whatever) and all the applications use the same.
  You can perhaps compare it to how applications use resolv.conf on
  unix and how it might be configured from DHCP or other systems.

> History suggests that DHCP server implementations are more likely to be 
> correct than DHCP client implementations, perhaps because there is less 
> risk of monoculture in the interoperability testing done by a DHCP 
> server vendor than by a DHCP client vendor (a client vendor will 
> typically test against a single server, whereas a server vendor will 
> typically have many different clients to test against).

Right

> So if it makes sense to do something like this, I would vote for doing 
> it in a stateful manner, not a stateless manner.

I think something like this is needed. Currently I'm in favour of
stateless, but I'm trying to explore both possibilities. I'm not
sure myself which one is superior.

Stig