Templin, Fred L wrote: ... >> >> On Dec 5, 2007, at 3:54 PM, Templin, Fred L wrote: ... >> 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.
All IP packets have a source address; there is no reason why any given address would fail on frag/reassy (including 0's or 1's). > 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. At that point you're seeking to traverse a non-Internet device; all bets are off, and there's frankly no point in trying to provide DHCP to the device behind it. > There are also wrapping problems with the 16-bit > ip_id, which are documented in RFC4963. The problem lies in the host or tunnel endpoint that wraps those IDs, in violation of RFC791. The RFC4963 is incorrect in suggesting that the error lies anywhere else; thankfully, it's only (mis)informational in that regard. If the IP ID wrap is really going to be deprecated, let's do so. If not, can we please stop calling wrap of the ID anything other than a violation of a standard? Joe > > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
