Subject: RE: DHCPv6 address allocation model

From: Richard Draves <[email-masked]>
Date: Fri, 21 Jan 2000 03:02:11 -0800

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Thursday, December 23, 1999 8:15 AM
> To: [email-masked]
> Subject: DHCPv6 address allocation model
> 
> 
> Mike Carney - SNT Internet Engineering 
> <[email-masked]> writes:
> 
> > We feel we've solved the issues of support for multiple 
> addresses (of
> > different prefixes) and multiple servers. Please read the following
> > and let us know if you agree.
> 
> Re: multiple addresses. I posted a note to the dhcpv6 list back in
> august (appended below). Does your solution solve all the points
> mentioned in it? Indeed, has the solution been explained to the WG
> yet?

I think Thomas is right, there are major problems here and I do not like the
ERE proposal. It's complicated and yet doesn't solve the problems.

A link will have a set of prefixes, say one site-local and three global.
With the current design, it seems like the DHCP server should generally
allocate addresses in groups: if a client sends a request with one IP
Address extension, it should get back addresses four addresses in this
example. If it sends another request with an IP Address extension, it should
get back four more addresses.

The client doesn't know how many prefixes are in use on the link, so it
can't adjust the number of IP Address extensions that it sends. And the
client will need addresses formed from each prefix.

Another issue - how does this play with the privacy draft, where clients
will want to get two global addresses for each prefix, one anonymous (not in
DNS) and one public?

Here's a different approach, more like what happens with auto-config: use
two kinds of extensions. First an IP Address Prefix extension that gives the
client a prefix to use in address formation. (This could be a flavor of the
IP Address extension.) This is normally sent in Advertise messages. The
server tells the client about multiple prefixes using multiple extensions.
Then the client requests addresses using the IP Address extension. In
extensions sent in the request, the client can include a prefix of an
address (the normal case for getting new addresses, the prefix being learned
from the Advertise) or an entire address (the normal case for renewing
address leases).

So in the example above, the Advertise would contain four IP Address Prefix
extensions communicating the site-local prefix and three global prefixes.
Then depending on the client's needs it might send in the Request:
a) four IP Address extensions, getting an address for each prefix. It can
control individually the DNS bits for each address prefix.
b) three IP Address extensions, it doesn't want a site-local address.
c) seven IP Address extensions, it wants a site-local, three global
anonymous, and three global public addresses.
d) eight IP Address extensions, it wants to have two sets of addresses,
etc, etc.

Thanks,
Rich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Jan 2000 14:24:04 -0800

Hello Richard,

> ERE proposal. It's complicated and yet doesn't solve the problems.

It does indeed solve some of the problems.  Our goal should be to
solve as many problems as we economically can.

> get back four more addresses.

This is one proposal, but there is no indication about why it's better
than another proposal.  Following the same logic, perhaps some links
might be configured to allocate _two_ addresses per prefix per request,
and some other links might be configured to allocate _.3333_ addresses
per prefix per request.  I don't see what's magic about one, and I don't
see how it's related to application requirements.

I do see that putting the client in charge of getting resources for
its application needs is placing the responsibility where it belongs.

> will want to get two global addresses for each prefix, one anonymous (not in

That's a really interesting question, and I hope before it's over that
an application can get an "anonymous" address just like it can get any
other address, and without any ordering restrictions.  We are long past
the days of serialized batch handling for appliction processing, and
it is the application that should decide whether to be anonymous.

We surely do not want separate applications to be _forced_ to be
associated
with each other by using the _same_ anonymous IP address.  I hope this
is obvious.  And, we don't want to force them to be invoked serially.

> from the Advertise) or an entire address (the normal case for renewing

I don't see the rationale for this!  And, it's very late in the process
to make this restructuring.  As a wannabe mathematician, I enjoy
symmetric
things like the symmetry in your proposal, but my understanding about
how
to make life easier for applications doesn't find much harmony with this
proposal.

Regards,
Charlie P.