I'd be very concerned if the IETF consensus was to introduce a change to
the UDP checksum without fully evaluating the implications for the
network and before considering the procedures by which new protocols
could access a zero-checksum mode.
As I understand, the proposal to update RFC 2460 is NOT just concerning
LISP routers, there would be host uses, at least for AMT, and likely
future other applications too, their would be implications on
middleboxes and possibly on existing applications.
I think the list below is a good summary of key issues. I'd like to use
this as the basis for a summary of the tradeoffs. I am aware there's
been quite a lot of discussion on the list while I was on vacation (both
before and after this email), and also some more quite some months ago
elsewhere. I'm going to try to compile what I understand under these
headings... and get back soon.
Gorry
Margaret Wasserman wrote:
On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
We intend to rev this shortly and comments would be appreciated.
If you do rev this document, I would like to see:
(1) An explanation of the difference in applicability between this
mechanism
and UDP-Lite.
(2) A specific applicability statement for when this mechanism can (and
can't)
be used. Would we be allowing this mechanism _only_ for cases where
IP is tunneled inside UDP/IP? What about the AMT case?
(3) A section listing considerations that must be documented for protocols
that use this mechanism, including:
(3a) What happens when the destination IP address is corrupted in
transit?
(Note: This isn't a concern in IPv4, as the IP header
checksum will result
in this packet being discarded by the receiving IP stack).
(3a.i) What if a node that does not implement this protocol
receives the
packet?
(3a.ii) What if a node that does implement this protocol
receives a packet
destined for another node?
(3b) What happens when the source IP address is corrupted in transit?
(Note: This isn't a concern in IPv4, as the IP header
checksum will result
in this packet being discarded by the receiving IP stack).
(3b.i) What happens when a node that does not implement this protocol
receives the ICMP "port unreachable" error?
(3b.ii) What happens when a node that does implement this protocol
receives an ICMP "port unreachable" error for a
packet it didn't send?
(3c) What happens if one or both of the UDP ports are corrupted in
transit?
(Note: This can happen in IPv4 in the zero checksum case,
too, but not
with UDP checksums turned on and/or UDP-Lite).
(3d) What types of middleboxes does the protocol need to cross
(routers,
NAT boxes, firewalls, etc.), and how will those middleboxes
deal with
these packet
I don't really have enough knowledge to answer these questions for LISP. I
tried to go down this path in an earlier message, and Dino didn't
understand what
I was saying, but I'll try to do it once again. Please correct me if I
am missing
something.
I am making the assumption that (unlike AMT), all LISP packets will be
sent to
a specific UDP port assigned to LISP. Also, I am making the assumption
that
if we write this document, some other protocols (besides LISP) will make
use of
it, so some IP stacks on non-LISP nodes will process these packets.
(3a.i) If a node that doesn't implement LISP receives this packet, it
may be
passed up to UDP (if zero checksums are supported). At that
point,
though, it will be thrown away because there is no process
listening
on the LISP port and an ICMPv6 "port unreachable" error will be
generated. (This is different than the IPv4 case, where the
packet
will never make it to UDP).
(3a.ii) If a node that does implement LISP receives this packet, it will be
sent to the LISP process, which will recognize that it is an
encapsulated LISP packet. What then? (Note: Again, this
wouldn't happen in IPv4, as the packet would be discarded by
the receiving IP stack.).
(3b.i) If a node that doesn't implement LISP receives an ICMP port
unreachable for the LISP port, it may have a process that is
using the local port from the original LISP packet. Will that
process receive the destination unreachable? Or will the
message be thrown away because the destination port doesn't
match? I think this might depend on how the process was
bound to its socket, or something. Can someone help me
out here? (Note: This won't happen in IPv4, because the
packet would have been discarded by IP, not by UDP).
(3b.ii) If a node that does implement LISP receives an ICMP port
unreachable, it still might not have a process that is using
the corresponding source port (right?). In that case, I think
that this is the same as 3b.i... Would another process
receive this error? And, if so, how would it respond?
(3c) If the ports were corrupted in transit, we might get packets
delivered to the wrong process (on the right machine)
and/or responses or errors sent to the wrong process (on
the right machine). I think this all would have been covered
by the above cases.
(3d) I don't know how middleboxes will deal with this... What
do IPv6 routers do today with zero-checksum UDP packets?
What other IPv6 middleboxes exist today, and what would
they do?
Personally, I think this is something we would need to understand
pretty fully before we could decide that turning off IPv6 UDP checksums
is a superior choice to using IP-in-IPv6 encapsulation (no UDP),
IP-in-IPv6/UDP-Lite encapsulation or UDP with checksums.
These are also areas that we should explore in a general sense before
we decide to publish Marshall's document as an alternative to using
IP-in-IPv6 encapsulation, UDP-Lite, or UDP with checksums.
Margaret
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------