Ted, > -----Original Message----- > From: Ted Lemon [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 05, 2007 4:13 PM > To: Templin, Fred L > Cc: [EMAIL PROTECTED] > Subject: Re: [Int-area] EAP and DHCP end-points > > On Dec 5, 2007, at 3:54 PM, Templin, Fred L wrote: > > The domain of applicability for this would be for any DHCP > > usage and not just the DHCP-AUTH stuff. But, I would also > > like to use it as a template for future documents that add > > similar support for other UDP applications. Any comments > > on it would be welcome. > > The fact that you say it this way actually illustrates the main > problem with it. There's already a way to do fragmentation of UDP > packets. It's done at the IP layer, so there's no need to > do it on a per-UDP-protocol basis.
IP fragmentation and reassembly doesn't work very well when there is no IP source address, which is the case the DHCP-AUTH stuff was looking at. It also doesn't work very well for UDP applications that sit behind IPv4 NATs and/or firewalls; especially when those devices fail to pass non-initial IPv4 fragments. There are also wrapping problems with the 16-bit ip_id, which are documented in RFC4963. But all that said, I'm not saying go out and change all UDP applications everywhere - only those for which IP fragmentation may be problematic. > A relay agent that doesn't handle a full 1500-byte DHCP packet is > broken - DHCP has been specified to allow this for a really long time > now. My comment in the WG is simply that nobody really ever uses > this, so we can't be sure that it works on every device. But it > should. So I would much rather get it working than come up with a > workaround. Hmm; several folks told me that relay agents only need to support 576? In any event, I'm all for paths that support the larger packet sizes w/o fragmentation - greatly in favor of it, in fact. But when the path doesn't support the packet size, and the application can't reduce the size of the packet, then it has to do what needs to be done to get the packet through. > E.g. you could come up with a hack to TCP to make it work for routers > that can't handle packets larger than 576 bytes, despite the fact that > the physical layers between which they are routing support 1500-byte > packets. But you wouldn't do that. You'd send back the router, and > demand a refund. Nodes are supposed to accept at least as large as the size of their attached links, so you are indeed describing a case of broken router. But, when there are links with small MTUs on the path, TCP has a way of reducing the size of the segments it sends when it correctly implements RFC1191. Fred [EMAIL PROTECTED] _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
