On Mar 30, 2011, at 2:23 PM, "Justin Dean" <[email protected]> wrote:
> "Deprecating the use of the IPv4 ID field for non-reassembly uses > should have little - if any - impact." > > That statement wasn't true for very long was it... Technically even if your devices rely on it it wouldn't be long before they started dropping valid packets, IMO. > Well section 9 may provide a way out. > > "Network address translators (NATs) and address/port translators > (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4 > encapsulation) copy and modify some IPv4 fields, so all are > considered sources, as do any devices that rewrite any portion of the > source address, destination address, protocol, and ID tuple for non- > atomic datagrams [RFC3022]. As a result, they are subject to all the > requirements of any source, as has been noted." > > With the current draft incoming packets can have their id fields modified by > the SMF gateway before being forwarded in the MANET. I would say this makes > the gateway a source. Then we just need to fragment everything! I can see > the reason for banning the behavior in high bandwidth wired links where > duplicates only occur with routing loops and the id wraps so fast it is > useless. But the way this is written it bans ALL use of the IPv4 ID field > for duplicate detection. > > "The IPv4 ID field is no longer permitted for duplicate detection." > > Does this mean we can't even hash this field for duplicate detection?! The field and the other parts of the header are not ensured unique for fragments right now - many hosts break the rules. A packet as a whole isn't either. It is much safer to expect the higher layers to drop such duplicates. You can drop but you need more requirements - e.g., that the higher layer won't send valid dups (TCP seqnos accomplish this), and you check/hash the whole packet. The header *isn't* enough right now, unless you ensure rate limiting. Joe > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Teco Boot >> Sent: Wednesday, March 30, 2011 7:29 AM >> To: [email protected]; MANET IETF >> Subject: [manet] SMF and intarea-ipv4-id-update >> >> Sorry for x-posting. But there is a conflict in: >> http://tools.ietf.org/html/draft-ietf-manet-smf >> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update >> >> SMF has a duplicate packet detection function based on the IPv4 >> ID field. So text in ietf-intarea-ipv4-id-update section 4 >> is not correct, in that there would be no deployments for such. >> That said, SMF deployment with IPv4 DPD on IP-ID would be limited. >> >> What to do? >> >> Teco >> >> >> >> >> _______________________________________________ >> manet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
