Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:[email protected]] > Sent: Thursday, August 06, 2009 9:15 AM > To: Templin, Fred L > Cc: [email protected]; [email protected] > Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] > > > 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.
How are non-TCP/UDP flows handled by these legacy systems today? For example, 6to4 uses ip-proto-41. Thanks - Fred [email protected] > - 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 > > [email protected] > > > > _______________________________________________ > 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 --------------------------------------------------------------------
