RE: [dhcwg] Message fragmentation in DHCPv6

Vijay:

Fragmentation is always possible - it just should be avoided. In most cases this
really only applies to boot proms that may have a limited IP implementation and
therefore not have sufficient resources for handling reassembly?

The MTU size is really dependent on the link and therefore isn't required to be
specified (recall that Path MTU Discovery is required in IPv6).

But, the general IPv6 MTU (of if I recall 1280 octets) is probably a reasonable
default and gives us much more space than is in general available in DHCPv4.

Anyway, the point is that if a large message must be sent, send it. However, if
that large message results because unrequested options might be added, don't bother
adding those options.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Saturday, June 15, 2002 9:46 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Message fragmentation in DHCPv6

"The server SHOULD limit the options returned to the client so that the DHCP
message header and options do not cause fragmentation."

Do we need to define some maximum DHCP message size here?

"The client has to include ALL the IAs in the reply to Reconfigure message."

Then, for this case, what should the client do, in the case if it finds that
there
will be fragmentation. The situation is worse, in the case, client is able
to send all the IAs, but the server is not able to reply with ALL IAs.
How will the server send the remaining options/IAs to the client?

~Vijay

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg