I must be slow this morning.
I am not sure which of two possible (similar) problems this checksum is
supposed to help.
1) Due to in-network corruption, the LISP packet arrives at some
non-LISP entity which has something listening at whatever UDP port the
packet now ha as a destination. Clearly, a checksum in the LISP header
won't help, since the receiver won't know there is a LISP header.
2) Due to in-network corruption, the LSP packet arrives at the wrok LISP
receiver. He understands it is LISP, and does not realize it was not
for him. So what? He decapsulates, looks at the contents, and says "I
can't do anything with that." The LISP spec already tells us what it
will do, and there is no problem. If LISP were not using UDP, we would
still have this "risk". I, at least, don't see this as a problem to be
solved.
2') There is some discussion of using the IPv 6 flow label instead of
the UDP header for ECMP effects. If we do that, I can not see why we
would suddenly decide that LISP itself needed a checksum.
Yours,
Joel
Margaret Wasserman wrote:
Hi Joel,
I think I understand both sides of the UDP checksum issue now...
We (or at least some of us) believe that it is a hard requirement to
support ECMP through legacy routing equipment. This equipment will only
identify flows using the 5-tuple described in the draft. These devices
do not know about UDP-Lite, and they couldn't usefully load balance LISP
traffic that was tunneled IP-in-IP, because there would be no source
port to use as a hash value for identification of the original flow.
We (or at least some of us) are concerned about using UDP zero checksums
in IPv6, because of possible problems caused by corruption of the
source/destination IP addresses or the next header field. These fields
are protected in IPv4, even when UDP checksums are disabled.
I have an idea that might work to satisfy both sets of concerns...
What about putting a checksum field in the LISP header? We could
checksum across the IP pseudo-header (at least for IPv6), and the LISP
header. LISP nodes that receive these packets could check the checksum
and discard packets that have been corrupted. In addition to resolving
the concerns about corruption in the IPv6 header fields, this checksum
would protect the LISP header, which contains some one-bit fields and a
nonce that would be sensitive to corruption. We could also specify that
LISP nodes that receive an ICMP error should check this checksum in the
returned packet before acting on the error.
We would still have to make sure that we understand the impacts of
non-LISP nodes receiving corrupted LISP packets (which will probably be
that the packet is dropped, which is fine), but we wouldn't have to
worry about what happens when a LISP packet arrives at the wrong LISP
node and/or when a response is sent back to the wrong LISP node.
Thoughts?
Margaret
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so that
different flows would be different in a place that the routers would
look when doing ECMP calculations.
And the router to date do not use the flow label.
Preliminary indications are that routers also won't use UDP-lite,
because it is a different protocol, and they don't know it has port
numbers.
The simple path forward is to allow UDP with 0 checksum.
If that is incorrect, then finding the correct path forward is going
to be hard.
Joel
Brian E Carpenter wrote:
Hi Joel,
On 2009-08-05 03:08, Joel M. Halpern wrote:
It has become clear with the passage of time that the description of
the
flow label in the original IPv6 specs served only to convince everyone
not to use that field for anything. Even now, no one is sure what
to do
with it.
If you're referring to the lame appendix to RFC2460, that's exactly
why we wrote RFC3697. My understanding is that some stacks do set the
flow label according to the SHOULD in RFC3697, but I'm not aware
of any deployed use cases (such as load balancing routers). The gap
is not in the basic specs but in exploitation. It's very similar to
what happened with the IPv4 TOS byte, and that took 20 years before
we (a) defined it properly and (b) began to see limited deployment,
as corporate VoIP took off.
My expectation has always been that exploitation of the flow label
would stay on the back burner until IPv6 deployment reached a
significant level, because there isn't much benefit in optimising
flow handling for <1% of the traffic. So I don't really see anything
odd in the current situation.
That said, I can't see any reason why ITRs and ETRs can't use
the flow label among themselves, in a way completely compatible
with RFC3697. But if their hardware engines can't include the
flow label in the n-tuple, that's a problem.
Brian
_______________________________________________
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
