Subject: RE: Advertising prefixes rather than addresses

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 16:41:54 -0500

Well, after trying to construct a message that argued for this because:
- What if you have no router but wanted stateless.
- This could be used in place of stateless when you wanted some level of control
as to which clients used which prefixes (for example, preventing printers from
using global addresses).
- ...

I also ran across a problem in that servers would need to take care on how this
was used since you could not tell a client to do this multiple times per prefix
(in cases where a client requested multiple IAs).

And then if the server is doing work anyway to answer these requests, why
not have it do the address assignment as well? It shouldn't be that much more
work for the server to generate an address for the client and log it.

So, I think we shouldn't bother with this support now.

- Bernie

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 5:10 PM
To: DHCPv6 discussion list
Subject: Re: Advertising prefixes rather than addresses

This is just duplicating functionality that is already in stateless
autoconfig. Presumably you'd use DHCPv6 for addressing if you wanted to do
it statefully. So I don't see the need or purpose of this. 

> > Bernie Volz wrote:
> >
> > >    At another time we also discussed using the server to just
> > >    advertise prefixes and allowing the client to generate the
> > >    addresses? What about adding a "P" bit (next to the "T"-temporary
> > >    bit) to indicate that this is a prefix from which the client should
> > >    generate an address (or simply allowing it to do so if the
> > >    link-identifier field is all 0's).
> >
> > Sounds like a reasonable idea - anyone have a strong reaction (either
> > positive or negative)?
> >
> > - Ralph

---

From: Jim Bound <[email-masked]>
Date: Fri, 27 Jul 2001 12:10:07 -0400 (EDT)

I am fine with that too.  I don't care either way.  I was just providing
abstraction of why it might be needed and ramifications to the protocol.

/jim