Joe - just a couple of clarifications, and an attempt to wrap this thread up:
> -----Original Message----- > From: Joe Touch [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 05, 2007 7:12 PM > To: Templin, Fred L > Cc: Ted Lemon; [EMAIL PROTECTED] > Subject: Re: [Int-area] EAP and DHCP end-points > > > > 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). The situation that originally started this discussion was the case for a DHCP exchange in which large packets must be sent before the client actually gets an IPv4 address. Then, if you have multiple such clients all using the same (all-0's) source address and their fragmented datagrams end up in the server's reassembly buffer at the same time, you can have reassembly misassociations. > > 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. The NAT comment was not meant to include DHCP; it was meant to be specific to "other" UDP applications. > > 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? I have no comment on this for the moment. But, to bring some closure to the issue at hand, can we agree that there is *no* fragmentation issue for the DHCP-AUTH proposal and no extra mechanism (such as draft-templin) needed? Thanks - Fred [EMAIL PROTECTED] > 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 > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
