Hi, Fred, Templin, Fred L wrote: > 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.
Understood. The fundamental problem here is sourcing packets with addresses the host doesn't own. While I appreciate this was an easy way to solve the problem, it violates 791, which means almost all bets on the rest of how IP works (or doesn't) are off. It's also legal for hosts to drop duplicate IP packets, which means that if you happen to try to send a packet with the same ID as someone else, it might not get through even if it wasn't fragmented. IMO, the best solution is to assume collision with backoff, i.e., try to send a packet with a random ID, and if you get no response, try again. A small number of tries ought to be reasonably successful, statistically, even if some individual tries get corrupted. That would allow you to still use fragmentation, FWIW. >>> 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. Well, NATs that don't pass fragmented packets are going to cause problems with those apps anyway. >>> 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? I agree there is no extra mechanism. IMO, it's OK to use large IP packets and allow IP fragmentation. The solution, IMO, is to have the app treat the message as "lossy" - perhaps moreso than usual, i.e. - and retry with other IDs if one fails. I don't see a need for fragmenting at the app layer to address this issue. Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
