Dear Margaret;
Thank you for this long list of issues/questions. They
will be addressed.
Regards
Marshall
On Aug 4, 2009, at 3:37 PM, 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
--------------------------------------------------------------------
