> >> Also, when a UDP-checksum-elided packet traverses the backbone, it will >> be sent back into the lowpan without the elision optimization. Big >> deal, I'd say; not the case we are optimizing for. >> Think "outsourcing the checksum computation to the ER". > >I don't have a problem with that form of outsourcing as long as L2 has >checksum/CRC that is applied between the ER and 6lowpan host that is at >least as strong as the UDP checksum. [Pascal] The stronger CRC we are talking about is in fact end-to-end so it encompasses the compressed segment. The Edge router can not know whether that happens, it can only trust that the source node behaved, and compressed the checksum only if it was entitled to per our spec.
>That would be a reasonable layer violation, since L3 can check the L2 >capabilities (implicitly or explicitly.) [Pascal] We can not be relying on the L2 MIC in mesh-under because the L2 information that the ER sees covers only the last hop. > >But the case at hand is where L3 needs to depend on L7 capabilities, and >furthermore the ER doesn't have an exact way to determine whether the >application has those capabilies; ithe ERt needs to employ some >heuristic guesswork. [Pascal] It is the source node responsibility to elide the checksum. The ER does not guess; it has to trust that the source node complies to this spec and is entitled to perform the compression. - For a packet sourced in a node in the LoWPAN, the ER recomputes a compressed checksum as part of the UDP expansion in the input (6LoWPAN) interface, and then passes the packet to L3. - For a packet coming from outside, the ER can not compress. Some manual config or hint in the packet might enable that but it's out of scope for this doc. > >> Yes, in a greenfield world. >> The problem is that the correspondent nodes are random legacy PCs and >> such stuff. >> How do you handle "UDP with a MIC" in Windows 3.1? >> (Yes, that is a rhetorical question, since 3.1 did not have IPv6.) > >Don't all the OSes on the legacy nodes on the backbone or that will run >as gateways have support for raw sockets? [Pascal] 6LoWPAN compression/expansion happens in a shim layer between L2 and L3. When sending a packet, Upper layers have to pass hints down the stack to enable it, like an IOCTL. That will be highly implementation dependant, but quite easy in a sensor stack that is very light and mission-optimized. OSes in Hosts in the backbome do not see a thing since all the magic happens above UDP. Gateways terminate the transport layer so they have to support 6LoWPAN interface like any node in the LoWPAN. Gateways might or might not shortcut the UDP checksum operation in presence of a MIC, depending on how easy it is in the code base they are using. A 'clean' implementation would have to compute the checksum in the shim for UDP above to verify it. If the NULL checksum was allowed in IPv6 it would certainly be used there. > >> PS.: I'm not saying the whole ordeal is worth it. I'm just saying it >> can be made to work. > >Your definition of "work" might be different than mine ;-) >It doesn't look robust when it is based on heuristics of this form. [Pascal] I can not see the need for heuristics. This mechanism has been discussed at length in this group and at ISA. For all I know it works but it's fair to shake it and review the associated text to make sure it's very crisp on when the checksum can be elided. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
