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

From: [email-masked]
Date: Fri, 16 Mar 2001 15:25:41 -0600

I mean't to bring up the version number before.  We were asked for this some
time ago and a suggestion from several.  I can't recall arguments against it
and it may have fell through the cracks?  

/jim

> -----Original Message-----
> From: ext ebenezer schubert [mailto:[email-masked]]
> Sent: Friday,March 16,2001 3:12 PM
> To: DHCPv6 discussion list
> Subject: Re: why seperate Ia is needed for sending new Requests?
> 
> 
> 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
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: DHCPv6 discussion list <[email-masked]>
> Sent: Friday, March 16, 2001 7:50 AM
> Subject: RE: why seperate Ia is needed for sending new Requests?
> 
> 
> > 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: Ralph Droms <[email-masked]>
Date: Fri, 16 Mar 2001 17:11:06 -0500

It's Friday afternoon, my wife's been visiting her mother in Wisconsin all 
week and I'm rushing around getting ready to go to Minneapolis - so I'm 
having trouble remembering the details about previous discussions about a 
version number in the DHCP message header.

But it strikes me that we came to the conclusion that a version number 
turns out to be not all that useful.  Does anyone else remember having this 
discussion previously - it might have been regarding DHCPv4?

- Ralph