Copying [email protected] for a question.
If we changed the text in the LISP draft from "MUST" to "MAY", would
we still need to write the accompanying document to RFC 2460?
Maybe Lars can comment on this.
See below for details.
Dino
On Aug 11, 2009, at 9:47 AM, Margaret Wasserman wrote:
On Aug 11, 2009, at 12:18 PM, Noel Chiappa wrote:
There is widely deployed hardware that will calculate and insert a
valid UDP checksum in packets that are transmitted by the TCP/IP
stack
with zero UDP checksums.
That's not necessarily a problem (e.g. it wouldn't be, for LISP). If
something fast computes a checksum for one - hey, one can either
use it, if
one wishes, or ignore it, if one wishes; whatever floats one's boat.
The only problem would be if something on the receiving end then
either i)
slowed down processing by checking the checksum, even though it was
not used,
or ii) (worse) discarded packets which had a bad checksum, _even
if_ the
application didn't want the checksums (e.g. packet voice).
As written, the LISP spec says:
"UDP Checksum: this field MUST be transmitted as 0 and ignored on
receipt by the ETR. Note, even when the UDP checksum is transmitted
as 0 an intervening NAT device can recalculate the checksum and
rewrite the UDP checksum field to non-zero. For performance reasons,
the ETR MUST ignore the checksum and MUST not do a checksum
computation."
This wording would make a LISP ITR that does send a non-zero
checksum non-compliant, and an ETR that checks non-zero checksums
non-compliant.
Your paragraph above would be more reasonably translated as "UDP
Checksum: this field MAY be transmitted as 0, and MAY be ignored on
receipt by the ETR". So, what you are saying above does not seem to
agree with the current LISP specification.
If we changed the MUSTs in the spec to MAYs, one could implement a
compliant (although perhaps not highly performing) LISP ITR or ETR
on a standard TCP/IP stack, even if I couldn't stop it from
computing outbound UDP checksums or checking inbound ones. IMO,
this would be substantial improvement.
However, the "MAY" wording still wouldn't be compliant with RFC 1122
(Requirements for Internet Hosts) or RFC 2460 (IPv6).
RFC 1122 requires that all TCP/IP stacks support UDP checksums in
both direction, and that they check all non-zero checksums on
receipt. So, to say "the ETR MUST ignore the checksum" (or even
"the ETR MAY ignore the checksum") in an IETF document, we would
need to get a standards track document approved that updates _both_
RFC 1122 and RFC 2460.
If we want to boil this down to the (relatively simpler and more
tractable) question of getting a document approved that allows zero
UDP checksums in IPv6, we could change this wording to say:
"UDP Checksums: this field MAY be transmitted as 0 [normative
reference to document that makes this okay in IPv6]. Note, even
when the UDP checksum is transmitted as 0, an intervening NAT device
can recalculate the checksum and rewrite the UDP checksum field to
non-zero. To address this concern, LISP ITRs SHOULD be capable of
calculating UDP checksums on encapsulated packets." Alternatively,
you could state that LISP won't work through NAT boxes with this
property, perhaps in a middlebox considerations section.
If you want LISP to actually _be_ RFC compliant, and not to
potentially lag behind standards-track RFC updates, you could simply
indicate that this field contains a valid UDP checksum value (MAY be
zero for IPv4, MUST NOT be zero for IPv6). Since there are checksum
offload chips that can calculate a UDP checksum very quickly, it
should be possible to build LISP hardware that does calculate UDP
checksums at the necessary level of performance.
This last choice, which I will summarize as "be RFC 1122 and 2460
compliant", would include checksum protection for the IPv6 header
_AND_ would support LAG/ECMP, at the cost of requiring that LISP
systems (which are the new thing we are building) be capable of
calculating checksums. I think this may be the best trade-off
available, although I understand that it isn't cost-free.
Margaret
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
