Subject: [lisp] #9, #10, #11: UDP checksum consensus call

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Sep 2009 19:42:35 -0400

One line answer: Friday diff with an additional note

Folks, we've spent a lot of bits discussing UDP checksums.  I think
we're going in circles at this point and are not significantly
covering new ground.

remember that what we were trying to do was to describe what LISP
would do well enough that we could put this issue aside until 6man and
the rest of the IETF decided for the IETF as a whole.  Obviously,
we'll go along with whatever IETF consensus emerges.  So, we don't
need to get this perfect.  It's not actually clear we needed to say
anything at all, although I believe a lot of us see value in telling
implementations what is going on today.

I don't think there is more value in discussing the referenced UDP
issues (and see a separate note on #12 I'll send)

So, to remind ourselves, especially for the tracker:

 * We get significant benefit from using UDP or TCP because  it makes  working with existing ECMP/LAG boxes possible.
 * For IPv6 the current specs do not allow sending 0 UDP checksum; we believe that there are significant hardware  implementations that cannot calculate UDP checksums without forcing the checksum calculation to software.  That's a non-starter for some of the deployment environments that these vendors want to use their hardware implementation in because the load would be higher than what could be handled in software.
 * We believe there are implementations that would be difficult to change  to send 0 checksums
    ** Several commodity operating systems  have removed the configuration parameter to send 0 checksums; where it exists, it tends to be per-system and not per socket/flow.  
    ** Existing commodity IP stacks definitely don't send 0 checksums for IPv6.
    ** One implementor and several individuals have indicated that is desirable to be able to implement on commodity IP stacks.
 *  We don't actually need to require that you send 0 checksums; there is debate about whether you should do so when you can.
 * For hardware implementations that cannot reasonably send UDP checksums to be able to turn them off, all receivers must be able to receive 0 checksums.
 * There are implementations of IP and UDP that would be very difficult to change in order to accept 0 checksums for UDP for IPv6.  There are hardware, software and politics issues, depending on the implementation
* Based on the discussion I think it likely that we will not achieve universal interoperability for lisp over IPv6 if 0 checksums are sent.  It's unclear how big of a problem this will be in practice.

Alternatives proposed:
 * Give up on the LAG/ECMP requirement.
    ** It's not clear how soon we need LAG/ECMP for V6; some have said today, but other WG participants questions this.
    ** It seems that it might be a full hardware cycle (7 years? 10 years?) before you could depend on different LAG behavior.
 * Use multiple source addresses--twiddle the V6 IID in order to work with ECMP/LAG and use something other than UDP
    ** The chairs called for people to flesh out such alternatives but none were fleshed out
    ** Doing this is very tricky.  For example, the control plane needs to be adapted so that things like locator reachability work.
    ** Some participants have claimed this is impossible.  I don't think that claim has been substantiated.  However there is no version of this proposal fleshed out sufficiently to be evaluated, and we have given ample opportunity for such a proposal to be developed.

Sausage was made.  There was a lot of discussion.  In the judgment of
the chairs, the LISP working group has reached rough consensus on the
text in Dino's Friday diff.  We do not believe that additional
discussion of the same issues will yield a better result within the
LISP working group.

Someone's going to ask when it would be appropriate to re-open this
discussion.  This is my personal opinion; I have not discussed in
detail with Darrel.

 * When the IETF comes to consensus on handling UDP encapsulation for tunnels we will need to revisit this issue.  Even if what is now our preferred behavior  is permitted by IETF standards track documents, it is quite conceivable that the larger discussion will bring forward information that changes our thinking.
 * #13 discusses analysis that we need to do in order to confirm that LISP itself does not require integrity protection and that LISP will not damage other Internet hosts.  I think we should leave concerns about damaging other Internet hosts  to the rest of the IETF, at least until they tell us what the bar is.  If we find that LISP itself needs integrity protection, we could potentially revisit  this discussion, although we should probably prefer other approaches.
 * I don't think we've come to an informed consensus about the tradeoff between various classes of implementation and for example how bad it would be not to have interop with commodity IP stacks.  In particular, the WG has not become sufficiently informed about the lisp deployment model.  I think there is a presumption in the WG (one I suspect that once I understand the deployment model I'll probably support) that it's really important for LISP  to be able to run on high-end routers.  I think there is a presumption in the WG that it is less important for it to be able to run on stock IP stacks.   If the deployment discussion significantly changes our thinking, we may revisit this issue for that reason.  However I think it would have to be a significant shift for it to be worthwhile.

Jari has asked the chairs to make it clear that this is a broader
issue and that we'll align with what the. IETF does.  So, I'm asking
Dino to take his Friday text plus a sentence noting that we will align
with the IETF when it is done.  I have not wordsmithed this; I'd like
to go with this for 04, and we can revise in 05 if really needed.
However I ask you to carefully consider whether you really want to
re-open this can of worms before you propose textual changes.

   UDP Checksum:  this field SHOULD be transmitted as zero by an ITR
for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].
When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR
transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes
      will be made to align LISP with the outcome of the broader
      discussion.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Sep 2009 17:00:56 -0700

>      will be made to align LISP with the outcome of the broader

Here are the latest diffs with the above change included.

I have also removed the Mobility-bit from the spec per Jari, among  
others, who indicated that mobility stuff is out of scope for the  
working group.

Chairs, let me know when we can post -04.

Thanks!
Dino/Dave/Darrel/Vince