Subject: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt

From: Ralph Droms <[email-masked]>
Date: Sun, 12 Oct 2003 11:17:00 -0400

This message announces a WG last call on "DHCP Option for Mobile IP Mobility
Agents" <draft-ietf-dhc-mipadvert-opt-01.txt>.  The last call will conclude
at 5PM ET on Friday, 10/24/2003.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the
Mobility Agent Option, and two sub-options of the Mobility Agent Option: the
Network Access Identifier Sub-Option, which provides
identifying information about a DHCP client to the DHCP server and the
Mobility Agent Announcement sub-option, which announces the address of one
or more mobility agents available to a host. This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt

- Ralph Droms

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

---

From: "Rob Stevens" <[email-masked]>
Date: Wed, 15 Oct 2003 15:45:00 -0700

I think it's fair to say that the question of which options to return
to a client remains an area of confusion in the protocol. The language
of 2131 is convoluted. And I don't believe there is a clear consensus
on the question of whether servers should only return what clients ask
for, or whether they should return everything they know. The latter is
potentially a problem due to packet overflow; a problem that is likely
to become worse as vendors define their own options.

Is there any interest in the idea of using another bit in the "flags"
field that servers can use to tell clients that there was more data
than could fit in the packet?

Another idea is to use option 55 (parameter request option) in
messages from servers to clients which could contain a list of all
options which could not be included due to space considerations.

Rob Stevens

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 15 Oct 2003 16:58:25 -0700

Rob,

glad you introduced this topic.

Given that a server sends a flag meaning "I have more options for you than
would fit in the DHCPACK packet," how would a client receive the remaining
data?

Possibilities include:

(1) Server uses the "parameter request list" option to specify which options
ARE included in the DHCPACK packet -- the client would use a DHCPINFORM
message to request any from its (the client's) original parameter list that
weren't included by the server.

(2) Server uses the "parameter request list" option to specify which options
ARE NOT included in the DHCPACK packet -- the client would use a DHCPINFORM
message to request any of interest.

(3) Server does not indicate which options have or have not been returned
(using the "parameter request list" option), leaving the determination of
which additional options to request in a DHCPINFORM message entirely to the
client, comparing the options requested to the options returned in the
DHCPACK message.

(4) Server uses some server-specific mechanism to determine which options to
return if they all do NOT fit in the DHCPACK message.  Subsequent DHCPINFORM
request messages are answered with any remaining options from the
DHCPREQUEST message, plus those requested in the DHCPINFORM message, until
the packet is filled.  This process could be repeated several times before
all [default or requested] options are given to the client.

Alternative (4) opens up a whole new discussion topic:  what options SHOULD
be returned.

--Barr

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Rob
> Stevens
> Sent: Wednesday, October 15, 2003 15:45
> To: [email-masked]
> Subject: [dhcwg] Bit in "flags" field indicating option overflow?
>
>

---

From: Simon Vogl <[email-masked]>
Date: Thu, 16 Oct 2003 07:45:04 +0200

Just as a suggestion (which would also suit my needs of getting asynchronous
information to the client), would it help to set a sort of 'more to come'
option, indicating that more options will follow in a consecutive DHCPACK?
This second (or nth) DHCPACK would have a 'additional information' option
set as first option, indicating that only the options are of interest, not
the ip settings.

So long,
Simon

-- 
------------------------------------------------
Dr. Simon Vogl
Department  of   Computer  Science
Johannes Kepler University of Linz
Altenberger Straße 69
A-4040 Linz - Austria

Tel: +43 70 2468 8517  [email-masked]
Fax: +43 70 2468 8426   www.soft.uni-linz.ac.at

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Oct 2003 09:09:28 -0400

Another potential solution would be for the client to increase its maximum 
DHCP message size to accommodate all of the options.

- Ralph

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 16 Oct 2003 11:52:01 -0700

Ralph--

of course this works, but I inferred from Rob's original note that either
(a) the client had not indicated it could accept a buffer large enough to
accommodate all of the options to be returned, or (b) that the client had
specified a larger packet size, but for some reason the server wasn't able
to accommodate that and had "fallen back" to a default value which was too
small.

Your point raises other issues as well:

1.  should the server respond at all if it can't fit the requested options
in the [specified or default] packet size?

2.  should the server try to fill the packet in any particular order?  For
example, the order of entries in the "parameter request list" if it appears,
the order [implied by] RFC 1122, server implementation default choice, or
order implied by RFC 2131 itself?

"Isn't this a fine kettle of fish?" -- Oliver Hardy

--Barr

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ralph Droms
> Sent: Thursday, October 16, 2003 06:09
>

---

From: "Rob Stevens" <[email-masked]>
Date: Thu, 16 Oct 2003 20:53:04 -0700

We should be careful not to imply that all the client has to do is
merely to suggest to the server a larger packet size, even if the
client could accept something almost arbitrarily large (up to the UDP
limit). 

Many arguments have been made to the effect that IP fragmentation is
not allowed on BOOTP/DHCP packets. Many (most?) implementations of
both clients and servers are using link level interfaces which follow
this dictum and will only accept an unfragmented packet. Quite
possibly routers implementing relay agents are doing the same.

Clients quite probably don't know the largest packet size that would
avoid fragmentation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barr Hibbs
Sent: Thursday, October 16, 2003 11:52 AM
To: [email-masked]
Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow?

Ralph--

of course this works, but I inferred from Rob's original note that
either
(a) the client had not indicated it could accept a buffer large enough
to accommodate all of the options to be returned, or (b) that the
client had specified a larger packet size, but for some reason the
server wasn't able to accommodate that and had "fallen back" to a
default value which was too small.

1.  should the server respond at all if it can't fit the requested
options in the [specified or default] packet size?

2.  should the server try to fill the packet in any particular order?
For example, the order of entries in the "parameter request list" if
it appears, the order [implied by] RFC 1122, server implementation
default choice, or order implied by RFC 2131 itself?

--Barr

> Another potential solution would be for the client to increase its 
> maximum DHCP message size to accommodate all of the options.
>
> - Ralph
>
>

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 16 Oct 2003 14:44:48 -0700

Good point, Rob,

so how do we determine the largest packet that will pass without
fragmentation?

That's really a rhetorical question, possibly one without a definitive
answer.

The practical issue you raise is that even if the client supplies a maximum
packet size, the server might format a response packet and STILL not be able
to get it to the client.

--Barr

> Sent: Thursday, October 16, 2003 20:53
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2003 21:54:06 -0700

In general, clients really should send max-message-size options every 
time.   It is unfortunate that they don't.   I think that if RFC2131 
were updated, it would be worthwhile to *require* (SHOULD) that the 
client send this option, and that they send a message size that is the 
MTU of the network interface being configured.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2003 21:58:07 -0700

Reassembling fragments really isn't very hard.   If a client knows it 
can't reassemble, it should specify the lowest legal value for MTU, but 
I think this is a very rare case.   These clients are likely the ones 
that need the fewest options.

And in answer to Rob's earlier question, except in cases where the 
parameter request list is stupid (i.e., doesn't request subnet mask), I 
think the DHCP server should honor it and not send options not listed 
in it.   This is how I read RFC2131 to begin with, although I know 
others have read it differently.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Oct 2003 07:25:49 -0400

Any reason not to allow a message size > MTU (with a strong admonition not 
to do so unless really, really necessary)?

- Ralph

At 09:54 PM 10/16/2003 -0700, Ted Lemon wrote:
>time.   It is unfortunate that they don't.   I think that if RFC2131 were 
>updated, it would be worthwhile to *require* (SHOULD) that the client send 
>this option, and that they send a message size that is the MTU of the 
>network interface being configured.
></blockquote></x-html>

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 17 Oct 2003 09:07:55 -0400

Personally, I think that if no max-message-size option is sent, the default
maximum message size should be used (512 if I recall).

I believe Rob Stevens mentioned that some routers (relays) may not support
reassembly - though I personally find that hard to believe today. Though I
can more easily believe the relay function may limit the packet size it is
capable of supporting.

So we really have three parties involved:
1. What can the client support?
2. What can the server support?
3. What can the relay support?

The current max-message-size option addresses the first two. There is
nothing that addresses the third issue and a client/server may fail to
communicate if the relay doesn't support the larger messages. Perhaps we
need a "relay-max-message-size" option that can override a client's
max-message-size option if the relay isn't able to support the client's
maximum?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph
Droms
Sent: Friday, October 17, 2003 7:26 AM
To: [email-masked]
Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow?

- Ralph

---

From: "Rob Stevens" <[email-masked]>
Date: Fri, 17 Oct 2003 15:45:54 -0700

No, reassembling fragments isn't at all hard. But it would require
quite a few implementations to be modified (or so I believe).
 
As far as the options go, I agree with Ted. We used to do similarly.
This whole question though is one where the language of 2131 is at its
most contorted. I can see arguments on both sides (i.e. for only
sending what a client requested, or for sending everything the server
knows). Barr and I  will try, in our draft, to focus the minds of the
WG on that issue (among others).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
Sent: Thursday, October 16, 2003 9:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow?

Reassembling fragments really isn't very hard. If a client knows it
can't reassemble, it should specify the lowest legal value for MTU,
but I think this is a very rare case. These clients are likely the
ones that need the fewest options.

And in answer to Rob's earlier question, except in cases where the
parameter request list is stupid (i.e., doesn't request subnet mask),
I think the DHCP server should honor it and not send options not
listed in it. This is how I read RFC2131 to begin with, although I
know others have read it differently.

The practical issue you raise is that even if the client supplies a
maximum
packet size, the server might format a response packet and STILL not
be able
to get it to the client.

---

From: [email-masked]
Date: Fri, 17 Oct 2003 19:19:19 +0200

> max-message-size option if the relay isn't able to support the client's

Why have a special option for case 3 ? The relay may check if the client's
max-message-size option is there and modify it in transit if the value
is too high for the relay to handle. This option is usually not stored
in the server, so the server will use the 'real' client max-message-size
value in ACKs sent directly to the client and the modified one when responding
through the relay.

	-Patrick

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 17 Oct 2003 13:47:48 -0400

What we went for with DHCPv6 (if I recall correctly) was that the server
MUST send those options that it supports from the parameter list and MAY
send other options (if they fit into the packet, etc.). The only tough case
you have is what happens if the parameter list options don't fit into the
packet - which to drop or how to tell the client to use a larger packet
(though I would think that if the client supported larger packets, it should
have just sent an appropriate max-message size).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob
Stevens
Sent: Friday, October 17, 2003 6:46 PM
To: 'Ted Lemon'; [email-masked]
Cc: [email-masked]
Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow?

No, reassembling fragments isn't at all hard. But it would require quite a
few implementations to be modified (or so I believe).

As far as the options go, I agree with Ted. We used to do similarly. This
whole question though is one where the language of 2131 is at its most
contorted. I can see arguments on both sides (i.e. for only sending what a
client requested, or for sending everything the server knows). Barr and I
will try, in our draft, to focus the minds of the WG on that issue (among
others).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Thursday, October 16, 2003 9:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow?

Reassembling fragments really isn't very hard. If a client knows it can't
reassemble, it should specify the lowest legal value for MTU, but I think
this is a very rare case. These clients are likely the ones that need the
fewest options.

And in answer to Rob's earlier question, except in cases where the parameter
request list is stupid (i.e., doesn't request subnet mask), I think the DHCP
server should honor it and not send options not listed in it. This is how I
read RFC2131 to begin with, although I know others have read it differently.

---

From: "Rob Stevens" <[email-masked]>
Date: Fri, 17 Oct 2003 19:04:50 -0700

This question about packet fragmentation goes back a long way.
I think more than 6 years; Mike Carney (and it may have been made way
before that by unknown others) made the point that routers are not
able to simply forward the second and subsequent fragments of
BOOTP/DHCP packets because those fragments don't have the destination
address (yiaddr, chaddr, ciaddr whatever..) - those were in the first
fragment only.

Thus routers are not simply doing IP forwarding.

But... we knew this already because BOOTP/DHCP relay agents are the
destination IP for packets coming back from servers. So IP forwarding
was never an issue. It is more like proxying. The relay agent itself
is the destination for the IP unicast, so why wouldn't it do assembly?

So the question is did routers, for reasons of incremental
improvements in efficiency, not bother to re-assemble datagrams to
port 67, and was that why this whole issue about not permitting
fragmentation got started. And regardless of what as done in ancient
history, what are people doing today?

Possibly the concern was the fragmentation of broadcast datagrams from
the client. They all have the source IP address of 0.0.0.0. So I
suppose there is some (minimal) chance of collisions involving the IP
datagram identification. But since clients never need to send large
packets this also seems moot.

Not being in the mainstream just now, I haven't the remotest idea
which vendors are doing what. I wish we had a forum where we could get
specific, timely answers from vendors (whatever they manufacture).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Volz
Sent: Friday, October 17, 2003 6:08 AM
To: 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow?

Personally, I think that if no max-message-size option is sent, the
default maximum message size should be used (512 if I recall).

I believe Rob Stevens mentioned that some routers (relays) may not
support reassembly - though I personally find that hard to believe
today. Though I can more easily believe the relay function may limit
the packet size it is capable of supporting.

The current max-message-size option addresses the first two. There is
nothing that addresses the third issue and a client/server may fail to
communicate if the relay doesn't support the larger messages. Perhaps
we need a "relay-max-message-size" option that can override a client's
max-message-size option if the relay isn't able to support the
client's maximum?

- Bernie

-----Original Message-----

Any reason not to allow a message size > MTU (with a strong admonition
not 
to do so unless really, really necessary)?

- Ralph

>time.   It is unfortunate that they don't.   I think that if RFC2131
were 
>updated, it would be worthwhile to *require* (SHOULD) that the client

>send

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2003 20:58:56 -0700

On Friday, October 17, 2003, at 06:07  AM, Bernie Volz wrote:
> we

Good point.  Unfortunately, relay agents that support this option would 
be new relay agents, which could probably also support packet 
reassembly.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2003 21:06:03 -0700

> specific, timely answers from vendors (whatever they manufacture).

I seem to recall that Cisco had a weird way of doing relay that looked 
like a layering violation, but I don't know if it actually was a 
layering violation or just looked like it might be one.   
Unfortunately, I think it is likely that many relay agents have a 
layering violation in this case.

And yes, we all wish there was such a forum.  And if wishes were 
horses, there'd be a lot of pollution in the streets... :'}

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Oct 2003 13:33:42 -0400

(written with WG chair hat on, not my employer's hat)

It is inappropriate to make unsubstantiated claims about the behavior, 
capabilities or operational inadequacies of specific vendors' products - 
such as implying that Cisco's relay agent was guilty of a layering 
violation - on an IETF mailing list.  List contributors should refrain from 
making such statements...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Oct 2003 14:02:39 -0400

A couple of parts of this conversation aren't making any sense to me;
comments in line:

>address (yiaddr, chaddr, ciaddr whatever..) - those were in the first

I don't remember ever hearing any discussion of this issue.  That's not to
say it didn't take place ... it's quite likely I just don't remember.  But,
as Rob points out, unless the router is trying to gain some small
incremental performance advantage (or perhaps implementation simplicity?) by
simply forwarding DHCP messages without sending them up through the stack to
a forwarding daemon, a fragmented message from a client will be reassembled
in the router stack, transparent to the relay agent.

I do seem to remember that there was some concern that the relay agent might
not have an internal buffer large enough to hold a fragmented datagram.  I
also remember that, as we worked on RFC 1541, we anticipated minimal DHCP
client implementations that might have a small internal message buffer.

>history, what are people doing today?

In fact, I don't think there is an issue about not permitting fragmentation,
per se, in DHCPv4.  Fragmentation is not mentioned anywhere in RFC 2131.  I
don't remember, in our work on DHCPv4 prior to the publication of RFC 1541,
that fragmentation was ever an issue (except in the generic "fragmentation
is a bad idea" sense).

We did need to take some care in backward compatibility with BOOTP relay
agents.  We also explicitly decided against building a protocol in which a
message might be carried in multiple UDP datagrams, not wanting to go down
the sequencing-retransmission-congestion "reinvent TCP" rathole
(anticipating the current IESG position on UDP by several years).

Perhaps this avoidance of sequential UDP messages is what Mike was referring
to?

---

From: "Barr Hibbs" <[email-masked]>
Date: Sat, 25 Oct 2003 15:14:19 -0700

Again, sorry to be so late in responding.

I support the advancement of this draft with what I summarize as
"suboptions SHOULD NOT have a zero length, unless there is a 
semantically appropriate reason to do so," and noting the following
nit:

(page 4, section 3.1, last paragraph of the section) contains the 
sentence, "The Mobility Agent Information field shall NOT be terminated 
with a 255 sub-option."  This should be changed to be "SHOULD NOT,"
"MUST NOT," or "MAY NOT" to conform with standard terminology.

--Barr