Subject: Re: [lisp] Suggested UDP checksum text

From: [email-masked] (Noel Chiappa)
Date: Sat, 12 Sep 2009 17:09:08 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > I also personally prefer a "SHOULD" for IPv6 ETRs to accept incoming
    > packets with a zero checksum (to support implementation on existing
    > desktop systems)

The problem which that would cause is that we would likely have pair-wise
black holes. If such an ETR is interacting with an ITR which is sending
packets with zero UDPv6 checksums (which under the current text it 'MAY'
do), all the traffic will be tossed. (And my apologies if that was already
perfectl clear to you, and I've misunderstood your point here.)

We could get rid of the black holes by adding a status bit to the
Map-Reply message ('this ETR accepts zero UDPv6 checksums'), and changing
the spec (and code) to say that ITRs which wish to send packets to that
ETR have to compute UDPv6 checkums unless that bit is set.

Even then, though, we could still find that there are pairs of xTRs which
cannot communicate, if there are some ITRs which cannot easily compute UDP
checkums. I am given to understand by a message here (too lazy to look for
it in the archives) that some router boxes only have access to headers,
and can't checksum the packet.

We could go the other way and add a status bit to the Map-Reply message
('this ETR does not accepts zero UDPv6 checksums'), and change the spec
(and code) to say that ITRs either i) have to compute UDPv6 checkums iff
that bit is set, or ii) not use such ETRs. Again, that would fix the black
holes, but ETRs which cannot accept zero checksums would almost certainly
be unable to communicate with some ITRs.

But if we don't add that complexity, we either have to have 'MUST accept
zero checksums', or we have to delete 'MAY send zero checksums' - or black
holes will result.

    > but I understand that others' opinions differ.

I want to make sure I understand what this means (in terms of
implications). Is this to be read as 'you aren't happy with the
existing text, but can live with it', or did you want to do something
else?

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Sep 2009 08:46:15 -0400

Hi Noel,

Most of your message boils down to something I think we both know...

If we want to write an interoperable specification that includes  
multiple options that are not interoperable, we have two choices:

(1) State that it is mandatory to support one of the choices on both  
ends, and signal/negotiate the use of any of the other options.
(2) Require all implementations of one end of the connection (in our  
case either the ITR or the ETR) to support all of the options.

At this point, the LISP specification achieves interoperability for  
IPv6/UDP checksums by requiring ETRs to accept IPv6/UDP/LISP packets  
with both zero or non-zero checksums.  So, the text in the LISP -04  
specification is theoretically sound.

With the text we have in -04, though, we will still have a _practical_  
problem with black holes.  There are many currently deployed systems  
that are _not capable_ of accepting a packet with an IPv6/UDP checksum  
of zero, and they will not gain the ability to do so simply because  
the LISP specification says that ETRs MUST accept them.  This is _not_  
a performance issue.  LISP simply _will not work_ over IPv6 on those  
systems.  The list includes all deployed copies of every major  
operating system, all currently deployed IPv6-capable CPE equipment,  
and the checksum offload hardware in all recently-shipped Macs and  
many (perhaps most) recently-shipped PCs.  Getting these things  
upgraded to accept IPv6/UDP zero checksums would take at least 7-to-10  
years, and the clock _won't even start_ until LISP becomes popular  
enough to affect the implementation of host operating systems and  
network interface cards  So, with luck, we will be able to implement a  
compliant IPv6-capable LISP ETR on most end nodes (to support things  
like mobile LISP) in the early 2020's.

We are making this choice to allow an _optimization_ on some existing  
high-end routers that _can and do_ (or at least claim to) support the  
calculation of UDP checksums on both ends when UDP checksums are  
enabled for other UDP-based tunneling protocols, such as L2TP.

The only interoperable choice (if we must use UDP) that is _actually  
available_ on all of these systems is to require both ITRs and ETRs to  
handle packets with non-zero IPv6/UDP checksums, and for ITRs to only  
send IPv6/UDP zero checksums when there is an indication from the  
other side that they are supported.

For some reason, though, the WG seems to be choosing an optimization  
for high-end routers over the ability to implement LISP on widely  
deployed host systems.  I think that is a _huge_ mistake, and an  
incorrect technical choice for an IETF specification.

> existing text, but can live with it', or did you want to do something

I am not satisfied with the current text, for the reasons I have  
stated above.  I do not think that I am ever going to convince a lot  
of folks from a large router vendor to change their minds about this,  
though...  So, I will accept that I am in the rough, and we can move on.

Margaret