Tuesday, June 23, 2009

Re: [Geopriv] Issue: version "negotiation"

There are no per-option version indications in DHCP.  For the most part, DHCP options are simple enough not to need versioning – it seems that versioning is expected to be done by consuming another option code and deprecating the old one (an approach I am beginning to appreciate heartily).

 

We aren't able to signal compliance in DHCP (*).  I can't speak for 11k, but I'd imagine that the story would be similar.

 

My perspective:

a.       Yes.

b.      Yes.

c.       My understanding is that a sensible v0 client will discard the information because it will interpret this as a "datum" that it does not support.  If someone actually has knowledge of an implementation that does other than this, then it would be a bug and we might look at that implementation specifically if it were especially widely deployed.

 

--Martin

 

(*) not strictly true: it used to be that DHCP (BOOTP?) clients sent up the options that they wanted in a request.  This is long deprecated by option 55.  We could hack something with that, but we'd be risking the ire of all sane DHC experts.

 

 

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Tuesday, 23 June 2009 5:08 PM
To: Thomson, Martin; drage@alcatel-lucent.com; jmpolk@cisco.com; rbarnes@bbn.com; mlinsner@cisco.com
Cc: geopriv@ietf.org
Subject: Issue: version "negotiation"

 

Martin said:

"Certainly we shouldn't be encouraging people to try to send the old encoding".

There are a number of potential cases here:

a. Legacy (v0) client speaking to v1 server.
b. Legacy (v0) client speaking to v0 server.
c. V1 client speaking to v0 server.
d. V1 client speaking to v1 server.

Am I correct in saying that there is nothing in the DHCPDISCOVER packet (or 11k location request, etc.) which provides the server with information on the version of the client?
Or is it possible for the server to learn (either out-of-band or in-band) what version the client supports?

Some questions:

a. Should a client implementation of RFC 3825bis be capable of handling both v0 and v1 packets sent by a server?
b. Should a server implementation of RFC 3825bis always set the version number to 1?
c. Do we understand how existing v0 client implementations will behave if they receive a v1 packet from a server?




------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]