Subject: [dhcwg] New version of DHC URI Option available

From: "James M. Polk" <[email-masked]>
Date: Thu, 09 Mar 2006 18:03:40 -0600

DHC WG

I have updated the DHC Option ID for URIs here:

http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-03.txt

Here are the highlights of the changes since -02:

    - offered an external applicability statement for URI purposes 1, 2 & 4,
      related to emergency services, in [ID-MAPPING] - which is located here:
http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt

    - clarified how concatenation functions according to RFC 3396

    - Added an Operational Considerations Section (6) as was asked for
      in Vancouver.  Asked for help if this still doesn't meet what the WG
      wants

    - rearranged the URI purposes into one group dealing with emergency
      services and another dealing with location.

    - subtle modifications to text here and there

Comments are greatly appreciated here

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Thu, 09 Mar 2006 16:21:38 -0800

> Comments are greatly appreciated here

Same as before.   You have a quote:

   - Server responses to a request for more than one URI MAY be in 
     separate messages (i.e. one URI per message), at the server's 
     discretion 

What do you mean by "separate messages"?  Is this implying that a DHCP 
service would need to be able to send multiple ACKs back in response to 
a single REQUEST (or INFORM for that matter)?

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 09 Mar 2006 18:45:41 -0600

Andre

I do not foresee this being the normal case, as the limit to any URI is 253 
bytes.  But if there are enough URIs requested from the client, then there 
could be more than one IP packet necessary to get them all to the client - 
unless the wording is changed in the doc.

A client cannot know how large any given URI is when it requests for a 
certain type of URI, but it can know if there is a limit to the aggregate 
of all URIs requested.

Should a new rule state there can be no more than 5 URIs (totaling 1265 
bytes) requested in any one server request message to ensure they fit into 
a single IP packet?  I have no issues with such a rule.

Again, I do not see this limit being pushed in deployments, but language to 
limit this possibility could be good to have.

Is this approximate change good?

At 04:21 PM 3/9/2006 -0800, Andre Kostur wrote:
>   - Server responses to a request for more than one URI MAY be 
> in     separate messages (i.e. one URI per message), at the 
> server's     discretion
>
>service would need to be able to send multiple ACKs back in response to a 
>single REQUEST (or INFORM for that matter)?

---

From: Andre Kostur <[email-masked]>
Date: Thu, 09 Mar 2006 17:14:14 -0800

James M. Polk wrote:
> Andre
>
> I do not foresee this being the normal case, as the limit to any URI 
> is 253 bytes.  But if there are enough URIs requested from the client, 
> then there could be more than one IP packet necessary to get them all 
> to the client - unless the wording is changed in the doc.

The problem here is that there is a 1 to 1 relationship between a 
REQUEST and an ACK.  You don't get multiple responses.  (and see below 
about "IP packets"). 

> certain type of URI, but it can know if there is a limit to the 
> aggregate of all URIs requested.
>
> Should a new rule state there can be no more than 5 URIs (totaling 
> 1265 bytes) requested in any one server request message to ensure they 
> fit into a single IP packet?  I have no issues with such a rule.

 From a protocol standpoint, why do we care whether it fits within a 
single IP packet or net?  We should only care about whether it fits 
within a single UDP message of a maximum size negotiated with the client 
(via option 57), with a default maximum size (in the absence of 
negotiation) of 576.  If the UDP message's size is larger than the size 
of the IP packet, then it's the IP stack's responsibility to perform the 
necessary reassembly before handing the UDP message up to the client.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 09 Mar 2006 19:41:53 -0600

At 05:14 PM 3/9/2006 -0800, Andre Kostur wrote:
>James M. Polk wrote:
>>Andre
>>
>>I do not foresee this being the normal case, as the limit to any URI is 
>>253 bytes.  But if there are enough URIs requested from the client, then 
>>there could be more than one IP packet necessary to get them all to the 
>>client - unless the wording is changed in the doc.
>
>The problem here is that there is a 1 to 1 relationship between a REQUEST 
>and an ACK.  You don't get multiple responses.  (and see below about "IP 
>packets").

Maybe I'm in dense mode, which wouldn't surprise me here, but I'm agreeing 
with your comment about a 1-to-1 relationship between request (REQUEST) and 
response (ACK) messages, and I'm offering to put in whatever language you 
see fit to accomodate that.  Given that a client cannot know how large a 
URI is that it requests of a server, it cannot ask for 10 and always expect 
10 to show up in the ACK, it has to make certain assumptions or be limited 
in what it can request by this document.

I can easily add to the rules section a rule stating the client cannot 
request there be more than 2 URIs of a server (253x2=506 bytes) without 
prior negotiation of default size of 576.  I can easily add a follow on 
rule stating that even if there is prior negotiation beyond 576 bytes, the 
maximum number of URIs requests is the whole number (integer) multiple of 
253 that fits under that negotiated value (A x 253 < max size negotiated 
within a single UDP packet).

Am I still missing what you want?

BTW - I would add text about option 57 (with a reference) if the above is 
generally acceptable.

>>bytes) requested in any one server request message to ensure they fit 
>>into a single IP packet?  I have no issues with such a rule.
>

---

From: Andre Kostur <[email-masked]>
Date: Thu, 09 Mar 2006 18:05:09 -0800

James M. Polk wrote:
>>> is 253 bytes.  But if there are enough URIs requested from the 
>>> client, then there could be more than one IP packet necessary to get 
>>> them all to the client - unless the wording is changed in the doc.
>>
>> REQUEST and an ACK.  You don't get multiple responses.  (and see 
>> below about "IP packets").
>
> Maybe I'm in dense mode, which wouldn't surprise me here, but I'm 
> agreeing with your comment about a 1-to-1 relationship between request 
> (REQUEST) and response (ACK) messages, and I'm offering to put in 
> whatever language you see fit to accomodate that.  Given that a client 
> cannot know how large a URI is that it requests of a server, it cannot 
> ask for 10 and always expect 10 to show up in the ACK, it has to make 
> certain assumptions or be limited in what it can request by this 
> document.

OK, so we're agreeing about 1-to-1 associations.  I don't think there 
needs to be additional language to state that since that's just the way 
DHCP works.  What I'm pointing out is that the draft seems to talk about 
the server sending back multiple packets in response to a client 
request, and that's a no-no.

> request there be more than 2 URIs of a server (253x2=506 bytes) 
> without prior negotiation of default size of 576.  I can easily add a 
> follow on rule stating that even if there is prior negotiation beyond 
> 576 bytes, the maximum number of URIs requests is the whole number 
> (integer) multiple of 253 that fits under that negotiated value (A x 
> 253 < max size negotiated within a single UDP packet).

I think this would be uneccessarily restrictive.  What if all of the 
requested URI's are really short?  Also, what if the server decides to 
overload the sname and file fields to fit more option data (that's 
another 192 bytes....).   Offhand, your clients will simply have to deal 
with the possibility that it may not get an answer for everything it 
asks for.  Same as for every other option in DHCP.  (Oh... and keep in 
mind that the 576 bytes also includes the 236 bytes of header, and the 4 
byte magic number, and the 3 bytes to hold the message type, and 6 bytes 
to hold the lease time..... so that's 249 bytes gone before you can put 
any options in there.  So under this scheme, a device could only ask for 
1 URI before running out of space.  You could fit 2 if the server 
overloads the sname and file fields, with certain other 
restrictions.).   As far as I know, the only way the client can register 
its displeasure with the received option data is to either not REQUEST 
what it has been OFFERed, or RELEASE the current lease and go back to 
DISCOVER (OK, within the DHCP protocol.  There could be other mechanisms 
outside the DHCP protocol such as sending messages to a syslog server, 
or something.)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Mar 2006 20:11:58 -0700

James, it's just not appropriate to try to cram that much data into a DHCP 
packet.   If you need to do something like this, you need to use a protocol 
other than DHCP to do it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Mar 2006 20:14:29 -0700

> Am I still missing what you want?

The kind of complexity you're describing is just inappropriate for a DHCP 
client/server interaction.   Why do you want to be able to pass so many URIs?   
Do you have running code, or is this a completely hypothetical process?

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 09 Mar 2006 23:31:46 -0600

At 08:14 PM 3/9/2006 -0700, Ted Lemon wrote:
>client/server interaction.

My writing style is to surround a thing, to try and account for a lot/most 
angles of (mis)use and that's obviously gotten me in trouble within this WG 
with this effort.

Would this Option be more appropriate if there were only the PSAP URI 
identified?

>Why do you want to be able to pass so many URIs?

it's not that I want that many URIs in the same message, it's that some 
installations will want #s 1 and 4 and 8 - but only when needed, and others 
will want #s 5, 6, and 9 - but only when needed.  I originally had a much 
shorter list of identified URIs, but some folks caught wind of what I was 
writing and asked that I add 1 here, 2 there, and it added up to 11 before 
the first version was release last August.

>Do you have running code, or is this a completely hypothetical process?

I do not have running code at this time

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 10 Mar 2006 00:02:40 -0600

Ted

Please look at

and review the message flows.  See the situation and suggest another means 
of doing this.

BTW - the SIP proposal is getting slammed too because SIP already does too 
much, and that's 2 of the 3 ideas meeting "resistance", with HTTP the lone 
alternative remaining, and I don't know how a client is going to learn the 
URL of a HTTP Server to provide it the appropriate PSAP-URI other than this 
idea...  ;-)

There seems to be a circular elimination going on, through no one's fault btw

---

From: Andre Kostur <[email-masked]>
Date: Thu, 09 Mar 2006 22:18:54 -0800

James M. Polk wrote:
> and review the message flows.  See the situation and suggest another 
> means of doing this.
>
> BTW - the SIP proposal is getting slammed too because SIP already does 
> too much, and that's 2 of the 3 ideas meeting "resistance", with HTTP 
> the lone alternative remaining, and I don't know how a client is going 
> to learn the URL of a HTTP Server to provide it the appropriate 
> PSAP-URI other than this idea...  ;-)
One URI doesn't seem too bad.  But you've got 11 of them so far.  Why 
not have the DHCP server tell the client where to find a more complete 
configuration file to round out the rest of its configuration?  It's 
basically what cable modems and PacketCable MTAs already do.  In the CM 
case, it's simply told that it can find its configuration file at a 
certain IP, and to request a file of a certain name.  Then the CM goes 
off and downloads that file which contains a whole lot more 
configuration data.  (See options 66 and 67)

Same idea on the PacketCable front, although in that case it 
encapsulates a bunch of ways to get the extra configuration.  One way is 
the same as CMs (options 66 and 67), another way is that the MTA 
contacts a provisioning server (See RFC 3495, option 122, suboption 3), 
and then a different protocol takes over for the rest of the 
configuration (in this case the provisioning server performs some SNMP 
SETs on the MTA to tell it where to download its bootfile from).

---

From: Mark Stapp <[email-masked]>
Date: Fri, 10 Mar 2006 09:25:50 -0500

James,
but that's exactly the suggestion that's been made, repeatedly: a dhcp 
option that tells the device _one_ uri. the device would get a nice file 
back from that uri via http, and that file would contain the data that's 
needed, including uris for the providers of other data.

that decouples the variety of configuration data that different devices 
or different networks may need from the dhcp configuration. that largely 
eliminates the dhcp payload size problem. and that gives the ecrit folks 
their own file to define, extend, and generate as they see fit.

-- Mark

James M. Polk wrote:
> to learn the URL of a HTTP Server to provide it the appropriate PSAP-URI 
> other than this idea...  ;-)
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Mar 2006 09:33:34 -0500

> unless the wording is changed in the doc.

We are no longer talking about DHC here. This is some other (weird)
protocol.

DHC responses are contained in a single (UDP/DHCP) response.  Period.

Another basic question: This option has a "URI purpose" field, that
describes the type of URI. Again, this doesn't fit with the DHC model
at all. How does a client request three separate URIs? Does it include
three of these options, each with a different "URI purpose" field?
Again, my understanding is that this is not supported by the current
widely-deployed DHC architecture. So entire idea seems suspect to me.

That is, in DHC, if you want different things, you put each in its own
option. You don't create a single option with "sub types", allowing
you to request things with sub-type granularity. Do other DHC experts
want to comment on this?

And finally, who is the "customer" of this work/option? That is, who
needs it? Which IETF WG is a needs this option?

Thomas

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 10 Mar 2006 10:07:32 -0500

in-line.... 

> 
> James,
> but that's exactly the suggestion that's been made, 
> repeatedly: a dhcp option that tells the device _one_ uri. 
> the device would get a nice file back from that uri via http, 
> and that file would contain the data that's needed, including 
> uris for the providers of other data.
> 
> that decouples the variety of configuration data that 
> different devices or different networks may need from the 
> dhcp configuration. that largely eliminates the dhcp payload 
> size problem. and that gives the ecrit folks their own file 
> to define, extend, and generate as they see fit.

The referred to "ecrit folks" have NOT asked for this option.  There has
been on-going discussion within ecrit around the possibility of performing
emergency call routing prior to the time of an actual emergency call.  This
has been referred to as "fall-back mapping" (mapping = using location
information to look up PSAP uri).  The use of the "fall-back mapping"
happens when real-time mapping fails during the setup of an emergency call.
Ecrit's current work is centered on defining the protocol (currently
identified as LoST) that provides this mapping function.  Architectural best
practices of when to invoke LoST is possible future work for ecrit.

{ecrit co-chair hat off}

IMO, using DHCP to perform the "fall-back mapping" is an operational
disaster.  I also share the same opinion with DHCP providing emergency dial
strings.  I'll leave the technical comments to those that understand DHC
better than I.

-Marc-

> >> James, it's just not appropriate to try to cram that much 
> data into a 
> >> DHCP

---

From: Stig Venaas <[email-masked]>
Date: Sun, 12 Mar 2006 16:44:47 +0000

> widely-deployed DHC architecture. So entire idea seems suspect to me.

Yes, this is one of my issues. If each URI was one option, there would
be a standard way for requesting a specific URI (option). There is no
way to request specific sub-options (the URI purpose field could be a
sub-option) without adding extra code to DHC servers.

> you to request things with sub-type granularity. Do other DHC experts

Right, this is my view as well.

Speaking only for myself,

Stig

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Mar 2006 09:52:38 -0800

> sub-option) without adding extra code to DHC servers.

I think it is not unreasonable to define the option space with such a
code.

For the time being, ISC DHCP servers presently deployed will give any
and all sub-options they are configured with at the time the space is
collapsed into a single DHCP option.

You rely then on a future release to adopt sub-option-space granularity
via client-supplied options within those spaces.

I would think it would be pretty easy to reuse our existing option 55
code.  Not impossible, anyway.  The hard part is the user interface
features (presenting an option as the requested-sub-optoins option
for a given unique space), but these are not insurmountable either.

Presuming you solve the option priority problem the simple way (and
make sub-option spaces all-or-nothing, as they are today).  Heck,
it wouldn't even be that hard, since the resulting option data contents
are uniform among all sub-option-spaces, to trim the fat off the end
of options that won't fit in the packet they're presentingly being
stored in.

The question I think is wether or not we are comfortable with there
being slightly different adoption policies before and after such
features are available in servers.

I'm normally against protocol drafts that require new deployed code
(as you will recall with queries about VIVSO), but in this case, I
think the current adoption method is reasonable, and is a space where
we can develop protocol that is later enhanced by server features (if
and when they develop).

At any rate, I think client-requested-sub-options is worth coding,
even if we have to have the feature deployed before any protocol
draft will use it.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Mar 2006 10:21:31 -0800

> necessary reassembly before handing the UDP message up to the client.

Some (ISC) DHCP Client (and server and relay) implementations have to
use...creative...means to acquire the type of network access that is
necessary to acheive RFC2131 compliance (most frequently in specific
relation to broadcast or unicast addressing both receiving and sending
packets).

Specifically, BPF (or variants similar to it) is used to construct
packets while the client is not BOUND to an address yet, or when the
server or relay have to craft these specifically-worded rfc2131
broadcast addressed packets.  The same socket is used to receive replies
from the remote system (be that client, server, or relay).  A second,
this time normal berkeley socket, bound to the appropriate port is used
to transmit unicast packets where that's necessary (eg a server
responding to a relay, a relay querying a server, or a BOUND client
renewing).  Packets received on this "fallback socket" are discarded,
as they are replicas of packets received on the BPF socket(s).  This
socket is necessary specifically to transmit packets that have to be
routed (or else we have to implement ARP, and route table lookups
within the DHCP client to transmit unicast packets to the correct
router via BPF).

The implementation has to do a lot of work it otherwise wouldn't have
to.  Packet header checksums.  Ethernet framing.  All this extra effort
is expended to support RFC2131 broadcast addresses.

But no one thought to include IP fragmentation support in any of that.
Instead of even attempting to decode fragments, our BPF filter throws
them out.

So we have an installed base for which 'maximum IP packet size' is not
and likely never will be a sufficient metric for the maximum size of a
DHCP datagram post-negotiations.

Realistically, on an ethernet interface, with the ISC DHCP software
suite, you will not acheive greater than 1500 byte DHCP packets measured
from the start of IP framing to the DHCP END option.  Server, client, or
even relay.

But to actually use this for these clients and servers you have to
completely accept that there are no intervening agents between the
two that might have a lower MTU.

Which makes option 57, from a completeness standpoint, presently
unusable, and we're stuck with 576 byte DHCP packets hoping that
overloading FILE and SNAME is enough.

In summary, at least in our installed base, there never is any
negotiation above 576, because to do that by default simply wouldn't
be sane or safe.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 14 Mar 2006 17:11:34 +0100

> Instead of even attempting to decode fragments, our BPF filter throws

Right, having written some other software using BPF to send and receive 
non-fragmented packets, I understand your concerns.

If you only use BPF for sending/receiving broadcasts, then I think you 
would be okay as long as the size of the IP packet containing the DHCP 
message is <= MTU of client's link.

If this is the case, then client could set option 57 based on its MTU. 
If client doesn't know its MTU, then hopefully the server does (how else 
to configure client with the right MTU?).

Stig

> ------------------------------------------------------------------------
>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Mar 2006 08:11:35 -0800

> >>necessary reassembly before handing the UDP message up to the client.

[snip]

> to configure client with the right MTU?).

Right, but let us condense the opinion I understood from Andre's
statement above:

*) It is reasonable to create new DHCP protocol work today that assumes
   all clients, servers, and relays, in every network where this
   technology will be used, will be able to process 65535-byte IP
   datagrams from fragment reassembly, and will be able to communicate
   that using option 57.

I believe this, possibly only perceived, opinion of Andre's to be
false.

That was what I was really trying to speak to.

If anyone objects I can expand on that, but I think I already have.

We can say more about option 57 but this is probably off-topic for this
draft.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 15 Mar 2006 09:06:58 -0800

> I believe this, possibly only perceived, opinion of Andre's to be

I guess that's my cue...

What I was trying to point out is that the draft talks about a server 
sending multiple "messages" back to the client.  I perceived it to be 
unclear as to whether the draft was talking about multiple IP packets, 
or multiple UDP messages (or multiple DHCP packets).  This was then 
clarified that the draft was intended to mean "... there could be more 
than one IP packet necessary ...".  I then said that I don't think the 
draft should be talking about multiple IP packets, since that would 
(should?) be the responsibility of the underlying IP stack to deal with 
potential message reassembly, should it be required.  Noting that in the 
absence of other information, the server can only assume that the client 
can receive a 576 byte UDP message (and thus cannot assume that clients 
will be able to reassemble multi-packet UDP messages).  However, should 
a client tell the server (via option 57) that it is willing to receive a 
10000 byte DHCP message, presumably the client is well aware that the 
resulting DHCP messages may require reassembly.

Although you do raise an interesting point.  Assuming the draft stays 
with the "more than one IP packet" idea, what's a relay in the middle 
going to do with these multiple IP packets?  Will it necessarily be able 
to forward them correctly to the client; or will the relay know to wait 
for the remaining fragements, reassemble them, and forward the full 
message on to the client (which may require re-fragmenting...)?

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Mar 2006 19:42:11 +0000

> resulting DHCP messages may require reassembly.

The substance of my reply is that won't work if any DHCP element is
derived from our software environment (if our client advertised that
number, it would be broken, our server will limit that value down to a
much lower number (1500 is hard-coded in, I think without looking), and
our relay will have no way to play nicely).

> message on to the client (which may require re-fragmenting...)?

_Any_ IP fragmentation that wants to be delivered to our client, relay,
or server, built with and using these 'BPF' style of network handling
(which is the default since other methods are incompliant with
reference) will be discarded.

Hence, won't work.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Mar 2006 14:44:57 -0700

To be clear, there is really no expectation at all in the DHCP standard that 
clients and relay agents will support fragmentation, and there's a lot of 
reason to assume that they don't, starting with the 576-byte default limit.   
My personal feeling here is that any DHCPv4 extension that requires 
fragmentation in order to be practical is probably a non-starter, mostly 
because I believe that a lot of relay agents will simply drop all fragments 
but the first or, if they don't drop them, will corrupt them.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Mar 2006 22:08:12 +0000

It may already be obvious, but I completely and totally concurr.