Hi Shoishi: I agree with you that the expanded packet is UDP. Whatever is inside that UDP packet is not IETF concern long as the UDP guidelines (http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines) from transport area are followed by the upper layer.
So again (and again): - The draft is not talking about a zero checksum: there appeared to be some confusion with the discussions around UDP tunnels in CAPWAP, AMT or LISP. Here, once the packet is expanded it is a valid UDP packet with a correct checksum. Routers on the way can verify that checksum if they care. The receiver receives a UDP packet with a proper UDP header and has to verify that checksum. What happens next is beyond UDP. - The draft not talking about hop-by-hop Message Integrity Check within the LoWPAN: Geoff introduced some confusion yesterday. - The draft is not loosing end to end integrity: the checksum can be elided ONLY IF there is an end-to-end integrity mechanism above UDP that is better than UDP checksum, covers everything that the UDP checksum covers (including the UDP pseudo header) etc... Yes we are talking about an improved UDP, but it inherits all the UDP properties so it is still UDP. But it is critical that the HC2 defined in the draft expands into a NH of UDP (17) even when the checksum is elided: - UDP is ULP agnostic: 6LoWPAN constrains the range of ports (F0Bx) so it implies that a port number will be overloaded depending on the deployments. Considering this, it makes a lot of sense that some magic happens at the ULP to make sure that the message being received is expected, IOW it makes a lot of sense to have an additional MIC that not only verifies the integraty but also authenticate the data. - UDP is well understood by now: with UDP, come the UDP guidelines and all the litterature. - UDP is a good fit for smart objects: It is lightweight and enables applications to save battery in constrained devices by piggy-backing acks and payload. - what would it expand to anyway? Defining an adhoc (6LoWPAN?) transport protocol, we'd loose UDP handling in the Internet. NATs (yes they are still there). Firewalls. Not defining it, we'd force other parties that would implement 6LowPAN with checksum compression to invent their own stuff. That's exactly the opposite of our mission, not only as 6LowPAN but as IETF. My take is to stick to what the draft does. We can improve the wording but changing the bottom-line would hurt terribly the applicability of this work. Pascal >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shoichi Sakane >Sent: mardi 18 novembre 2008 19:47 >To: 6lowpan >Subject: [6lowpan] UDP checksum elide > >Hi, > >In today's meeting, we didn't make a consensus to have the UDP checksum >elide bit in the HC. I think that it is something like UDP-NAT. >The 6lowpan adaptation layer is responsible to realize it. >In my understanding, the UDP stack of both end devices should calculate >the checksum, and the 6lowpan layer elides or recalculate the checksum. >I believe it is UDP still. >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
