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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 16 Mar 2001 16:42:49 -0600

Ralph:

Wish I could remember the details as well.

I think one argument might be that why not just change the UDP port number if you revise the protocol?

Another is that by using a version number, you might not gain that much because at least part of the message format must stay the same in order to be able to recognize that this is a new version of the protocol.

And, a third possiblity is that since the message type is the first byte, why not just use new message types? 

And, forth, future revisions of the protocol could be handled by sending a special option on the Advertise or Solicit to indicate that the server is capable of the extended functionality. Though in this case, the basic message format has to be retained.

BTW: Regarding the error message issue, how about we have a message type which can be sent by a agent (server or relay) to respond to a client to return some error. That way, if the client sends an unknown message type, the server (or relay) can respond. This message type MUST be unicast by the relay or server. That message type might be formatted as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |  error-number |      error-text               |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Probably the only error number that is needed today is "unknown/unimplemented message type"?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, March 16, 2001 5:11 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

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

At 03:25 PM 3/16/2001 -0600, [email-masked] wrote:
>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: Ebenezer Schubert <[email-masked]>
Date: Fri, 16 Mar 2001 15:09:38 -0800 (PST)

Hi,

	As long as there is an agreement that any new functionality starting
	from  draft  revision  xxxx,  there  would be no changes  to the msg
	structure or the  interpretation  of existing  message types and any
	new feature would be through the introduction of a new message type.
	Then it is ok.

	But right  now,  there  seems to be a lot of  changes.  So  having a
	version  no.  field,  can help to  start  the  development  activity
	parallel to the work in the IETF.

	This is the reason why  revising  the  protocol  port no.  would not
	make any  sense,  because  we may not be able to  change  port  nos,
	between different  versions of the draft.  Also, we cannot gurantee,
	that the interpretation of a particular message type will not change
	until this becomes an RFC.

-ebi