Hi Fred,
There are three things we are trying to address here:
- We want to support load balancing through legacy systems that only
support load balancing based on the 5-tuple of IP src/dest address,
protocol/next header and UDP or TCP src/dest ports. To meet this goal,
we need a UDP (or TCP) header, so that we can prevent all LISP packets
between a single ITR/ETR pair from being seen as a single flow.
- But, we don't want to pay the cost of checksumming the entire UDP
payload (including the LISP header and the encapsulated packet). To
avoid this, the current proposal states that we will use UDP with zero
checksums.
- However, we are concerned about using UDP with zero checksums in
IPv6, because there would be no checksum protection for the IPv6
header fields (src/dest port and next header). These fields are
protected by the IP header checksum in IPv4. Some people are also
concerned about making sure that LISP is compatible with other IETF
RFCs, which currently say that there won't be zero UDP checksums in
IPv6.
So, we need to figure out what to do. Once we have all of the facts
on the table, we'll probably have to make a hard decision and
compromise on some of the above goals.
It seems to me that our proposal to move to a different LISP header
format is a non-starter, because it doesn't address any of these
issues/tradeoffs.
Margaret
On Aug 6, 2009, at 11:50 AM, Templin, Fred L wrote:
I told myself I would stay out of this, but I can't help
but point out that if the SEAL-FS header were used instead
of the UDP/LISP headers there would only be 4 bytes exposed
to corruption instead of 16. And, if one of the SEAL-FS
header fields is corrupted there is no danger of causing
unpredictable behavior.
The SEAL-FS header is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER|I| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the I bit is flipped, the end result is that the ETR
could send a spurious Information Request message which
should cause no harm whatsoever to the ITR. If the
Identification field is corrupted, the end result is that
the ETR may send a control message back to the ITR with
an unrecognized Identification - this would be dropped
silently by the ITR. If the VER field is corrupted, there
is a chance that the ETR could try to process the packet
according to a different SEAL protocol version. But, LISP
ITRs would only be expected to implement VER=0 anyway so
the packet would simply be dropped.
All this, plus a tidy 12 bytes per-packet saved over what
the existing UDP/LISP encapsulation gives.
Fred
fred.l.temp...@boeing.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
