Hi Carsten:
I including your input and reshuffled a bit.
Here's the updated proposal for -04:
3.2.2. Compressing UDP checksum
The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
packets. For that reason [RFC4944] disallows the compression of the
UDP checksum.
With this specification, a compressor in the source transport
endpoint MAY elide the UDP checksum if it authorized by the Upper
Layer. The compressor SHOULD NOT set the C bit unless it has
received such authorization. The Upper Layer SHOULD only provide the
authorization in the following cases:
Tunneling: In this case, 6LowPAN is deployed as a wireless pseudo-
fieldbus by tunneling existing field protocols over UDP. If the
tunneled PDU possesses its own addressing, security and integrity
check, the tunneling mechanism MAY authorize to elide the UDP
checksum in order to save on the encapsulation overhead.
Upper Layer Message Integrity Check: In this case, there is some
other form of integrity check in the UDP payload that covers at
least the same information as the UDP checksum (pseudo-header,
data) and has at least the same strength.
A forwarding node MAY imply authorization from the incoming packet
being forwarded if the C bit was set there. The forwarding node that
can not derive the authorization in an non-ambiguous fashion SHOULD
NOT elide the UDP checksum when performing 6LoWPAN compression. The
forwarding node that expands a 6LoWPAN packets with the C bit on MUST
compute the UDP checksum on behalf of the source node and place that
checksum in the restored UDP header as specified in the incumbent
standards [RFC0768], [RFC2460].
If a 6LoWPAN termination is also the transport endpoint, and it
receives a compressed packet that has the C bit set, then it is
entitled to ignore the UDP checksum process completely. If the C bit
is not set, the packet might have been forwarded by an edge router,
so this is not an indication that the MIC is not present. If the
terminating node knows that the message integrity will be validated
by the upper layer by some state associated to the Service Access
Point, it is entitled to ignore the checksum operation as if the C
bit was set.
What do you think?
Pascal
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Pascal Thubert
>(pthubert)
>Sent: jeudi 20 novembre 2008 11:46
>To: 6lowpan
>Subject: [6lowpan] Proposed new text for the UDP checksum elide issue
>
>Hi:
>
>Carsten asked for a crisper wording for which node can elide the UDP
>checksum and when that happens. There seems to be a consensus that
>we are not ready to open the door for heuristics based operations.
>
>So at this point, only the source of a packet MAY elide the checksum,
>And the receiver of a packet MAY ignore the checksum if it is present.
>This in only allowed in the case of tunneling or stronger integrity
>check above UDP.
>
>Here is a proposed text:
>
>"
> With this specification, the source of a packet MAY elide the UDP
> checksum in the following cases:
>
> Tunneling: The source of the packet is tunneling another packet
that
> possesses its own integrity mechanism.
> Upper Layer MIC: The Upper Layer Protocol over UDP uses an end-to-
> end Message Integrity Check (MIC) that has stronger properties
> than what is provided by the UDP checksum. Such an integrity
> check MUST be end-to-end and cover the IPv6 pseudo-header, UDP
> header, and UDP payload.
>
> Only the source of a packet can know what Upper Layer operation
takes
> place. A router on the way that is not aware of such operation
> SHOULD NOT elide the UDP checksum when performing 6LoWPAN
> compression.
>
> The 6LoWPAN termination point has to recompute the elided checksum
> based on the received packet. If that point is a router, then the
> router reforms a proper IPv6/UDP packet that can be forwarded on any
> interface. If the 6LoWPAN termination point is the destination of
> the packet and is aware of the presence of the Upper Layer MIC for
> the destination UDP port, it MAY omit the UDP checksum operation
> completely.
>"
>
>What do you think?
>
>Pascal
>
>
>_______________________________________________
>6lowpan mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
