Subject: RE: why seperate Ia is needed for sending new Requests?

From: [email-masked]
Date: Fri, 16 Mar 2001 09:50:18 -0600

hi ralph,

I agree with you in spirit but the flesh is weak.  we have chased the client
telling servers "I want x addresses" for a long time.  I suggest as I do for
reconf-init multicast we not permit in our effort to get to PS.  We will not
reach consensus and the market is ready for dhcp using ipv6. I also believe
reality is that most clients will get a default number of addresses from the
server.  clients that send another IA will get x addresses as they will be
special anyway.  So though in "theory" it seems messy, in practice I think
it will work fine.

for temporary addresses I think the client setting a bit in IA Status will
tell the server I need to "note" temporary addresses.  When the server
responds it will send x addresses to the client.  Before each address a bit
will be set in the addr status field that this address is "noted" as
temporary.  I really don't think temporary addresses is a complex thing and
I think we need to be careful we don't over complicate this part of what we
need to do.  at the server for the T1,T2,Preferred, and Valid lifetimes the
server can apply the recommendations of rfc 3041 to the times it uses to
provide the client leases.  Pretty simplex stuff I think.  then we just need
to make a decision on whether we let server renew temporary addresses.  in
the design call I think I heard it was ok to extend the valid lifetime but
not the preferred lifetime.  I think we should be able to wrap this up at
minneapolis.

what would be really useful for the wed dhcpv6 venue is if ted could provide
the format and datum picture of the IA + client-id parts for the IA option
and the text for forming it so we can discuss.  That is necessary to go to
last call.  I think this is the most important and critical item we work on
next week.

thanks 

/jim 

> -----Original Message-----
> From: ext Ralph Droms [mailto:[email-masked]]
> Sent: Thursday,March 15,2001 7:57 PM
> To: DHCPv6 discussion list
> Cc: DHCPv6 discussion list
> Subject: RE: why seperate Ia is needed for sending new Requests?
> 
> 
> If I remember correctly, we've considered the issue of 
> virtual web servers 
> in the past.  Based on the capabilities of the current 
> version of HTTP for 
> identifying virtual web servers behind a single IP address, 
> we've discarded 
> virtual web servers as a motivation for on-demand address assignment.
> 
> That's not to say there aren't other motivations for 
> on-demand address 
> assignment.  Perhaps temporary addresses are a good 
> motivating example.  If 
> we're going to add complexity to the protocol to support 
> on-demand address 
> assignment, we need to make sure we understand the specific 
> motivations and 
> requirements.
> 
> - Ralph
> 
> At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote:
> >It is entirely possible for a client to ask for more 
> "normal" addresses. 
> >The reason being in IPv4, addresses were a bottle neck and 
> in IPv6 it wont 
> >be. A server that does web hosting may need thousands of IP 
> addresses and 
> >it may not be possible to know the requirement ahead of time 
> in all cases. 
> >It will contact the DHCP Server to request more IP addresses 
> in this case 
> >or use stateless config to generate the IPs it needs. A 
> server hosting 
> >different services may want to use different "normal" 
> addresses for each 
> >service.
> 
> 
>

---

From: "ebenezer schubert" <[email-masked]>
Date: Fri, 16 Mar 2001 12:11:57 -0800

Hi,

    I would agree with what Jim is saying. The market
    is ready for DHCPv6 and we need some conclusion
    on this fast.

   At the same time there should be some scope for
   whatever the future versions to interoperate with
   the older ones. I would like to make 2 suggestions
   in this regard

    1. To have an unimplemented error message.
    2. To have a version field in the header.

   So that even if the IESG takes a long time to make
   a standard. We can proceed with the existing drafts,
   if the standard is different from the draft, we should
   be able to handle them easily.

-ebi
Hewlett-Packard
408-447-7652