Subject: [lisp] #6: LISP ITRs using value of 0 for UDP Checksum in IPv6 LISP outer header

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 20 Aug 2009 13:13:49 -0000

#6: LISP ITRs using value of 0 for  UDP Checksum in IPv6 LISP outer header
-------------------------------+--------------------------------------------
Reporter:  [email-masked]  |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:  Checksum LISP  
-------------------------------+--------------------------------------------
 Discussion on the list focused on whether the IPv6 UDP checksum
 could be sent/received as zero, and what the potential costs and
 benefits of this change would be. There was also a discussion of
 which RFCs would need to be updated if the LISP WG decided the
 IPv6 zero UDP checksum issue in favor of being able to
 transmit/receive a zero UDP checksum.

 Background:

 The LISP Draft authors chose to use UDP encapsulation and further to
 specify setting the checksum of these packets to 0 for several reasons.

 1) The LISP authors received feedback very early (during the RRG meetings)
 that having LISP encapsulated flows be hashable by existing Link
 Aggregation hardware was critical.  Which, in the hardware existing in
 large ISP networks, limits LISP to using either UDP or TCP protocols for
 IPv4 and IPv6.  (ref msgs: Chris Morrow, Vince Fuller, and Shane Amante
 Joel Halpern)

 2) The LISP authors feel that having to calculate the pseudo header
 checksum on encapsulation will impose an unreasonable burden on high speed
 (non commodity) encapsulation hardware.  This then requires LISP to allow
 for encapsulating with 0 checksum datagrams in IPv4 and IPv6. (ref msg:
 Dino Farinacci, vince fuller, Joel Halpern).

 These requirements taken together prevent LISP from using other
 encapsulation types, which were suggested during the thread, including
 UDP-Lite, IP-IP (say GRE) encapsulation, etc.

 Some input from participants on thread on the WG list are included below,
 since they help summarize the outstanding issues and the impacts of this
 decision.

 -------------------

 Margaret Wasserman contributed the following analysis:
 (text edited to focus on encapsulation issue)

 #1:  Sending UDP Zero Checksums Violates RFC 2460

 The use of zero UDP checksums in IPv6 is forbidden by RFC 2460.  This
 issue could be addressed in one of two ways:  (1) move to any
 standards-compliant encapsulation, or (2) include a normative
 reference to a standards-track document that updates RFC 2460 to allow UDP
 zero checksums.

 #2: Sending UDP Zero Checksums not Universally Implemented

 Current TCP/IP stacks do not always implement the ability to turn off UDP
 checksum calculation for outbound traffic.  In some cases, this could be
 corrected by a software change.  In other cases, the checksum may be
 calculated in hardware.  It may not be possible to turn off UDP checksum
 calculation for outbound LISP traffic, without turning off  UDP checksum
 calculation for all outbound traffic.  This issue could  be resolved by
 changing the text that indicates that LISP ITRs "MUST"  send zero UDP
 checksums to a "MAY".

 #3: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis

 Research (the Stone/Partridge paper) and prior experience (with NFS and
 IS-IS, among others) have indicated that it is (at least
 sometimes) a very bad idea to disable and/or bypass UDP or IP
 checksums.  References:

 Stone/Partridge Paper on Internet Checksums:
 http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm
 IS-IS Optional Checksum:  http://www.rfc-editor.org/rfc/rfc3358.txt

 We have proposed disabling the IPv4 UDP checksum and effectively
 disabling both the IPv6 header and UDP checksum in IPv6.  As part of
 making this decision in a responsible manner, we need to perform (and
 document) an analysis of the implications of that choice, both on LISP
 itself and on other nodes and applications that have to co-exist with
 LISP.

 #4:  LAG/ECMP Requirements Not Well-Explained

 The LAC/ECMP requirements that drive some LISP design choices are not
 well-explained in the draft.  This issue was raised by Sam Hartman, and
 Dino agreed to add additional text.

 ------------------

 Sam Hartman Contributed the following summary of general requirements for
 LISP encapsulation:

 Requirements participants have stated include:

  * Works with LAGs/ECMP
  * Implementable in router hardware
  * Implementable on stock TCP/IP stacks
  * Implementable using server/desktop NICs with checksum offload
  * Can be easily deployed
  * Works through firewalls and NATs

 We have not yet judged formally whether some or all of these requirements
 are important to the WG as a whole.  We may b e able to move forward
 without that although refocusing on the requirements is certainly a tool
 that is available to us.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/6>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues