On Thu, 30 Jul 2009 21:25:29 +0200, Lars Eggert <[email protected]> wrote: > On 2009-7-29, at 14:02, Dino Farinacci wrote: >> From a practical perspective, we prefer that a LISP encapsulator (ITR >> and PTR) not incurred additional work when encapsulating packets. > > could you share some data on how much of a performance impact we're > talking about here? I was under the (maybe naive) impression that > checksum offloading was practically ubiquitous these days.
On high-end hardware, I guess it is indeed. >> The main LISP spec indicates: >> >> (1) The UDP checksum in the outer header MUST be set to 0 by an >> encapsulator. >> (2) The decapsulator MUST ignore the UDP checksum. >> >> We stand by this text and see no reason to change it. > > This is in direct conflict with what RFC2460 says, and I'd personally > would find it problematic to approve publication of an Experimental > protocol that did this, unless there was an IETF consensus on a > standards-track document that would update RFC2460 accordingly. Such a > document would IMO need to show extremely strong arguments for why > this change is needed. Updating RFC2460 is also in direct conflict > with the message that the IETF has been trying to send, namely, that > IPv6 is stable and done. Is this really worth it? Yep. Sounds like this would require a third datagram protocol number, that is basically UDP except the checksum would only covering the IPv6 and transport header. Hmmph, this is just like UDP-Lite really but it seems like there is opposition to overloading UDP-Lite. Then the 64-translators would convert it to normal UDP/IPv4... ? -- Rémi Denis-Courmont -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
